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

[Rajeev Koodli <[e-mail]>]

Hemant,

[e-mail] wrote:

> Hi James:
>
> I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is

CT is an optimization to avoid signaling and the associated overheads, and maintain
desirable transport (RTP/TCP)performance. A historical note: CT was not designed
to be an optimization for NSIS.

> simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR.

This was discussed earlier. In essence,

- with some standard Profile Types, you would expect participating routers to
    support a majority of the feature contexts. In the absence of additional
    protocol support (e.g., CARD), transferring what you have is just fine. The
     receiving router ignores the context(s) it does not understand.
    London IETF was where we specifically had this discussion in depth.
- when a feature context type is not understood, CT should provide a notification.
    Such a notification is also useful when a feature context is partially understood.
    This notification could be used as a trigger to engage in NSIS signaling.
    This was presented at the NSIS interim WG meeting.

>
>
> If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD.
>

Ok. When CARD is available, it can provide input to CT.

-Rajeev


>
> Hemant
>
> -----Original Message-----
> From: ext James Kempf [mailto:[e-mail]]
> Sent: 08. July 2002 12:39
> To: Chaskar Hemant (NRC/Boston); [e-mail];
> [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
> >
>
> _______________________________________________
> Seamoby mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby


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