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

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

Rajeev: 

  A user starts up an application that requests a "gold service". 
The protocol stack (perhaps an NSIS protocol stack) sends in a 
request from MN to AN for gold service". A handover occurs, and 
(according to your scenario), the QoS context transfer fails (for some 
inexplicable reason). Some entity (the CT protocol stack according to 
your proposal) sends an indication to the MN that the QoS context transfer 
has failed (according to your proposal). How does the MN know what to do 
with this notice? The MN has to understand: 
    
   - what a handover is at the IP level 
   - what an IP context transfer is 
   - that QoS context is (sometimes) transferred separately from other 
     context 
   - what the nature of the failure was, and thus, what action to take. 
   - how and with what entity to initiate QoS re-negotiation. 

  The knowledge for all of the above is either explicitly or implicitly 
built into the MN. If the intent were for the MN to receive back a message 
that indicating "Gold service not available" then this is simply a session 
disconnect. If the intent is for the MN to be told that "the QoS associated 
with Gold service" has failed, then the MN has to know that Gold service 
is actually a combination of features (AAA, security, HC), and to initiate 
negotiation, it has to be able to talk to the individual network entities 
- entities which may not even exist within a given network (e.g. a provision

model). 

 So, how is the MN ignorant of CT? Service models? 

 Keep in mind, according to the CT requirements, CT does not know what 
is contained in the data chunks it transports. Thus, at best, it can 
only forward to the MN that data chunk or another, opaque data chunk. 
Even this capability is a major modification to what should be 
a simple state machine for the CT protocol. 

Gary 

*snip*

> 
> 
> _______________________________________________ 
> nsis mailing list 
> [email-masked] 
>  <https://www1.ietf.org/mailman/listinfo/nsis>
https://www1.ietf.org/mailman/listinfo/nsis

---

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

Gary,

OK, I think I am beginning to see your point. The CT protocol is just a
container, if a particular feature context fails, it is up to the code
handling the feature context to actually perform the notification of the
MN. The CT code doesn't do particular features.

I think there is still the case of a failure in interpretation by the
new AR, or even a failure in CT itself, like it got lost on the way.

            jak

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