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

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 12:55:04 -0700

> As I outlined in one of my other posts, why would you perform CT to an
> AR that did not have the necessary capabilities. Is this actually
about
> CAR failure??

Yes and no.

Suppose the MN is expecting CT to be performed and it is not because the
new AR can't interpret the context.
The old AR may discover this via CAR, but if there is no way to
communicate it to the MN, then the MN can't know to perform the
signaling from scratch on the new AR.  One could either inform the MN
beforehand to do the signaling, as is done with FMIPv6/BETH, or signal
the MN on the new AR.

For dynamic failures, such as when the AR runs out of Gold Class
service, the signaling could only be done afterwards.

            jak

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 12:55:04 -0700

about

Yes and no.

            jak

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 15:49:16 -0400

"Re-create" was Rajeev's term, not mine. I think that it is an appropriate
term if one considers other mechanisms besides session setup signalling.
Either way, it is not a CT function.

As I outlined in one of my other posts, why would you perform CT to an
AR that did not have the necessary capabilities. Is this actually about
CAR failure??

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: April 8, 2002 14:26
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Gary,
> 
> I don't think the issue is having the MN re-create the context. Is is
> allowing the MN to recover by re-running the actions that 
> were necessary
> to create the context in the first place, in the event the AR 
> was unable
> to interpret it.
> Thus, for example, suppose that QoS context is transferred from old to
> new AR, but new AR for some reason can't interpret it, 
> perhaps there is
> no bandwidth left or perhaps the new AR uses a different 
> representation
> for QoS context. The MN would need to be informed somehow so that it
> could re-do its QoS signaling.
> 
>             jak
> 
> ----- Original Message -----
> From: "Gary Kenward" <[email-masked]>
> To: "'Rajeev Koodli'" <[email-masked]>; "Nakhjiri
> Madjid-MNAKHJI1" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, April 08, 2002 10:54 AM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by 
> the policy
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating 
> actions requires
> > more over-the-air signalling.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:[email-masked]]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS 
> after handoff.
> > > >
> > > > 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
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > 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: Mon, 08 Apr 2002 13:42:26 -0700

> Either way, it is not a CT function.

By "re-create" I meant the MN establishes a context
through feature-specific signaling, e.g., QoS signaling. I think
I described this in the associated posting.

> AR that did not have the necessary capabilities. Is this actually

you may have missed my response.. Anyway, you would
like to be able to do CT without assuming CAR support.
When you do CT and the target AR does not support
the feature or only partially supports it (IPv6/UDP/RTP
versus IPv6/UDP only header compression) , that's an
example where you want the MN notified.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 08 Apr 2002 13:42:26 -0700

-Rajeev

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 8 Apr 2002 20:57:37 -0400

>>AR that did not have the necessary capabilities. Is this actually about 

Yupper I agree!

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 8 Apr 2002 20:57:37 -0400

Yupper I agree!