Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt

From: [email-masked]
Date: Mon, 8 Jul 2002 12:20:23 -0400

Hi Gary:

Some comments inline:

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 08. July 2002 12:00
To: [email-masked]'; 'NSIS'
Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Sensitivity: Confidential

I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. 

The one general comment I would like to offer up at this time, is that while

the draft does a good job of integrating MIP, CT and NSIS concepts, the 
proposed solutions for QoS negotiation between MN and AN (e.g. the use of
the 
CIN message) is NSIS not CT.

[Hemant] Point well taken.

CT is concerned with the transfer of forwarding service context between
ANRs. 
NSIS is concerned with the signalling of service requirements. Thus, the
issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but
how 
the CIN, etc., form part of the NSIS solution.

[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. 

[Hemant] Thanks, Hemant 

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a
significant 
benefit in the real world to be realized in keeping the context transfer
solution
(CT) independent from the service signalling solution (NSIS) (and the
mobility 
solution - MIP or whatever). I would think that there is also a benefit to
keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over
the air 
(MN to AN) service signalling? 

Regards,
Gary Kenward

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

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Jul 2002 09:39:16 -0700

Could CT be viewed as an optimization of NSIS signaling?

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, July 08, 2002 9:20 AM
Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt

> [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly
integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that
impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails.
> [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition.
Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation,
which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain
loss of seamlessness.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Jul 2002 09:39:16 -0700

jak