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

Hemant.Chaskar@nokia.com Mon, 08 July 2002 16:24 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 MAA22944 for <seamoby-archive@odin.ietf.org>; Mon, 8 Jul 2002 12:24:25 -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 MAA00567; Mon, 8 Jul 2002 12:20:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00502 for <seamoby@optimus.ietf.org>; Mon, 8 Jul 2002 12:20:37 -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 MAA22698; Mon, 8 Jul 2002 12:19:38 -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 g68GOCj11255; Mon, 8 Jul 2002 11:24:12 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5bf65bbab1ac12f257126@davir04nok.americas.nokia.com>; Mon, 8 Jul 2002 11:20:30 -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 11:20:24 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 08 Jul 2002 12:20:23 -0400
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF908922F@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Thread-Index: AcImmMjymZiFaTWITiG8gRYc39SSCQAANpPQ
Sensitivity: Company-Confidential
To: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org
X-OriginalArrivalTime: 08 Jul 2002 16:20:24.0550 (UTC) FILETIME=[5D378060:01C2269B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA00503
Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
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 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