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

Behcet Sarikaya <behcet.sarikaya@alcatel.com> Mon, 08 July 2002 18:34 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 OAA00524 for <seamoby-archive@odin.ietf.org>; Mon, 8 Jul 2002 14:34:08 -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 OAA10803; Mon, 8 Jul 2002 14:30:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10699 for <seamoby@optimus.ietf.org>; Mon, 8 Jul 2002 14:30:18 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00167; Mon, 8 Jul 2002 14:29:25 -0400 (EDT)
Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g68ITjv03128; Mon, 8 Jul 2002 13:29:45 -0500 (CDT)
Message-ID: <3D29DA39.1090405@alcatel.com>
Date: Mon, 08 Jul 2002 13:30:17 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Hemant.Chaskar@nokia.com
CC: seamoby@ietf.org, nsis@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
References: <E320A8529CF07E4C967ECC2F380B0CF9089230@bsebe001.NOE.Nokia.com>
Content-Type: multipart/alternative; boundary="------------060308060208010408090808"
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

Hello Hemant,
 The relationship between nsis and CT, as far as I know is
that of uncertainty.
nsis which started out to develop signaling for QoS now changed to only 
signaling,
CT is going nowhere at Seamoby.
  The only sure thing is that the links have CT quite well defined, IEEE 
defined for 802.11 links and 3G links also have well defined context 
transfer protocols.
  In order to add to the present confusion, let me note the new BOF called:
Topology-Insensitive Service Traversal
which is probably going to deal with RSVP based signaling.

  My 0.03 euros (increased due to recent increase in value of the Euro).

Hemant.Chaskar@nokia.com 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 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
>>
>
>
>_______________________________________________
>nsis mailing list
>nsis@ietf.org
>https://www1.ietf.org/mailman/listinfo/nsis
>

-- 
Behcet