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

["Gary Kenward" <[e-mail]>]

James:

  In a way, yes. But if CT is present, and succeeds, then there
should be no need for MN-AN signalling, thus CT optimizes NSIS completely
away during handover (in this preferred scenario).

  Note that I specifically identified MN-AN NSIS, as I think what happens
within the interior of the AN is a broader discussion. From a seamless
perspective, one would hope that no signalling would be required. However,
this objective may not be possible with some service topologies (e.g. Int
Serv QoS). As I hinted earlier, one could assume the use of CT for internal
router context transfer (e.g. Int Serv configuration/state between IRs), 
unfortunately, there are some serious discover/topological issues that
arise.
NSIS may be the best possible general approach for per flow IR service 
configuration with handovers. On the other hand, some may be willing to live
with topological constraints (PDP context relocation comes to mind here).

Gary

> -----Original Message-----
> From: James Kempf [mailto:[e-mail]]
> Sent: July 8, 2002 12:39
> To: [e-mail]; Kenward, Gary [WDLN2:AN10:EXCH];
> [e-mail]; [e-mail]
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
> 
> 
> Could CT be viewed as an optimization of NSIS signaling?
> 
>             jak
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> Sent: Monday, July 08, 2002 9:20 AM
> Subject: [Seamoby] RE: [NSIS] Re: 
> draft-westphal-nsis-qos-mobileip-00.txt
> 
> 
> > Hi Gary:
> >
> > Some comments inline:
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:[e-mail]]
> > Sent: 08. July 2002 12:00
> > To: '[e-mail]'; '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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> > _______________________________________________
> > Seamoby mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
>