Subject: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 11:06:04 -0500

Hemant:

  Just a point of clarification, but as I understand CARD (and
I don't understand it well), it is not a QoS negotiation 
protocol. The main application that you are referring to primarily
arises out of a perceived need to determine at the MN the best link
layer to handover over to when inter-technology handovers are involved.
It can be applied to intra-technology handovers, but the value in
that situation is highly questionable (e.g. since it is a discovery 
protocol, the implication is that the purpose is to determine the 
choice of channels available; for intra-technology handovers, there 
are many, many reasons why this "choice" may not be available).

  There is a requirement, 5.1.2, which seems to imply NSIS involvement
during/after a handover. John has stated that this is not the intention
(please correct me if I have this wrong John), in which case I think
5.1.2 needs to be clarified. 

  Specifically, is NSIS to be used to negotiated new QoS for an 
existing flow after a handover, or is it specifically for establishing
QoS for a new flow? I don't think the answer is boolean: the role
of NSIS in QoS re-negotiation is still open, I believe, and clearly
handover is a dynamic situation that could cause the QoS provided to change.

  I have been told there is no issue, but here's a frightening scenario:

	- a handover takes place, and context transfer has been used to
       move the QoS context to the new routers (by the requirements for
       CT this could be intra-, or inter- technology. Some of us believe
       that for "seamless" handovers, the context will be available at
       routers before the first packets need to be forwarded. This implies
       that there is a relationship, probabilistic perhaps, between
       the handover process and the target ARs for CT.

     - CARD is used by the MN to influence the handover decision (it
       is not clear to me how this happens, but it seems clear that
       for a more "seamless" handover, the MN should chose an AR that 
       has received the appropriate context; if not, then what?

     - NSIS kicks in and starts re-negotiating QoS because of changes
       introduced by the handover; 

  How do these three protocols interact to produce predictable outcomes? 
Or, perhaps, the question is, how do the functional entities associated 
with the three protocols interact before, during and after a handover? 
If it the interaction is within the functional entities, the respective 
wg's could declare the issue out of scope, but this approach does not 
sit well with me, for it seems to defer the problem to the people who
have to implement this "stuff".

  Am I imagining things?

Cheers,
Gary

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: April 4, 2002 22:33
> To: [email-masked]
> Subject: RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Hi Sharif:
> 
> There is currently a debate going on in Seamoby as to whether 
> this QoS negotiation be covered by NSIS or Seamoby (CAR 
> discovery protocol). 
> 
> IMHO it should be covered by CAR discovery and not NSIS. CAR 
> discovery is supposed to identify candidate access routers 
> for handoff and QoS is an important property for candidacy. 
> 
> Br,
> Hemant
> 
> -----Original Message-----
> From: ext Shahrier, Sharif M. 
> [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 3:35 PM
> To: Shahrier, Sharif M.
> Cc: [email-masked]'
> Subject: [NSIS] Establishing QoS after handoff.
> 
> 
> 
> I have a question for clarification.
> 
> I think it was stated that NSIS should only be concerned with the
> establishment of QoS after handoff.
> 
> This is inconvienent with respect to IP-level QoS 
> negotiation, which ideally
> should be done before handoff has taken place.
> 
> QoS negotiation is in the current requirements draft.
> 
> So, NSIS signaling protocol development should be concerned 
> with activity
> before handoff occurs.
> 
> Sharif.
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 09:01:16 -0800

Hello,

well, if the issue is QoS establishment after handover,

- CT is applicable for establishing QoS state at the AR
- if further signaling is desired beyond the AR, NSIS may
    consider it. I don't see how _signaling_ for QoS establishment
    beyond AR is relevant for seamoby.

CAR _discovery_ could exchange QoS capability as one of the
parameters that might then be fed to a selection algorithm. Any
signaling for actually establishing QoS itself beyond the AR
should be outside the scope of seamoby..

Regards,

-Rajeev

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 09:01:16 -0800

Hello,

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Apr 2002 09:07:27 -0800

There is an issue if CT fails. In that case, some kind of negotiation
after handover would be required.

So, I'd say that some indication of CT failure is needed.

As for CAR, I don't see the relevance for QoS negotiation, though it may
be useful for finding a new wireless medium. I also see it primarily for
intertechnology handover, or, at best, interprovider handover.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Apr 2002 09:07:27 -0800

jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 09:19:20 -0800

Hello Jim,

> So, I'd say that some indication of CT failure is needed.

Yes, but this is between AR and MN. If CT fails, the AR should
notify the MN to engage in context re-creation.

My point was specific to signaling _beyond_ AR (i.e., upstream signaling)
independent of failure/success of CT.

Hope this is clearer..

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 09:19:20 -0800

Hello Jim,

Hope this is clearer..

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Apr 2002 09:39:12 -0800

Rajeev,

I agree, but there is still an issue of how the AR would notify the MN
if CT fails. Is this covered by CT or not?

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gary Kenward" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 05, 2002 9:19 AM
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> > > > handover is a dynamic situation that could cause the QoS
provided to
> > > > change.
> > > >         - a handover takes place, and context transfer has been
used
> > > > to
> > > >        move the QoS context to the new routers (by the
requirements
> > > > for
> > > >        that for "seamless" handovers, the context will be
available
> > at
> > > >
> > > >        routers before the first packets need to be forwarded.
This
> > > > implies
> > > > wg's could declare the issue out of scope, but this approach
does
> > not
> > > > sit well with me, for it seems to defer the problem to the
people
> > who

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Apr 2002 09:39:12 -0800

Rajeev,

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gary Kenward" <[email-masked]>;

provided to
used
requirements
available
This
does
people

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 10:02:54 -0800

> if CT fails. Is this covered by CT or not?

This notification should be covered by CT.  We should offer
seamless handover to NSIS :-) Seriously, this concerns
robustness of CT protocol.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 10:02:54 -0800

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Apr 2002 10:21:58 -0800

Agree.

But I don't see anything in the CT requirements about handling CT
failure.

???

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gary Kenward" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 05, 2002 10:02 AM
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> > > > As for CAR, I don't see the relevance for QoS negotiation,
though it
> > may
> > > > be useful for finding a new wireless medium. I also see it
primarily
> > > > > > arises out of a perceived need to determine at the MN the
best
> > link
> > > > > > layer to handover over to when inter-technology handovers
are
> > > > > > involved.
> > > > > > It can be applied to intra-technology handovers, but the
value
> > in
> > > > > > protocol, the implication is that the purpose is to
determine
> > the
> > > > > > choice of channels available; for intra-technology
handovers,
> > there
> > > > > > during/after a handover. John has stated that this is not
the
> > > > > > intention
> > > > > > (please correct me if I have this wrong John), in which case
I
> > think
> > > > > >   I have been told there is no issue, but here's a
frightening
> > > > > > scenario:
> > > > > >        CT this could be intra-, or inter- technology. Some
of us
> > > > > > believe
> > > > > >      - CARD is used by the MN to influence the handover
decision
> > (it
> > > > > >        is not clear to me how this happens, but it seems
clear
> > that
> > > > > >        for a more "seamless" handover, the MN should chose
an AR
> > > > that
> > > > > >      - NSIS kicks in and starts re-negotiating QoS because
of
> > > > changes
> > > > > >   How do these three protocols interact to produce
predictable
> > > > > > outcomes?
> > > > > > > I think it was stated that NSIS should only be concerned
with
> > the

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Apr 2002 10:21:58 -0800

Agree.

???

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gary Kenward" <[email-masked]>;

though it
primarily
best
are
value
determine
handovers,
the
I
frightening
of us
decision
clear
an AR
of
predictable
with