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

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

James:

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: April 8, 2002 15:55
> 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.
> 
> 
> 
> > 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

A nit, but the MN does not expect CT. The MN expects continuous
service (i.e. seamless service), and knows nothing about how it is 
supported (it could be provisioned).

> 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.

I understand these scenarios, but I do not understand what they have
to do with CT. CT has never intended to be an MN signalling protocol.
Let me try a counter example: the service authorization fails. Would
a CT message saying the AA context transfer failed be of much use
to the MN? No, because the problem wasn't with the context, it was with
a disconnect between the service request and authorization profile for
that MN. 

There is a need for a "handover failure" indication message to the
MN (indicating full or partial handover failure), but this message should
be part of a different protocol from CT.

Gary

>             jak

---

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

Gary,

When you say "handover failure" I think Mobile IP, and there is already
some signaling available in FMIPv6/BETH to do this. This signaling does
not extend to attributes of the IP service like whether or not the MN
can connect to the network, what class of QoS service it gets, and any
other security, etc.. There is currently no way to signal that the
network expects the MN to reestablish these, except to say that the MN
has entered a new AAA domain and should therefore perform network entry
from scratch. This seems a little too heavyweight to me.

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "'Rajeev Koodli'"
<[email-masked]>; "Nakhjiri Madjid-MNAKHJI1"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, April 08, 2002 1:21 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> be part of a different protocol from CT.

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

---

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

Gary,

            jak