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: Rajeev Koodli <[email-masked]>
Date: Mon, 08 Apr 2002 17:39:51 -0700

> inexplicable reason). Some entity (the CT protocol stack according to

Well, it is not so hard to imagine why CT might fail

- transferred context is not useful; you don't want to
   CT to be applicable only where CARD is available, do you ?
- transferred context is lost, and retransmission is not desirable

>    - what a handover is at the IP level

It already knows, since it is on a new router!

>    - what an IP context transfer is

to the same extent it has to know how to handle
an error as a reply to feature (QoS) signaling.

>    - that QoS context is (sometimes) transferred separately from other

I don't see why MN needs to know this..

>    - what the nature of the failure was, and thus, what action to

What if this says initiate signaling to re-establish QoS.
Until this signaling takes place, the MN's packets are
still forwarded. That is, the session is _not_ disconnected.

>    - how and with what entity to initiate QoS re-negotiation.

the entity that sent the notification.

> disconnect. If the intent is for the MN to be told that "the QoS

I disagree with disconnecting a session because the support
for received context is not available.

> - entities which may not even exist within a given network (e.g. a

"Gold Service" is a bundle you have conceived. I am only
looking at the individual features. If QoS feature cannot be
activated for whatever reason, the QoS feature uses a generic
CT message to inform the MN. If multiple features cannot
be instantiated, you would send a single message with
multiple error codes.

So, for a particular feature or an enumeration thereof, the
MN _must_ know how to engage in signaling in order to
obtain features it desires.

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

MN is not ignorant of CT. In fact, the trigger to initiate CT
may come from the MN itself!
"4.4 The IP level context transfer triggers MAY be initiated by IP level

    (layer three) signalling. "

Whether MN is ignorant/cognizant of service models is
beyond scope, while recognized.

> only forward to the MN that data chunk or another, opaque data chunk.

CT does not know what is in the data chunk. But, the
feature-specific code knows, and it must have a hook to
CT that allows MN notification.

> a simple state machine for the CT protocol.

I disagree. I readily see a CT SM that sends a notification
message just as it processes a request for one or more
contexts to be transferred.

-Rajeev

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

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 08 Apr 2002 17:39:51 -0700

-Rajeev

---

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.

---

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

Gary,

            jak