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

Hemant.Chaskar@nokia.com Mon, 08 July 2002 17:10 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25639 for <seamoby-archive@odin.ietf.org>; Mon, 8 Jul 2002 13:10:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05055; Mon, 8 Jul 2002 13:05:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04986 for <seamoby@optimus.ietf.org>; Mon, 8 Jul 2002 13:05:36 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25330; Mon, 8 Jul 2002 13:04:44 -0400 (EDT)
From: Hemant.Chaskar@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68H9Gj19579; Mon, 8 Jul 2002 12:09:16 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5bf684f9a6ac12f257126@davir04nok.americas.nokia.com>; Mon, 8 Jul 2002 12:05:33 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 12:04:37 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 08 Jul 2002 13:04:36 -0400
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF9089230@bsebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Thread-Index: AcImnjwicOWGywY0SGyWtZe2Im4KQQAAIWpg
To: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org
X-OriginalArrivalTime: 08 Jul 2002 17:04:37.0145 (UTC) FILETIME=[8A496090:01C226A1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA04987
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit

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 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.

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.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: 08. July 2002 12:39
To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com;
seamoby@ietf.org; nsis@ietf.org
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: <Hemant.Chaskar@nokia.com>
To: <gkenward@nortelnetworks.com>; <seamoby@ietf.org>; <nsis@ietf.org>
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:gkenward@nortelnetworks.com]
> Sent: 08. July 2002 12:00
> To: 'seamoby@ietf.org'; '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
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby