From exim@www1.ietf.org Tue Aug 5 10:34:07 2003 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 KAA13809 for ; Tue, 5 Aug 2003 10:34:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2sg-0001iq-6W for nsis-archive@odin.ietf.org; Tue, 05 Aug 2003 10:33:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75EXgRV006603 for nsis-archive@odin.ietf.org; Tue, 5 Aug 2003 10:33:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2s2-0001eL-11; Tue, 05 Aug 2003 10:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2rt-0001e1-Ci for nsis@optimus.ietf.org; Tue, 05 Aug 2003 10:32:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13765 for ; Tue, 5 Aug 2003 10:32:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2rr-0002T0-00 for nsis@ietf.org; Tue, 05 Aug 2003 10:32:51 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19k2rq-0002Sh-00 for nsis@ietf.org; Tue, 05 Aug 2003 10:32:50 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h75EWCVI002215; Tue, 5 Aug 2003 16:32:12 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 317B82AEEC; Tue, 5 Aug 2003 16:10:13 +0200 (CEST) Date: Tue, 05 Aug 2003 16:32:12 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: "Hancock, Robert" , "'Charles Q. Shen '" , "''Xiaoming Fu' '" Cc: "''Paulo Mendes' '" , "'nsis@ietf.org '" Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Message-ID: <22167354.1060101132@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > 1. The identifier that should not change during mobilily (if there is > one) is called the Session Identifier, while its detailed structure is > still open. > [reh] this is my view. designing it is an NTLP design matter (i.e. > the framework at least will not comment further on it). i think this > is generally agreed so far as it goes. > Yes, I think it is even a design requirement in the req draft. > 2. The flow identifier is the low level identifier that is used to > acutally route the packet at the NTLP level, its structure could contain > IP 5-tuple, IPv6 flow label, or related IP fields. > [reh] this is also my view. the precise definition is 'it has to contain > whatever fields that are used by routers to route packets'. discussion > post-Vienna on the mailing list implies to me that this is also generally > agreed. I think it is agreed not seen any objection. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Aug 6 22:32:03 2003 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 WAA14184 for ; Wed, 6 Aug 2003 22:32:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaYz-0005Jm-TO for nsis-archive@odin.ietf.org; Wed, 06 Aug 2003 22:31:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h772VbJr020427 for nsis-archive@odin.ietf.org; Wed, 6 Aug 2003 22:31:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaYP-0005Be-LZ; Wed, 06 Aug 2003 22:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaXl-0005Ao-0R for nsis@optimus.ietf.org; Wed, 06 Aug 2003 22:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14121 for ; Wed, 6 Aug 2003 22:30:15 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kaXh-0001XD-00 for nsis@ietf.org; Wed, 06 Aug 2003 22:30:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19kaXg-0001XA-00 for nsis@ietf.org; Wed, 06 Aug 2003 22:30:17 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h772UGJ05454 for ; Thu, 7 Aug 2003 05:30:16 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Aug 2003 05:30:11 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:11 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Reliable Transport for NTLP Date: Thu, 7 Aug 2003 05:30:09 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNPj1Add5b76FOES/KqGmax4OQsDQJYyP1A To: , Cc: X-OriginalArrivalTime: 07 Aug 2003 02:30:10.0410 (UTC) FILETIME=[D2D834A0:01C35C8B] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, > As I mentioned in another mail, I think reliablbe transport isn't = required=20 > if there's a "low" amount of signaling to be processed. If NSIS will = be=20 > designed to prevent a "high" signaling load in backbones, I guess I=20 > won't have a problem. Besides RSVP TE (and DiffServ aware TE) there's = also=20 > RFC 3175 ( aggregated RSVP). Both aim on rather stable state in the=20 > backbone by flow aggregation.=20 So, what I suspect what you are saying, that in the presences of = multiple different NLSPs between two NSIS peers, aggregation is needed. Flows which are aggregated should be congestion-friendly, etc. I think that this is the direction which Henning aiming for with NTLP. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Aug 6 22:32:04 2003 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 WAA14199 for ; Wed, 6 Aug 2003 22:32:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaZ0-0005KF-KR for nsis-archive@odin.ietf.org; Wed, 06 Aug 2003 22:31:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h772VcWX020454 for nsis-archive@odin.ietf.org; Wed, 6 Aug 2003 22:31:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaYR-0005CU-EA; Wed, 06 Aug 2003 22:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaXm-0005Ay-O6 for nsis@optimus.ietf.org; Wed, 06 Aug 2003 22:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14127 for ; Wed, 6 Aug 2003 22:30:17 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kaXj-0001XO-00 for nsis@ietf.org; Wed, 06 Aug 2003 22:30:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19kaXi-0001XJ-00 for nsis@ietf.org; Wed, 06 Aug 2003 22:30:18 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h772UIJ05501 for ; Thu, 7 Aug 2003 05:30:18 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Aug 2003 05:30:18 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Reliable Transport for NTLP Date: Thu, 7 Aug 2003 05:30:16 +0300 Message-ID: Thread-Topic: [NSIS] Reliable Transport for NTLP Thread-Index: AcNRYktzfprMk9lJSJWsmTywZCOBrgHkZN8Q To: , , Cc: X-OriginalArrivalTime: 07 Aug 2003 02:30:17.0808 (UTC) FILETIME=[D7410D00:01C35C8B] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, > However, even if we agree that a signalling application > needing reliability needs it between (say) adjacent NSLP > peers rather than simply end-to-end, there is still the=20 > question of which layer it should be provided at (NTLP > or within each application). The question could be put another another way, can a NSLP=20 'reliably' rely on a multi-hop NTLP providing reliability? Will an NSLP need to augment NTLP-layer reliability with reliability at the NSLP layer (such as explicit acks,=20 retransmission timers, etc)? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Aug 6 23:24:04 2003 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 XAA15847 for ; Wed, 6 Aug 2003 23:24:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kbNI-00070h-Ui for nsis-archive@odin.ietf.org; Wed, 06 Aug 2003 23:23:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h773NaSf026930 for nsis-archive@odin.ietf.org; Wed, 6 Aug 2003 23:23:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kbMj-0006tK-3h; Wed, 06 Aug 2003 23:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kbMC-0006sw-82 for nsis@optimus.ietf.org; Wed, 06 Aug 2003 23:22:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15806 for ; Wed, 6 Aug 2003 23:22:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kbMA-0001yZ-00 for nsis@ietf.org; Wed, 06 Aug 2003 23:22:26 -0400 Received: from relay6.kornet.net ([211.48.62.166]) by ietf-mx with esmtp (Exim 4.12) id 19kbM9-0001yO-00 for nsis@ietf.org; Wed, 06 Aug 2003 23:22:25 -0400 Received: from [210.183.206.27] (shjeong@hufs.ac.kr) by relay6.kornet.net (Terrace MailWatcher) with ESMTP id 2003080712:21:32:819225.9332.14 for ; Thu, 07 Aug 2003 12:21:32 +0900 (KST) Message-ID: <008901c35c92$c653ff00$1bceb7d2@shjeong2> From: "Seong Ho Jeong" To: "Hancock, Robert" Cc: , "Sung Hycuk Lee" , , References: <76C92FBBFB58D411AE760090271ED4181EA3F1@rsys002a.roke.co.uk> Date: Thu, 7 Aug 2003 12:19:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Subject: [NSIS] Crossover node discovery issue Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJbiBTZWN0aW9uIDUuMi4yIChMb2NhbGl6ZWQgUGF0aCBSZXBhaXIpIG9m IHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQsIA0KSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGdp dmUgYSBnZW5lcmFsIGRlc2NyaXB0aW9uIG9mIGhvdyB0byBkaXNjb3ZlciB0aGUgDQpjcm9zc292 ZXIgbm9kZSBpbiBhIGxpdHRsZSBtb3JlIGRldGFpbC4gRm9yIGV4YW1wbGUsIGFzIGRpc2N1c3Nl ZCBiZWZvcmUsIGEgc2Vzc2lvbiBJRCwgDQphIGZsb3cgSUQsIGFuZC9vciBhIG1vYmlsaXR5IG9i amVjdCBjYW4gYmUgdXNlZCBmb3IgdGhlIGNyb3Nzb3ZlciBub2RlIGRpc2NvdmVyeS4gDQpJbiB0 aGlzIGNhc2UsIHdlIG1heSBhbHNvIG5lZWQgdG8gY2hlY2sgd2hldGhlciBvciBub3QgdGhlIHVz ZSBvZiB0aG9zZSBmaWVsZHMgaXMgDQpzdWZmaWNpZW50IGJlY2F1c2Ugc29tZSBzb3J0IG9mIGF1 dGhvcml6YXRpb24gYW5kIGRldGVybWluYXRpb24gb2Ygc2Vzc2lvbiBvd25lcnNoaXAgbWF5IGJl IA0KbmVjZXNzYXJ5Li4uSG93IGFib3V0IGFkZGluZyBhIGdlbmVyYWwgZGVzY3JpcHRpb24gb2Yg dGhlIGNyb3Nzb3ZlciBub2RlIGRpc2NvdmVyeSANCmFuZCByZWxhdGVkIHNlY3VyaXR5IGlzc3Vl cyB0byB0aGUgZnJhbWV3b3JrIGRvY3VtZW50Pw0KDQpSZWdhcmRzLCANCg0KU2VvbmcgSmVvbmc= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Aug 7 04:59:28 2003 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 EAA04972 for ; Thu, 7 Aug 2003 04:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgbv-0003qu-Al for nsis-archive@odin.ietf.org; Thu, 07 Aug 2003 04:59:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h778x3Ek014790 for nsis-archive@odin.ietf.org; Thu, 7 Aug 2003 04:59:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgbt-0003q4-IC; Thu, 07 Aug 2003 04:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgb2-0003nW-3i for nsis@optimus.ietf.org; Thu, 07 Aug 2003 04:58:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04915 for ; Thu, 7 Aug 2003 04:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgay-0004AE-00 for nsis@ietf.org; Thu, 07 Aug 2003 04:58:04 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19kgay-00049m-00 for nsis@ietf.org; Thu, 07 Aug 2003 04:58:04 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 09:57:34 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , hgs@cs.columbia.edu, attila.bader@ericsson.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliable Transport for NTLP Date: Thu, 7 Aug 2003 09:57:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , john, even between two adjacent NSLP peers, there are really two questions (which are nearly independent): 1. what's the best layer to provide a guarantee that a message has got from one to the other. 2. what's the best layer to detect and recover from a message loss within the network. i'm still finishing off my reliability analysis draft at the moment. but my current feeling is that there are really at least two aspects to reliability - making sure the message arrives in the face of congestion, corruption and so on, and retransmitting rapidly if not (the NTLP is best place to do this but intermediate NTLP-only nodes shouldn't take part in the process) - making sure that a message has been processed and acted on correctly, and this has to be an NSLP responsibility. and, overall reliability at the 'e2e' level, e.g. between source and destination, has to be an NSLP responsibility also (e.g. our QoS-NSLP had a confirmation request object for this purpose). r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, August 07, 2003 03:30 > To: Hancock, Robert; hgs@cs.columbia.edu; attila.bader@ericsson.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] Reliable Transport for NTLP > > > Hi Robert, > > > However, even if we agree that a signalling application > > needing reliability needs it between (say) adjacent NSLP > > peers rather than simply end-to-end, there is still the > > question of which layer it should be provided at (NTLP > > or within each application). > > The question could be put another another way, can a NSLP > 'reliably' rely on a multi-hop NTLP providing reliability? > Will an NSLP need to augment NTLP-layer reliability with > reliability at the NSLP layer (such as explicit acks, > retransmission timers, etc)? > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Aug 7 20:24:40 2003 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 UAA09636 for ; Thu, 7 Aug 2003 20:24:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3F-0003mF-BP for nsis-archive@odin.ietf.org; Thu, 07 Aug 2003 20:24:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780ODiV014492 for nsis-archive@odin.ietf.org; Thu, 7 Aug 2003 20:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3B-0003lS-6G; Thu, 07 Aug 2003 20:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv2X-0003dH-Lb for nsis@optimus.ietf.org; Thu, 07 Aug 2003 20:23:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09422 for ; Thu, 7 Aug 2003 20:23:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kv2V-0003tG-00 for nsis@ietf.org; Thu, 07 Aug 2003 20:23:27 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19kv2U-0003tD-00 for nsis@ietf.org; Thu, 07 Aug 2003 20:23:26 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h780NLFh017027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Aug 2003 20:23:21 -0400 (EDT) Message-ID: <3F32ED79.9040405@cs.columbia.edu> Date: Thu, 07 Aug 2003 20:23:21 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: robert.hancock@roke.co.uk, attila.bader@ericsson.com, nsis@ietf.org Subject: Re: [NSIS] Reliable Transport for NTLP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I see these as complementary. End-to-end reliability is good for dealing with node failures, for example, which are relatively rare and have longer time constants for discovery. In many cases, softstate 'reliability' (on the order of 30s) should do the trick there. john.loughney@nokia.com wrote: > Hi Robert, > > >>However, even if we agree that a signalling application >>needing reliability needs it between (say) adjacent NSLP >>peers rather than simply end-to-end, there is still the >>question of which layer it should be provided at (NTLP >>or within each application). > > > The question could be put another another way, can a NSLP > 'reliably' rely on a multi-hop NTLP providing reliability? > Will an NSLP need to augment NTLP-layer reliability with > reliability at the NSLP layer (such as explicit acks, > retransmission timers, etc)? > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Aug 11 09:45:32 2003 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 JAA15754 for ; Mon, 11 Aug 2003 09:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCyx-0003aP-MH for nsis-archive@odin.ietf.org; Mon, 11 Aug 2003 09:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BDj76p013781 for nsis-archive@odin.ietf.org; Mon, 11 Aug 2003 09:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCyr-0003Zj-Ku; Mon, 11 Aug 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCyW-0003ZJ-8D for nsis@optimus.ietf.org; Mon, 11 Aug 2003 09:44:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15739 for ; Mon, 11 Aug 2003 09:44:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCyU-0005y1-00 for nsis@ietf.org; Mon, 11 Aug 2003 09:44:38 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19mCyT-0005xy-00 for nsis@ietf.org; Mon, 11 Aug 2003 09:44:37 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 11 Aug 2003 15:44:46 +0200 Message-ID: <3F379D90.7000808@cs.uni-goettingen.de> Date: Mon, 11 Aug 2003 15:43:44 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" , nsis@ietf.org CC: "'Charles Q. Shen'" , "'Paulo Mendes'" Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Sorry for the delay in answering your mail - I just came back from a few days of vocation. Some comments inline: Hancock, Robert wrote: > hi xiaoming, > (snip) > [reh] the fundamental question is: how are the data packets themselves > being routed? whatever is making them follow the route they follow > should be invoked to make the signalling packets follow the same route. > (*how* to make that invocation is another issue; one approach is to > make the signalling packets look like data packets, another is to > make the nodes which do some forwarding which is not-purely-IP-DA > NSIS-aware and have them route signalling packets at the NTLP level > on the flow-id directly. see numerous other emails on that subject.) > > [if the data packets are being routed on something other than 3/5 tuple > and possibly routing header, I suspect we are in deep trouble.] I totally agree with you that signaling packets should follow exactly the same route as data packets (I believe this is part of the NSIS requirements regarding mobility and any other things). Now let's go to the problem of "how the data packets are routed in mobile IP?" and look at CN-->MN in basic Mobile IPv6 protocol first: - For Mobile IP without route optimization: the data packets will stay as normal IP packets (src: CN, dst: HoAddress) before arriving at the HA. The HA uses IP-in-IP encapsulation to assemble these packets towards the MN's CoA, i.e., the tunnel entry is HA address and the tunnel exit is MN's CoA. In the MN, CoA --> HoA is done inside OS. To route these data packets, per Melina's NTLP proposal we may have to rely on NTLP-in-NTLP tunnel while according to Henning's NTLP proposal, we can add some functionalities to NTLP (in this case, for basic Mobile IPv6, routing per flow-id works.) - For Mobile IP with route optimization: very unfortunately, the data packets will be destinated to CoA but with a routing header (containing MN's HoA). As the CoA can still be seen from the IP normal header, we probably don't need special care to routing header, if CoA is used to route signaling packets. Second, may we look at MN-->CN in basic Mobile IPv6 protocol: - For Mobile IP without reverse tunnel: the data packets will be assembled as IP packets with a home address option. We only need CN's address to route these packets, not a problem for both proposals. - For Mobile IP with reverse tunnel: the data packets sent by the MN will be encapsulated within a tunnel (entry CoA, exit HA address), with the original IP packets destined to CN. In order to address signaling packets inside this tunnel, we may either add another NTLP object which is similar to SESSION_ASSOC in RFC2746 and map the SESSION object into tunnel object (for Melinda's NTLP proposal), or rely on a discovery/routing component which locates in NTLP (for Henning's NTLP proposal), let it be aware of tunnel entry and exit and determine which next NTLP hop to go. Third, let's go to a bit more complicated case - fast handover and hmipv6: - As my draft states, these LMM proposals add one or two tunnels in the path where data packets traverse in basic Mobile IP. It becomes problematic if we re-apply RFC2746 every time when a data packet goes into a tunnel (and exits) - imagine how things work if we handle 2+ levels of tunnels each by a SESSION_ASSOC object and mapping between SESSION <--> tunnel SESSION object (each level the same object type? yet another new type for another level?). In this case, Henning's NTLP proposal seems to be more appealing, - if we even need to signal into such tunnels. On the other hand, I think this holds as long as QoS NSLP demands - Hemant's draft "Requirements of a QoS Solution for Mobile IP" states "QoS mechanism for Mobile IP SHOULD have provisions to handle such heterogeneity as regards the QoS mechanisms deployed along different packet paths. ... A QoS mechanism SHOULD be able to support QoS along the different potential packet paths. " In a short summary: - 3/5-tuple flow-id could be insufficient to address NTLP messages; some additional views are needed for mobility scenarios. - Mobility is more about an NTLP issue, not only an NSLP issue (although NSLP might be necessary to be aware of mobility). Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Aug 12 05:34:30 2003 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 FAA06237 for ; Tue, 12 Aug 2003 05:34:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mVXZ-00043n-Mf for nsis-archive@odin.ietf.org; Tue, 12 Aug 2003 05:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C9Y52E015608 for nsis-archive@odin.ietf.org; Tue, 12 Aug 2003 05:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mVXV-00043H-7w; Tue, 12 Aug 2003 05:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mVX7-000436-9z for nsis@optimus.ietf.org; Tue, 12 Aug 2003 05:33:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06231 for ; Tue, 12 Aug 2003 05:33:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mVX3-0006b7-00 for nsis@ietf.org; Tue, 12 Aug 2003 05:33:33 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19mVX2-0006ay-00 for nsis@ietf.org; Tue, 12 Aug 2003 05:33:33 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h7C9X1VI074068; Tue, 12 Aug 2003 11:33:01 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E7FA46EFB5; Tue, 12 Aug 2003 11:09:56 +0200 (CEST) Date: Tue, 12 Aug 2003 11:33:01 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Loughney , Allison Mankin Cc: nsis@ietf.org, Harald Tveit Alvestrand , Steve Bellovin Message-ID: <91739274.1060687981@[10.1.1.130]> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] New version of Req submitted Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, Allison, I have a new version of the requirements submitted (draft-ietf-nsis-req-09.txt). The comments from Harald and Steve have been addressed (see below for the difference between the 08 and 09 of the draft. Marcus Section 5 (Harald's comment #1) OLD 5 Requirements This section defines more detailed requirements for a signaling solution, respecting the framework, scoping assumptions, and terminology considered earlier. The requirements are in subsections, grouped roughly according to general technical aspects: architecture and design goals, topology issues, parameters, performance, security, information, and flexibility. Two general (and potentially contradictory) goals for the solution are that it should be applicable in a very wide range of scenarios, and at the same time lightweight in implementation complexity and resource consumption requirements in NSIS Entities. One approach to this is that the solution could deal with certain requirements via modular components or capabilities, which are optional to implement or use in individual nodes. In order to prioritize the various requirements we informally define different 'parts of the network'. In the different parts of the network a particular requirement might have a different priority. The parts of the networks we differentiate are the host-to-first router, the access network, and the core network. The host to first router part includes all the layer 2 technologies to access to the Internet. This part of the division is especially informal and may incorporate several access segments. In many cases, there is an application and/or user running on the host initiating signaling. The access network can be characterized by low capacity links, medium speed IP processing capabilities, and it might consist of a complete layer 2 network as well. The core network characteristics include high-speed forwarding capacities and inter-domain issues. These divisions between network types are not strict and do not appear in all networks, but where they do exist they may influence signaling requirements and will be highlighted as necessary. NEW 5 Requirements This section defines more detailed requirements for a signaling solution, respecting the framework, scoping assumptions, and terminology considered earlier. The requirements are in subsections, grouped roughly according to general technical aspects: architecture and design goals, topology issues, parameters, performance, security, information, and flexibility. Two general (and potentially contradictory) goals for the solution are that it should be applicable in a very wide range of scenarios, and at the same time lightweight in implementation complexity and resource consumption requirements in NSIS Entities. We use the terms 'access' and 'core' informally in the discussion of some particular requirements to refer to deployment conditions where particular protocol attributes, especially performance characteristics, have special importance. Specifically, 'access' refers to lower capacity networks and fewer users and sessions. 'Core' refers to high capacity networks with a large number of users and sessions. One approach to this is that the solution could deal with certain requirements via modular components or capabilities, which are optional to implement or use in individual nodes. ==================================================== Req 5.5.1 Scalability (Harald's comment #2) NEW added the following paragraph at the end of req 5.5.1 Specifically, NSIS MUST work in Internet scale deployments, where the use of signaling by hosts becomes universal. Note that requirement 5.2.4 requires the functionality of transparently signal through networks without interpretation. Additionally, requirement 5.6.1 lists the capability to aggregate. Furthermore, requirement 5.5.4 states that NSIS should be able to constrain the load on devices. Basically, the performance of the signaling MUST degrade gracefully rather than catastrophically under overload conditions. ============================ section 3, last paragraph (Steve Bellovin comment #1) OLD 5. We can see the network at the level of domains/subdomains rather than individual routers (except in the special case that the domain contains one link). Domains are assumed to be administrative entities, so security requirements apply to the signaling between them. NEW 5. We can see the network at the level of domains/subdomains rather than individual routers (except in the special case that the domain contains one link). Domains are assumed to be administrative entities. So security requirements might apply differently for the signaling between the domains and within a domain. Both cases we deal with in this document. ============================ Requirement 5.7.8 (Steve Bellovin comment #2) OLD 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner MAY be provided. Note that the protection can be provided on a hop-by-hop basis for most message payloads since it is required that entities which actively participating in the signaling protocol must be able to read and eventually modify the content of the signaling messages. NEW 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. Since the ability to listen to signaling channels is a major guide to what data channels are interesting ones. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner SHOULD be provided. Note that most messages must be protected on a hop-by-hop basis, since entities, which actively participate in the signaling protocol, must be able to read and eventually modify the signaling messages. -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Aug 12 10:18:30 2003 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 KAA15390 for ; Tue, 12 Aug 2003 10:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZyP-0004MM-Sh for nsis-archive@odin.ietf.org; Tue, 12 Aug 2003 10:18:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CEI5ij016752 for nsis-archive@odin.ietf.org; Tue, 12 Aug 2003 10:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZyL-0004L1-MS; Tue, 12 Aug 2003 10:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZxc-0004KP-Lp for nsis@optimus.ietf.org; Tue, 12 Aug 2003 10:17:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15206; Tue, 12 Aug 2003 10:17:09 -0400 (EDT) Message-Id: <200308121417.KAA15206@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 12 Aug 2003 10:17:09 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-09.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Requirements for Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-09.txt Pages : 36 Date : 2003-8-12 This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service such as The Resource Reservation Protocol, however in recent years several other applications of signaling have been defined such as signaling for label distribution in Multiprotocol Label Switching or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-req-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-req-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-12095404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-12095404.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Aug 12 18:26:29 2003 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 SAA01693 for ; Tue, 12 Aug 2003 18:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mhaf-0005ce-6I for nsis-archive@odin.ietf.org; Tue, 12 Aug 2003 18:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CMQ5o8021596 for nsis-archive@odin.ietf.org; Tue, 12 Aug 2003 18:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mhab-0005cC-Cj; Tue, 12 Aug 2003 18:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mhaN-0005bt-4Z for nsis@optimus.ietf.org; Tue, 12 Aug 2003 18:25:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01690 for ; Tue, 12 Aug 2003 18:25:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mhaK-0004IV-00 for nsis@ietf.org; Tue, 12 Aug 2003 18:25:44 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19mhaJ-0004IP-00 for nsis@ietf.org; Tue, 12 Aug 2003 18:25:43 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 23:25:09 +0100 Message-ID: From: "Hancock, Robert" To: "'nsis@ietf.org'" Date: Tue, 12 Aug 2003 23:25:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [NSIS] framework: proposal on reliability Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, we've had multiple inconclusive discussions on reliability requirements for the NTLP in the recent and distant past. i've tried to summarise them and provide some additional factoids for consideration in an i-d. while the i-d editor processes it, you can find it at http://sigcomp.srmr.co.uk/~reh/draft-hancock-nsis-reliability-00.txt my conclusions from all this are: ...it is appropriate for the NTLP to provide a reliable message delivery service, which would be optional for signaling applications to use. The role of such a service would be limited to ensuring rapid delivery of messages to the nodes where they are to be processed in signaling applications, and not to provide any application-layer state synchronization service or hard-state support. Such a reliability service should if possible be implemented in a way which can be transparent to intermediate NSIS nodes which don't take part in the signaling application; it will probably require congestion control in the NTLP as a consequence. If you disagree with this conclusion, take a look at the draft and tell me why. Apart from congestion control (a closely related subject), I regard this as the single major outstanding technical issue with the framework, and would like to see how we can finish off that discussion during August and early September (if that's possible). cheers, robert h. No doubt, people will complain that this draft is too long (there's about 14 pages of argument + a pile of references). On the other hand, people have also complained that the argument about reliability has not really been made (despite > 200 emails on the subject), and have also asked for 'details not handwaving'. Well, here goes. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Aug 13 01:41:31 2003 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 BAA13107 for ; Wed, 13 Aug 2003 01:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moNd-0005kx-3t for nsis-archive@odin.ietf.org; Wed, 13 Aug 2003 01:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D5f5Y6022127 for nsis-archive@odin.ietf.org; Wed, 13 Aug 2003 01:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moNZ-0005kL-78; Wed, 13 Aug 2003 01:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moNO-0005k8-MM for nsis@optimus.ietf.org; Wed, 13 Aug 2003 01:40:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13051 for ; Wed, 13 Aug 2003 01:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19moNL-0006nM-00 for nsis@ietf.org; Wed, 13 Aug 2003 01:40:47 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19moNK-0006nJ-00 for nsis@ietf.org; Wed, 13 Aug 2003 01:40:46 -0400 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Wed, 13 Aug 2003 07:40:56 +0200 Message-ID: <3F39CF10.5080709@cs.uni-goettingen.de> Date: Wed, 13 Aug 2003 07:39:28 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: "'Charles Q. Shen '" , "''Paulo Mendes' '" , "'nsis@ietf.org '" Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, (trying to follow up this thread and give short comments below:) Hancock, Robert wrote: > (snip) > [reh] your draft is certainly the one referred to, i have seen the > same idea since in other places. the key distinction is > whether the stable identifier is only in the control plane, and > you accept an update (probably end to end as well) in the data plane; > or whether you attempt to put a stable identifier in the data plane > itself. You could try to use the HA (or something else) in either > place as part of the stable identifier, but the main point of the > above distinction is to claim that the second is impossible for > fairly fundamental reasons. My understanding is also that a seperation of control and data planes is of particular importance for NSIS. (snip..) > 3. The association of the two (layer split functionality, etc.) is still > open. > [reh] basically, yes. My current proposal is that the framework will > explain the implications of the open-ness of this, but that the details > will be worked out in 'later activities', i.e. individual mobility > analysis work. The only thing I will assert is that the association > machinery is in the NSLP rather than the NTLP - but we still don't > really know what that machinery is. I like your idea of keeping the open-ness of this. To sum up, it looks to me that mobility, even basic Mobile IP or Mobile IPv6, brings troubles in three main aspects: 1) change of end host address (CoA), 2) change of routing (in mobility agent and/or end hosts), while a "cross-over router" is actually the first NSIS hop where two routes diverges and needs to be discoverd correctly, 3) IP-in-IP encapsulation in the data path. 1) and 2) - already introduce various challenges - have been explored in many docs, while IMO the addition of 3) also contributes to the reasons why today's RSVP has not been extended by the IETF for operations in mobility scenarios. Probably we need to look at exact implications for NSLP/NTLP seperation in "later activities" (to which I am looking forward). > > I think the framework draft already contains very good descriptions of > the two IDs, but it would be helpful to document explicitly what are > still open issues, either in that draft or somewhere else. > [reh] i hope this reply goes some way in that direction. Thanks for your nice elaboration and hope this discussion helps for the next. Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Aug 13 02:20:28 2003 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 CAA00205 for ; Wed, 13 Aug 2003 02:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mozK-0008GB-Bo for nsis-archive@odin.ietf.org; Wed, 13 Aug 2003 02:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D6K2rM031730 for nsis-archive@odin.ietf.org; Wed, 13 Aug 2003 02:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mozJ-0008Ff-Iw; Wed, 13 Aug 2003 02:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19moyw-0008BT-D8 for nsis@optimus.ietf.org; Wed, 13 Aug 2003 02:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29295 for ; Wed, 13 Aug 2003 02:19:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19moys-0006zH-00 for nsis@ietf.org; Wed, 13 Aug 2003 02:19:34 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19moyr-0006zE-00 for nsis@ietf.org; Wed, 13 Aug 2003 02:19:33 -0400 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Wed, 13 Aug 2003 08:19:44 +0200 Message-ID: <3F39D828.5010709@cs.uni-goettingen.de> Date: Wed, 13 Aug 2003 08:18:16 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sung-Hyuck Lee CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Modeling of mobility? References: <000801c349eb$a2000b80$3be0a051@starsu> In-Reply-To: <000801c349eb$a2000b80$3be0a051@starsu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Sung-Hyuck, Some comments inline: Sung-Hyuck Lee wrote: > Hi, John, Fu, and all, > > I think we need to clearly re-define how nsis(ntlp/nslp) should operate > with mobility and what is in-scope about mobility. I think current NSIS charter is quite clear; we need to work with various mobility protocols but not doing the same work in mobility signaling. > The NSIS is clearly different from mobility signaling, but the NSIS > should cooperate with mobility signaling to support seamless > QoS service (e.g., pre-resource reservation) in IP-based radio access > network. In this case, the NSIS should be independent > of any specific MIP signaling, but sometimes a mobility signaling can > initiate the nsis signaling (e.g, to support reservation > during the specific time) Here you raise two issues: whether advanced/pre- reservation is necessary, and which can be mobility triggers for NSIS. I think generally we are tending to pursue something to be done after mobility signaling; it might be useful if we look at the basic requirements imposed by mobility rather than these advanced features in the first place. In terms of NSIS trigger, I see a routing change in the data path caused by mobility protocols might be a reasonable source. Thanks, Xiaoming > Regards, > > Sung Hyuck Lee > --------------t------------------------------------------- > > >john.loughney@nokia.com wrote: > >>You may like to bring this up at the MIPv6 Signaling and Handoff > Optimization BOF on Wednesday, as this sounds somewhat out of scope for > NSIS. > >Well, I shall have mentioned more clearly, that doing such a > characterizing is not going to do MIP signaling at all, but to use the > route change _resulting >from_ MIP signaling (what meant by "independent > of any specific MIP signaling") and to signaling into IP-in-IP tunnels > (what meant by "IP-in-IP >encasulation/tunnel"). My thought was that if > NSIS finally needs to work with mobility, this can be necessary in NSIS. > > >Thanks, > >Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Aug 13 10:03:27 2003 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 KAA19647 for ; Wed, 13 Aug 2003 10:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwDO-0008IY-3V for nsis-archive@odin.ietf.org; Wed, 13 Aug 2003 10:03:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DE32eC031894 for nsis-archive@odin.ietf.org; Wed, 13 Aug 2003 10:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwDN-0008ID-5x; Wed, 13 Aug 2003 10:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwDC-0008G4-0g for nsis@optimus.ietf.org; Wed, 13 Aug 2003 10:02:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19537; Wed, 13 Aug 2003 10:02:44 -0400 (EDT) Message-Id: <200308131402.KAA19537@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 13 Aug 2003 10:02:43 -0400 Subject: [NSIS] I-D ACTION:draft-hancock-nsis-reliability-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reliability Functions in the NSIS Transport Layer Protocol Author(s) : R. Hancock Filename : draft-hancock-nsis-reliability-00.txt Pages : 23 Date : 2003-8-13 The Next Steps in Signaling working group is developing a protocol suite for signaling information about a data flow along its path in the network. The lower layer in the protocol suite, the NSIS Transport Layer Protocol (NTLP) is intended to provide a generally useful transport service for such signaling messages. There is a long-running open question about how much (if at all) the NTLP should provide reliable message transport. There is a large amount of confusion about what this question even means, let alone how to answer it. This document identifies the possible reliability requirements for signaling protocols in general, based on past evaluations of RSVP and research in soft-state protocol performance. It makes a proposal for what kind of reliable transport functionality should be supported in the NTLP, and discusses some of the resulting impacts and constraints on the NTLP design. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-nsis-reliability-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hancock-nsis-reliability-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hancock-nsis-reliability-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-13102107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hancock-nsis-reliability-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hancock-nsis-reliability-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-13102107.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Aug 14 02:54:29 2003 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 CAA01784 for ; Thu, 14 Aug 2003 02:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBzm-00036u-S4 for nsis-archive@odin.ietf.org; Thu, 14 Aug 2003 02:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E6s2BR011955 for nsis-archive@odin.ietf.org; Thu, 14 Aug 2003 02:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBzl-00036i-Dm; Thu, 14 Aug 2003 02:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBzh-00036X-A5 for nsis@optimus.ietf.org; Thu, 14 Aug 2003 02:53:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01781 for ; Thu, 14 Aug 2003 02:53:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nBzd-0000IS-00 for nsis@ietf.org; Thu, 14 Aug 2003 02:53:53 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19nBzc-0000IJ-00 for nsis@ietf.org; Thu, 14 Aug 2003 02:53:52 -0400 Received: from sait1gc9bc522b (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7E6qZJ5013895; Thu, 14 Aug 2003 15:52:37 +0900 (KST) From: "Sung Hycuk Lee" To: "Xiaoming Fu" Cc: , Subject: RE: [NSIS] Modeling of mobility? (mobility-related issues in framework) Date: Thu, 14 Aug 2003 15:52:39 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3F39D828.5010709@cs.uni-goettingen.de> Importance: Normal Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgWGlhb21pbmcsIFJvYmVydCwgYW5kIGFsbCwNCg0KIFBsZWFzZSwgcmVmZXJlIG15IGNvbW1l bnRzIGlubGluZSBbc2hsXS4NCg0KUmVnYXJkcywNCg0KU3VuZy1IeXVjaw0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIA0KPiA+IEkgdGhpbmsg d2UgbmVlZCB0byBjbGVhcmx5IHJlLWRlZmluZSBob3cgbnNpcyhudGxwL25zbHApIHNob3VsZCBv cGVyYXRlIA0KPiA+IHdpdGggbW9iaWxpdHkgYW5kIHdoYXQgaXMgaW4tc2NvcGUgYWJvdXQgbW9i aWxpdHkuDQo+IA0KPiBJIHRoaW5rIGN1cnJlbnQgTlNJUyBjaGFydGVyIGlzIHF1aXRlIGNsZWFy OyB3ZSBuZWVkIHRvIHdvcmsgd2l0aA0KPiB2YXJpb3VzIG1vYmlsaXR5IHByb3RvY29scyBidXQg bm90IGRvaW5nIHRoZSBzYW1lIHdvcmsgaW4gbW9iaWxpdHkNCj4gc2lnbmFsaW5nLg0KIA0KW3No bF0gWW91J3JlIHJpZ2h0IGZvciBOU0lTIGNoYXJ0ZXIsIGJ1dCBJIGd1ZXNzIGl0J3Mgbm90IGNs ZWFyIEhPVyBOU0lTIFNIT1VMRCBXT1JLIFdJVEggTU9CSUxJVFkgUFJPVE9DT0wuIEZvciBleGFt cGxlLCAoYXMgeW91IGtub3cpIGhvdyB0byBjb29wZXJhdGUgY29udGV4dCB0cmFuc2ZlciBiZWZv cmUgb3IgZHVyaW5nIGhhbmRvdmVyIChzZWUgcmVxdWlyZW1lbnQgZG9jLiA1LjkuNSBhbmQgZnJh bWV3b3JrIGRvYyA1LjIuNSksIGhvdyB0byB0cmlnZXIgTlNJUyAoTlRMUCkgYWZ0ZXIgaGFuZG92 ZXIsIGhvdyB0byBkaXN0aW5jdCBhIENyb3Nzb3ZlciBOb2RlIChDTikgKGhvdyB0byBmZXJyZXQg dGhlIENOIHdpdGggc2Vzc2lvbiBJRCwgRmxvdyBJRCBhbmQgTW9iaWxpdHkgb2JqZWN0IGNsZWFy bHkpLCBldGMuIA0KQXMgUm9iZXJ0IHdhcyBtZW50aW9uZWQgaW4gdGhlIFZpZW5uYSBtZWV0aW5n LCB3ZSBhbHNvIG5lZWQgbW9yZSBwaWN0dXJlcyBjb25zaWRlcmluZyBtb2JpbGl0eSAobmVlZGlu ZyBkaXNjdXNzaW9uKS4gSG93ZXZlciwgSSB3b25kZXIgd2hpY2ggcGljdHVyZXMgd2l0aCBtb2Jp bGl0eSBSb2JlcnQgY29uc2lkZXJzIGluIHRoZSBGVyBkb2MuICANCg0KQlRXLCBTZWFtYm95IHdv cmtpbmcgZ3JvdXAgd2FzIGNsb3NlZCBub3csIHNvIChhY2NvcmRpbmcgdG8gSmFtZXMgKSB0aGUg cmVsYXRlZCBpc3N1ZXMgd2lsbCBiZSBkZWFsIHdpdGggTW9iaWxpdHkgUmVzZWFyY2ggR3JvdXAg aW4gSVJURi4gSSB0aGluayB0aGUgU2VhbW9ieSBXRy1yZWxhdGVkIHNlbnRlbmNlcyBpbiBzZWN0 aW9uIDUuMi41IG9mIGZyYW1ld29yayBkb2Mgd2lsbCBiZSBuZWVkIG1vZGlmaWNhdGlvbiAoYWx0 aG91Z2ggbWlub3IgcGFydHMpLg0KDQo+ID4gVGhlIE5TSVMgaXMgY2xlYXJseSBkaWZmZXJlbnQg ZnJvbSBtb2JpbGl0eSBzaWduYWxpbmcsIGJ1dCB0aGUgTlNJUyANCj4gPiBzaG91bGQgY29vcGVy YXRlIHdpdGggbW9iaWxpdHkgc2lnbmFsaW5nIHRvIHN1cHBvcnQgc2VhbWxlc3MNCj4gPiBRb1Mg c2VydmljZSAoZS5nLiwgcHJlLXJlc291cmNlIHJlc2VydmF0aW9uKSBpbiBJUC1iYXNlZCByYWRp byBhY2Nlc3MgDQo+ID4gbmV0d29yay4gSW4gdGhpcyBjYXNlLCB0aGUgTlNJUyBzaG91bGQgYmUg aW5kZXBlbmRlbnQNCj4gPiBvZiBhbnkgc3BlY2lmaWMgTUlQIHNpZ25hbGluZywgYnV0IHNvbWV0 aW1lcyBhIG1vYmlsaXR5IHNpZ25hbGluZyBjYW4gDQo+ID4gaW5pdGlhdGUgdGhlIG5zaXMgc2ln bmFsaW5nIChlLmcsIHRvIHN1cHBvcnQgcmVzZXJ2YXRpb24NCj4gPiBkdXJpbmcgdGhlIHNwZWNp ZmljIHRpbWUpDQo+IA0KPiBIZXJlIHlvdSByYWlzZSB0d28gaXNzdWVzOiB3aGV0aGVyIGFkdmFu Y2VkL3ByZS0gcmVzZXJ2YXRpb24gaXMNCj4gbmVjZXNzYXJ5LCBhbmQgd2hpY2ggY2FuIGJlIG1v YmlsaXR5IHRyaWdnZXJzIGZvciBOU0lTLiBJIHRoaW5rDQo+IGdlbmVyYWxseSB3ZSBhcmUgdGVu ZGluZyB0byBwdXJzdWUgc29tZXRoaW5nIHRvIGJlIGRvbmUgYWZ0ZXIgbW9iaWxpdHkNCj4gc2ln bmFsaW5nOyBpdCBtaWdodCBiZSB1c2VmdWwgaWYgd2UgbG9vayBhdCB0aGUgYmFzaWMgcmVxdWly ZW1lbnRzDQo+IGltcG9zZWQgYnkgbW9iaWxpdHkgcmF0aGVyIHRoYW4gdGhlc2UgYWR2YW5jZWQg ZmVhdHVyZXMgaW4gdGhlIGZpcnN0DQo+IHBsYWNlLiBJbiB0ZXJtcyBvZiBOU0lTIHRyaWdnZXIs IEkgc2VlIGEgcm91dGluZyBjaGFuZ2UgaW4gdGhlIGRhdGEgcGF0aA0KPiBjYXVzZWQgYnkgbW9i aWxpdHkgcHJvdG9jb2xzIG1pZ2h0IGJlIGEgcmVhc29uYWJsZSBzb3VyY2UuDQogDQpbc2hsXSAg SW4gSW50ZXJhY3Rpb24gd2l0aCBzZWFtbGVzcyBoYW5kb3ZlciBwcm90b2NvbHMsIENUIGFuZCBD QVJEIG9jY3VyIGR1cmluZyBoYW5kb3ZlciBvciBiZWZvcmUgaGFuZG92ZXIsICBob3cgZG9lcyBO U0lTIHdvcmsgd2l0aCB0aGVzZSBwcm90b2NvbD8= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Aug 14 02:58:27 2003 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 CAA01847 for ; Thu, 14 Aug 2003 02:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC3d-0003Gd-Vs for nsis-archive@odin.ietf.org; Thu, 14 Aug 2003 02:58:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E6w1oC012538 for nsis-archive@odin.ietf.org; Thu, 14 Aug 2003 02:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC3d-0003G3-26; Thu, 14 Aug 2003 02:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC3Z-0003Fs-8Y for nsis@optimus.ietf.org; Thu, 14 Aug 2003 02:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01838 for ; Thu, 14 Aug 2003 02:57:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nC3V-0000JV-00 for nsis@ietf.org; Thu, 14 Aug 2003 02:57:53 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19nC3U-0000JS-00 for nsis@ietf.org; Thu, 14 Aug 2003 02:57:52 -0400 Received: from sait1gc9bc522b (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7E6vLJ4014208 for ; Thu, 14 Aug 2003 15:57:21 +0900 (KST) From: "Sung Hycuk Lee" To: Subject: RE: [NSIS] Modeling of mobility? (mobility-related issues in framework) Date: Thu, 14 Aug 2003 15:57:26 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQpIaSBYaWFvbWluZywgUm9iZXJ0LCBhbmQgYWxsLA0KDQogUGxlYXNlLCByZWZlcmUgbXkgY29t bWVudHMgaW5saW5lIFtzaGxdLg0KDQpSZWdhcmRzLA0KDQpTdW5nLUh5dWNrDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgDQo+ID4gSSB0aGlu ayB3ZSBuZWVkIHRvIGNsZWFybHkgcmUtZGVmaW5lIGhvdyBuc2lzKG50bHAvbnNscCkgc2hvdWxk IG9wZXJhdGUgDQo+ID4gd2l0aCBtb2JpbGl0eSBhbmQgd2hhdCBpcyBpbi1zY29wZSBhYm91dCBt b2JpbGl0eS4NCj4gDQo+IEkgdGhpbmsgY3VycmVudCBOU0lTIGNoYXJ0ZXIgaXMgcXVpdGUgY2xl YXI7IHdlIG5lZWQgdG8gd29yayB3aXRoDQo+IHZhcmlvdXMgbW9iaWxpdHkgcHJvdG9jb2xzIGJ1 dCBub3QgZG9pbmcgdGhlIHNhbWUgd29yayBpbiBtb2JpbGl0eQ0KPiBzaWduYWxpbmcuDQogDQpb c2hsXSBZb3UncmUgcmlnaHQgZm9yIE5TSVMgY2hhcnRlciwgYnV0IEkgZ3Vlc3MgaXQncyBub3Qg Y2xlYXIgSE9XIE5TSVMgU0hPVUxEIFdPUksgV0lUSCBNT0JJTElUWSBQUk9UT0NPTC4gRm9yIGV4 YW1wbGUsIChhcyB5b3Uga25vdykgaG93IHRvIGNvb3BlcmF0ZSBjb250ZXh0IHRyYW5zZmVyIGJl Zm9yZSBvciBkdXJpbmcgaGFuZG92ZXIgKHNlZSByZXF1aXJlbWVudCBkb2MuIDUuOS41IGFuZCBm cmFtZXdvcmsgZG9jIDUuMi41KSwgaG93IHRvIHRyaWdlciBOU0lTIChOVExQKSBhZnRlciBoYW5k b3ZlciwgaG93IHRvIGRpc3RpbmN0IGEgQ3Jvc3NvdmVyIE5vZGUgKENOKSAoaG93IHRvIGZlcnJl dCB0aGUgQ04gd2l0aCBzZXNzaW9uIElELCBGbG93IElEIGFuZCBNb2JpbGl0eSBvYmplY3QgY2xl YXJseSksIGV0Yy4gDQpBcyBSb2JlcnQgd2FzIG1lbnRpb25lZCBpbiB0aGUgVmllbm5hIG1lZXRp bmcsIHdlIGFsc28gbmVlZCBtb3JlIHBpY3R1cmVzIGNvbnNpZGVyaW5nIG1vYmlsaXR5IChuZWVk aW5nIGRpc2N1c3Npb24pLiBIb3dldmVyLCBJIHdvbmRlciB3aGljaCBwaWN0dXJlcyB3aXRoIG1v YmlsaXR5IFJvYmVydCBjb25zaWRlcnMgaW4gdGhlIEZXIGRvYy4gIA0KDQpCVFcsIFNlYW1ib3kg d29ya2luZyBncm91cCB3YXMgY2xvc2VkIG5vdywgc28gKGFjY29yZGluZyB0byBKYW1lcyApIHRo ZSByZWxhdGVkIGlzc3VlcyB3aWxsIGJlIGRlYWwgd2l0aCBNb2JpbGl0eSBSZXNlYXJjaCBHcm91 cCBpbiBJUlRGLiBJIHRoaW5rIHRoZSBTZWFtb2J5IFdHLXJlbGF0ZWQgc2VudGVuY2VzIGluIHNl Y3Rpb24gNS4yLjUgb2YgZnJhbWV3b3JrIGRvYyB3aWxsIGJlIG5lZWQgbW9kaWZpY2F0aW9uIChh bHRob3VnaCBtaW5vciBwYXJ0cykuDQoNCj4gPiBUaGUgTlNJUyBpcyBjbGVhcmx5IGRpZmZlcmVu dCBmcm9tIG1vYmlsaXR5IHNpZ25hbGluZywgYnV0IHRoZSBOU0lTIA0KPiA+IHNob3VsZCBjb29w ZXJhdGUgd2l0aCBtb2JpbGl0eSBzaWduYWxpbmcgdG8gc3VwcG9ydCBzZWFtbGVzcw0KPiA+IFFv UyBzZXJ2aWNlIChlLmcuLCBwcmUtcmVzb3VyY2UgcmVzZXJ2YXRpb24pIGluIElQLWJhc2VkIHJh ZGlvIGFjY2VzcyANCj4gPiBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIHRoZSBOU0lTIHNob3VsZCBi ZSBpbmRlcGVuZGVudA0KPiA+IG9mIGFueSBzcGVjaWZpYyBNSVAgc2lnbmFsaW5nLCBidXQgc29t ZXRpbWVzIGEgbW9iaWxpdHkgc2lnbmFsaW5nIGNhbiANCj4gPiBpbml0aWF0ZSB0aGUgbnNpcyBz aWduYWxpbmcgKGUuZywgdG8gc3VwcG9ydCByZXNlcnZhdGlvbg0KPiA+IGR1cmluZyB0aGUgc3Bl Y2lmaWMgdGltZSkNCj4gDQo+IEhlcmUgeW91IHJhaXNlIHR3byBpc3N1ZXM6IHdoZXRoZXIgYWR2 YW5jZWQvcHJlLSByZXNlcnZhdGlvbiBpcw0KPiBuZWNlc3NhcnksIGFuZCB3aGljaCBjYW4gYmUg bW9iaWxpdHkgdHJpZ2dlcnMgZm9yIE5TSVMuIEkgdGhpbmsNCj4gZ2VuZXJhbGx5IHdlIGFyZSB0 ZW5kaW5nIHRvIHB1cnN1ZSBzb21ldGhpbmcgdG8gYmUgZG9uZSBhZnRlciBtb2JpbGl0eQ0KPiBz aWduYWxpbmc7IGl0IG1pZ2h0IGJlIHVzZWZ1bCBpZiB3ZSBsb29rIGF0IHRoZSBiYXNpYyByZXF1 aXJlbWVudHMNCj4gaW1wb3NlZCBieSBtb2JpbGl0eSByYXRoZXIgdGhhbiB0aGVzZSBhZHZhbmNl ZCBmZWF0dXJlcyBpbiB0aGUgZmlyc3QNCj4gcGxhY2UuIEluIHRlcm1zIG9mIE5TSVMgdHJpZ2dl ciwgSSBzZWUgYSByb3V0aW5nIGNoYW5nZSBpbiB0aGUgZGF0YSBwYXRoDQo+IGNhdXNlZCBieSBt b2JpbGl0eSBwcm90b2NvbHMgbWlnaHQgYmUgYSByZWFzb25hYmxlIHNvdXJjZS4NCiANCltzaGxd ICBJbiBJbnRlcmFjdGlvbiB3aXRoIHNlYW1sZXNzIGhhbmRvdmVyIHByb3RvY29scywgQ1QgYW5k IENBUkQgb2NjdXIgZHVyaW5nIGhhbmRvdmVyIG9yIGJlZm9yZSBoYW5kb3ZlciwgIGhvdyBkb2Vz IE5TSVMgd29yayB3aXRoIHRoZXNlIHByb3RvY29sPw== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Aug 14 11:05:28 2003 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 LAA14191 for ; Thu, 14 Aug 2003 11:05:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJew-0006nh-P8 for nsis-archive@odin.ietf.org; Thu, 14 Aug 2003 11:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EF52ku026129 for nsis-archive@odin.ietf.org; Thu, 14 Aug 2003 11:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJev-0006mS-Mb; Thu, 14 Aug 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJeQ-0006lv-Uz for nsis@optimus.ietf.org; Thu, 14 Aug 2003 11:04:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14158 for ; Thu, 14 Aug 2003 11:04:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJeO-0003Ch-00 for nsis@ietf.org; Thu, 14 Aug 2003 11:04:28 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19nJeN-0003Ce-00 for nsis@ietf.org; Thu, 14 Aug 2003 11:04:27 -0400 Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 14 Aug 2003 17:04:37 +0200 Message-ID: <3F3BA4C5.7030903@cs.uni-goettingen.de> Date: Thu, 14 Aug 2003 17:03:33 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sung Hycuk Lee CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Modeling of mobility? (mobility-related issues in framework) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Sung-Hyuck, >>> I think we need to clearly re-define how nsis(ntlp/nslp) should >>> operate with mobility and what is in-scope about mobility. >> >> I think current NSIS charter is quite clear; we need to work with >> various mobility protocols but not doing the same work in mobility >> signaling. > > [shl] You're right for NSIS charter, but I guess it's not clear HOW > NSIS SHOULD WORK WITH MOBILITY PROTOCOL. For example, (as you know) > how to cooperate context transfer before or during handover (see > requirement doc. 5.9.5 and framework doc 5.2.5), how to triger NSIS > (NTLP) after handover, how to distinct a Crossover Node (CN) (how to > ferret the CN with session ID, Flow ID and Mobility object clearly), > etc. As Robert was mentioned in the Vienna meeting, we also need more > pictures considering mobility (needing discussion). However, I wonder > which pictures with mobility Robert considers in the FW doc. If I understand Robert correctly, framework is the place to talk what are the building blocks & the way to link those blocks together, but HOW each block works internally is up to further analysis & design. > BTW, Seamboy working group was closed now, so (according to James ) > the related issues will be deal with Mobility Research Group in IRTF. > I think the Seamoby WG-related sentences in section 5.2.5 of > framework doc will be need modification (although minor parts). > > [shl] In Interaction with seamless handover protocols, CT and CARD > occur during handover or before handover, how does NSIS work with these > protocols? While the focus of NSIS is on-path signaling, I agree with you that working with SEAMOBY CT (as current charter suggests) needs more thoughts, :-) Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Aug 15 08:13:32 2003 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 IAA25578 for ; Fri, 15 Aug 2003 08:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ndS4-0008DD-Hb for nsis-archive@odin.ietf.org; Fri, 15 Aug 2003 08:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FCD4bm031563 for nsis-archive@odin.ietf.org; Fri, 15 Aug 2003 08:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ndS0-0008Cy-N1; Fri, 15 Aug 2003 08:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ndRX-00089v-Sg for nsis@optimus.ietf.org; Fri, 15 Aug 2003 08:12:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25558 for ; Fri, 15 Aug 2003 08:12:28 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ndRW-0002Ac-00 for nsis@ietf.org; Fri, 15 Aug 2003 08:12:30 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ndRV-0002AZ-00 for nsis@ietf.org; Fri, 15 Aug 2003 08:12:30 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7FCCSB16670 for ; Fri, 15 Aug 2003 15:12:28 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Aug 2003 15:12:28 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 15:12:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 15:12:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Aug 2003 15:12:24 +0300 Message-ID: Thread-Topic: New version of Req submitted Thread-Index: AcNgtRgFqDxWz7LMTSel/BPHJiRubQCcR8FA To: , Cc: , , X-OriginalArrivalTime: 15 Aug 2003 12:12:27.0179 (UTC) FILETIME=[7E1617B0:01C36326] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: New version of NSIS Req submitted Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcus, Thanks for updating the document. I hope the text changes are sufficient for Harald & Steve. Allison, as long as there are no objects, can the updated document be considered at the next IESG call? thanks, John > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 12 August, 2003 12:33 > To: Loughney John (NRC/Helsinki); Allison Mankin > Cc: nsis@ietf.org; Harald Tveit Alvestrand; Steve Bellovin > Subject: New version of Req submitted >=20 >=20 > John, Allison, >=20 > I have a new version of the requirements submitted=20 > (draft-ietf-nsis-req-09.txt). The comments from Harald and=20 > Steve have been=20 > addressed (see below for the difference between the 08 and 09=20 > of the draft. >=20 > Marcus >=20 > Section 5 (Harald's comment #1) >=20 > OLD >=20 > 5 Requirements >=20 > This section defines more detailed requirements for a=20 > signaling solution,=20 > respecting the framework, scoping assumptions, and=20 > terminology considered=20 > earlier. The requirements are in subsections, grouped roughly=20 > according to=20 > general technical aspects: architecture and design goals,=20 > topology issues,=20 > parameters, performance, security, information, and flexibility. >=20 > Two general (and potentially contradictory) goals for the=20 > solution are that=20 > it should be applicable in a very wide range of scenarios,=20 > and at the same=20 > time lightweight in implementation complexity and resource=20 > consumption=20 > requirements in NSIS Entities. One approach to this is that=20 > the solution=20 > could deal with certain requirements via modular components or=20 > capabilities, which are optional to implement or use in=20 > individual nodes. >=20 > In order to prioritize the various requirements we informally define=20 > different 'parts of the network'. In the different parts of=20 > the network a=20 > particular requirement might have a different priority. >=20 > The parts of the networks we differentiate are the=20 > host-to-first router,=20 > the access network, and the core network. The host to first=20 > router part=20 > includes all the layer 2 technologies to access to the=20 > Internet. This part=20 > of the division is especially informal and may incorporate=20 > several access=20 > segments. In many cases, there is an application and/or user=20 > running on the=20 > host initiating signaling. The access network can be=20 > characterized by low=20 > capacity links, medium speed IP processing capabilities, and it might=20 > consist of a complete layer 2 network as well. The core network=20 > characteristics include high-speed forwarding capacities and=20 > inter-domain=20 > issues. These divisions between network types are not strict=20 > and do not=20 > appear in all networks, but where they do exist they may influence=20 > signaling requirements and will be highlighted as necessary. >=20 > NEW >=20 > 5 Requirements >=20 > This section defines more detailed requirements for a=20 > signaling solution,=20 > respecting the framework, scoping assumptions, and=20 > terminology considered=20 > earlier. The requirements are in subsections, grouped roughly=20 > according to=20 > general technical aspects: architecture and design goals,=20 > topology issues,=20 > parameters, performance, security, information, and flexibility. >=20 > Two general (and potentially contradictory) goals for the=20 > solution are that=20 > it should be applicable in a very wide range of scenarios,=20 > and at the same=20 > time lightweight in implementation complexity and resource=20 > consumption=20 > requirements in NSIS Entities. We use the terms 'access' and 'core'=20 > informally in the discussion of some particular requirements=20 > to refer to=20 > deployment conditions where particular protocol attributes,=20 > especially=20 > performance characteristics, have special importance. Specifically,=20 > 'access' refers to lower capacity networks and fewer users=20 > and sessions.=20 > 'Core' refers to high capacity networks with a large number=20 > of users and=20 > sessions. >=20 > One approach to this is that the solution could deal with certain=20 > requirements via modular components or capabilities, which=20 > are optional to=20 > implement or use in individual nodes. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Req 5.5.1 Scalability (Harald's comment #2) >=20 > NEW added the following paragraph at the end of req 5.5.1 >=20 > Specifically, NSIS MUST work in Internet scale deployments,=20 > where the use=20 > of signaling by hosts becomes universal. Note that requirement 5.2.4=20 > requires the functionality of transparently signal through=20 > networks without=20 > interpretation. Additionally, requirement 5.6.1 lists the=20 > capability to=20 > aggregate. Furthermore, requirement 5.5.4 states that NSIS=20 > should be able=20 > to constrain the load on devices. Basically, the performance of the=20 > signaling MUST degrade gracefully rather than catastrophically under=20 > overload conditions. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > section 3, last paragraph (Steve Bellovin comment #1) >=20 > OLD > 5. We can see the network at the level of domains/subdomains=20 > rather than=20 > individual routers (except in the special case that the=20 > domain contains one=20 > link). Domains are assumed to be administrative entities, so security=20 > requirements apply to the signaling between them. >=20 > NEW > 5. We can see the network at the level of domains/subdomains=20 > rather than=20 > individual routers (except in the special case that the=20 > domain contains one=20 > link). Domains are assumed to be administrative entities. So security=20 > requirements might apply differently for the signaling=20 > between the domains=20 > and within a domain. Both cases we deal with in this document. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Requirement 5.7.8 (Steve Bellovin comment #2) >=20 > OLD >=20 > 5.7.8 Confidentiality of signaling messages >=20 > Based on the signaling information exchanged between nodes=20 > participating in=20 > the signaling protocol an adversary may learn both the=20 > identities and the=20 > content of the signaling messages. To prevent this from happening,=20 > confidentiality of the signaling message in a hop-by-hop=20 > manner MAY be=20 > provided. Note that the protection can be provided on a=20 > hop-by-hop basis=20 > for most message payloads since it is required that entities=20 > which actively=20 > participating in the signaling protocol must be able to read=20 > and eventually=20 > modify the content of the signaling messages. >=20 > NEW >=20 > 5.7.8 Confidentiality of signaling messages >=20 > Based on the signaling information exchanged between nodes=20 > participating in=20 > the signaling protocol an adversary may learn both the=20 > identities and the=20 > content of the signaling messages. Since the ability to=20 > listen to signaling=20 > channels is a major guide to what data channels are interesting ones. >=20 > To prevent this from happening, confidentiality of the=20 > signaling message in=20 > a hop-by-hop manner SHOULD be provided. Note that most=20 > messages must be=20 > protected on a hop-by-hop basis, since entities, which=20 > actively participate=20 > in the signaling protocol, must be able to read and=20 > eventually modify the=20 > signaling messages. >=20 >=20 > -------------------------------------- > Marcus Brunner > Network Laboratories > NEC Europe Ltd. >=20 > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus >=20 >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Aug 16 00:48:28 2003 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 AAA22949 for ; Sat, 16 Aug 2003 00:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nsyw-0005fp-Jb for nsis-archive@odin.ietf.org; Sat, 16 Aug 2003 00:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7G4m2nE021805 for nsis-archive@odin.ietf.org; Sat, 16 Aug 2003 00:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nsyv-0005fP-ID; Sat, 16 Aug 2003 00:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nf0p-0003YP-OJ for nsis@optimus.ietf.org; Fri, 15 Aug 2003 09:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27291 for ; Fri, 15 Aug 2003 09:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nf0k-0002fa-00 for nsis@ietf.org; Fri, 15 Aug 2003 09:52:58 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 19nf0j-0002ex-00 for nsis@ietf.org; Fri, 15 Aug 2003 09:52:58 -0400 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A5C861B95; Fri, 15 Aug 2003 15:52:25 +0200 (CEST) Date: Fri, 15 Aug 2003 06:36:46 -0700 From: Harald Tveit Alvestrand To: Marcus Brunner , Loughney , Allison Mankin Cc: nsis@ietf.org, Steve Bellovin Message-ID: <379870995.1060929406@localhost> In-Reply-To: <91739274.1060687981@[10.1.1.130]> References: <91739274.1060687981@[10.1.1.130]> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: New version of NSIS Req submitted Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marcus, thanks! --On 12. august 2003 11:33 +0200 Marcus Brunner wrote: > John, Allison, > > I have a new version of the requirements submitted > (draft-ietf-nsis-req-09.txt). The comments from Harald and Steve have > been addressed (see below for the difference between the 08 and 09 of the > draft. > > Marcus > > Section 5 (Harald's comment #1) > > OLD > > 5 Requirements > > This section defines more detailed requirements for a signaling solution, > respecting the framework, scoping assumptions, and terminology considered > earlier. The requirements are in subsections, grouped roughly according > to general technical aspects: architecture and design goals, topology > issues, parameters, performance, security, information, and flexibility. > > Two general (and potentially contradictory) goals for the solution are > that it should be applicable in a very wide range of scenarios, and at > the same time lightweight in implementation complexity and resource > consumption requirements in NSIS Entities. One approach to this is that > the solution could deal with certain requirements via modular components > or capabilities, which are optional to implement or use in individual > nodes. > > In order to prioritize the various requirements we informally define > different 'parts of the network'. In the different parts of the network a > particular requirement might have a different priority. > > The parts of the networks we differentiate are the host-to-first router, > the access network, and the core network. The host to first router part > includes all the layer 2 technologies to access to the Internet. This > part of the division is especially informal and may incorporate several > access segments. In many cases, there is an application and/or user > running on the host initiating signaling. The access network can be > characterized by low capacity links, medium speed IP processing > capabilities, and it might consist of a complete layer 2 network as well. > The core network characteristics include high-speed forwarding capacities > and inter-domain issues. These divisions between network types are not > strict and do not appear in all networks, but where they do exist they > may influence signaling requirements and will be highlighted as necessary. > > NEW > > 5 Requirements > > This section defines more detailed requirements for a signaling solution, > respecting the framework, scoping assumptions, and terminology considered > earlier. The requirements are in subsections, grouped roughly according > to general technical aspects: architecture and design goals, topology > issues, parameters, performance, security, information, and flexibility. > > Two general (and potentially contradictory) goals for the solution are > that it should be applicable in a very wide range of scenarios, and at > the same time lightweight in implementation complexity and resource > consumption requirements in NSIS Entities. We use the terms 'access' and > 'core' informally in the discussion of some particular requirements to > refer to deployment conditions where particular protocol attributes, > especially performance characteristics, have special importance. > Specifically, 'access' refers to lower capacity networks and fewer users > and sessions. 'Core' refers to high capacity networks with a large number > of users and sessions. > > One approach to this is that the solution could deal with certain > requirements via modular components or capabilities, which are optional > to implement or use in individual nodes. This one is fine with me. It's now clear that it's an informal definition, and the "first hop" thing has entirely gone. > > ==================================================== > Req 5.5.1 Scalability (Harald's comment #2) > > NEW added the following paragraph at the end of req 5.5.1 > > Specifically, NSIS MUST work in Internet scale deployments, where the use > of signaling by hosts becomes universal. Note that requirement 5.2.4 > requires the functionality of transparently signal through networks > without interpretation. Additionally, requirement 5.6.1 lists the > capability to aggregate. Furthermore, requirement 5.5.4 states that NSIS > should be able to constrain the load on devices. Basically, the > performance of the signaling MUST degrade gracefully rather than > catastrophically under overload conditions. This one works for me, too. > > ============================ > section 3, last paragraph (Steve Bellovin comment #1) > > OLD > 5. We can see the network at the level of domains/subdomains rather than > individual routers (except in the special case that the domain contains > one link). Domains are assumed to be administrative entities, so security > requirements apply to the signaling between them. > > NEW > 5. We can see the network at the level of domains/subdomains rather than > individual routers (except in the special case that the domain contains > one link). Domains are assumed to be administrative entities. So security > requirements might apply differently for the signaling between the > domains and within a domain. Both cases we deal with in this document. > > ============================ > Requirement 5.7.8 (Steve Bellovin comment #2) > > OLD > > 5.7.8 Confidentiality of signaling messages > > Based on the signaling information exchanged between nodes participating > in the signaling protocol an adversary may learn both the identities and > the content of the signaling messages. To prevent this from happening, > confidentiality of the signaling message in a hop-by-hop manner MAY be > provided. Note that the protection can be provided on a hop-by-hop basis > for most message payloads since it is required that entities which > actively participating in the signaling protocol must be able to read and > eventually modify the content of the signaling messages. > > NEW > > 5.7.8 Confidentiality of signaling messages > > Based on the signaling information exchanged between nodes participating > in the signaling protocol an adversary may learn both the identities and > the content of the signaling messages. Since the ability to listen to > signaling channels is a major guide to what data channels are interesting > ones. note: the last sentence does not parse. If you drop "Since", it both parses and makes sense (I think). If this is the only problem in -09, it can be fixed with an RFC Editor's note. > > To prevent this from happening, confidentiality of the signaling message > in a hop-by-hop manner SHOULD be provided. Note that most messages must > be protected on a hop-by-hop basis, since entities, which actively > participate in the signaling protocol, must be able to read and > eventually modify the signaling messages. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Aug 17 01:25:35 2003 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 BAA24555 for ; Sun, 17 Aug 2003 01:25:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oG2P-0001QV-FI for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 01:25:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7H5P9mT005484 for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 01:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oG2H-0001QH-0C; Sun, 17 Aug 2003 01:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oG1K-0001Py-Su for nsis@optimus.ietf.org; Sun, 17 Aug 2003 01:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24521 for ; Sun, 17 Aug 2003 01:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oG1H-0006Mr-00 for nsis@ietf.org; Sun, 17 Aug 2003 01:23:59 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19oG1G-0006Mm-00 for nsis@ietf.org; Sun, 17 Aug 2003 01:23:59 -0400 Received: from sait1gc9bc522b (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7H5MeJ5028973; Sun, 17 Aug 2003 14:22:42 +0900 (KST) From: "Sung Hycuk Lee" To: "Xiaoming Fu" Cc: Subject: RE: [NSIS] Modeling of mobility? (mobility-related issues in framework) Date: Sun, 17 Aug 2003 14:22:41 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3F3BA4C5.7030903@cs.uni-goettingen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQogSGkgWGlhb21pbmcsDQoNCj4gPj4+IEkgdGhpbmsgd2UgbmVlZCB0byBjbGVhcmx5IHJlLWRl ZmluZSBob3cgbnNpcyhudGxwL25zbHApIHNob3VsZA0KPiA+Pj4gb3BlcmF0ZSB3aXRoIG1vYmls aXR5IGFuZCB3aGF0IGlzIGluLXNjb3BlIGFib3V0IG1vYmlsaXR5Lg0KPiA+PiANCj4gPj4gSSB0 aGluayBjdXJyZW50IE5TSVMgY2hhcnRlciBpcyBxdWl0ZSBjbGVhcjsgd2UgbmVlZCB0byB3b3Jr IHdpdGggDQo+ID4+IHZhcmlvdXMgbW9iaWxpdHkgcHJvdG9jb2xzIGJ1dCBub3QgZG9pbmcgdGhl IHNhbWUgd29yayBpbiBtb2JpbGl0eSANCj4gPj4gc2lnbmFsaW5nLg0KPiA+IA0KPiA+IFtzaGxd IFlvdSdyZSByaWdodCBmb3IgTlNJUyBjaGFydGVyLCBidXQgSSBndWVzcyBpdCdzIG5vdCBjbGVh ciBIT1cNCj4gPiBOU0lTIFNIT1VMRCBXT1JLIFdJVEggTU9CSUxJVFkgUFJPVE9DT0wuIEZvciBl eGFtcGxlLCAoYXMgeW91IGtub3cpDQo+ID4gaG93IHRvIGNvb3BlcmF0ZSBjb250ZXh0IHRyYW5z ZmVyIGJlZm9yZSBvciBkdXJpbmcgaGFuZG92ZXIgKHNlZQ0KPiA+IHJlcXVpcmVtZW50IGRvYy4g NS45LjUgYW5kIGZyYW1ld29yayBkb2MgNS4yLjUpLCBob3cgdG8gdHJpZ2VyIE5TSVMNCj4gPiAo TlRMUCkgYWZ0ZXIgaGFuZG92ZXIsIGhvdyB0byBkaXN0aW5jdCBhIENyb3Nzb3ZlciBOb2RlIChD TikgKGhvdyB0bw0KPiA+IGZlcnJldCB0aGUgQ04gd2l0aCBzZXNzaW9uIElELCBGbG93IElEIGFu ZCBNb2JpbGl0eSBvYmplY3QgY2xlYXJseSksDQo+ID4gZXRjLiBBcyBSb2JlcnQgd2FzIG1lbnRp b25lZCBpbiB0aGUgVmllbm5hIG1lZXRpbmcsIHdlIGFsc28gbmVlZCBtb3JlDQo+ID4gcGljdHVy ZXMgY29uc2lkZXJpbmcgbW9iaWxpdHkgKG5lZWRpbmcgZGlzY3Vzc2lvbikuIEhvd2V2ZXIsIEkg d29uZGVyDQo+ID4gd2hpY2ggcGljdHVyZXMgd2l0aCBtb2JpbGl0eSBSb2JlcnQgY29uc2lkZXJz IGluIHRoZSBGVyBkb2MuDQo+IA0KPiBJZiBJIHVuZGVyc3RhbmQgUm9iZXJ0IGNvcnJlY3RseSwg ZnJhbWV3b3JrIGlzIHRoZSBwbGFjZSB0byB0YWxrIHdoYXQgDQo+IGFyZSB0aGUgYnVpbGRpbmcg YmxvY2tzICYgdGhlIHdheSB0byBsaW5rIHRob3NlIGJsb2NrcyB0b2dldGhlciwgYnV0IEhPVyAN Cj4gZWFjaCBibG9jayB3b3JrcyBpbnRlcm5hbGx5IGlzIHVwIHRvIGZ1cnRoZXIgYW5hbHlzaXMg JiBkZXNpZ24uDQoNCltzaGxdIEkgbWVhbnQgdGhhdCBOU0lTIFdHIHNob3VsZCBjbGFyaWZ5IHRo ZSBpc3N1ZXMgcmVsYXRlZCB3aXRoIG1vYmlsaXR5IGluDQpBbmFseXNpcyAmIERlc2lnbiwgYW5k IEkganVzdCB3b25kZXJlZCB3aGF0IFJvYmVydCdzIGJpZyBwaWN0dXJlIHdhcyBpbiBGVyBkb2N1 bWVudDsuDQozR1BQIG9yIDNHUFAyLXJlbGF0ZWQgaXNzdWVzIChob3cgZG9lcyBOU0lTIHdvcmsg aW4gM0c/KSwgb3IgQmV5b25kIDNHPyANCiBJZiB5b3Ugd2FzIGNvbmZ1c2VkIGJ5IG15IHdyaXRp bmcsIEknbSBzb3JyeSB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpTdW5nLUh5dWNr _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Aug 17 13:53:27 2003 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 NAA16849 for ; Sun, 17 Aug 2003 13:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oRiA-000823-GU for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 13:53:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HHr2up030874 for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 13:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oRi9-00081r-HF; Sun, 17 Aug 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oRhC-00081G-2I for nsis@optimus.ietf.org; Sun, 17 Aug 2003 13:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16840 for ; Sun, 17 Aug 2003 13:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oRh9-0001uo-00 for nsis@ietf.org; Sun, 17 Aug 2003 13:51:59 -0400 Received: from web41215.mail.yahoo.com ([66.218.93.48]) by ietf-mx with smtp (Exim 4.12) id 19oRh9-0001ue-00 for nsis@ietf.org; Sun, 17 Aug 2003 13:51:59 -0400 Message-ID: <20030817175128.33405.qmail@web41215.mail.yahoo.com> Received: from [67.161.8.79] by web41215.mail.yahoo.com via HTTP; Sun, 17 Aug 2003 10:51:28 PDT Date: Sun, 17 Aug 2003 10:51:28 -0700 (PDT) From: Vishal Zinjuvadia To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [NSIS] Questions about draft-ietf-nsis-req-09.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I had a few questions regarding the nsis req. draft and would appreciate any help. In the following paragraph from the draft: "2. Something that assists in managing state further along the signaling path, the NSIS Forwarder. The NSIS Forwarder does not interact with higher layers, but interacts with the NSIS Initiator, NSIS Responder, and possibly one or more NSIS Forwarders on the signaling path, edge-to-edge or end-to-end." I do not completely understand the necessity of direct interactions between NSIS Forwarder with NSIS Initiator and NSIS Responder. For example, in the following diagram: A-B-C-D-E-F |_____| | Domain Assuming that A and F are NSIS Initiators and Responders respectively and that B-C-D-E belong to the same domain and are NSIS Forwarders for a particular session. Why would C or D need to communicate with either of A or F. I may be missing something important here and would really appreciate if someone made it clear for me. In the following paragraph from the draft: "6. NSIS assumes layer 3 routing and the determination of next data node selection is not done by NSIS." Would this requirement have to change in any way if we decide to allow the NSIS Initiator some (partial or complete) control over the path through which the data for a particular session must flow? From the draft: " 5.1.2 NSIS MUST be designed modularly A modular design allows for more lightweight implementations, if fewer features are needed. Mutually exclusive solutions are supported. Examples for modularity: - Work over any kind of network (narrowband versus broadband, error-prone versus reliable, ...). This implies low bandwidth signaling, and elimination of redundant information MUST be supported if necessary. - State setup for uni- and bi-directional flows is possible - Extensible in the future with different add-ons for certain environments or scenarios - Protocol layering, where appropriate. This means NSIS MUST provide a base protocol, which can be adapted to different environments. " I was particularly impressed with the above requirement. The requirement for Security is known to be different in different segments of the network and IMO is a good candidate as an optional composable module. If soft-state approach is chosen, refresh reduction may also be a good candidate since it depends on the number of sessions for which the NSIS entity has to preserve state. Moreover any NSIS entity should be able to dynamically compose its stack of modules to serve the NSIS protocol. This becomes apparent in wireless networks where the requirements for any NSIS entity change dramatically depending on its position (in the access or core) in the network. This does not affect the draft's suggestions about handling handovers since NSIS sessions may have to be resignalled in such a case anyway. One question I had was: Would the role of the NSIS entity (NI,NF,NR) have any affect on what modules compose its set of features for the NSIS protocol. How would we handle situation where a single NSIS entity has multiple roles for multiple sessions that it is a part of? Running multiple processes might be an overkill and defeat the whole purpose. From the draft: " 5.4.5 Grouping of signaling for several micro-flows MAY be provided NSIS MAY group signaling information for several micro-flow into one signaling message. The goal of this is the optimization in terms of setup delay, which can happen in parallel. This helps applications requesting several flows at once. Also potential refreshes (in case of a soft state solution) might profit from grouping. However, the network needs not know that a relationship between the grouped flows exists. There MUST NOT be any transactional semantic associated with the grouping. It is only meant for optimization purposes." Let us assume that three NSIS sessions exist 1) A (NI) and G(NR), 2) B(NI) and H (NR) and 3) C(NI) and I(NR) A---+ +---G | | B---+---D---E---F---+---H | | C---+ +---I Does the grouping of signaling for micro-flows apply to this situation. In other words, would D attempt to group signaling information for the three NSIS signaling messages it receives from A, B and C? Lastly, there was no mention of prioritization of NSIS resource requests - for e.g. a NSIS request with higher priority may terminate an existing NSIS reservation and make the resources available. Has it been left out on purpose or covered implicitly somewhere in the draft? Thanks for patiently going through the email. I would appreciate any comments and/or answers to these questions. Regards, Vishal __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Aug 17 19:00:28 2003 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 TAA23670 for ; Sun, 17 Aug 2003 19:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oWVG-0006Vw-Kd for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 19:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HN02qI025030 for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 19:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oWVF-0006VX-Rs; Sun, 17 Aug 2003 19:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oWV4-0006Un-ND for nsis@optimus.ietf.org; Sun, 17 Aug 2003 18:59:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23627 for ; Sun, 17 Aug 2003 18:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oWV1-00037B-00 for nsis@ietf.org; Sun, 17 Aug 2003 18:59:47 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19oWV0-000370-00 for nsis@ietf.org; Sun, 17 Aug 2003 18:59:46 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Aug 2003 23:59:10 +0100 Message-ID: From: "Hancock, Robert" To: Xiaoming Fu Cc: nsis@ietf.org Subject: RE: [NSIS] mobility-related requirements from nsis-req-08 Date: Sun, 17 Aug 2003 23:59:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Xiaoming, You'll have to forgive me for being dense, but I'm unable to follow your argument. So far as I can see, all the scenarios and packet flows you list can be signalled for correctly and safely using 'ordinary' NSIS signalling, possibly supplemented by some special tunnel support. (BTW, nobody has ever proposed NTLP-in-NTLP tunneling, so far as I can tell; I'm not even sure what this would mean.) Specifically: *) a route optimised data flow from CN->MN can be treated like any flow from CNaddr --> MN-CoA (the type 2 routing header can be ignored) *) a non-reverse tunneled data flow from MN->CN can be treated like any flow from MN-CoA --> CNaddr (the HoAO can be ignored) *) non-route-optimised traffic from CN->MN can be treated like any flow from CNaddr --> MN-HoA, supported by additional signalling from HA --> MN-CoA (the HA has to be NSIS aware) *) reverse tunneled traffic from MN->CN can be treated like any flow from MN-HoA --> CNaddr, supported by additional signalling from MN-CoA --> HA (the MN has to run 2 signalling sessions). *) In the edge tunneling case, traffic and existing signalling messages will be hidden in a bidirectional tunnel between PARaddr and NARaddr; the ARs can carry out signalling for that tunnel. In the FMIP6 case, this is just a single level tunnel, since the ARs only ever see traffic as addressed to and from the MN-CoA (but in any case, I'm not aware of why multiple levels of 2746-style tunneling would not work). It might be helpful if you could say if you think either: a traditional 2746-like solution really would not work (and if so why), or: if you think it just would not work very well (and if so what - in simple terms - you propose in its place.) Handling an addition signalling session at the tunnel endpoints is clearly additional work; however, the 2746-like solution can be made very robust to conditions like the remote endpoint being NSIS-unaware, whereas more integrated solutions would either have to detect this and fall back to 2746 anyway, or [worse] proceed blind and run the risk of black-holing the end-to-end signalling. Both those cases strike me as unattractive, given that we will need to have 2746-like support for many other scenarios anyway. cheers, r. > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: Monday, August 11, 2003 14:44 > To: Hancock, Robert; nsis@ietf.org > Cc: 'Charles Q. Shen'; 'Paulo Mendes' > Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 > > > Robert, > > Sorry for the delay in answering your mail - I just came back > from a few > days of vocation. Some comments inline: > > Hancock, Robert wrote: > > hi xiaoming, > > > (snip) > > [reh] the fundamental question is: how are the data packets > themselves > > being routed? whatever is making them follow the route they follow > > should be invoked to make the signalling packets follow the > same route. > > (*how* to make that invocation is another issue; one approach is to > > make the signalling packets look like data packets, another is to > > make the nodes which do some forwarding which is not-purely-IP-DA > > NSIS-aware and have them route signalling packets at the NTLP level > > on the flow-id directly. see numerous other emails on that subject.) > > > > [if the data packets are being routed on something other > than 3/5 tuple > > and possibly routing header, I suspect we are in deep trouble.] > > I totally agree with you that signaling packets should follow exactly > the same route as data packets (I believe this is part of the NSIS > requirements regarding mobility and any other things). Now > let's go to > the problem of "how the data packets are routed in mobile > IP?" and look > at CN-->MN in basic Mobile IPv6 protocol first: > > - For Mobile IP without route optimization: the data packets > will stay > as normal IP packets (src: CN, dst: HoAddress) before arriving at the > HA. The HA uses IP-in-IP encapsulation to assemble these > packets towards > the MN's CoA, i.e., the tunnel entry is HA address and the > tunnel exit > is MN's CoA. In the MN, CoA --> HoA is done inside OS. To route these > data packets, per Melina's NTLP proposal we may have to rely on > NTLP-in-NTLP tunnel while according to Henning's NTLP > proposal, we can > add some functionalities to NTLP (in this case, for basic > Mobile IPv6, > routing per flow-id works.) > > - For Mobile IP with route optimization: very unfortunately, the data > packets will be destinated to CoA but with a routing header > (containing > MN's HoA). As the CoA can still be seen from the IP normal header, we > probably don't need special care to routing header, if CoA is used to > route signaling packets. > > Second, may we look at MN-->CN in basic Mobile IPv6 protocol: > > - For Mobile IP without reverse tunnel: the data packets will be > assembled as IP packets with a home address option. We only need CN's > address to route these packets, not a problem for both proposals. > > - For Mobile IP with reverse tunnel: the data packets sent by the MN > will be encapsulated within a tunnel (entry CoA, exit HA > address), with > the original IP packets destined to CN. In order to address signaling > packets inside this tunnel, we may either add another NTLP > object which > is similar to SESSION_ASSOC in RFC2746 and map the SESSION > object into > tunnel object (for Melinda's NTLP proposal), or rely on a > discovery/routing component which locates in NTLP (for Henning's NTLP > proposal), let it be aware of tunnel entry and exit and > determine which > next NTLP hop to go. > > Third, let's go to a bit more complicated case - fast > handover and hmipv6: > > - As my draft states, these LMM proposals add one or two > tunnels in the > path where data packets traverse in basic Mobile IP. It becomes > problematic if we re-apply RFC2746 every time when a data packet goes > into a tunnel (and exits) - imagine how things work if we handle 2+ > levels of tunnels each by a SESSION_ASSOC object and mapping between > SESSION <--> tunnel SESSION object (each level the same > object type? yet > another new type for another level?). In this case, Henning's NTLP > proposal seems to be more appealing, - if we even need to signal into > such tunnels. On the other hand, I think this holds as long > as QoS NSLP > demands - Hemant's draft "Requirements of a QoS Solution for Mobile > IP" states "QoS mechanism for Mobile IP SHOULD have > provisions to handle > such heterogeneity as regards the QoS mechanisms deployed along > different packet paths. ... A QoS mechanism SHOULD be able to support > QoS along the different potential packet paths. " > > In a short summary: > - 3/5-tuple flow-id could be insufficient to address NTLP > messages; some > additional views are needed for mobility scenarios. > - Mobility is more about an NTLP issue, not only an NSLP > issue (although > NSLP might be necessary to be aware of mobility). > > Cheers, > Xiaoming > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Aug 17 19:00:28 2003 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 TAA23673 for ; Sun, 17 Aug 2003 19:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oWVG-0006Vv-Kh for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 19:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HN022O025029 for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 19:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oWVF-0006VO-4I; Sun, 17 Aug 2003 19:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oWV4-0006Um-Kx for nsis@optimus.ietf.org; Sun, 17 Aug 2003 18:59:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23625 for ; Sun, 17 Aug 2003 18:59:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oWV1-000378-00 for nsis@ietf.org; Sun, 17 Aug 2003 18:59:47 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19oWV0-00036z-00 for nsis@ietf.org; Sun, 17 Aug 2003 18:59:46 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Aug 2003 23:59:10 +0100 Message-ID: From: "Hancock, Robert" To: Sung Hycuk Lee , Xiaoming Fu Cc: nsis@ietf.org Subject: RE: [NSIS] Modeling of mobility? (mobility-related issues in fram ework) Date: Sun, 17 Aug 2003 23:59:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA23628 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Sung-Hyuck, Xiaoming: Some [more] comments about frameworks scope and mobility. You are quite right that in the long term, it may be necessary=20 to explain how to use NSIS signalling protocols in particular network environments. However, we want to be careful not to make the NSIS protocol designs specific to any particular environments; therefore, for example, I wouldn't want the framework to discuss 3G networks as a specific case. We have material in the requirements document to remind us not to forget about this, but the engineering discussion=20 in the framework should be as general as possible. The other point is that the framework is supposed to cover *all* signalling applications in the scope of NSIS, but the correct mobility handling (taking into account cost tradeoffs, performance benefits) will be quite dependent on the application in question. For example: *) for QoS, having parallel reservations on old and new paths has a cost and should be avoided, but typically doesn't affect the correctnes= s of network behaviour (i.e. it's not dangerous); *) for firewall pinholing, having pinholes open for two paths is a very low additional cost, but leaving open a pinhole on the old path for an address that has since be re-assigned could be a disaster. It's because of issues like this that I don't believe it's possible to=20 give a general statement about 'how signalling should interact with mobil= ity'. Therefore, the approach we are currently taking is that the mobility specific functionality in the lower (general) layer, the NTLP, is limited. To achieve proper mobility functionality in any particular signalling=20 application, the designers of that application will have to do their own analysis of how the events and state transitions of that application=20 should interact with events and state transitions of mobility signalling. (That, incidentally, is analysis that I am very interested in seeing done and contributing to.) To summarise: 1) I suspect the sort of detail you are looking for is not currently in t= he framework 2) I have currently no plans to put it in the framework. Of course, I'm at the mercy of JL and the rest of the WG on this, and people who think t= his approach is misguided should speak up. 3) The analysis definitely has to be done, and I believe it has to be=20 done at the signalling application level. 4) The layer split has been chosen such that (I hope) the results of (3) = won't invalidate what the framework actually does say. Does this address your concerns? r. > -----Original Message----- > From: Sung Hycuk Lee [mailto:starsu@sait.samsung.co.kr] > Sent: Sunday, August 17, 2003 06:23 > To: Xiaoming Fu > Cc: nsis@ietf.org > Subject: RE: [NSIS] Modeling of mobility? (mobility-related issues in > framework) >=20 >=20 >=20 > Hi Xiaoming, >=20 > > >>> I think we need to clearly re-define how nsis(ntlp/nslp) should > > >>> operate with mobility and what is in-scope about mobility. > > >>=20 > > >> I think current NSIS charter is quite clear; we need to=20 > work with=20 > > >> various mobility protocols but not doing the same work=20 > in mobility=20 > > >> signaling. > > >=20 > > > [shl] You're right for NSIS charter, but I guess it's not=20 > clear HOW > > > NSIS SHOULD WORK WITH MOBILITY PROTOCOL. For example, (as=20 > you know) > > > how to cooperate context transfer before or during handover (see > > > requirement doc. 5.9.5 and framework doc 5.2.5), how to=20 > triger NSIS > > > (NTLP) after handover, how to distinct a Crossover Node=20 > (CN) (how to > > > ferret the CN with session ID, Flow ID and Mobility=20 > object clearly), > > > etc. As Robert was mentioned in the Vienna meeting, we=20 > also need more > > > pictures considering mobility (needing discussion).=20 > However, I wonder > > > which pictures with mobility Robert considers in the FW doc. > >=20 > > If I understand Robert correctly, framework is the place to=20 > talk what=20 > > are the building blocks & the way to link those blocks=20 > together, but HOW=20 > > each block works internally is up to further analysis & design. >=20 > [shl] I meant that NSIS WG should clarify the issues related=20 > with mobility in > Analysis & Design, and I just wondered what Robert's big=20 > picture was in FW document;. > 3GPP or 3GPP2-related issues (how does NSIS work in 3G?), or=20 > Beyond 3G?=20 > If you was confused by my writing, I'm sorry that. >=20 > Regards, >=20 > Sung-Hyuckz=C8=AC(tm)=A8=A5Sx%S=CBg=B2+"z=D7=E8=AE=08m=B6>?=FF=0C> 0=D6= '=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=F9=EC >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Aug 18 03:51:36 2003 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 DAA12962 for ; Mon, 18 Aug 2003 03:51:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oenF-0004WO-1I for nsis-archive@odin.ietf.org; Mon, 18 Aug 2003 03:51:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7I7p8LT017381 for nsis-archive@odin.ietf.org; Mon, 18 Aug 2003 03:51:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oen7-0004W7-63; Mon, 18 Aug 2003 03:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oemK-0004VU-Ix for nsis@optimus.ietf.org; Mon, 18 Aug 2003 03:50:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12918 for ; Mon, 18 Aug 2003 03:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oemH-0005WF-00 for nsis@ietf.org; Mon, 18 Aug 2003 03:50:09 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19oemG-0005W9-00 for nsis@ietf.org; Mon, 18 Aug 2003 03:50:09 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 08:49:35 +0100 Message-ID: From: "Hancock, Robert" To: "'Vishal Zinjuvadia'" , nsis@ietf.org Subject: RE: [NSIS] Questions about draft-ietf-nsis-req-09.txt Date: Mon, 18 Aug 2003 08:49:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , i can make some tiny clarifications (maybe): > I had a few questions regarding the nsis req. draft > and would appreciate any help. > > In the following paragraph from the draft: > > "2. Something that assists in managing state further > along the signaling path, the NSIS Forwarder. > > The NSIS Forwarder does not interact with higher > layers, but interacts with the NSIS Initiator, NSIS > Responder, and possibly one or more NSIS Forwarders on > the signaling path, edge-to-edge or end-to-end." > > I do not completely understand the necessity of > direct interactions between NSIS Forwarder with NSIS > Initiator and NSIS Responder. For example, in the > following diagram: > > A-B-C-D-E-F > |_____| > | > Domain > > Assuming that A and F are NSIS Initiators and > Responders respectively and that B-C-D-E belong to the > same domain and are NSIS Forwarders for a particular > session. Why would C or D need to communicate with > either of A or F. I may be missing something important > here and would really appreciate if someone made it > clear for me. [reh] in these cases, the interactions may be with neighbour NEs only (C talks to B which talks to A). > > In the following paragraph from the draft: > > "6. NSIS assumes layer 3 routing and the > determination of next data node selection is not done > by NSIS." > > Would this requirement have to change in any way if we > decide to allow the NSIS Initiator some (partial or > complete) control over the path through which the data > for a particular session must flow? [reh] the node with NI functionality could do this, but it would not be part of NSIS functionality to specify how. In other words, there could be node implementations which coordinate routing and signalling, but this doesn't alter the signalling requirement. > > From the draft: > > " 5.1.2 NSIS MUST be designed modularly > > A modular design allows for more lightweight > implementations, if fewer features are needed. > Mutually exclusive solutions are supported. Examples > for modularity: > > - Work over any kind of network (narrowband versus > broadband, error-prone versus reliable, ...). This > implies low bandwidth signaling, and elimination of > redundant information MUST be supported if necessary. > > > - State setup for uni- and bi-directional flows is > possible > > - Extensible in the future with different add-ons > for certain environments or scenarios > > - Protocol layering, where appropriate. This means > NSIS MUST provide a base protocol, which can be > adapted to different environments. " > > I was particularly impressed with the above > requirement. The requirement for Security is known to > be different in different segments of the network and > IMO is a good candidate as an optional composable > module. If soft-state approach is chosen, refresh > reduction may also be a good candidate since it > depends on the number of sessions for which the NSIS > entity has to preserve state. Moreover any NSIS entity > should be able to dynamically compose its stack of > modules to serve the NSIS protocol. This becomes > apparent in wireless networks where the requirements > for any NSIS entity change dramatically depending on > its position (in the access or core) in the network. > This does not affect the draft's suggestions about > handling handovers since NSIS sessions may have to be > resignalled in such a case anyway. > > One question I had was: Would the role of the NSIS > entity (NI,NF,NR) have any affect on what modules > compose its set of features for the NSIS protocol. How > would we handle situation where a single NSIS entity > has multiple roles for multiple sessions that it is a > part of? Running multiple processes might be an > overkill and defeat the whole purpose. [reh] I think the answer to the first question in this last paragraph is 'yes, obviously' and to the second is 'it is up to the implementor'. > > From the draft: > > " 5.4.5 Grouping of signaling for several micro-flows > MAY be provided > > NSIS MAY group signaling information for several > micro-flow into one signaling message. The goal of > this is the optimization in terms of setup delay, > which can happen in parallel. This helps applications > requesting several flows at once. Also potential > refreshes (in case of a soft state solution) might > profit from grouping. > > However, the network needs not know that a > relationship between the grouped flows exists. There > MUST NOT be any transactional semantic associated with > the grouping. It is only meant for optimization > purposes." > > Let us assume that three NSIS sessions exist 1) A (NI) > and G(NR), > 2) B(NI) and H (NR) and 3) C(NI) and I(NR) > > A---+ +---G > | | > B---+---D---E---F---+---H > | | > C---+ +---I > > Does the grouping of signaling for micro-flows apply > to this situation. In other words, would D attempt to > group signaling information for the three NSIS > signaling messages it receives from A, B and C? [reh] see the framework discussion on bundling. the interpretation in this example would be 'D could put the messages in the same packet if it found it convenient to do so' (but whether any implementation would attempt to do so is another matter). this is really a protocol design question. > > Lastly, there was no mention of prioritization of NSIS > resource requests - for e.g. a NSIS request with > higher priority may terminate an existing NSIS > reservation and make the resources available. Has it > been left out on purpose or covered implicitly > somewhere in the draft? [reh] this is being discussed as something which can be achieved within the QoS signalling application protocol. the need for the functionality is understood, but currently it's not clear that there needs to be a direct requirement on the protocol itself. > > Thanks for patiently going through the email. I would > appreciate any comments and/or answers to these > questions. > > Regards, > Vishal hope this helps, r. > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Aug 18 10:31:30 2003 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 KAA20928 for ; Mon, 18 Aug 2003 10:31:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol2G-0007Q3-Es for nsis-archive@odin.ietf.org; Mon, 18 Aug 2003 10:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IEV4PY028518 for nsis-archive@odin.ietf.org; Mon, 18 Aug 2003 10:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol2E-0007Pg-3K; Mon, 18 Aug 2003 10:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol1G-0007Nx-Vl for nsis@optimus.ietf.org; Mon, 18 Aug 2003 10:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20878 for ; Mon, 18 Aug 2003 10:29:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ol1E-0007PB-00 for nsis@ietf.org; Mon, 18 Aug 2003 10:30:00 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19ol1D-0007P3-00 for nsis@ietf.org; Mon, 18 Aug 2003 10:29:59 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h7IETOVI014561; Mon, 18 Aug 2003 16:29:28 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C6BE2BCCB3; Mon, 18 Aug 2003 16:05:20 +0200 (CEST) Date: Mon, 18 Aug 2003 16:29:24 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: "Hancock, Robert" , "'Vishal Zinjuvadia'" Cc: nsis@ietf.org Subject: RE: [NSIS] Questions about draft-ietf-nsis-req-09.txt Message-ID: <26071138.1061224164@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vishal, see comment inline --On Montag, 18. August 2003 08:49 +0100 "Hancock, Robert" wrote: > i can make some tiny clarifications (maybe): > >> I had a few questions regarding the nsis req. draft >> and would appreciate any help. >> >> In the following paragraph from the draft: >> >> "2. Something that assists in managing state further >> along the signaling path, the NSIS Forwarder. >> >> The NSIS Forwarder does not interact with higher >> layers, but interacts with the NSIS Initiator, NSIS >> Responder, and possibly one or more NSIS Forwarders on >> the signaling path, edge-to-edge or end-to-end." >> >> I do not completely understand the necessity of >> direct interactions between NSIS Forwarder with NSIS >> Initiator and NSIS Responder. For example, in the >> following diagram: >> >> A-B-C-D-E-F >> | _____| >> | >> Domain >> >> Assuming that A and F are NSIS Initiators and >> Responders respectively and that B-C-D-E belong to the >> same domain and are NSIS Forwarders for a particular >> session. Why would C or D need to communicate with >> either of A or F. I may be missing something important >> here and would really appreciate if someone made it >> clear for me. > > [reh] in these cases, the interactions may be with neighbour > NEs only (C talks to B which talks to A). > Here it is going to be very design specific. For example, an error message or notification, could be directly send from D to A. But this has some security implication we are trying to sort out in the framework draft and the NTLP design. >> >> In the following paragraph from the draft: >> >> "6. NSIS assumes layer 3 routing and the >> determination of next data node selection is not done >> by NSIS." >> >> Would this requirement have to change in any way if we >> decide to allow the NSIS Initiator some (partial or >> complete) control over the path through which the data >> for a particular session must flow? > > [reh] the node with NI functionality could do this, but > it would not be part of NSIS functionality to specify how. > In other words, there could be node implementations which > coordinate routing and signalling, but this doesn't alter > the signalling requirement. > Basically, the paragraph restricts to path-coupled signaling, where follows the data path. With any implementation of tight integration of routing and signaling you can achieve any behaviour you want for a limited part of the network. [...] Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Aug 18 11:57:33 2003 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 LAA24756 for ; Mon, 18 Aug 2003 11:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omNT-0002SQ-Sz for nsis-archive@odin.ietf.org; Mon, 18 Aug 2003 11:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IFv3HM009440 for nsis-archive@odin.ietf.org; Mon, 18 Aug 2003 11:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omNR-0002S9-9X; Mon, 18 Aug 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omNJ-0002Rx-1a for nsis@optimus.ietf.org; Mon, 18 Aug 2003 11:56:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24735 for ; Mon, 18 Aug 2003 11:56:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19omNH-0000da-00 for nsis@ietf.org; Mon, 18 Aug 2003 11:56:51 -0400 Received: from web41207.mail.yahoo.com ([66.218.93.40]) by ietf-mx with smtp (Exim 4.12) id 19omNG-0000dA-00 for nsis@ietf.org; Mon, 18 Aug 2003 11:56:51 -0400 Message-ID: <20030818155619.73963.qmail@web41207.mail.yahoo.com> Received: from [206.54.51.125] by web41207.mail.yahoo.com via HTTP; Mon, 18 Aug 2003 08:56:19 PDT Date: Mon, 18 Aug 2003 08:56:19 -0700 (PDT) From: Vishal Zinjuvadia Subject: RE: [NSIS] Questions about draft-ietf-nsis-req-09.txt To: Marcus Brunner , "Hancock, Robert" Cc: nsis@ietf.org In-Reply-To: <26071138.1061224164@[10.1.1.130]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Thanks for your answers. Vishal --- Marcus Brunner wrote: > Vishal, > > see comment inline > --On Montag, 18. August 2003 08:49 +0100 "Hancock, > Robert" > wrote: > > > i can make some tiny clarifications (maybe): > > > >> I had a few questions regarding the nsis req. > draft > >> and would appreciate any help. > >> > >> In the following paragraph from the draft: > >> > >> "2. Something that assists in managing state > further > >> along the signaling path, the NSIS Forwarder. > >> > >> The NSIS Forwarder does not interact with > higher > >> layers, but interacts with the NSIS Initiator, > NSIS > >> Responder, and possibly one or more NSIS > Forwarders on > >> the signaling path, edge-to-edge or end-to-end." > >> > >> I do not completely understand the necessity of > >> direct interactions between NSIS Forwarder with > NSIS > >> Initiator and NSIS Responder. For example, in the > >> following diagram: > >> > >> A-B-C-D-E-F > >> | _____| > >> | > >> Domain > >> > >> Assuming that A and F are NSIS Initiators and > >> Responders respectively and that B-C-D-E belong > to the > >> same domain and are NSIS Forwarders for a > particular > >> session. Why would C or D need to communicate > with > >> either of A or F. I may be missing something > important > >> here and would really appreciate if someone made > it > >> clear for me. > > > > [reh] in these cases, the interactions may be with > neighbour > > NEs only (C talks to B which talks to A). > > > > Here it is going to be very design specific. For > example, an error message > or notification, could be directly send from D to A. > But this has some > security implication we are trying to sort out in > the framework draft and > the NTLP design. > > >> > >> In the following paragraph from the draft: > >> > >> "6. NSIS assumes layer 3 routing and the > >> determination of next data node selection is not > done > >> by NSIS." > >> > >> Would this requirement have to change in any way > if we > >> decide to allow the NSIS Initiator some (partial > or > >> complete) control over the path through which the > data > >> for a particular session must flow? > > > > [reh] the node with NI functionality could do > this, but > > it would not be part of NSIS functionality to > specify how. > > In other words, there could be node > implementations which > > coordinate routing and signalling, but this > doesn't alter > > the signalling requirement. > > > > Basically, the paragraph restricts to path-coupled > signaling, where follows > the data path. With any implementation of tight > integration of routing and > signaling you can achieve any behaviour you want for > a limited part of the > network. > > [...] > > Marcus > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Aug 24 18:36:26 2003 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 SAA29342 for ; Sun, 24 Aug 2003 18:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3St-0001Hg-Oh for nsis-archive@odin.ietf.org; Sun, 24 Aug 2003 18:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OMa3Rv004935 for nsis-archive@odin.ietf.org; Sun, 24 Aug 2003 18:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3Ss-0001HM-61; Sun, 24 Aug 2003 18:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3Ry-0001Gb-Om for nsis@optimus.ietf.org; Sun, 24 Aug 2003 18:35:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29276 for ; Sun, 24 Aug 2003 18:34:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r3Rv-0004uO-00 for nsis@ietf.org; Sun, 24 Aug 2003 18:35:03 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19r3Ru-0004uE-00 for nsis@ietf.org; Sun, 24 Aug 2003 18:35:02 -0400 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 25 Aug 2003 00:35:10 +0200 Message-ID: <3F493D32.30707@cs.uni-goettingen.de> Date: Mon, 25 Aug 2003 00:33:22 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] mobility-related requirements from nsis-req-08 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, Thanks for your extensive comments, which are very helpful to review the mobility scenarios for NSIS. Yes, it is true that we are currently not discussing (I agree it needs to be considered in NSLP) what happens for the data packets (which are signaled for) inside an IP-in-IP tunnel, but the tunnel endpoints. In addition, I believe there might be something being overlooked: ==> Signaling should reflect the data being signaled upon the update of the tunnel. As some other interested people might also have noticed, the mobility registration itself is also soft-state based. The mobility registration phase does not occur only at t0, or during re-registration after a timeout, in the operation of mobile IP. Once a first binding cache is associated, it is possible for more than 1 tunnels segments to be added to the data path. Therefore, while the post-registration phase in ongoing in one part of the system the pre-association phase can be ongoing in another. Hancock, Robert wrote: > Hi Xiaoming, > > You'll have to forgive me for being dense, but I'm unable to follow your > argument. ==> I think both of us have been trying to clarifying things complementally. > So far as I can see, all the scenarios and packet flows you > list can be signalled for correctly and safely using 'ordinary' NSIS > signalling, possibly supplemented by some special tunnel support. (BTW, ==> Thanks, these are also my hope. (Also thanks for your acknowledgement of possibile necessity of special tunnel support). > nobody has ever proposed NTLP-in-NTLP tunneling, so far as I can tell; > I'm not even sure what this would mean.) ==> One can think of a way (although not enough efficient), to add an NTLP header to the NTLP message when it enter into a tunnel, and remove the additional NTLP header after leaving. > Specifically: > *) a route optimised data flow from CN->MN can be treated like any > flow from CNaddr --> MN-CoA (the type 2 routing header can be ignored) ==> Yes, excluded its difficulty already. > *) a non-reverse tunneled data flow from MN->CN can be treated like any > flow from MN-CoA --> CNaddr (the HoAO can be ignored) ==> Yes, also discussed. > *) non-route-optimised traffic from CN->MN can be treated like any flow > from CNaddr --> MN-HoA, supported by additional signalling from > HA --> MN-CoA (the HA has to be NSIS aware) ==> We're also almost agreeing to each other here. Are you suggesting to signal twice into the segment between HA and MN? Otherwise, I'm afraid whether a unified (for a single message at one time) 3/5-tuple flow-id would work. > *) reverse tunneled traffic from MN->CN can be treated like any flow from > MN-HoA --> CNaddr, supported by additional signalling from MN-CoA --> HA > (the MN has to run 2 signalling sessions). ==> Signaling by 2 sessions looks a bit wired/complicated to me: how to coordinate both, eg., should they be performed subsequently one after another, or parrallelly? if some error happens to one of them, should we skip another, or special notification/decision should be made? > *) In the edge tunneling case, traffic and existing signalling messages > will be hidden in a bidirectional tunnel between PARaddr and NARaddr; the ARs > can carry out signalling for that tunnel. ==> It has been identified during the MIP-QOS mailing list discussions that a scenario can be possible: while the ARs are physically locating close to each other, data packets can be traversing rather long, even into the core, and it would be desireable in such scenarios to also signal into these path. > In the FMIP6 case, this is just a > single level tunnel, since the ARs only ever see traffic as addressed to > and from the MN-CoA ==> If the PAR receives data packet arriving at PCoA, they will be tunneled to NCoA, I see this as a 2-level tunnel case (correct me if I'm wrong). >(but in any case, I'm not aware of why multiple levels > of 2746-style tunneling would not work). ==> Not "would not work", but a little bit difficult in case of multiple levels of tunnels, as it seems each level has to introduce a different object type in the NTLP header (and process them). > It might be helpful if you could say if you think > either: a traditional 2746-like solution really would not work > (and if so why), > or: if you think it just would not work very well > (and if so what - in simple terms - you propose in its place.) ==> My understanding is that RFC2746 might needs some neat work. RFC2746 discusses possible solutions to two types (type #2 and #3) of tunnels. It looks to me mobile IP tunnels most likely will be of type #3. RFC2746, essentially, recursively re-applies RSVP inside a tunnel by an additional object to help the one-to-one mapping between the tunnel session and the corresponding e2e session (the mapping is done in the tunnel entry and exit points). However, in the perspectives of the soft, possibly multiple tunnels created by mobility protocols, we might look into some technical details. > Handling an addition signalling session at the tunnel endpoints is clearly > additional work; however, the 2746-like solution can be made very robust > to conditions like the remote endpoint being NSIS-unaware, whereas more > integrated solutions would either have to detect this and fall back to 2746 > anyway, or [worse] proceed blind and run the risk of black-holing the end-to-end > signalling. Both those cases strike me as unattractive, given that we will > need to have 2746-like support for many other scenarios anyway. ==> I also think RFC2746 would be a good start for looking at NSIS mobility. Any additional comments, views would be more than appreciated. Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Aug 26 15:36:04 2003 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 PAA29418 for ; Tue, 26 Aug 2003 15:36:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjbN-0001jd-Kx for nsis-archive@odin.ietf.org; Tue, 26 Aug 2003 15:35:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJZb6G006669 for nsis-archive@odin.ietf.org; Tue, 26 Aug 2003 15:35:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjaf-0001av-6p; Tue, 26 Aug 2003 15:34:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rSwi-00089p-PS for nsis@optimus.ietf.org; Mon, 25 Aug 2003 21:48:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27131 for ; Mon, 25 Aug 2003 21:48:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rSwf-0002EA-00 for nsis@ietf.org; Mon, 25 Aug 2003 21:48:29 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19rSwe-0002Dy-00 for nsis@ietf.org; Mon, 25 Aug 2003 21:48:28 -0400 Received: from sait1gc9bc522b (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7Q1lpJ4013762 for ; Tue, 26 Aug 2003 10:47:52 +0900 (KST) From: "Sung Hycuk Lee" To: Subject: FW: [NSIS] NSLP design draft: way forward Date: Tue, 26 Aug 2003 10:47:53 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQpEZWFyIFN2ZW4gVmFuIGRlbiBCb3NjaCwNCg0KSSB3b25kZXIgaG93IHRoZSBOU0xQIGRlc2ln biB3b3JrIGFuZCB0aGUgY29uZmVyZW5jaW5nIGNhbGwgYXJlIGdvaW5nIG9uDQpJZiB0aGUgY29u ZmVyZW5jaW5nIGNhbGwgd2FzIHBlcmZvcm1lZCwgY291bGQgeW91IHRlbGwgbWUgaG93IHRoZSBO U0xQIGRlc2lnbiB3b3JrIGlzIGJlaW5nIHBsYW5uZWQ/DQoNClJlZ2FyZHMsDQoNClN1bmctSHl1 Y2sNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5zaXMtYWRtaW5A aWV0Zi5vcmcgW21haWx0bzpuc2lzLWFkbWluQGlldGYub3JnXU9uIEJlaGFsZiANCj4gT2YgU3Zl biBWYW4gZGVuIEJvc2NoDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxOCwgMjAwMyA3OjA5IFBNDQo+ IFRvOiBuc2lzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtOU0lTXSBOU0xQIGRlc2lnbiBkcmFmdDog d2F5IGZvcndhcmQNCj4gDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBEdXJpbmcgdGhlIE5TSVMgbWVl dGluZyB0aGlzIHdlZWssIGl0IHdhcyBkZWNpZGVkIHRvIHdvcmsgdG93YXJkcyBhIGpvaW50IA0K PiBOU0xQIGRyYWZ0LiBUaGUgZWRpdGluZyB0ZWFtIGNvbnNpc3RzIG9mIG9uZSByZXByZXNlbnRh dGl2ZSBvZiB0aGUgYXV0aG9yIA0KPiB0ZWFtIG9mIGVhY2ggaW5kaXZpZHVhbCBOU0xQIGNvbnRy aWJ1dGlvbi4gVGhpcyBtYWlsIG91dGxpbmVzIHRoZSB3YXkgaW4gDQo+IHdoaWNoIHdlIGludGVu ZCB0byBwcm9jZWVkLg0KPiBUaGUgbWFpbiBwdXJwb3NlIG9mIHRoZSBkcmFmdCBpcyB0aGUgY29y ZSBOU0xQIGRlc2lnbi4gVGhlIGRyYWZ0IG1heSBhbHNvIA0KPiBpZGVudGlmeSB0aGUgbmVlZCBm b3Igb3RoZXIgZG9jdW1lbnRzIGRlc2NyaWJpbmcgZS5nLiBNSUIsIG9wZXJhdGlvbmFsIA0KPiBw cmFjdGljZXMgYW5kIC9vciBiZWFyZXIgc2VydmljZSBkZWZpbml0aW9uLiBUaGUgY3VycmVudGx5 IA0KPiBwcm9wb3NlZCBwbGFuIGlzIA0KPiBhZ3JlZWQgYmV0d2VlbiB0aGUgZWRpdG9ycyBhbmQg dGhlIGNoYWlyIGFuZCBtYXkgYmUgdXBkYXRlZCBhdCBlYWNoIElFVEYgDQo+IG1lZXRpbmcuDQo+ IFRoZSBpbnRlbnRpb24gaXMgdG8gaGF2ZSBhIC0wMCB2ZXJzaW9uIGJ5IG1pZCBzZXB0ZW1iZXIg YW5kIGEgLTAxIA0KPiB2ZXJzaW9uIGJ5IA0KPiB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgKE1pbm5l YXBvbGlzKS4NCj4gVGhlIC0wMCB2ZXJzaW9uIHdvdWxkIGJlIGFuIG9wZW4sIGhpZ2gtbGV2ZWwg ZG9jdW1lbnQgaW52aXRpbmcgDQo+IGNvbW1lbnRzIGZyb20gDQo+IHRoZSBncm91cC4gSXQgd291 bGQgY29udGFpbiBhIGJhc2ljIG91dGxpbmUgb2Ygb3BlcmF0aW9uLCBzdWdnZXN0aW9ucyBmb3Ig DQo+IGFkZGl0aW9uYWwgZG9jdW1lbnRhdGlvbiwgcG90ZW50aWFsbHkgYWRkaXRpb25hbCBOVExQ IA0KPiByZXF1aXJlbWVudHMgYW5kIElBTkEgDQo+IGNvbnNpZGVyYXRpb25zIHJlbGF0ZWQgdG8g cHJvdG9jb2wgZXh0ZW5zaWJpbGl0eSAod2F5IG9mIGNyZWF0aW5nIG5ldyANCj4gb2JqZWN0cykg YW5kIFFvUyBtb2RlbHMgKHdoYXQgbWFrZXMgdXAgYSBRb1MgbW9kZWwsIGhvdyBpcyB0aGlzIA0K PiByZWZsZWN0ZWQgaW4gDQo+IHN0YW5kYXJkcyBwcm9jZWR1cmUgYW5kIGNhbiB3ZSBtYXAgUlNW UCB0byBpdCBhcyBhbiBleGFtcGxlKS4gIEl0IA0KPiB3b3VsZCBhbHNvIA0KPiBjb250YWluIGEg c2VjdGlvbiBkZXNjcmliaW5nIHNlY3VyaXR5IGFuZCBBQUEgaW50ZXJhY3Rpb25zIG1haW5seSAN Cj4gZm9jdXNlZCBvbiANCj4gdGhlIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhlIGF1dGhvcml6YXRp b24gZGVjaXNpb24gYW5kIHdoZXJlIGl0IA0KPiBpcyBpbnZva2VkIA0KPiByZXF1aXJlbWVudHMg b24gQUFBIG9iamVjdCkuIFRoZSAobWFueSkgb3BlbiBpc3N1ZXMgd2lsbCBiZSBjYXB0dXJlZCBp biBhIA0KPiBzZXBhcmF0ZSBUaGUgcHVycG9zZSBvZiB0aGUgLTAxIHZlcnNpb24gd291bGQgYmUg dHdvLWZvbGQuIE9uIHRoZSANCj4gb25lIGhhbmQsIA0KPiBtb3JlIHByb3RvY29sIGlzc3VlcyB3 aWxsIGJlIGRpc2N1c3NlZCAoZXhhbXBsZXMgaW5jbHVkZSBTL1IgDQo+IG9wZXJhdGlvbiBhbmQg DQo+IHJlZHVjZWQgc3RhdGUgb3BlcmF0aW9uKS4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBleGlz dGluZyBwcm90b2NvbCBiYXNpY3MgDQo+IHdpbGwgYmUgd29ya2VkIG91dCBpbiBtb3JlIGRldGFp bCAobWVzc2FnZSBmbG93cywgaGlnaC1sZXZlbCBtZXNzYWdlIA0KPiBmb3JtYXRzKS4NCj4gTGF0 ZXIgdmVyc2lvbnMgb2YgdGhlIGRvY3VtZW50IHdpbGwgd2lsbCBjb250YWluIGFkZGl0aW9uYWwg ZnVuY3Rpb25hbGl0eSANCj4gaW5jbHVkaW5nIGFnZ3JlZ2F0aW9uLCB0dW5uZWwgbWFuYWdlbWVu dCwgYmlkaXJlY3Rpb25hbC9wcm94eSANCj4gb3BlcmF0aW9uIGFuZCANCj4gcHJpb3JpdHkvcHJl ZW1wdGlvbg0KPiBXZSB3ZWxjb21lIGlucHV0cyBmcm9tIHRoZSBncm91cC4gRm9yIHRoaXMgcHVy cG9zZSwgb3BlbiBjb25mZXJlbmNlIGNhbGxzIA0KPiB3aWxsIGJlIG9yZ2FuaXplZCBmb3Igd2hp Y2ggYSBudW1iZXIgb2YgbGluZXMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIA0KPiBpbnRlcmVzdGVk IHBhcnRpZXMuIEFuIGFnZW5kYSBvZiBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGNpcmN1bGF0 ZWQgDQo+IGJlZm9yZWhhbmQuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFN2ZW4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG5zaXMgbWFpbGluZyBsaXN0DQo+IG5zaXNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNpcw0KPiA= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Aug 29 05:31:56 2003 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 FAA03152 for ; Fri, 29 Aug 2003 05:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfDy-0002Xw-GD for nsis-archive@odin.ietf.org; Fri, 29 Aug 2003 05:07:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T97IpL009781 for nsis-archive@odin.ietf.org; Fri, 29 Aug 2003 05:07:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sf5y-0002Bz-Id; Fri, 29 Aug 2003 04:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sekb-0001BI-Dd for nsis@optimus.ietf.org; Fri, 29 Aug 2003 04:36:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28384 for ; Fri, 29 Aug 2003 04:36:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sekY-00059D-00 for nsis@ietf.org; Fri, 29 Aug 2003 04:36:54 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19sekX-00058T-00 for nsis@ietf.org; Fri, 29 Aug 2003 04:36:53 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 09:36:19 +0100 Message-ID: From: "Hancock, Robert" To: Seong Ho Jeong Cc: nsis@ietf.org, Sung Hycuk Lee , jh0278.bang@samsung.com, bj33.lee@samsung.com Date: Fri, 29 Aug 2003 09:36:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Subject: [NSIS] RE: Crossover node discovery issue Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi Seong Jeong, thanks for the comment and apologies for the slow response. in the framework document, i would prefer to look purely at a definition of what the crossover router is rather than mechanisms for how to discover it (which would be more of a protocol issue). i think my current definition of x-over router would be: the NSLP aware node which, for a given session id, has one neighbour NE in one direction but two neighbour NEs in the other, and this situation may be transient (re-routing case) or long-term (multihoming case). this would probably require more wordsmithing. on the security issues, i think these are important to discuss, but at the moment I think they are more signalling application specific than NSIS generic so all we can do is talk generally. what I would really like to see is some discussion on this list of hannes' draft on the issue, http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-sid-00.txt (which is very short and easy to read!) cheers, robert h. > -----Original Message----- > From: Seong Ho Jeong [mailto:shjeong@hufs.ac.kr] > Sent: Thursday, August 07, 2003 05:20 > To: Hancock, Robert > Cc: nsis@ietf.org; Sung Hycuk Lee; jh0278.bang@samsung.com; > bj33.lee@samsung.com > Subject: Crossover node discovery issue > > > Hi Robert, > > In Section 5.2.2 (Localized Path Repair) of the framework document, > I think it would be good to give a general description of how > to discover the > crossover node in a little more detail. For example, as > discussed before, a session ID, > a flow ID, and/or a mobility object can be used for the > crossover node discovery. > In this case, we may also need to check whether or not the > use of those fields is > sufficient because some sort of authorization and > determination of session ownership may be > necessary...How about adding a general description of the > crossover node discovery > and related security issues to the framework document? > > Regards, > > Seong Jeong > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis