From nsis-bounces@ietf.org Sat Jul 30 04:49:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyn2S-0003B1-VC; Sat, 30 Jul 2005 04:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyn2R-0003At-Jy for nsis@megatron.ietf.org; Sat, 30 Jul 2005 04:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28997 for ; Sat, 30 Jul 2005 04:49:45 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DynYE-00028R-8k for nsis@ietf.org; Sat, 30 Jul 2005 05:22:41 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6U8haF3021836; Sat, 30 Jul 2005 11:43:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 11:49:36 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 11:49:35 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.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] RE: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt Date: Sat, 30 Jul 2005 11:49:35 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEA5F@esebe100.NOE.Nokia.com> Thread-Topic: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt Thread-Index: AcWGWB4FZXf0zJtCQoiay2jpPBLJrAABXVAAA6EgH/A= To: , X-OriginalArrivalTime: 30 Jul 2005 08:49:35.0481 (UTC) FILETIME=[9C8B9E90:01C594E3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Jerry, I had a quick reading of this draft, it looks fairly interesting, but I = would need to=20 re-read and analysis the scenario in a bit more detail. The scope of the document is somewhat confusing though. I orignally = thought this would be a more general solution, for example, proposing how to use NSIS QoS NSLP with SIP signaling, but you do focus on the ETS case. = Perhaps better clarifying this in the revision would helpful. Depending upon = what your target is, illustrating the basic QoS NSLP operation for consumer VOIP, without such a specific network deployment, "DiffServ-enabled MPLS = traffic=20 engineering (DSTE) [RFC3564] tunnel ..." for example, would be a good = idea. I'd suggest for a revision that you include a terminology section, as = there=20 are a lot of acronyms, and terminology that are not immediately = recognizable. Any consideration on discussing this draft in ieprep, at least to verify the usecase? This seems like it would be of interest there. thanks, John > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of > ext Ash, Gerald R (Jerry), ALABS > Sent: 12 July, 2005 00:38 > To: nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: [NSIS] RE: I-D=20 > ACTION:draft-ash-nsis-vertical-interface-00.txt=20 >=20 >=20 > Hi All, >=20 > Please review and comment on the draft 'User Application-to-User Plane > Vertical Interface' > (http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-i=09 > nterface-0 > 0.txt). =20 >=20 > The draft proposes requirements for communicating QoS > parameters/attributes between the user application layer down to the > user plane to create an NSIS session. For this discussion, SIP is the > signaling protocol assumed at the user application layer and QoS-NSIS > signaling layer protocol (QoS-NSLP) is assumed at the user=20 > plane layer. >=20 > Thanks, > Jerry >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 11, 2005 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : User Application-to-User Plane Vertical > Interface > Author(s) : J. Ash, et al. > Filename : draft-ash-nsis-vertical-interface-00.txt > Pages : 11 > Date : 2005-7-11 > =09 > This draft describes a mechanism to map QoS requirements from the > User application layer down to the user plane to create an NSIS > session. This 'vertical signaling interface' between the user > application layer and user plane is needed to communicate these QoS > requirements, such as flow priority values, to user plane network > elements. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-in terface-00 .txt _______________________________________________ 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 nsis-bounces@ietf.org Sat Jul 30 05:03:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynG1-0006T3-9Q; Sat, 30 Jul 2005 05:03:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynFz-0006Sy-At for nsis@megatron.ietf.org; Sat, 30 Jul 2005 05:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29519 for ; Sat, 30 Jul 2005 05:03:45 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dynlo-0002aS-5Z for nsis@ietf.org; Sat, 30 Jul 2005 05:36:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6U93fmP011990; Sat, 30 Jul 2005 12:03:43 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 12:03:29 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 12:03:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.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] New Draft: NSIS Signaling Protocols in Multihomed MobileNetworks Date: Sat, 30 Jul 2005 12:03:28 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEA60@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] New Draft: NSIS Signaling Protocols in Multihomed MobileNetworks Thread-Index: AcWIJyFP2KUO7OduTZuW4cJTalDX/AMvJoUg To: , X-OriginalArrivalTime: 30 Jul 2005 09:03:29.0079 (UTC) FILETIME=[8D689470:01C594E5] X-Spam-Score: 0.3 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Suwon, Thanks for that draft. This is quite a useful draft, so I hope we can = have some discussion on it. When reading, I wanted to comment on a few = things. In the intro: "Multihoming refers to a situation where an end node has several parallel communication paths to use." I think I'd modify this definition a bit. RFC 3582 has a definition for site-multihoming, so you might want to reference this. If we want to talk about host-multihoming, it usually refers to a host that has multiple, active (or potentially active) interfaces connected to different subnets which then implies multiple communication paths. Also, in the intro, I think I wouldn't want to explain why hosts / users = / networks might want to be multihomed (i.e. - the advantages of = multihoming) but rather discuss the implications of multihoming. Multihoming has = interesting implications for path-oriented signaling, and path-oriented signaling = can bring benefits for a multihomed host. For example, a host might have = both an active 802.11 interface and WCDMA interface. If the 802.11 interface = might be behind=20 a slow DSL line, making the network path on the WCDMA interface = 'better'. If the host=20 has only knowledge about the link conditions, it will not know enough = about the path=20 conditions to make an informed decision about which interface (and by = extention, which path) is 'better'. In section 3, Problem Statement, "Registration of Multiple CoAs" might = not really be in-scope of NSIS. I think quite a bit of section 4, which is good, seems to be quite = closely related to the Mobility Applicability statement. Does the group feel like it = would be useful to capture this information in that document? thanks, John > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of > ext Suwon Lee > Sent: 14 July, 2005 06:46 > To: nsis@ietf.org > Subject: [NSIS] New Draft: NSIS Signaling Protocols in Multihomed > MobileNetworks >=20 >=20 > Dear All,=20 >=20 > We would like to address that a new draft "NSIS Signaling=20 > Protocols in=20 > Multihomed Mobile Networks" was submitted. > (=20 > http://www.ietf.org/internet-drafts/draft-lee-nsis-multihoming > -mobility-00.txt ) > We would appreciate it if you would review and comment on the draft. >=20 > The draft deals with: > - Possible issues on NSIS signaling in the multihomed environments > - NSIS operations in multihomed networks > - Receiver-initiated reservation > - Sender-initiated reservation > - NSIS Applicability in multihomed scenarios > - Link/node failure > - Load balancing > - Load sharing >=20 > Abstract: > A host that is an initiator or responder of NSIS signaling=20 > messages can be not=20 > only mobile but also multihomed. Multihomed hosts and=20 > scenarios may be common > in the future IPv6-based Internet. Benefits of multihoming=20 > include increased=20 > bandwidth, load balancing, load sharing, ubiquitous access,=20 > bi-casting,=20 > resilience, and etc. NSIS signaling should be able to=20 > support various=20 > multihoming scenarios. This draft describes NSIS operations=20 > and applicability=20 > in multihomed environments. >=20 > Regards, >=20 > Suwon Lee >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 30 05:09:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynLk-0007sH-Ty; Sat, 30 Jul 2005 05:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynLj-0007rm-PS for nsis@megatron.ietf.org; Sat, 30 Jul 2005 05:09:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29723 for ; Sat, 30 Jul 2005 05:09:42 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DynrY-0002m2-Tz for nsis@ietf.org; Sat, 30 Jul 2005 05:42:38 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6U99Vsh015464; Sat, 30 Jul 2005 12:09:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 12:08:56 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 12:08:55 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.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] Draft on NSIS Operation Over IP Tunnels Date: Sat, 30 Jul 2005 12:08:55 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEA61@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] Draft on NSIS Operation Over IP Tunnels Thread-Index: AcWIL2LgLS8jmU++RnuOU+T2c4VgugMtmaxg To: , X-OriginalArrivalTime: 30 Jul 2005 09:08:55.0678 (UTC) FILETIME=[5013A1E0:01C594E6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Charles, Thanks for the draft, I think this is quite a useful analysis. As = tunneling, like multihoming, can be related to mobility, I wonder if the analysis = could go into the Mobility Applicability Statement document. =20 After that, for the BOUND_FLOW_SESSION object, do you think that this = would be a general object for all NSLPs that might run over a tunnel? One = option would be to add this to the existing NSLPs, or to write a very short = document registering this as a NSLP object in the NSIS IANA registry (when there = is one). What does the rest of the wg think? thanks, John > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of > ext Charles Shen > Sent: 14 July, 2005 07:45 > To: nsis@ietf.org > Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels >=20 >=20 > Dear all, >=20 > We've submitted a draft on "NSIS Operation Over IP Tunnels".=20 > The abstract is > as follows: >=20 > In this draft we briefly review various IP Tunnelling=20 > mechanisms and > discuss the main problems with signaling operation over IP tunnels. > We also summarize the existing RSVP operation over IP tunnels > mechanism. Then we present the design details and case examples of > an NSIS operation over IP tunnels scheme. QoS NSLP is=20 > assumed as the > NSIS signaling application in our discussion. >=20 > The document is available at >=20 > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt >=20 > Any comments are greatly appreciated! >=20 > Best regards, >=20 > Charles=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 30 05:13:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynPA-0000MT-9v; Sat, 30 Jul 2005 05:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynP8-0000L1-GB for nsis@megatron.ietf.org; Sat, 30 Jul 2005 05:13:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00016 for ; Sat, 30 Jul 2005 05:13:12 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dynux-0002x4-Ko for nsis@ietf.org; Sat, 30 Jul 2005 05:46:09 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6U97Cna032270; Sat, 30 Jul 2005 12:07:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 12:13:07 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 12:13:07 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.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] RMD Security Date: Sat, 30 Jul 2005 12:13:06 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEA62@esebe100.NOE.Nokia.com> Thread-Topic: RMD Security Thread-Index: AcWH+JRmNzf3MiEMSF2GZOJ6l42DhAM7eT5A To: , X-OriginalArrivalTime: 30 Jul 2005 09:13:07.0116 (UTC) FILETIME=[E5F206C0:01C594E6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hannes, Replying to part of this mail: > The first very important aspect that I had to realize was the there is > always a message exchange like the one shown in Fig. 1. This message > exchange below takes place even if there is no end-to-end signaling > session. If RMD is triggered based on an e2e signaling session then = the > RESERVE is created by a node outside the RMD domain and will > subsequently travel further on (e.g., to the data receiver). Such an > exchange is shown in Fig. 3 of [RMD]. Hence, the security of RMD = should > always been seen as a combination of these two exchanges.=20 Should we write-up some considerations that the combination of the two exchanges are a potential security mechanism? What I mean is if = they can be matched and this match is used to verify authenticity of the reservation, then this could be used a protection against DoS attacks, especially if state is not created until the RESERVE' is received and matched against the RESERVE message. This is somewhat conceptually = related to return routability in MIPv6. thoughts? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Jul 30 07:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DypmW-0006P2-Hz; Sat, 30 Jul 2005 07:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DypmV-0006Ox-Mf for nsis@megatron.ietf.org; Sat, 30 Jul 2005 07:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04899 for ; Sat, 30 Jul 2005 07:45:31 -0400 (EDT) Received: from bay103-f15.bay103.hotmail.com ([65.54.174.25] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyqIM-0007qF-87 for nsis@ietf.org; Sat, 30 Jul 2005 08:18:27 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Jul 2005 04:45:20 -0700 Message-ID: Received: from 65.54.174.201 by by103fd.bay103.hotmail.msn.com with HTTP; Sat, 30 Jul 2005 11:45:20 GMT X-Originating-IP: [65.54.174.201] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CEA62@esebe100.NOE.Nokia.com> From: "Hannes Tschofenig" To: john.loughney@nokia.com, hannes.tschofenig@siemens.com, nsis@ietf.org Subject: RE: [NSIS] RMD Security Date: Sat, 30 Jul 2005 13:45:20 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 30 Jul 2005 11:45:20.0873 (UTC) FILETIME=[2A16BD90:01C594FC] X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi john, >Hannes, > >Replying to part of this mail: > > > The first very important aspect that I had to realize was the there is > > always a message exchange like the one shown in Fig. 1. This message > > exchange below takes place even if there is no end-to-end signaling > > session. If RMD is triggered based on an e2e signaling session then the > > RESERVE is created by a node outside the RMD domain and will > > subsequently travel further on (e.g., to the data receiver). Such an > > exchange is shown in Fig. 3 of [RMD]. Hence, the security of RMD should > > always been seen as a combination of these two exchanges. > >Should we write-up some considerations that the combination of the >two exchanges are a potential security mechanism? What I mean is if they >can be matched and this match is used to verify authenticity of the >reservation, then this could be used a protection against DoS attacks, >especially if state is not created until the RESERVE' is received and >matched against the RESERVE message. This is somewhat conceptually related >to return routability in MIPv6. you are right. i also think that the discussions we had in the rmd context could be valuable for other areas. we haven't updated the rmd document with regard to this aspect but we certainly should. still, i think further analysis is need to complete the picture. ciao hannes > >thoughts? >John > >_______________________________________________ >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 nsis-bounces@ietf.org Sat Jul 30 09:21:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyrHF-0000nt-3x; Sat, 30 Jul 2005 09:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyrHC-0000nJ-3N for nsis@megatron.ietf.org; Sat, 30 Jul 2005 09:21:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09278 for ; Sat, 30 Jul 2005 09:21:16 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyrn1-0002jt-S8 for nsis@ietf.org; Sat, 30 Jul 2005 09:54:14 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j6UDK8Ft017185; Sat, 30 Jul 2005 14:20:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PJSG145K; Sat, 30 Jul 2005 14:22:46 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels Date: Sat, 30 Jul 2005 14:20:04 +0100 Message-ID: <006301c59509$664bdfe0$e71fff56@comm.ad.roke.co.uk> Thread-Topic: [NSIS] Draft on NSIS Operation Over IP Tunnels Thread-Index: AcWVCcZTKJOr951xTNiQin3T8AU76w== From: "Hancock, Robert" To: , , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1678563078==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1678563078== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59509.C60E5700" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C59509.C60E5700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, One thing it would be interesting to get the viewpoints of the various sets of authors on is whether the use case for the BOUND_FLOW_SESSION (in this draft) is related to the use case for the "Filter List" from draft-cheng-nsis-flowid-issues-01.txt or "Path Type" from draft-sanda-nsis-path-type-02.txt. All of these things seem to be about ways to link together multiple signalling sessions in various ways. One feels that generic=20 (multi-NSLP) solutions should be possible, but it is not clear to me exactly how many different problems there are (or how many different solutions are needed). Robert H. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com > Sent: 30 July 2005 11:09 > To: charles@cs.columbia.edu; nsis@ietf.org > Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels >=20 >=20 > Hi Charles, >=20 > Thanks for the draft, I think this is quite a useful=20 > analysis. As tunneling, like multihoming, can be related to=20 > mobility, I wonder if the analysis could go into the Mobility=20 > Applicability Statement document. =20 >=20 > After that, for the BOUND_FLOW_SESSION object, do you think=20 > that this would be a general object for all NSLPs that might=20 > run over a tunnel? One option would be to add this to the=20 > existing NSLPs, or to write a very short document registering=20 > this as a NSLP object in the NSIS IANA registry (when there is one). >=20 > What does the rest of the wg think? >=20 > thanks, > John >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org=20 > [mailto:nsis-bounces@ietf.org]On Behalf Of=20 > > ext Charles Shen > > Sent: 14 July, 2005 07:45 > > To: nsis@ietf.org > > Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels > >=20 > >=20 > > Dear all, > >=20 > > We've submitted a draft on "NSIS Operation Over IP Tunnels". > > The abstract is > > as follows: > >=20 > > In this draft we briefly review various IP Tunnelling > > mechanisms and > > discuss the main problems with signaling operation over=20 > IP tunnels. > > We also summarize the existing RSVP operation over IP tunnels > > mechanism. Then we present the design details and case=20 > examples of > > an NSIS operation over IP tunnels scheme. QoS NSLP is=20 > > assumed as the > > NSIS signaling application in our discussion. > >=20 > > The document is available at > >=20 > > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt > >=20 > > Any comments are greatly appreciated! > >=20 > > Best regards, > >=20 > > Charles > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C59509.C60E5700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Draft on NSIS Operation Over IP Tunnels

Hi,

One thing it would be interesting to get the = viewpoints of the
various sets of authors on is whether the use case = for the
BOUND_FLOW_SESSION (in this draft) is related to the = use case
for the "Filter List" from = draft-cheng-nsis-flowid-issues-01.txt
or "Path Type" from = draft-sanda-nsis-path-type-02.txt. All of
these things seem to be about ways to link together = multiple
signalling sessions in various ways. One feels that = generic
(multi-NSLP) solutions should be possible, but it is = not clear
to me exactly how many different problems there are = (or how
many different solutions are needed).

Robert H.

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of john.loughney@nokia.com
> Sent: 30 July 2005 11:09
> To: charles@cs.columbia.edu; = nsis@ietf.org
> Subject: RE: [NSIS] Draft on NSIS Operation Over = IP Tunnels
>
>
> Hi Charles,
>
> Thanks for the draft, I think this is quite a = useful
> analysis.  As tunneling, like multihoming, = can be related to
> mobility, I wonder if the analysis could go into = the Mobility
> Applicability Statement document. 
>
> After that, for the BOUND_FLOW_SESSION object, = do you think
> that this would be a general object for all = NSLPs that might
> run over a tunnel?  One option would be to = add this to the
> existing NSLPs, or to write a very short = document registering
> this as a NSLP object in the NSIS IANA registry = (when there is one).
>
> What does the rest of the wg think?
>
> thanks,
> John
>
> > -----Original Message-----
> > From: nsis-bounces@ietf.org
> [mailto:nsis-bounces@ietf.org]On= Behalf Of
> > ext Charles Shen
> > Sent: 14 July, 2005 07:45
> > To: nsis@ietf.org
> > Subject: [NSIS] Draft on NSIS Operation = Over IP Tunnels
> >
> >
> > Dear all,
> >
> > We've submitted a draft on "NSIS = Operation Over IP Tunnels".
> > The abstract is
> > as follows:
> >
> >    In this draft we briefly = review various IP Tunnelling
> > mechanisms and
> >    discuss the main problems = with signaling operation over
> IP tunnels.
> >    We also summarize the = existing RSVP operation over IP tunnels
> >    mechanism.  Then we = present the design details and case
> examples of
> >    an NSIS operation over IP = tunnels scheme.  QoS NSLP is
> > assumed as the
> >    NSIS signaling = application in our discussion.
> >
> > The document is available at
> >
> > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt
> >
> > Any comments are greatly = appreciated!
> >
> > Best regards,
> >
> > Charles
> >
> >
> >
> > = _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.or= g/mailman/listinfo/nsis
> >
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C59509.C60E5700-- --===============1678563078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1678563078==-- From nsis-bounces@ietf.org Sun Jul 31 08:55:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzDLl-0003mC-Qn; Sun, 31 Jul 2005 08:55:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzD66-0000vP-I7; Sun, 31 Jul 2005 08:39:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21840; Sun, 31 Jul 2005 08:39:16 -0400 (EDT) Received: from smtp.ci.uc.pt ([193.136.200.57] helo=smtp-2-relay.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzDc9-0001Cc-6I; Sun, 31 Jul 2005 09:12:27 -0400 Received: from smtp-2.ci.uc.pt (localhost [127.0.0.1]) by smtp-2-relay.ci.uc.pt (Postfix) with ESMTP id 99846192B60; Sun, 31 Jul 2005 13:39:02 +0100 (WEST) Received: from teste-d.ci.uc.pt (sendmail.uc.pt [193.136.200.162]) by smtp-2.ci.uc.pt (Postfix) with ESMTP id 4D10E2FD004; Sun, 31 Jul 2005 13:39:02 +0100 (WEST) Received: from [127.0.0.1] (open-28-58.ietf63.ietf.org [86.255.28.58]) by teste-d.ci.uc.pt (Postfix) with ESMTP id 0D18D4A8169; Sun, 31 Jul 2005 13:39:00 +0100 (WEST) Message-ID: <42ECD472.9010304@dei.uc.pt> Date: Sun, 31 Jul 2005 14:38:58 +0100 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org, nsis-imp@ietf.org X-Antivirus: avast! (VPS 0530-3, 29-07-2005), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Sun, 31 Jul 2005 08:55:28 -0400 Cc: Subject: [NSIS] GIMPS Java implementation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0720004692==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0720004692== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all,

You can find  the GIMPS version 6 Java implementation of the University of Coimbra in http://nsis.dei.uc.pt/.

This implementation needs a Linux platform with Java 1.4.2 to work correctly.

Even though not all functionalities of the GIMPS draft are implemented, the D-Mode and C-Mode handshake and association reuse are working properly.

You can also find a GIMPSPing Java implementation based on the GIMPSPing tool defined and implemented in C++ by University of Göettingen (http://user.informatik.uni-goettingen.de/~nsis/).

Soon we will release a more stable version of the two tools.

Best regards,

Luís Cordeiro
Informatics Engineering Department
University of Coimbra
Portugal
 --===============0720004692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0720004692==-- From nsis-bounces@ietf.org Sun Jul 31 10:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzExT-0008GL-OA; Sun, 31 Jul 2005 10:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzExS-0008G8-6o for nsis@megatron.ietf.org; Sun, 31 Jul 2005 10:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29302 for ; Sun, 31 Jul 2005 10:38:27 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzFTS-0005eU-CU for nsis@ietf.org; Sun, 31 Jul 2005 11:11:40 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j6VEbmFt004682 for ; Sun, 31 Jul 2005 15:37:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PJSG146Z; Sun, 31 Jul 2005 15:40:26 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Date: Sun, 31 Jul 2005 15:37:42 +0100 Message-ID: <001301c595dd$690407b0$f306ff56@comm.ad.roke.co.uk> Thread-Topic: IANA considerations for GIMPS Thread-Index: AcWV3cpEOO4z+GF7RAacRJYm5wlPrw== From: "Hancock, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [NSIS] IANA considerations for GIMPS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1561625165==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1561625165== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C595DD.CA0BA900" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C595DD.CA0BA900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, There is now a strawman IANA considerations section for GIMPS. This identifies the registries needed, the initial assignments, and the policies IANA should follow for new registrations. You=20 can find it online at=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue60 Note that although this defines the IANA policies (e.g. "Expert Review"), it doesn't define the technical criteria to be taken into account in applying those policies (e.g. what an "Expert"=20 should think about). The latter will be covered at the overall NSIS level in a separate document. robert h. ------_=_NextPart_001_01C595DD.CA0BA900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IANA considerations for GIMPS

Hi all,

There is now a strawman IANA considerations section = for GIMPS.
This identifies the registries needed, the initial = assignments,
and the policies IANA should follow for new = registrations. You
can find it online at
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue60

Note that although this defines the IANA policies = (e.g. "Expert
Review"), it doesn't define the technical = criteria to be taken
into account in applying those policies (e.g. what an = "Expert"
should think about). The latter will be covered at = the overall
NSIS level in a separate document.

robert h.

------_=_NextPart_001_01C595DD.CA0BA900-- --===============1561625165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1561625165==-- From nsis-bounces@ietf.org Sun Jul 31 12:19:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGXe-00056C-Uo; Sun, 31 Jul 2005 12:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGXd-000567-Rz for nsis@megatron.ietf.org; Sun, 31 Jul 2005 12:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05209 for ; Sun, 31 Jul 2005 12:19:54 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzH3k-0002Ya-6O for nsis@ietf.org; Sun, 31 Jul 2005 12:53:08 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7E720EDC; Sun, 31 Jul 2005 18:19:48 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 18:19:47 +0200 Content-class: urn:content-classes:message Subject: RE: [NSIS] RMD Security MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 Jul 2005 18:19:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [NSIS] RMD Security Thread-Index: AcWU/HVL55gfYphBTg+PXBoeQU+z7wA7DOQA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hannes Tschofenig" , , , X-OriginalArrivalTime: 31 Jul 2005 16:19:47.0441 (UTC) FILETIME=[AB575E10:01C595EB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John and All,=20 Yes, it is great finding that this signaling mechanism solves important = security concerns regarding stateless domains. Actually, we did not = think of this security feature originally, so thanks to Hannes for = pointing it out. We will make it explicite in the next version of the = draft.=20 Best regards, Attila > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] > Sent: Saturday, July 30, 2005 1:45 PM > To: john.loughney@nokia.com; hannes.tschofenig@siemens.com; > nsis@ietf.org > Subject: RE: [NSIS] RMD Security >=20 >=20 > hi john, >=20 > >Hannes, > > > >Replying to part of this mail: > > > > > The first very important aspect that I had to realize was=20 > the there is > > > always a message exchange like the one shown in Fig. 1.=20 > This message > > > exchange below takes place even if there is no end-to-end=20 > signaling > > > session. If RMD is triggered based on an e2e signaling =20 > session then the > > > RESERVE is created by a node outside the RMD domain and will > > > subsequently travel further on (e.g., to the data=20 > receiver). Such an > > > exchange is shown in Fig. 3 of [RMD]. Hence, the security=20 > of RMD should > > > always been seen as a combination of these two exchanges. > > > >Should we write-up some considerations that the combination of the > >two exchanges are a potential security mechanism? What I=20 > mean is if they > >can be matched and this match is used to verify authenticity of the > >reservation, then this could be used a protection against=20 > DoS attacks, > >especially if state is not created until the RESERVE' is received and > >matched against the RESERVE message. This is somewhat=20 > conceptually related > >to return routability in MIPv6. >=20 > you are right. i also think that the discussions we had in=20 > the rmd context=20 > could be valuable for other areas. > we haven't updated the rmd document with regard to this aspect but we=20 > certainly should. still, i think further analysis is need to=20 > complete the=20 > picture. >=20 > ciao > hannes >=20 > > > >thoughts? > >John > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 31 12:31:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGjG-0007Rn-CH; Sun, 31 Jul 2005 12:31:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGjF-0007Ri-7x for nsis@megatron.ietf.org; Sun, 31 Jul 2005 12:31:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05847 for ; Sun, 31 Jul 2005 12:31:54 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzHFK-0003C9-RQ for nsis@ietf.org; Sun, 31 Jul 2005 13:05:08 -0400 Received: from ccs (dhcp-65-162.ee.columbia.edu [128.59.65.162]) (user=qs2005 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6VGVp8O026753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 31 Jul 2005 12:31:52 -0400 (EDT) From: "Charles Shen" To: , Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels Date: Sun, 31 Jul 2005 12:31:46 -0400 Organization: Columbia University Message-ID: <000001c595ed$580cf880$a2413b80@ccs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CEA61@esebe100.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John, > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Saturday, July 30, 2005 5:09 AM > To: charles@cs.columbia.edu; nsis@ietf.org > Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels >=20 >=20 > Hi Charles, >=20 > Thanks for the draft, I think this is quite a useful=20 > analysis.=20 Thank you very much. > As tunneling, like multihoming, can be related to=20 > mobility, I wonder if the analysis could go into the Mobility=20 > Applicability Statement document. =20 >=20 Yes some analysis could go to the Mobility Applicability document since mobility (e.g. Mobile IP) makes use of tunneling. It also seems to be = true that tunneling itself does not need to be tied with mobility. So I am = not sure whether the topic itself deserves a separate document. (Indeed = RFC2746 RSVP over IP tunnel is a separate one).=20 On the other hand, I am not sure whether the scope of the Mobility Applicability Statement document would cover specific solutions. If the = NSIS operation over tunnel draft describes a specific solution (like RFC2746) would it still be appropriate to be included in the Mobility = Applicability Statement document? =20 The current version of the draft is intended to focus on more generic aspects of NSIS tunneling, without explicit description of mobility. We = are also working on applying this general scheme in the NSIS mobility environment, which I think is probably a good part of the Mobility Applicability Statement document. =20 > After that, for the BOUND_FLOW_SESSION object, do you think=20 > that this would be a general object for all NSLPs that might=20 > run over a tunnel? One option would be to add this to the=20 > existing NSLPs, or to write a very short document registering=20 > this as a NSLP object in the NSIS IANA registry (when there is one). >=20 I tend to favor having a general intra-session binding object for all = NSLPs. In fact we might also have the same question for inter-session binding.=20 Thanks. Charles > What does the rest of the wg think? >=20 > thanks, > John >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org=20 > [mailto:nsis-bounces@ietf.org]On Behalf Of=20 > > ext Charles Shen > > Sent: 14 July, 2005 07:45 > > To: nsis@ietf.org > > Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels > >=20 > >=20 > > Dear all, > >=20 > > We've submitted a draft on "NSIS Operation Over IP Tunnels". > > The abstract is > > as follows: > >=20 > > In this draft we briefly review various IP Tunnelling > > mechanisms and > > discuss the main problems with signaling operation over=20 > IP tunnels. > > We also summarize the existing RSVP operation over IP tunnels > > mechanism. Then we present the design details and case=20 > examples of > > an NSIS operation over IP tunnels scheme. QoS NSLP is=20 > > assumed as the > > NSIS signaling application in our discussion. > >=20 > > The document is available at > >=20 > > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt > >=20 > > Any comments are greatly appreciated! > >=20 > > Best regards, > >=20 > > Charles > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 31 12:33:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGkP-0007b4-7r; Sun, 31 Jul 2005 12:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGkO-0007az-6T for nsis@megatron.ietf.org; Sun, 31 Jul 2005 12:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05910 for ; Sun, 31 Jul 2005 12:33:05 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzHGU-0003EI-Hq for nsis@ietf.org; Sun, 31 Jul 2005 13:06:19 -0400 Received: from ccs (dhcp-65-162.ee.columbia.edu [128.59.65.162]) (user=qs2005 mech=LOGIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6VGWqH9006443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 31 Jul 2005 12:33:01 -0400 (EDT) From: "Charles Shen" To: "'Hancock, Robert'" , , , Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels Date: Sun, 31 Jul 2005 12:32:47 -0400 Organization: Columbia University Message-ID: <000101c595ed$84399080$a2413b80@ccs> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <006301c59509$664bdfe0$e71fff56@comm.ad.roke.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1027734438==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1027734438== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C595CB.FD27F080" This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C595CB.FD27F080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 I see them as related yet slightly different issues. =20 According to my understanding, generally Flow (packet) Classfication Information is assumed to be derived from the flow MRI. draft-cheng-nsis-flowid-issues-01.txt discussed cases where this might = not be sufficient and it might be desired to separate the flow = classification information from MRI.=20 =20 In fact there is a related case in the NSIS tunneling analysis. Packets inside the tunnel carry tunnel MRI in the outer header and the e2e MRI = in the innner header. The separation of the tunnel MRI and tunnel flow classification information will occur if flows inside the tunnel are to = be classified based on the inner header. (Although note that our chosen approach is to perform tunnel flow classification based on the outer = header due to the fact that most routers won't look at the inner header.) =20 =20 Two basic solutions to the above issue seem to be either extending the current MRI definition or having a separate flow classification = information object. The Filter_List represents one of the latter approaches. I have = a few questions about this Filter_List mechanism and would appreciate if = the authors of draft-cheng-nsis-flowid-issues-01.txt can clarify. Sec. 6.1 = says: =20 Since the NTLP does not need to modify the Flow ID or MRI every time = the address changes, the state maintained on the NSIS nodes will be more = stable, and thus requires less operation in updating.=20 =20 Wouldn't the MRI change every time you have an address change? Does this draft keep the assumption that MRI and Flow ID are tied togher? Also it seems to me we will have one session with one SESSION ID and possibly multiple FLOW IDs, then each FLOW ID may have multiple FILTER SPECS? = Please correct me if I misunderstood it.=20 =20 =20 draft-shen-nsis-tunnel-00.txt discusses intra-session associaiton, i.e. = to associate different FLOW IDs (for flow classification) with the same = SESSION ID. The association may be done for different purposes, such as = supporting NSIS operation over IP tunnels. The association can be achieved in = different ways given different assumptions about the relationship between flow classification information and MRI. Indeed, I feel that the FILTER_LIST approach with its ADD action might serve a similar function as ASSOCIATE_FLOW_SESSION. However, the action name might need to be made = more specific. i.e, to indicate whether this is for NSIS-tunnel handling or = for other purposes. =20 =20 Thanks. Charles=20 -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 Sent: Saturday, July 30, 2005 9:20 AM To: john.loughney@nokia.com; charles@cs.columbia.edu; nsis@ietf.org Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels Hi,=20 One thing it would be interesting to get the viewpoints of the=20 various sets of authors on is whether the use case for the=20 BOUND_FLOW_SESSION (in this draft) is related to the use case=20 for the "Filter List" from draft-cheng-nsis-flowid-issues-01.txt=20 or "Path Type" from draft-sanda-nsis-path-type-02.txt. All of=20 these things seem to be about ways to link together multiple=20 signalling sessions in various ways. One feels that generic=20 (multi-NSLP) solutions should be possible, but it is not clear=20 to me exactly how many different problems there are (or how=20 many different solutions are needed).=20 Robert H.=20 > -----Original Message-----=20 > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com=20 > Sent: 30 July 2005 11:09=20 > To: charles@cs.columbia.edu; nsis@ietf.org=20 > Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels=20 >=20 >=20 > Hi Charles,=20 >=20 > Thanks for the draft, I think this is quite a useful=20 > analysis. As tunneling, like multihoming, can be related to=20 > mobility, I wonder if the analysis could go into the Mobility=20 > Applicability Statement document. =20 >=20 > After that, for the BOUND_FLOW_SESSION object, do you think=20 > that this would be a general object for all NSLPs that might=20 > run over a tunnel? One option would be to add this to the=20 > existing NSLPs, or to write a very short document registering=20 > this as a NSLP object in the NSIS IANA registry (when there is one).=20 >=20 > What does the rest of the wg think?=20 >=20 > thanks,=20 > John=20 >=20 > > -----Original Message-----=20 > > From: nsis-bounces@ietf.org=20 > [mailto:nsis-bounces@ietf.org]On Behalf Of=20 > > ext Charles Shen=20 > > Sent: 14 July, 2005 07:45=20 > > To: nsis@ietf.org=20 > > Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels=20 > >=20 > >=20 > > Dear all,=20 > >=20 > > We've submitted a draft on "NSIS Operation Over IP Tunnels".=20 > > The abstract is=20 > > as follows:=20 > >=20 > > In this draft we briefly review various IP Tunnelling=20 > > mechanisms and=20 > > discuss the main problems with signaling operation over=20 > IP tunnels.=20 > > We also summarize the existing RSVP operation over IP tunnels=20 > > mechanism. Then we present the design details and case=20 > examples of=20 > > an NSIS operation over IP tunnels scheme. QoS NSLP is=20 > > assumed as the=20 > > NSIS signaling application in our discussion.=20 > >=20 > > The document is available at=20 > >=20 > > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt=20 > >=20 > > Any comments are greatly appreciated!=20 > >=20 > > Best regards,=20 > >=20 > > Charles=20 > >=20 > >=20 > >=20 > > _______________________________________________=20 > > nsis mailing list=20 > > nsis@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/nsis=20 > >=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 ------=_NextPart_000_0002_01C595CB.FD27F080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Robert,
 
I = see them as related yet slightly different issues.
 
According to my understanding, = generally Flow=20 (packet) Classfication Information is assumed to be derived from the = flow MRI.=20 draft-cheng-nsis-flowid-issues-01.txt discussed cases where this might = not be=20 sufficient and it might be desired to separate the flow classification=20 information from MRI.
 
In fact there is a = related case in=20 the NSIS tunneling analysis. Packets inside the tunnel carry tunnel MRI = in the=20 outer header and the e2e MRI in the innner header. The separation of the = tunnel=20 MRI and tunnel flow classification information will occur if flows inside the tunnel are to be classified based on the inner header. = (Although=20 note that our chosen approach is to perform tunnel flow classification based on the outer = header=20 due to the fact that most routers won't look at the inner header.)  =
 
Two basic solutions to = the above issue seem to be either = extending=20 the current MRI definition = or having=20 a separate flow classification information object. The=20 Filter_List represents one = of the=20 latter approaches. I have a=20 few questions about = this=20 Filter_List mechanism and would appreciate if the authors of=20 draft-cheng-nsis-flowid-issues-01.txt can clarify. Sec. 6.1 says: =
 
   Since the = NTLP does not=20 need to modify the Flow ID or MRI every time the address changes, the = state=20 maintained on the NSIS nodes will be more stable, and thus requires less = operation in updating.
 
Wouldn't = the MRI change=20 every time you have an address change? Does this draft keep the = assumption that=20 MRI and Flow ID are tied togher? Also it seems to me we will have one = session=20 with one SESSION ID and possibly multiple FLOW IDs, then each FLOW ID = may have=20 multiple FILTER SPECS? Please correct me if I misunderstood it.=20
 
 
draft-shen-nsis-tunnel-00.txt=20 discusses intra-session associaiton, i.e. to associate different FLOW = IDs (for=20 flow classification) with the same SESSION ID.=20 The association may be done for different = purposes, such as supporting NSIS = operation=20 over IP tunnels. The = association can=20 be achieved in different ways given different assumptions about the = relationship=20 between flow classification information and MRI. Indeed, I feel that the FILTER_LIST approach = with its ADD=20 action might serve a = similar function=20 as ASSOCIATE_FLOW_SESSION. However, the action name might need to be = made more=20 specific. i.e, to indicate whether this is = for=20 NSIS-tunnel handling or for other purposes. 
 
Thanks.

Charles
------=_NextPart_000_0002_01C595CB.FD27F080-- --===============1027734438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1027734438==--
-----Original Message-----
From: = Hancock, Robert=20 [mailto:robert.hancock@roke.co.uk]
Sent: Saturday, July 30, = 2005=20 9:20 AM
To: john.loughney@nokia.com; = charles@cs.columbia.edu;=20 nsis@ietf.org
Subject: RE: [NSIS] Draft on NSIS Operation = Over IP=20 Tunnels

Hi,

One thing it would be interesting to get the = viewpoints of=20 the
various sets of authors on is whether = the use case=20 for the
BOUND_FLOW_SESSION (in this draft) = is related=20 to the use case
for the "Filter List" from=20 draft-cheng-nsis-flowid-issues-01.txt
or = "Path Type"=20 from draft-sanda-nsis-path-type-02.txt. All of
these=20 things seem to be about ways to link together multiple =
signalling sessions in various ways. One feels that generic=20
(multi-NSLP) solutions should be possible, = but it is=20 not clear
to me exactly how many different = problems=20 there are (or how
many different solutions = are=20 needed).

Robert H.

> -----Original Message-----
>=20 From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On=20
> Behalf Of = john.loughney@nokia.com=20
> Sent: 30 July 2005 11:09
>=20 To: charles@cs.columbia.edu; nsis@ietf.org
>=20 Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels =
>
>
> Hi=20 Charles,
>
> = Thanks for=20 the draft, I think this is quite a useful
>=20 analysis.  As tunneling, like multihoming, can be related to=20
> mobility, I wonder if the analysis = could go into=20 the Mobility
> Applicability Statement=20 document. 
>
>=20 After that, for the BOUND_FLOW_SESSION object, do you think =
> that this would be a general object for all NSLPs that = might=20
> run over a tunnel?  One option = would be to=20 add this to the
> existing NSLPs, or to = write a=20 very short document registering
> this as = a NSLP=20 object in the NSIS IANA registry (when there is one).
>
> What does the rest of the = wg=20 think?
>
>=20 thanks,
> John
>=20
> > -----Original Message----- =
> > From: nsis-bounces@ietf.org
> [mailto:nsis-bounces@ietf.org]On= Behalf=20 Of
> > ext Charles Shen =
> > Sent: 14 July, 2005 07:45
> >=20 To: nsis@ietf.org
> > Subject: [NSIS] = Draft on=20 NSIS Operation Over IP Tunnels
> >=20
> >
> = > Dear=20 all,
> >
> > We've=20 submitted a draft on "NSIS Operation Over IP Tunnels". =
> > The abstract is
> > = as=20 follows:
> >
>=20 >    In this draft we briefly review various IP=20 Tunnelling
> > mechanisms and =
> >    discuss the main problems with = signaling=20 operation over
> IP tunnels. =
> >    We also summarize the existing = RSVP=20 operation over IP tunnels
> = >   =20 mechanism.  Then we present the design details and case =
> examples of
> = >    an=20 NSIS operation over IP tunnels scheme.  QoS NSLP is =
> > assumed as the
>=20 >    NSIS signaling application in our = discussion.=20
> >
> > The = document is=20 available at
> >
>=20 > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt=20
> >
> > Any = comments are=20 greatly appreciated!
> > =
> > Best regards,
> >=20
> > Charles
> >=20
> >
> = >=20
> >=20 _______________________________________________
>=20 > nsis mailing list
> > = nsis@ietf.org=20
> > https://www1.ietf.or= g/mailman/listinfo/nsis=20
> >
> =
> _______________________________________________ =
> nsis mailing list
>=20 nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis=20
>