From daemon@optimus.ietf.org Mon Jul 1 06:53:38 2002 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 GAA24173 for ; Mon, 1 Jul 2002 06:53:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27394 for nsis-archive@odin.ietf.org; Mon, 1 Jul 2002 06:54:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20789; Mon, 1 Jul 2002 06:40:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20588 for ; Mon, 1 Jul 2002 06:40:03 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22530 for ; Mon, 1 Jul 2002 06:39:13 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g61AdZs02751 for ; Mon, 1 Jul 2002 12:39:35 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id g61AdZX09205 for ; Mon, 1 Jul 2002 12:39:35 +0200 (MEST) From: "Hannes Tschofenig" To: Date: Mon, 1 Jul 2002 12:44:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] New draft version - NSIS Threats Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Dear all, I have submitted a new version of the NSIS Threat draft. The draft contains a list of threats applicable to NSIS. You will also find a copy of the draft at following URL: http://www.ersue.de/nsis/draft-tschofenig-nsis-threats-01.txt Your comments are welcome! Ciao Hannes ======================================================================= Abstract As the work in the NSIS working has begun to describe requirements and the framework people started thinking about possible security implication. This document should provide a starting point for the discussion at the NSIS working group mailing list regarding the security issues that have to be addressed by a protocol or within the framework. This document does not describe vulnerabilities of a particular protocol or threats of published NSIS framework proposals. This memo is furthermore meant to create awareness for security issues within the NSIS group. Security requirements related to the threat scenarios are described in [1]. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 1 12:35:38 2002 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 MAA17114 for ; Mon, 1 Jul 2002 12:35:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16970 for nsis-archive@odin.ietf.org; Mon, 1 Jul 2002 12:36:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14749; Mon, 1 Jul 2002 12:19:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14721 for ; Mon, 1 Jul 2002 12:19:31 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15787 for ; Mon, 1 Jul 2002 12:18:43 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g61GIxK67119; Mon, 1 Jul 2002 18:18:59 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA06138; Mon, 1 Jul 2002 18:13:37 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C44224F06C; Mon, 1 Jul 2002 18:13:36 +0200 (CEST) Date: Mon, 01 Jul 2002 18:13:40 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Message-ID: <30791265.1025547220@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Robert, --On Dienstag, 25. Juni 2002 09:57 +0100 "Hancock, Robert" wrote: > Hi Marcus, > > I like this draft a lot. Especially since, following recent scope > discussions, we've been supposed to think about NSIS != QoS signalling > but broader, but all our instincts about the top level way the protocol > should operate are clearly still driven by QoS-derived thinking (although > we did our best to make the latest framework more generic, at least in > the terminology). So, thinking about the middlebox aspect is interesting. Yes, thats why I did it. > On which basis, a few questions: > > 1. On the 'directional property' (6.3) I see the reasoning clearly. The > implication of this (to me) is that the ability to support receiver > initiation as well as sender initiation is a must (in fact, a MUST). Is > this true? Actually, it is difficult to say. The reasoning is not technically motivated. Additionally, I seams to be more a security problem in terms of who is authorized to receive the service. Since there might have happen a different (high-level) signaling already, the right credential migh already be available for signaling on NSIS. > 2. With a QoS background, we've tended to think in terms of a > chain-of-trust model (in fact, a chain-of-AAA-interactions) model. Does > the same thinking apply in the middlebox case, or something more > complicated? This assumption has quite a big impact on the way an > eventual protocol gets structured (it's one of our framework critical > issues.) I am not sure what exactly the chain of trust model implies, but fact is that nodes inside the FW are trusted more than those from outside (again non technical argument). And I think the chain is not possible. I would think more in 1-to-1. Where the NSIS agent on the firewall exactly trust one entity (the final one) not over a chain of trust. > 3. Relatedly, I guess that using NSIS for this might commonly result in > partial failures ("i've set things up this far but the rest needs to be > done from the other end"). Again, thinking about semantics of > acknowledgement/error messages was one of our open issues. Do you think > that this sort of thing could be service specific (and hence opaque to > NSIS) or does the protocol have to account for it somehow? I not sure whether partial setup is a feature for QoS signaling as well. Might be a more general concept then. One the other hand, it is definitly possible to regard it service-specific. There definitly are implications, but they hold also for NSIS signaling over firewalls (not for firewall traversal) > 4. The multihomed network problem (6.5) is clearly a headache. It seems > to me that we really need a sort of ultra-lightweight path discovery > message (icmp based?) which the sender can generate (maybe at receiver > request), but which carries so little information that people will be > happy-ish (maybe...) to let it through firewalls. But i don't know > whether this is in the scope of NSIS to think about (it should be > 'on-path' enough for most people...) > I don't think we should spent too much in this direction. Marcus > Cheers, > > Robert > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 24 June 2002 20:18 >> To: nsis@ietf.org >> Subject: [NSIS] draft on middlebox communication and NSIS >> >> >> I interpreted the cut-off time wrong (9:00) though to be in >> the evening) >> Nevertheless, those of you interested in middlebox >> communication, here is a >> short text on middlebox communication in the NSIS framework. >> >> http://www.brubers.org/marcus/papers/draft-brunner-nsis-mbox-f > mwk-00.txt > > Marcus > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 1 12:35:56 2002 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 MAA17139 for ; Mon, 1 Jul 2002 12:35:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17000 for nsis-archive@odin.ietf.org; Mon, 1 Jul 2002 12:36:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14796; Mon, 1 Jul 2002 12:19:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14765 for ; Mon, 1 Jul 2002 12:19:37 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15812 for ; Mon, 1 Jul 2002 12:18:49 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g61GJ6K67137; Mon, 1 Jul 2002 18:19:06 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA06143; Mon, 1 Jul 2002 18:13:44 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 863CA4E8B9; Mon, 1 Jul 2002 18:13:43 +0200 (CEST) Date: Mon, 01 Jul 2002 18:13:46 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "'Melinda Shore'" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Message-ID: <30798015.1025547226@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit [..] >> >> At 09:57 AM 6/25/02 +0100, Hancock, Robert wrote: >> > 1. On the 'directional property' (6.3) I see the reasoning >> clearly. The implication of this (to me) is that the ability >> to support receiver initiation as well as sender initiation >> is a must (in fact, a MUST). Is this true? >> >> Not necessarily - a sender-initiated "reservation" may include >> rules to describe incoming packets. It's probably best to think >> of the problem in terms of who owns the policy in the firewall >> and who's allowed to manipulate it (and there are some rather >> difficult issues here with regard to firewalls outside the >> sender's policy domain). I tend to think of this use of signaling >> as being responsive to individual endpoint's *application's* needs, >> and not being useful for general firewall provisioning/configuration. > > I used the term 'receiver initiated' to mean 'receiver of data packets > sets up the reservation' (this is the way I think it's used in the NSIS > requirements draft). So, when you say 'sender-initiated reservation ... > incoming packets' I think we must be describing the same requirement. > (And we have to think of the incoming and outgoing flows as basically > logically distinct, because of asymmetric routing reasons.) > > The reason I raise the question is that there is an open issue in the > requirements draft about whether we can restrict NSIS to thinking about > the sender initiated case (i.e. only support signalling for reservations > about outgoing packets), since you can sometimes build a very lightweight > protocol under this assumption. However, it appears that it can't cover > all the bases (especially this one). I think in the NSIS context, it is again a question of definition of sender initiated with respect to AAA. If it is only about the data packets we are still fine, if sender initiated also means the identity behind the data sender then we have a problem. > >> >> > 2. With a QoS background, we've tended to think in terms of >> a chain-of-trust model (in fact, a chain-of-AAA-interactions) >> model. Does the same thinking apply in the middlebox case, or >> something more complicated? This assumption has quite a big >> impact on the way an eventual protocol gets structured (it's >> one of our framework critical issues.) >> >> This is a huge problem, actually. Aside from the lack of >> authentication >> infrastructure that would allow arbitrary middleboxes to authenticate >> to each other, there's an authorization problem, as well. It is >> incorrect to assume that you can trust anybody who authenticates >> correctly (assuming that's possible in the first place). > > Yep, it's clear that this is a hard issue. But even apart from the > solution, I'm still struggling to work out what the gross operational > requirements are in the multi-'domain' case (it's one of our prime > framework issues, section 3.3.3 of our latest framework draft). To be > specific, consider the following example: > > host --[1]-- nsis entity A --[2]-- nsis entity B --> rest of world > > ([1] and [2] are logical associations - we call them 'peer sessions' - > between peer NSIS entities, which might extend over multiple IP hops.) > > We've found it would be nice to assume that the AAA (at least, the first > two As) aspects of [1] are independent of the AAA aspects of [2], and so > host and NSIS B don't have any mutual authentication or authorisation (if > they do, they set up a direct peer session). But we don't know if this is > reasonable, because it obviously depends on the resource type being > signalled for. > > Actually, there is a good case for saying that AAA aspects are out of > NSIS scope because they're all resource specific (and opaque to us). But, > authentication is related to key management, and we'd like NSIS to be > able to do something sensible for its users in this area, and > authorisation models seem to affect state storage requirements where > authorisation at one node is contingent on authorisation at another node > (before or after it in the signalling chain). So, it seems we at least > need to be thinking about it at some level. > Actually, I more and more think we should deal with AA in an opaque way. As I see it with the middlebox case, the trust models muight be service, dependent and are different even for QoS depending on the scenario used. Marcus [...] -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 1 13:46:33 2002 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 NAA21742 for ; Mon, 1 Jul 2002 13:46:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24165 for nsis-archive@odin.ietf.org; Mon, 1 Jul 2002 13:47:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21943; Mon, 1 Jul 2002 13:31:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21915 for ; Mon, 1 Jul 2002 13:31:50 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20716 for ; Mon, 1 Jul 2002 13:31:01 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g61HVgRb027188; Mon, 1 Jul 2002 19:31:42 +0200 (MEST) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA08022; Mon, 1 Jul 2002 19:31:41 +0200 Received: from wrtw014 by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id TAA08415; Mon, 1 Jul 2002 19:31:41 +0200 (MET DST) Message-Id: <200207011731.TAA08415@wrtw014.wrn.ki.sw.ericsson.se> Date: Mon, 1 Jul 2002 19:31:41 +0200 (MET DST) From: Gabor Fodor Reply-To: Gabor Fodor Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt To: cedric@iprg.nokia.com Cc: nsis@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1ImuQn8UGWVWJ/ROXasamA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cedric, Thnaks for your answers, I would like to discuss one of your points here, which I believe is important: [...] > > [GF] > 4 > I am not sure that it is meaningful at this point to start > discussing specific solution approaches. You seem to propose > to use ICMP as a design base for both edge signaling and for > context transfer (AR to AR). At least for the edge signaling, > we need to consider the edge specific requirements before > we start discussing what existing or new protocol can be the > design base for that. > [GF] > Let me explain a bit here: the design base for edge signaling and > context transfer is > really 'A context transfer protocol for seamless mobility', > draft-koodli-seamoby-ctv6-03.txt. > Earlier version of draft-koodli-seamoby-ctv6 were ICMP based. However, > it is more general in this latest version, and not necessarily ICMP. As > a consequence, we mention ICMP > as a possible illustration. The main point is that QoS signaling is > redundant with context transfer, one object being transferred being QoS > context, and that CT signaling will do the job for the MN to AR QoS > signaling. > We will clarify this point. [GF] We need to understand and analyze better the requirements on the edge and the CT signaling protocols. You make a good point : the QoS signaling is to a great extent redundant with context transfer (which makes the re-use of the same design attractive), but there may as well be important differences that are connected to the wireless interface itself. I believe that there are scenarios where transferring the context from AR1 to AR2 is not sufficient to exercise admission control at and make the mecessary configurations of the new wireless link. I think we need to list the requirements for the edge protocol and go check how those are fulfilled with differenet alternatives. [GF] /Gabor _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 1 17:06:08 2002 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 RAA03153 for ; Mon, 1 Jul 2002 17:06:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12218 for nsis-archive@odin.ietf.org; Mon, 1 Jul 2002 17:06:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10613; Mon, 1 Jul 2002 16:51:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10582 for ; Mon, 1 Jul 2002 16:51:20 -0400 (EDT) Received: from hunter.ee.tu-berlin.de (pD9587451.dip.t-dialin.net [217.88.116.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02385 for ; Mon, 1 Jul 2002 16:50:31 -0400 (EDT) Received: from hunter ([127.0.0.1]) by hunter.ee.tu-berlin.de with Microsoft SMTPSVC(5.0.2172.1); Mon, 1 Jul 2002 22:50:12 +0200 Message-ID: <00b201c22140$e554f910$6b1dfea9@ee.tuberlin.de> Reply-To: "Xiaoming Fu" From: "Xiaoming Fu" To: , Cc: , References: Subject: Re: [NSIS] RE: Comments on draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 1 Jul 2002 22:50:12 +0200 Organization: TU-Berlin MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 01 Jul 2002 20:50:12.0897 (UTC) FILETIME=[E554F910:01C22140] Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Hemant and Cedric, Some comments inline: > [Hemant] In this draft, we have considered following requirements as prime ones: air interface bandwidth saving, fast QoS establishment after handoff, authentication of handoff-induced signaling (to avoid spoofing attacks) and minimizing the impact of signaling on the segment of packet path that remains unchanged after handoff. [XF] What you presented in this draft is quite interesting. Suggested ways of locating of crossover router and crossover router-related authentication are tricky, eg., - borrows a "Previous hop" way in RSVP to record the backward route - using TEAR DOWN to release unauthenticated request, and You also consider the integration of context transfer procedure at first place. [XF] While you heavily consider depreciation of over-using wireless bandwidth, I think there is a concern that resources in access networks are limited as well. It then makes sense to release the unnecessary resources as quick as one can. This implies your TEAR DOWN is helpful, even if you deploy a soft-state way. If we take the default value of time-out in RSVP (30s), 5 times larger than the default refreshment timer, as an example, it may take long to timeout the reserved resources even a mobile user moves to another point of attachment or his request being rejected by the crossover router. Therefore, while soft-state is the realistic option (I think due to best-effort feature of Internet transmission and dynamic routing, any state potentially kept in the routers would be dangerous!), releasing message is still needed. [XF] I'm not of a security expert, but it seems to me the entity performing authentication for a QoS request is the crossover router. Is it sufficient enough? Again the resources in access networks are limited, what if a misbehaved router (between MN and crossover router) modifies a QoS request? Then rest of routers would better be untouched, instead of reserving resources on! And what if an MN doesn't really want to consume QoS he requested? I think we should protect this DoS at the very edge (e.g., AR)! [XF] It looks like IPv6 signaling is your main focus (e.g., 3 > The draft talks about the negotiation procedures (in 4.2). > In my opinion the draft should identify the requirement more > clearly, preferably with a reference to either the NSIS or > the mobile IP requirement draft. Is there a difference between > negotiation (which takes place upon QoS initiation time) and > QoS adaptation signaling which may take place upon hand-over ? > > [Hemant] We have advocated one pass reservation approach in the interest of speed of QoS establishment (in other words, minimize the number of packets that may get default forwarding treatment after handoff, just because QoS signaling has not yet completed). In most of the handoff cases, the request will be granted. But, there could be cases when requested QoS < offered QoS, and then, MN may choose to have control over decision as to whether to continue or terminate the session. For this case, we have provided fallback mechanism in the form of negotiation procedure. If the MN knows at handoff time (e.g. handoff from 2.5G to WLAN or vice versa) as to whether it needs to adapt QoS after handover to the characteristics of new access, it will put the adapted QoS parameters in the QoS signaling packet in the first place. Even after that, if some router cannot offer the requested QoS, we have negotiation procedure as fallback. > [XF] In this way, you may implicate somewhat complicated application interface(s). How about push some complexity into the networks (though some violating Internet design principles, but maybe beneficial in wireless/mobile environments), say, put adaption QoS data in the AR (and let AR to decide whether to depreciate or increase a session's QoS - in fact ARs could know this e.g., by checking the AP interfaces)? An AR can gracefully forward on those info to new ARs given a first one by the MN. > 6 > You identify QoS release as a necessary functionality. > Here there is a need to identify if the protocol should > support soft state (in which case this explicit QoS release > may not be necessary) or not. > > [Hemant] In soft state approach, explicit TEAR DOWN may not be required. Of course, if inter-REFRESH period is chosen long enough to save REFRESH signaling overhead, TEAR DOWN can still help. Finally, if we go for soft state & no tear down approach, the TEAR DOWN part of the protocol can be gracefully omitted. > [XF] See above. Regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 02:20:24 2002 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 CAA26632 for ; Tue, 2 Jul 2002 02:20:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA15176 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 02:21:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14730; Tue, 2 Jul 2002 02:04:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14642 for ; Tue, 2 Jul 2002 02:04:19 -0400 (EDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22194 for ; Tue, 2 Jul 2002 02:03:26 -0400 (EDT) Received: from Freedom.icr.a-star.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g6265HBL019321; Tue, 2 Jul 2002 14:05:31 +0800 (SGT) Message-Id: <5.1.0.14.2.20020702134257.00b86230@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Jul 2002 14:03:11 +0800 To: "Hancock, Robert" , "'Zhigang.Kan@nokia.com'" , nsis@ietf.org From: "Charles Q. Shen" Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA3F3@rsys002a.roke.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA14644 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, >*) if an intermediate node is NSIS unaware, or is NSIS aware but doesn't >do any management for some particular resource, then there's nothing NSIS >can do directly to help the resource management at that node. That doesn't >stop you using some other technique to control the resource at that node >(some variant of SNMP or COPS or RMD or whatever), but so far as NSIS is >concerned, all of that would be hidden inside your RMF implementation. Do you mean an NSIS aware node is at least doing something regarding certain resources, although it might not be managing a particular resource in question, as we use resource as a general term for serval items? What actually confused me is I remember you said before: 2) even if a node does process NSIS messages, it might do so for reasons not associated with resource management. So can you elaborate on this point, if NSIS is all about resource signaling? (Unless you are talking about for example, in the case of NI and NR you may not have a RMF associated with it, but even in this case virtually the processing of NSIS message is still one segment in the whole resource management picture.) BR/Charles >i'll look forward to the 'modes of operation' questions! > >cheers, > >robert h. > >ps apologies about my email disclaimer, it's not entirely under my control >to fix it, though we're doing what we can. i am aware that i am sending >this email to a public mailing list ... > > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 28 June 2002 11:08 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > Hi Robert, > > > > Till now, I understood the definition of NE. Thank you. :-) > > It is right that we must have the common understanding of the > > terms, so we can continue the discussion further. > > > > One more thing, If one/more router(s) on the data path does > > not support RMF (as you said: if you have a distributed > > approach to resource management, i guess we would typically > > expect most nodes would have a resource management > > responsibility, but there's no requirement for every node to > > do something with resource management.), how about in this > > case? Can the QoS of data on this path be affected by these routers? > > > > Next I would like to discuss the relationship of modes of > > NSIS protocol operation such as how the end-to-end, > > edge-to-edge, and end-to-edge signaling take effects when the > > per-flow/per-class-flow traffic is initiated by a host. > > > > Nice weekend. > > > > BR/Kan Zhigang > > > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 2002å¹´6月28æ—¥ 17:33 > > To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > hi - minor correction - in 3rd sentence below, s/nodes/hosts/. > > > > r. > > > > > -----Original Message----- > > > From: Hancock, Robert > > > Sent: 28 June 2002 10:31 > > > To: 'Zhigang.Kan@nokia.com'; nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > Hi Zhigang, > > > > > > Apologies for maybe informal language. By 'box' I really mean > > > typically a physical thing you plug into a power supply, with > > > wires carrying packets into and out of it. So, usually it's a > > > host or a router. If signalling only follows the data path > > > (which is considered at the router level, not the network > > > level), the only relevant nodes can be the data flow > > > endpoints, and the only relevant routers can be the routers > > > the flow passes through. > > > > > > We've tried to describe things in terms of signalling going > > > between signalling entities rather than hosts/routers and so > > > on; one of the goals of this is to aim for concepts and > > > terminology to describe the signalling that are re-usable > > > if/when we subsequently think about signalling paths that are > > > less constrained. > > > > > > It may be (I get the impression) that the level of > > > abstraction in the framework makes it hard to get a grip on. > > > I'm not sure what would be the best way to handle this (maybe > > > some concrete example scenarios or something). > > > > > > We didn't want to make all the definitions very concrete, > > > since that implies building in assumptions about particular > > > application domains. Specifically, we have two potential > > > degrees of freedom about NSIS applicability which we've tried > > > to reflect by using more abstract language: > > > *) what sort of resources are signalled for > > > *) what sort of signalling paths are traversed > > > Currently, the first is in scope and the second not. I hope > > > we can avoid too long confusion about the > > > node/entity/network/whatever issue, because if we can't, > > > we'll probably be encouraged to re-write everything in terms > > > of routers and hosts, which will make any future extension to > > > other cases much harder. > > > > > > Cheers, > > > > > > Robert H. > > > > > > ps apologies about my email disclaimer, it's not entirely > > > under my control to fix it, though we're doing what we can. i > > > am aware that i am sending this email to a public mailing list ... > > > > > > > > > > -----Original Message----- > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > Sent: 28 June 2002 10:10 > > > > To: Hancock, Robert; nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > Hi Robert, > > > > > > > > I am more confused about 'node' is for 'box', but what in the > > > > box, a part of netwok or a whole network or whatever? Does > > > > the data pass through the box? How to understand the data > > > > path, based on per-router or per-network? Is NSIS Framework > > > > independent of the true networks and is it only abstract > > > > concept over the different environments? I cannot image how > > > > to deploy it in the future. > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: 2002å¹´6月28æ—¥ 16:28 > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > Hi Zhigang, > > > > > > > > Please see inline below. > > > > > > > > Cheers, > > > > > > > > Robert H. > > > > > > > > ps apologies about my email disclaimer, it's not entirely > > > > under my control to fix it, though we're doing what we can. i > > > > am aware that i am sending this email to a public mailing list ... > > > > > > > > > -----Original Message----- > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > Sent: 28 June 2002 08:43 > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > Q1: "Node" used in your terminology can be a router, an end > > > > > host or a server, right? > > > > > > > > [reh] yes, in the broadest sense ('node' is a fancy name for > > > > 'box'). if you respect the 'on-path' restriction, a node that > > > > processes NSIS signalling must be on the data path, which > > > > probably rules out the 'server' case. > > > > > > > > > In the case of distributed RMF, must > > > > > each node have the resource management function in a > > NSIS domain? > > > > > > > > [reh] if you have a distributed approach to resource > > > > management, i guess we would typically expect most nodes > > > > would have a resource management responsibility, but there's > > > > no requirement for every node to do something with resource > > > > management. in particular: > > > > 1) not every node has to process NSIS messages (cf. RSVP > > > > operation over non-RSVP clouds) > > > > 2) even if a node does process NSIS messages, it might do so > > > > for reasons not associated with resource management. > > > > > > > > > > > > > > Q2: The RMF is responsible for all network provisioning and > > > > > resource allocation functions, and "some" of the state > > > > > management is an RMF responsibility. How about the "other" of > > > > > the state management, and it is refered to the state > > > > > management mechanism of NSIS related with "Refresh" message? > > > > > If so, what relationship between these two parts of state > > > > > management? Is it out of the scope of NSIS? I hope answer is no. > > > > > > > > [reh] this is a hard question to answer, and a hard question > > > > in general. > > > > > > > > 1. It's clear that to do resource management, you need to > > > > store some state information. That information might be at > > > > the flow level, or some 'resource class' level, or something > > > > else. Because the state you need to store depends on the > > > > resource you are trying to manage and the precision with > > > > which you need to manage it, we don't think NSIS can define > > > > how this is done. > > > > > > > > 2. You also need state to make a protocol operate correctly. > > > > This could include all (or none) of: > > > > *) information about how to reverse-path route messages for a flow > > > > *) information about who to send an acknowledgement to and when > > > > *) information about when to send a refresh message > > > > *) information about who was authenticated when a > > > reservation was made > > > > *) and so on > > > > This is all in NSIS scope to worry about. Most of it is per-flow. > > > > > > > > 3. The relationship between these two types of state is > > > > something we discussed, but only in outline. I think a basic > > > > design goal could be stated as: > > > > "It should be possible to use [a|the] NSIS protocol in such a > > > > way that it only requires the minimum of state storage, in > > > > particular no more than the resource management mechanism > > > > that it is supporting." It's then (I think) mainly a job for > > > > the implementor to do both aspects of state management in an > > > > economical way (in particular, without duplication). So, I > > > > think we need to consider the possible interactions between > > > > the different parts of state management, and make sure they > > > > get reflected as goals for NSIS design in terms of > > > > flexibility and general usefulness of the protocol, but > > > > without defining details of exactly how the different types > > > > of state interact. > > > > > > > > This is actually a special case of a more general issue. Look > > > > also at draft-braden-2level-signal-arch-00.txt where there is > > > > the related question of the split between CSTP and ALSP. The > > > > general point is that we almost certainly can't have a pure > > > > structure of independent layers (I would expect the ALSP-like > > > > upper layer to hook into the operation of the lower layer > > > > quite intimately rather than the other way round, but that's > > > > more of a protocol design issue). The state management issue > > > > is just one aspect of this. > > > > > > > > So, I think the answer to your question is "yes and no" (if > > > > you see what I mean...) > > > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > -----Original Message----- > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > Sent: 2002å¹´6月27æ—¥ 19:02 > > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > Hi Zhigang, > > > > > > > > > > Please see inline: > > > > > > > > > > > -----Original Message----- > > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > > Sent: 27 June 2002 11:53 > > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > In the draft about In-Band & Out-of-Band: > > > > > > > > > > > > "In-band signaling means that the path followed by the user > > > > > > data packets is the same as the path followed by signaling > > > > > > messages. In other words, the signaling and data paths are > > > > > > identical. Out-of-band signaling means that the path followed > > > > > > by signaling messages might be different from the path used > > > > > > by the user data packets. " > > > > > > > > > > > > So in-band signaling is same as RSVP's operation mode? > > > > > > > > > > [reh] basically yes, from a topological ("where the messages > > > > > go") point of view. > > > > > > > > > > > And > > > > > > must it install soft states in each router it passed through > > > > > > based on per-flow or per-class-flow? > > > > > > > > > > [reh] that's one reasonable way for it to work. see 4.4 about > > > > > general state management issues; there are several different > > > > > sorts of state and several different ways to manage them. and > > > > > some of the state management is an RMF responsibility. > > > > > > > > > > > I think that it may be > > > > > > better if in-band signaling is used in access network and > > > > > > out-of-band signaling is used in backbone networks (i.e. the > > > > > > out-of-band signaling is used for communcation between RMFs > > > > > > which are responsible for the "resource" management > > > > > > independent of concrete user traffic in control plane). Is > > > > > > resource reservation really needed in backbone network now or > > > > > > in the future? > > > > > > > > > > [reh] that's a good question. however, in our framework we > > > > > tried hard to avoid saying that NSIS would work in particular > > > > > ways in particular network parts. (ideally, I think there > > > > > should be implementation and deployment flexibility within > > > > > the protocol to allow this.) > > > > > > > > > > > > > > > > > I don't know why "the initial goal of NSIS is to concentrate > > > > > > mainly on the in-band case". > > > > > > > > > > [reh] that's a WG chair/AD question. > > > > > > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > Cheers, > > > > > > > > > > Robert H. > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > > Sent: 2002å¹´6月24æ—¥ 19:47 > > > > > > To: NSIS > > > > > > Subject: [NSIS] New framework draft > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > > activities got together after the interim meeting to put > > > > > > together a joint framework document in the form of an all-new > > > > > > individual submission. It (roughly) follows the structure > > > > > > that was introduced and refined at that meeting. > > > > > > > > > > > > ============================================================== > > > > > > ============ > > > > > > Abstract > > > > > > > > > > > > The NSIS working group is considering protocol > > > developments in > > > > > > signaling for resources for a traffic flow along its > > > > path in the > > > > > > network. The requirements for such signaling are being > > > > > > developed in a > > > > > > separate document; This Internet Draft proposes a > > > > framework for > > > > > > such signaling. This initial version provides a model for > > > > > > describing > > > > > > the entities that take part in the signaling and the > > > > > ways in which > > > > > > they can be used in different modes of operation. It also > > > > > > discusses > > > > > > the overall structure of such a signaling protocol. > > > > Finally, it > > > > > > considers the possible interactions of NSIS signaling > > > > with other > > > > > > protocols and functions, including security issues. > > > > > > ============================================================== > > > > > > ============ > > > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > > find a copy here: > > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > > highlights in section 3. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Robert Hancock > > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 05:29:53 2002 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 FAA29416 for ; Tue, 2 Jul 2002 05:29:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26049 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 05:30:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25348; Tue, 2 Jul 2002 05:13:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25320 for ; Tue, 2 Jul 2002 05:13:45 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29187 for ; Tue, 2 Jul 2002 05:12:42 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 10:12:52 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA40E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Charles Q. Shen'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Tue, 2 Jul 2002 10:12:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Charles, Sometimes my over-careful use of language may cause more confusion than it prevents. Formally: *) An NSIS-aware node is defined as anything which processes an NSIS message for whatever reason. *) There might be reasons to process NSIS messages other than resource management. One reason might be to address-translate a flow definition. *) There might be several types of resource being managed, and not all nodes will do all of them. For example, a 'normal' interior router probably _should_ ignore NSIS messages which are about signalling for firewall pinholing. (But note: we aren't certain if the differences between different types of resource will be opaque to NSIS or not. See section 4.5.3.) Having said that, I would not be surprised if 99% of NSIS nodes do resource management for QoS for the forseeable future. But that's just a personal view about how NSIS might be used, not a statement about how the protocol should be designed. The basic point we are trying to emphasise is that we should strictly avoid identifying "NSIS aware node" = "router that does QoS management". It's true that NSIS is about resource signalling; but the emphasis is that NSIS is about _signalling_, not about _resources_. Is this any clearer? Cheers, Robert > -----Original Message----- > From: Charles Q. Shen [mailto:shenqi@icr.a-star.edu.sg] > Sent: 02 July 2002 07:03 > To: Hancock, Robert; 'Zhigang.Kan@nokia.com'; nsis@ietf.org > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > Hi Robert, > > >*) if an intermediate node is NSIS unaware, or is NSIS aware > but doesn't > >do any management for some particular resource, then there's > nothing NSIS > >can do directly to help the resource management at that > node. That doesn't > >stop you using some other technique to control the resource > at that node > >(some variant of SNMP or COPS or RMD or whatever), but so > far as NSIS is > >concerned, all of that would be hidden inside your RMF > implementation. > > Do you mean an NSIS aware node is at least doing something regarding > certain resources, although it might not be managing a > particular resource > in question, as we use resource as a general term for serval > items? What > actually confused me is I remember you said before: > > 2) even if a node does process NSIS messages, it might do so > for reasons > not associated with resource management. > > So can you elaborate on this point, if NSIS is all about resource > signaling? (Unless you are talking about for example, in the > case of NI and > NR you may not have a RMF associated with it, but even in this case > virtually the processing of NSIS message is still one segment > in the whole > resource management picture.) > > BR/Charles > > > >i'll look forward to the 'modes of operation' questions! > > > >cheers, > > > >robert h. > > > >ps apologies about my email disclaimer, it's not entirely > under my control > >to fix it, though we're doing what we can. i am aware that i > am sending > >this email to a public mailing list ... > > > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 28 June 2002 11:08 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > Hi Robert, > > > > > > Till now, I understood the definition of NE. Thank you. :-) > > > It is right that we must have the common understanding of the > > > terms, so we can continue the discussion further. > > > > > > One more thing, If one/more router(s) on the data path does > > > not support RMF (as you said: if you have a distributed > > > approach to resource management, i guess we would typically > > > expect most nodes would have a resource management > > > responsibility, but there's no requirement for every node to > > > do something with resource management.), how about in this > > > case? Can the QoS of data on this path be affected by > these routers? > > > > > > Next I would like to discuss the relationship of modes of > > > NSIS protocol operation such as how the end-to-end, > > > edge-to-edge, and end-to-edge signaling take effects when the > > > per-flow/per-class-flow traffic is initiated by a host. > > > > > > Nice weekend. > > > > > > BR/Kan Zhigang > > > > > > -----Original Message----- > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: 2002å¹´6æoe^28æ-¥ 17:33 > > > To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > hi - minor correction - in 3rd sentence below, s/nodes/hosts/. > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Hancock, Robert > > > > Sent: 28 June 2002 10:31 > > > > To: 'Zhigang.Kan@nokia.com'; nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > Hi Zhigang, > > > > > > > > Apologies for maybe informal language. By 'box' I really mean > > > > typically a physical thing you plug into a power supply, with > > > > wires carrying packets into and out of it. So, usually it's a > > > > host or a router. If signalling only follows the data path > > > > (which is considered at the router level, not the network > > > > level), the only relevant nodes can be the data flow > > > > endpoints, and the only relevant routers can be the routers > > > > the flow passes through. > > > > > > > > We've tried to describe things in terms of signalling going > > > > between signalling entities rather than hosts/routers and so > > > > on; one of the goals of this is to aim for concepts and > > > > terminology to describe the signalling that are re-usable > > > > if/when we subsequently think about signalling paths that are > > > > less constrained. > > > > > > > > It may be (I get the impression) that the level of > > > > abstraction in the framework makes it hard to get a grip on. > > > > I'm not sure what would be the best way to handle this (maybe > > > > some concrete example scenarios or something). > > > > > > > > We didn't want to make all the definitions very concrete, > > > > since that implies building in assumptions about particular > > > > application domains. Specifically, we have two potential > > > > degrees of freedom about NSIS applicability which we've tried > > > > to reflect by using more abstract language: > > > > *) what sort of resources are signalled for > > > > *) what sort of signalling paths are traversed > > > > Currently, the first is in scope and the second not. I hope > > > > we can avoid too long confusion about the > > > > node/entity/network/whatever issue, because if we can't, > > > > we'll probably be encouraged to re-write everything in terms > > > > of routers and hosts, which will make any future extension to > > > > other cases much harder. > > > > > > > > Cheers, > > > > > > > > Robert H. > > > > > > > > ps apologies about my email disclaimer, it's not entirely > > > > under my control to fix it, though we're doing what we can. i > > > > am aware that i am sending this email to a public > mailing list ... > > > > > > > > > > > > > -----Original Message----- > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > Sent: 28 June 2002 10:10 > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > I am more confused about 'node' is for 'box', but what in the > > > > > box, a part of netwok or a whole network or whatever? Does > > > > > the data pass through the box? How to understand the data > > > > > path, based on per-router or per-network? Is NSIS Framework > > > > > independent of the true networks and is it only abstract > > > > > concept over the different environments? I cannot image how > > > > > to deploy it in the future. > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > Sent: 2002å¹´6æoe^28æ-¥ 16:28 > > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > Hi Zhigang, > > > > > > > > > > Please see inline below. > > > > > > > > > > Cheers, > > > > > > > > > > Robert H. > > > > > > > > > > ps apologies about my email disclaimer, it's not entirely > > > > > under my control to fix it, though we're doing what we can. i > > > > > am aware that i am sending this email to a public > mailing list ... > > > > > > > > > > > -----Original Message----- > > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > > Sent: 28 June 2002 08:43 > > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & > Out-of-Band > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > Q1: "Node" used in your terminology can be a router, an end > > > > > > host or a server, right? > > > > > > > > > > [reh] yes, in the broadest sense ('node' is a fancy name for > > > > > 'box'). if you respect the 'on-path' restriction, a node that > > > > > processes NSIS signalling must be on the data path, which > > > > > probably rules out the 'server' case. > > > > > > > > > > > In the case of distributed RMF, must > > > > > > each node have the resource management function in a > > > NSIS domain? > > > > > > > > > > [reh] if you have a distributed approach to resource > > > > > management, i guess we would typically expect most nodes > > > > > would have a resource management responsibility, but there's > > > > > no requirement for every node to do something with resource > > > > > management. in particular: > > > > > 1) not every node has to process NSIS messages (cf. RSVP > > > > > operation over non-RSVP clouds) > > > > > 2) even if a node does process NSIS messages, it might do so > > > > > for reasons not associated with resource management. > > > > > > > > > > > > > > > > > Q2: The RMF is responsible for all network provisioning and > > > > > > resource allocation functions, and "some" of the state > > > > > > management is an RMF responsibility. How about the > "other" of > > > > > > the state management, and it is refered to the state > > > > > > management mechanism of NSIS related with "Refresh" message? > > > > > > If so, what relationship between these two parts of state > > > > > > management? Is it out of the scope of NSIS? I hope > answer is no. > > > > > > > > > > [reh] this is a hard question to answer, and a hard question > > > > > in general. > > > > > > > > > > 1. It's clear that to do resource management, you need to > > > > > store some state information. That information might be at > > > > > the flow level, or some 'resource class' level, or something > > > > > else. Because the state you need to store depends on the > > > > > resource you are trying to manage and the precision with > > > > > which you need to manage it, we don't think NSIS can define > > > > > how this is done. > > > > > > > > > > 2. You also need state to make a protocol operate correctly. > > > > > This could include all (or none) of: > > > > > *) information about how to reverse-path route > messages for a flow > > > > > *) information about who to send an acknowledgement > to and when > > > > > *) information about when to send a refresh message > > > > > *) information about who was authenticated when a > > > > reservation was made > > > > > *) and so on > > > > > This is all in NSIS scope to worry about. Most of it > is per-flow. > > > > > > > > > > 3. The relationship between these two types of state is > > > > > something we discussed, but only in outline. I think a basic > > > > > design goal could be stated as: > > > > > "It should be possible to use [a|the] NSIS protocol in such a > > > > > way that it only requires the minimum of state storage, in > > > > > particular no more than the resource management mechanism > > > > > that it is supporting." It's then (I think) mainly a job for > > > > > the implementor to do both aspects of state management in an > > > > > economical way (in particular, without duplication). So, I > > > > > think we need to consider the possible interactions between > > > > > the different parts of state management, and make sure they > > > > > get reflected as goals for NSIS design in terms of > > > > > flexibility and general usefulness of the protocol, but > > > > > without defining details of exactly how the different types > > > > > of state interact. > > > > > > > > > > This is actually a special case of a more general issue. Look > > > > > also at draft-braden-2level-signal-arch-00.txt where there is > > > > > the related question of the split between CSTP and ALSP. The > > > > > general point is that we almost certainly can't have a pure > > > > > structure of independent layers (I would expect the ALSP-like > > > > > upper layer to hook into the operation of the lower layer > > > > > quite intimately rather than the other way round, but that's > > > > > more of a protocol design issue). The state management issue > > > > > is just one aspect of this. > > > > > > > > > > So, I think the answer to your question is "yes and no" (if > > > > > you see what I mean...) > > > > > > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > > Sent: 2002å¹´6æoe^27æ-¥ 19:02 > > > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & > Out-of-Band > > > > > > > > > > > > > > > > > > Hi Zhigang, > > > > > > > > > > > > Please see inline: > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > > > Sent: 27 June 2002 11:53 > > > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > > > Subject: RE: [NSIS] New framework draft: In-Band > & Out-of-Band > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > In the draft about In-Band & Out-of-Band: > > > > > > > > > > > > > > "In-band signaling means that the path followed > by the user > > > > > > > data packets is the same as the path followed by signaling > > > > > > > messages. In other words, the signaling and data paths are > > > > > > > identical. Out-of-band signaling means that the > path followed > > > > > > > by signaling messages might be different from the > path used > > > > > > > by the user data packets. " > > > > > > > > > > > > > > So in-band signaling is same as RSVP's operation mode? > > > > > > > > > > > > [reh] basically yes, from a topological ("where the messages > > > > > > go") point of view. > > > > > > > > > > > > > And > > > > > > > must it install soft states in each router it > passed through > > > > > > > based on per-flow or per-class-flow? > > > > > > > > > > > > [reh] that's one reasonable way for it to work. see > 4.4 about > > > > > > general state management issues; there are several different > > > > > > sorts of state and several different ways to manage > them. and > > > > > > some of the state management is an RMF responsibility. > > > > > > > > > > > > > I think that it may be > > > > > > > better if in-band signaling is used in access network and > > > > > > > out-of-band signaling is used in backbone > networks (i.e. the > > > > > > > out-of-band signaling is used for communcation > between RMFs > > > > > > > which are responsible for the "resource" management > > > > > > > independent of concrete user traffic in control plane). Is > > > > > > > resource reservation really needed in backbone > network now or > > > > > > > in the future? > > > > > > > > > > > > [reh] that's a good question. however, in our framework we > > > > > > tried hard to avoid saying that NSIS would work in > particular > > > > > > ways in particular network parts. (ideally, I think there > > > > > > should be implementation and deployment flexibility within > > > > > > the protocol to allow this.) > > > > > > > > > > > > > > > > > > > > I don't know why "the initial goal of NSIS is to > concentrate > > > > > > > mainly on the in-band case". > > > > > > > > > > > > [reh] that's a WG chair/AD question. > > > > > > > > > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Robert H. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Hancock, Robert > [mailto:robert.hancock@roke.co.uk] > > > > > > > Sent: 2002å¹´6æoe^24æ-¥ 19:47 > > > > > > > To: NSIS > > > > > > > Subject: [NSIS] New framework draft > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > > > activities got together after the interim meeting to put > > > > > > > together a joint framework document in the form > of an all-new > > > > > > > individual submission. It (roughly) follows the structure > > > > > > > that was introduced and refined at that meeting. > > > > > > > > > > > > > > > ============================================================== > > > > > > > ============ > > > > > > > Abstract > > > > > > > > > > > > > > The NSIS working group is considering protocol > > > > developments in > > > > > > > signaling for resources for a traffic flow along its > > > > > path in the > > > > > > > network. The requirements for such signaling are being > > > > > > > developed in a > > > > > > > separate document; This Internet Draft proposes a > > > > > framework for > > > > > > > such signaling. This initial version provides > a model for > > > > > > > describing > > > > > > > the entities that take part in the signaling and the > > > > > > ways in which > > > > > > > they can be used in different modes of > operation. It also > > > > > > > discusses > > > > > > > the overall structure of such a signaling protocol. > > > > > Finally, it > > > > > > > considers the possible interactions of NSIS signaling > > > > > with other > > > > > > > protocols and functions, including security issues. > > > > > > > > ============================================================== > > > > > > > ============ > > > > > > > > > > > > > > While it works its way through the i-d editor > queue, you can > > > > > > > find a copy here: > > > > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > > > highlights in section 3. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Robert Hancock > > > > > > > > > > > > > > > > > > > > > > > > > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 05:55:00 2002 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 FAA29875 for ; Tue, 2 Jul 2002 05:55:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27230 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 05:55:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26530; Tue, 2 Jul 2002 05:39:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26501 for ; Tue, 2 Jul 2002 05:39:10 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29609 for ; Tue, 2 Jul 2002 05:38:21 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 10:38:55 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA40F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Gabor Fodor'" , cedric@iprg.nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t Date: Tue, 2 Jul 2002 10:38:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi Gabor, Cedric, all, I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing. Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as: "To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK. "NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case. "You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first. In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.] In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages. In case this all comes across as wildly vacuous, here are two lesser but concrete questions: *) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS? *) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable? cheers, robert h. > -----Original Message----- > From: Gabor Fodor [mailto:erafodo@ESEALNT448.al.sw.ericsson.se] > Sent: 01 July 2002 18:32 > To: cedric@iprg.nokia.com > Cc: nsis@ietf.org > Subject: Re: [NSIS] Re: Comments on > draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Cedric, > > Thnaks for your answers, I would like to discuss > one of your points here, which I believe > is important: > > [...] > > > > > > [GF] > > 4 > > I am not sure that it is meaningful at this point to start > > discussing specific solution approaches. You seem to propose > > to use ICMP as a design base for both edge signaling and for > > context transfer (AR to AR). At least for the edge signaling, > > we need to consider the edge specific requirements before > > we start discussing what existing or new protocol can be the > > design base for that. > > [GF] > > > Let me explain a bit here: the design base for edge signaling and > > context transfer is > > really 'A context transfer protocol for seamless mobility', > > draft-koodli-seamoby-ctv6-03.txt. > > Earlier version of draft-koodli-seamoby-ctv6 were ICMP > based. However, > > it is more general in this latest version, and not > necessarily ICMP. As > > a consequence, we mention ICMP > > as a possible illustration. The main point is that QoS signaling is > > redundant with context transfer, one object being > transferred being QoS > > context, and that CT signaling will do the job for the MN to AR QoS > > signaling. > > We will clarify this point. > > [GF] > We need to understand and analyze better the requirements on the edge > and the CT signaling protocols. You make a good point : the > QoS signaling > is to a great extent redundant with context transfer > (which makes the re-use of the same design attractive), but there > may as well be important differences that are connected to the > wireless interface itself. I believe that there are scenarios where > transferring the context from AR1 to AR2 is not sufficient to exercise > admission control at and make the mecessary configurations of the new > wireless link. I think we need to list the requirements for the edge > protocol and go check how those are fulfilled > with differenet alternatives. > [GF] > > /Gabor > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 07:01:34 2002 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 HAA03037 for ; Tue, 2 Jul 2002 07:01:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA02880 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 07:02:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01575; Tue, 2 Jul 2002 06:46:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01544 for ; Tue, 2 Jul 2002 06:46:42 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02510 for ; Tue, 2 Jul 2002 06:45:53 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g62AkBI98098 for ; Tue, 2 Jul 2002 12:46:11 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA15575 for ; Tue, 2 Jul 2002 12:40:46 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 32B7449138 for ; Tue, 2 Jul 2002 12:40:46 +0200 (CEST) Date: Tue, 02 Jul 2002 12:40:46 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <7237617.1025613646@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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] requirements draft -03 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Dear NSIS-friends, I submitted the -03 version of the requirements draft yesterday (Monday) but due to E-Mail problems too late. So potatially it will not show up on the ftp, sorry for that. Nevertheless, you can get it here http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-03.txt Changes are based on discussion of open issues at the interim meeting. The still open issues include - resilience issues (see draft-vandenbosch-nsis-resilience-00.txt) - security issues (IMO are now very readable with the help of Hannes and with the requested threat analysis, draft-tschofenig-nsis-threats-01.txt) - sender/receiver initiation (see also framework work) - MUST/SHOULDs, actually looking over the requirements, there are only a small set of requirements, which depend on the parts of the network. So currently I tend to change my mind on how to write down the MUST. I currently tend to immediatly include the MUSTS/SHOULDs into the reqirements text, and only where necessary put MUSTs depending on the part of the network. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 08:18:37 2002 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 IAA05395 for ; Tue, 2 Jul 2002 08:18:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06578 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 08:19:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05942; Tue, 2 Jul 2002 08:03:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05855 for ; Tue, 2 Jul 2002 08:03:39 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04767 for ; Tue, 2 Jul 2002 08:02:49 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 13:03:24 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA413@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Date: Tue, 2 Jul 2002 13:03:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Marcus, [snip] > Actually, I more and more think we should deal with AA in an opaque way. As > I see it with the middlebox case, the trust models muight be service, > dependent and are different even for QoS depending on the > scenario used. > > Marcus > I don't know whether to read anything into using the term 'AA' not 'AAA'. But maybe we need some guesses about the second two As to work out where the scope lies. (Background concern: we could easily end up saying 'everything is opaque', in which case NSIS is just 'any protocol on top of IP'.) Accounting: Actually, I think this is easy. "Nodes may generate accounting records, but there's no reason for them to follow the signalling path, and so no reason to integrate their handling with NSIS. So far as NSIS is concerned, accounting might as well not exist." Authorisation: Here, there seems to be a much wider range of reasonable opinions. 1) Everything about authorisation should be opaque to NSIS. If NSIS messages can be used to transport authorisation information that's all very well, but we aren't going to worry about making it easy; if people need message flows (even on-path ones) that don't fit with NSIS, they'll need another protocol to carry them. 2) Authorisation messages are opaque to NSIS, but we'll try to make sure that we can support the most important scenarios that we can think of within a basic set of message flows. 3) Authorisation messages are opaque to NSIS, but we'll assume that the message flows can be absolutely anything and the protocol will have to be flexible enough to support that (even if that means multiple passes and so on). 4) NSIS has to have well-defined interactions with authorisation protocols. The accounting view seems to be compatible with the requirements (just checked the latest version). For authorisation, I guess you would prefer (1)? I'd like (2) but that means some verification work. (3) would be horrible. The requirements seem currently closer to (4), but I'm not absolutely clear. Seems like a tricky choice. Cheers, Robert H. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 09:30:34 2002 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 JAA08776 for ; Tue, 2 Jul 2002 09:30:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11462 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 09:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09953; Tue, 2 Jul 2002 09:12:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09926 for ; Tue, 2 Jul 2002 09:12:10 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07703 for ; Tue, 2 Jul 2002 09:11:19 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g62DBYI07696; Tue, 2 Jul 2002 15:11:34 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA17193; Tue, 2 Jul 2002 15:06:09 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AEB0D49374; Tue, 2 Jul 2002 15:06:08 +0200 (CEST) Date: Tue, 02 Jul 2002 15:06:09 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Message-ID: <15961982.1025622369@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA413@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA413@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Dienstag, 2. Juli 2002 13:03 +0100 "Hancock, Robert" wrote: > Hi Marcus, > > [snip] >> Actually, I more and more think we should deal with AA in an opaque way. >> As I see it with the middlebox case, the trust models muight be >> service, dependent and are different even for QoS depending on the >> scenario used. >> >> Marcus >> > > I don't know whether to read anything into using the term 'AA' not 'AAA'. > But maybe we need some guesses about the second two As to work out where > the scope lies. (Background concern: we could easily end up saying > 'everything is opaque', in which case NSIS is just 'any protocol on top > of IP'.) > Yes, I know. Actually, I excluded Acounting. > Accounting: Actually, I think this is easy. "Nodes may generate > accounting records, but there's no reason for them to follow the > signalling path, and so no reason to integrate their handling with NSIS. > So far as NSIS is concerned, accounting might as well not exist." > You might account based on reservation not usage. > Authorisation: Here, there seems to be a much wider range of reasonable > opinions. 1) Everything about authorisation should be opaque to NSIS. If > NSIS messages can be used to transport authorisation information that's > all very well, but we aren't going to worry about making it easy; if > people need message flows (even on-path ones) that don't fit with NSIS, > they'll need another protocol to carry them. 2) Authorisation messages > are opaque to NSIS, but we'll try to make sure that we can support the > most important scenarios that we can think of within a basic set of > message flows. 3) Authorisation messages are opaque to NSIS, but we'll > assume that the message flows can be absolutely anything and the protocol > will have to be flexible enough to support that (even if that means > multiple passes and so on). 4) NSIS has to have well-defined interactions > with authorisation protocols. Do you mean here authentication or authorization or both. For me authentication tells an entity who the other party is, and authorization is a entity local decision on whether the action another party wants to perform is allowed to. So from an NSIS point of view I see different entities with a defined identity and a mechanism to authenticate. The only part I see prety static is the local authorization, but probably it is not that simple. > > The accounting view seems to be compatible with the requirements (just > checked the latest version). For authorisation, I guess you would prefer > (1)? I'd like (2) but that means some verification work. (3) would be > horrible. The requirements seem currently closer to (4), but I'm not > absolutely clear. Seems like a tricky choice. Yes, I would like (1). I don't see something which implies (4) in the req draft. What makes you think (4) is implied? Marcus > Cheers, > > Robert H. > > > ========================================================================= > =============== Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 10:42:00 2002 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 KAA13383 for ; Tue, 2 Jul 2002 10:41:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25321 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 10:42:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23099; Tue, 2 Jul 2002 10:21:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23068 for ; Tue, 2 Jul 2002 10:21:52 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11594 for ; Tue, 2 Jul 2002 10:21:05 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g62EK7I13157; Tue, 2 Jul 2002 16:20:12 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA17950; Tue, 2 Jul 2002 16:14:41 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BBE1CD8FC; Tue, 2 Jul 2002 16:14:40 +0200 (CEST) Date: Tue, 02 Jul 2002 16:14:41 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "'Melinda Shore'" , nsis@ietf.org Subject: Re: discovery & authorisation requirements (was: RE: [NSIS] draft on middlebox communication and NSIS) Message-ID: <20074565.1025626481@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA3E2@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA3E2@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Donnerstag, 27. Juni 2002 08:47 +0100 "Hancock, Robert" wrote: [...] > Bigger point: it would clearly be nice if we could make 'what NSIS does' > adaptive to network changes to the same extent that packet routing is. > But NSIS is all about creating flow state or something (e.g. > per-some-class state) derived from it. (If NSIS didn't modify the network > state along the path, we could all pretty well stop now.) The ideal (for > some people) seems to be that all that state should be soft, but as soon > as authentication and message protection (let alone service negotiation > and authorisation) are involved I guess this is going to be tricky. If > your neighbour middlebox changes, do you really want to be kept ignorant > of the fact? Just finding out automatically and reacting seems the best > one can aim for; maybe I'm over pessimistic. Isn't this a general problem for security related issues in NSIS. Where changing routes means changing security associations. Marcus > Your questions about how on earth authorisation will take place are of > course reasonable. But so far as I can tell, the mechanisms by which this > will happen are highly resource-type specific and so defining them is out > of scope of NSIS (we suggested this in our latest framework draft > anyway); I think the best we can do is see if there are particular types > of operations which don't need authorisation (e.g. if you can prove > you're the same person who opened a pinhole, you probably don't need to > be re-authorised to close it??). I don't know if this view is generally > held (it's not compatible with a strict reading of the latest set of > requirements). > > Robert H. > >> -----Original Message----- >> From: Melinda Shore [mailto:mshore@cisco.com] >> Sent: 26 June 2002 16:47 >> To: Hancock, Robert; nsis@ietf.org >> Subject: RE: [NSIS] draft on middlebox communication and NSIS >> >> >> At 01:55 PM 6/26/02 +0100, Hancock, Robert wrote: >> > The reason I raise the question is that there is an open >> issue in the requirements draft about whether we can restrict >> NSIS to thinking about the sender initiated case (i.e. only >> support signalling for reservations about outgoing packets), >> since you can sometimes build a very lightweight protocol >> under this assumption. However, it appears that it can't >> cover all the bases (especially this one). >> >> I would tend to want to do that for this particular application, >> anyway, because 1) in the cases which make firewalls and NATs >> difficult in the first place (VoIP, for example) the receiver won't >> have sufficient information (i.e. addresses and port numbers) to >> request the reservation until the sender tells him, anyway, and >> 2) there may be policy reasons to have the person initiating >> the request "closer" to the administrative domain of the sender. >> That last bit is muddy, granted, and needs a lot more work in >> general - it's related to the security difficulties that we'll >> surely be grappling with. >> >> > We've found it would be nice to assume that the AAA (at >> least, the first two As) aspects of [1] are independent of >> the AAA aspects of [2], and so host and NSIS B don't have any >> mutual authentication or authorisation (if they do, they set >> up a direct peer session). But we don't know if this is >> reasonable, because it obviously depends on the resource type >> being signalled for. >> >> It's a little messier than that, actually - one of the benefits >> of talking to middleboxes like this is that you don't need to know >> where they are in advance. That is to say, you don't need an >> existing relationship with them. The difficulty is that for >> practical purposes there's no good way in the internet *today* >> to have arbitrary entities be authenticated to each other (TLS >> works because a limited number of servers buy certs from more-or- >> less trusted certificate agencies - imagine every middlebox doing >> that). But here's the real question - even if you could authenticate >> someone you'd never known existed, on what basis do you authorize >> them to, say, open a hole in your firewall? >> >> > It's clear that we need technologies for path discovery for >> precisely this reason. I'm not sure how many technologies >> there should be. NSIS will (I hope) develop a general >> RSVP-like mechanism; I'm wondering if it also needs a special >> lightweight variant which firewall administrators are happy >> about being transparent to. >> >> The problem is how you intend to use the information. Aside from >> the fact that the folks who run big networks don't *want* you to know >> where their firewalls are, I've been looking at some of the arguments >> for middlebox discovery and haven't found anything particularly >> compelling. Actually, that's not quite right - what I have found is >> a compelling argument for not doing it. It's like programming - >> if you do some work to find out whether or not you can do something >> and if you can then you try to do it, you create potential race >> conditions. If you just go ahead and do it and check the results >> you'll know whether or not you succeeded, you saved yourself >> the overhead >> of running checks ahead of time, and you avoid race conditions. >> >> I've gotten religion about this, and so you'll have to forgive me. If >> you do middlebox discovery it suggests that you intend to do something >> with the information that you collect. There are multiple problems >> with doing so, including that discovery only gives you a picture of >> the network at the time that you did the discovery, and yet one of >> the things we like (don't we?) about IP is that routing is adaptive >> to changes in network state on a per-packet basis. By establishing >> explicit connections to middleboxes and wiring state into middleboxes >> we're violating two fundamental IP design principles, one of them >> major and the other somewhat lesser. The major one is that of fate- >> sharing, which is part of what makes (or used to make) applications >> running over IP so robust. The lesser one is layering, although >> I feel pretty strongly that layer violations lead to network >> topology problems and perhaps isn't so lesser after all. >> >> I would tread quite lightly where discovery is concerned. >> >> Melinda >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 11:25:44 2002 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 LAA22076 for ; Tue, 2 Jul 2002 11:25:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29394 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 11:26:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28333; Tue, 2 Jul 2002 11:12:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28302 for ; Tue, 2 Jul 2002 11:12:10 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17378 for ; Tue, 2 Jul 2002 11:11:22 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:11:49 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA41A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , "'Melinda Shore'" , nsis@ietf.org Subject: RE: discovery & authorisation requirements (was: RE: [NSIS] draft on middlebox communication and NSIS) Date: Tue, 2 Jul 2002 16:11:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Marcus, I think I probably agree with you. I was just responding to the penultimate paragraph in Melinda's email (at the end); see also her response. Essentially the question seems to be, how hard should we work to minimise explicit routing dependencies (especially in security associations), and how much should we just accept it. (You might be able to remove some of this state information e.g. with heavier use of public key methods and certification, but I'm not sure that the end result would be preferable to something which accepted a more explicit negotiated security association.) Robert H. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 02 July 2002 15:15 > To: Hancock, Robert; 'Melinda Shore'; nsis@ietf.org > Subject: Re: discovery & authorisation requirements (was: RE: [NSIS] > draft on middlebox communication and NSIS) > > > > > --On Donnerstag, 27. Juni 2002 08:47 +0100 "Hancock, Robert" > wrote: > > [...] > > Bigger point: it would clearly be nice if we could make > 'what NSIS does' > > adaptive to network changes to the same extent that packet > routing is. > > But NSIS is all about creating flow state or something (e.g. > > per-some-class state) derived from it. (If NSIS didn't > modify the network > > state along the path, we could all pretty well stop now.) > The ideal (for > > some people) seems to be that all that state should be > soft, but as soon > > as authentication and message protection (let alone service > negotiation > > and authorisation) are involved I guess this is going to be > tricky. If > > your neighbour middlebox changes, do you really want to be > kept ignorant > > of the fact? Just finding out automatically and reacting > seems the best > > one can aim for; maybe I'm over pessimistic. > > Isn't this a general problem for security related issues in > NSIS. Where > changing routes means changing security associations. > > Marcus > > > Your questions about how on earth authorisation will take > place are of > > course reasonable. But so far as I can tell, the mechanisms > by which this > > will happen are highly resource-type specific and so > defining them is out > > of scope of NSIS (we suggested this in our latest framework draft > > anyway); I think the best we can do is see if there are > particular types > > of operations which don't need authorisation (e.g. if you can prove > > you're the same person who opened a pinhole, you probably > don't need to > > be re-authorised to close it??). I don't know if this view > is generally > > held (it's not compatible with a strict reading of the latest set of > > requirements). > > > > Robert H. > > > >> -----Original Message----- > >> From: Melinda Shore [mailto:mshore@cisco.com] > >> Sent: 26 June 2002 16:47 > >> To: Hancock, Robert; nsis@ietf.org > >> Subject: RE: [NSIS] draft on middlebox communication and NSIS > >> > >> > >> At 01:55 PM 6/26/02 +0100, Hancock, Robert wrote: > >> > The reason I raise the question is that there is an open > >> issue in the requirements draft about whether we can restrict > >> NSIS to thinking about the sender initiated case (i.e. only > >> support signalling for reservations about outgoing packets), > >> since you can sometimes build a very lightweight protocol > >> under this assumption. However, it appears that it can't > >> cover all the bases (especially this one). > >> > >> I would tend to want to do that for this particular application, > >> anyway, because 1) in the cases which make firewalls and NATs > >> difficult in the first place (VoIP, for example) the receiver won't > >> have sufficient information (i.e. addresses and port numbers) to > >> request the reservation until the sender tells him, anyway, and > >> 2) there may be policy reasons to have the person initiating > >> the request "closer" to the administrative domain of the sender. > >> That last bit is muddy, granted, and needs a lot more work in > >> general - it's related to the security difficulties that we'll > >> surely be grappling with. > >> > >> > We've found it would be nice to assume that the AAA (at > >> least, the first two As) aspects of [1] are independent of > >> the AAA aspects of [2], and so host and NSIS B don't have any > >> mutual authentication or authorisation (if they do, they set > >> up a direct peer session). But we don't know if this is > >> reasonable, because it obviously depends on the resource type > >> being signalled for. > >> > >> It's a little messier than that, actually - one of the benefits > >> of talking to middleboxes like this is that you don't need to know > >> where they are in advance. That is to say, you don't need an > >> existing relationship with them. The difficulty is that for > >> practical purposes there's no good way in the internet *today* > >> to have arbitrary entities be authenticated to each other (TLS > >> works because a limited number of servers buy certs from more-or- > >> less trusted certificate agencies - imagine every middlebox doing > >> that). But here's the real question - even if you could > authenticate > >> someone you'd never known existed, on what basis do you authorize > >> them to, say, open a hole in your firewall? > >> > >> > It's clear that we need technologies for path discovery for > >> precisely this reason. I'm not sure how many technologies > >> there should be. NSIS will (I hope) develop a general > >> RSVP-like mechanism; I'm wondering if it also needs a special > >> lightweight variant which firewall administrators are happy > >> about being transparent to. > >> > >> The problem is how you intend to use the information. Aside from > >> the fact that the folks who run big networks don't *want* > you to know > >> where their firewalls are, I've been looking at some of > the arguments > >> for middlebox discovery and haven't found anything particularly > >> compelling. Actually, that's not quite right - what I > have found is > >> a compelling argument for not doing it. It's like programming - > >> if you do some work to find out whether or not you can do something > >> and if you can then you try to do it, you create potential race > >> conditions. If you just go ahead and do it and check the results > >> you'll know whether or not you succeeded, you saved yourself > >> the overhead > >> of running checks ahead of time, and you avoid race conditions. > >> > >> I've gotten religion about this, and so you'll have to > forgive me. If > >> you do middlebox discovery it suggests that you intend to > do something > >> with the information that you collect. There are multiple problems > >> with doing so, including that discovery only gives you a picture of > >> the network at the time that you did the discovery, and yet one of > >> the things we like (don't we?) about IP is that routing is adaptive > >> to changes in network state on a per-packet basis. By establishing > >> explicit connections to middleboxes and wiring state into > middleboxes > >> we're violating two fundamental IP design principles, one of them > >> major and the other somewhat lesser. The major one is > that of fate- > >> sharing, which is part of what makes (or used to make) applications > >> running over IP so robust. The lesser one is layering, although > >> I feel pretty strongly that layer violations lead to network > >> topology problems and perhaps isn't so lesser after all. > >> > >> I would tread quite lightly where discovery is concerned. > >> > >> Melinda > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 11:44:34 2002 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 LAA23485 for ; Tue, 2 Jul 2002 11:44:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02037 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 11:45:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29160; Tue, 2 Jul 2002 11:24:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29080 for ; Tue, 2 Jul 2002 11:24:13 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21728 for ; Tue, 2 Jul 2002 11:23:24 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:24:10 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA41B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] draft on middlebox communication and NSIS Date: Tue, 2 Jul 2002 16:24:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Marcus, By 'authorisation' I mean only authorisation. If we knew the authorisation requirements we would then know some of the authentication ones, but probably not all; but I don't think there is any question (is there?) about authentication being a requirement for NSIS anyway. The current requirements draft (5.8.2) says "The signaling protocol must provide means to authorize resource requests." As it stands, that's quite broad. The rest of the paragraph talks about interactions with policy servers and sending notifications that an authorisation has succeeded. It doesn't seem to be the same as my (1), anyway. Cheers, Robert H. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 02 July 2002 14:06 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] draft on middlebox communication and NSIS > > > > > --On Dienstag, 2. Juli 2002 13:03 +0100 "Hancock, Robert" > wrote: > [stuff snipped out] > > > Authorisation: Here, there seems to be a much wider range > of reasonable > > opinions. 1) Everything about authorisation should be > opaque to NSIS. If > > NSIS messages can be used to transport authorisation > information that's > > all very well, but we aren't going to worry about making it easy; if > > people need message flows (even on-path ones) that don't > fit with NSIS, > > they'll need another protocol to carry them. 2) > Authorisation messages > > are opaque to NSIS, but we'll try to make sure that we can > support the > > most important scenarios that we can think of within a basic set of > > message flows. 3) Authorisation messages are opaque to > NSIS, but we'll > > assume that the message flows can be absolutely anything > and the protocol > > will have to be flexible enough to support that (even if that means > > multiple passes and so on). 4) NSIS has to have > well-defined interactions > > with authorisation protocols. > > Do you mean here authentication or authorization or both. For me > authentication tells an entity who the other party is, and > authorization is > a entity local decision on whether the action another party wants to > perform is allowed to. > > So from an NSIS point of view I see different entities with a defined > identity and a mechanism to authenticate. The only part I see > prety static > is the local authorization, but probably it is not that simple. > > > > > > The accounting view seems to be compatible with the > requirements (just > > checked the latest version). For authorisation, I guess you > would prefer > > (1)? I'd like (2) but that means some verification work. > (3) would be > > horrible. The requirements seem currently closer to (4), but I'm not > > absolutely clear. Seems like a tricky choice. > > Yes, I would like (1). I don't see something which implies > (4) in the req > draft. What makes you think (4) is implied? > > Marcus > > > Cheers, > > > > Robert H. > > > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 16:01:10 2002 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 QAA12451 for ; Tue, 2 Jul 2002 16:01:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21369 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 16:01:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19941; Tue, 2 Jul 2002 15:40:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19913 for ; Tue, 2 Jul 2002 15:40:38 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11234 for ; Tue, 2 Jul 2002 15:39:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17154; Tue, 2 Jul 2002 12:40:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g62Je3u01801; Tue, 2 Jul 2002 12:40:03 -0700 X-mProtect: <200207021940> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.186, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfQrNXC; Tue, 02 Jul 2002 12:39:53 PDT Message-ID: <3D220180.90701@iprg.nokia.com> Date: Tue, 02 Jul 2002 12:39:44 -0700 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hancock, Robert" CC: "'Gabor Fodor'" , nsis@ietf.org, hemant.chaskar@nokia.com Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t References: <76C92FBBFB58D411AE760090271ED4181EA40F@rsys002a.roke.co.uk> Content-Type: multipart/alternative; boundary="------------020306090904040405080101" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------020306090904040405080101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Robert, I added Hemant to the cc:-list. I'll give my best shot at answering your comments. Hancock, Robert wrote: >hi Gabor, Cedric, all, > >I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing. > thanks. Hopefully our draft will fit in this framework:-) > > >Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as: >"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK. >"NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case. >"You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first. > Our attempt in this draft was to present a somewhat restricted framework: QoS establishment for e2e can be down with existing tools (RSVP + slight modifications); edge signaling (for establishment or during handoff) can be done with tools under construction (context transfer); so NSIS should focus on the QoS re-establishment after a handoff. So our main working assumption is to deal with mobility. How to deal with mobility? I agree with you that "NSIS can be implemented so as to work well with YYY mobility protocols and other with the same properties". So the question is to figure out what set of properties the protocol YYY and others have that are of interest for NSIS. The mobility protocols used in our proposal are mobile IP and context transfer. There is little dependence on MIP in our framework. The second one is somewhat redundant with NSIS, and there has been a thread on this list cross-posted on seamoby about it. We suggest that as CT and NSIS share the same properties on the edge (CT by signaling which QoS context should be transfered, and nsis by signaling QoS itself), NSIS has no need signaling over the air interface whenever CT is available. However, as your first statement suggests, "Use NSIS with CT or it won't work" is unacceptable, as CT is not always successful or available. > > >In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. > The update on the data path is pretty much independent of mobility protocols. Let me state why: the trigger is a message independent of the mobility protocol. The mechanism to identify the crossover router is also independent of the mobility protocol, but based on the QoS session id jointly with a flow filter. I haven't looked at the details, but I would think it could be not based on Mobile IP. However, I for one want to make sure that it works well with MIP:-) >That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.] > The title expresses the incremental approach we considered. I think if you can get something to work with MIP (without dependencies) then MIP is general enough in principles to extend it to other mobility. I admit not having examined other mobility solutions, even though it seems to me we did not lose generality by assuming MIP as mobility. > > >In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages. > Don't you think that the MN-AR signaling changes if there is an AR-AR signaling? It does change as CT will add its own signaling to trigger the AR-AR signaling (which contexts are transfered and such). I agree on the other hand that if no AR-AR signaling is available (not implemented/failure) then the MN-AR should be aware/able to recover > >In case this all comes across as wildly vacuous, here are two lesser but concrete questions: >*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS? > First, by 'rohc world', do you mean some 'resource signaling protocol compression'? I think we have to look back to the thread with seamoby. But my impression was that seamoby would do QoS ct independently of NSIS, and that NSIS was not taking up redundant work with theirs. As such, I'd use the first solution whenever CT is available. The signaling compression interworking with CT is a neat idea, but seems much more difficult. > >*) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable? > Well, the terms are from draft-koodli-seamoby-ct-03.txt. [seamoby] is chartered to define context transfer protocol for QoS, and NSIS will not recreate anything new there. So interworking these is not inevitable, but should be the primary choice. Thanks for your comments, Cedric. > > >cheers, > >robert h. > >>-----Original Message----- >>From: Gabor Fodor [mailto:erafodo@ESEALNT448.al.sw.ericsson.se] >>Sent: 01 July 2002 18:32 >>To: cedric@iprg.nokia.com >>Cc: nsis@ietf.org >>Subject: Re: [NSIS] Re: Comments on >>draft-westphal-nsis-qos-mobileip-00.txt >> >> >>Hi Cedric, >> >>Thnaks for your answers, I would like to discuss >>one of your points here, which I believe >>is important: >> >>[...] >> >> >> >>>[GF] >>>4 >>>I am not sure that it is meaningful at this point to start >>>discussing specific solution approaches. You seem to propose >>>to use ICMP as a design base for both edge signaling and for >>>context transfer (AR to AR). At least for the edge signaling, >>>we need to consider the edge specific requirements before >>>we start discussing what existing or new protocol can be the >>>design base for that. >>>[GF] >>> >>>Let me explain a bit here: the design base for edge signaling and >>>context transfer is >>>really 'A context transfer protocol for seamless mobility', >>>draft-koodli-seamoby-ctv6-03.txt. >>>Earlier version of draft-koodli-seamoby-ctv6 were ICMP >>> >>based. However, >> >>>it is more general in this latest version, and not >>> >>necessarily ICMP. As >> >>>a consequence, we mention ICMP >>>as a possible illustration. The main point is that QoS signaling is >>>redundant with context transfer, one object being >>> >>transferred being QoS >> >>>context, and that CT signaling will do the job for the MN to AR QoS >>>signaling. >>>We will clarify this point. >>> >>[GF] >>We need to understand and analyze better the requirements on the edge >>and the CT signaling protocols. You make a good point : the >>QoS signaling >>is to a great extent redundant with context transfer >>(which makes the re-use of the same design attractive), but there >>may as well be important differences that are connected to the >>wireless interface itself. I believe that there are scenarios where >>transferring the context from AR1 to AR2 is not sufficient to exercise >>admission control at and make the mecessary configurations of the new >>wireless link. I think we need to list the requirements for the edge >>protocol and go check how those are fulfilled >>with differenet alternatives. >>[GF] >> >>/Gabor >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > >======================================================================================== >Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. > > >------------------------------------------------------------------------ > >The information contained in this e-mail and any attachments is confidential to Roke >Manor Research Ltd and must not be passed to any third party without permission. This >communication is for information only and shall not create or change any contractual >relationship. > --------------020306090904040405080101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi  Robert,

I added Hemant to the cc:-list. I'll give my best shot at answering your comments.

Hancock, Robert wrote:
hi Gabor, Cedric, all,

I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing.
thanks. Hopefully our draft will fit in this framework:-)


Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as:
"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK.
"NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case.
"You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first.
Our attempt in this draft was to present a somewhat restricted framework: QoS establishment for e2e can be down with existing tools (RSVP + slight modifications); edge signaling (for establishment or during handoff) can be done with tools under construction (context transfer); so NSIS should focus on the QoS re-establishment after a handoff. So our main working assumption is to deal with mobility.

How to deal with mobility? I agree with you that "NSIS can be implemented so as to work well with YYY mobility protocols and other with the same properties". So the question is to figure out what set of properties the protocol YYY and others have that are of interest for NSIS. The mobility protocols used in our proposal are mobile IP and context transfer.

There is little dependence on MIP in our framework. The second one is somewhat redundant with NSIS, and there has been a thread on this list cross-posted on seamoby about it.  We suggest that as CT
and NSIS share the same properties on the edge (CT by signaling which QoS context should be transfered, and nsis by signaling QoS itself), NSIS has no need signaling over the air interface whenever CT is available. However, as your first statement suggests, "Use NSIS with CT or it won't work" is unacceptable, as CT is not always successful or available. 


In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism.
The update on the data path is pretty much independent of mobility protocols. Let me state why: the trigger is a message independent of the mobility protocol. The mechanism to identify the crossover router is also independent of the mobility protocol, but based on the QoS session id jointly with a flow filter. I haven't looked at the details, but I would think it could be not based on Mobile IP. However, I for one want to make sure that it works well with MIP:-)
That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.]
The title expresses the incremental approach we  considered. I think if you can get something to work with MIP (without dependencies) then MIP is general enough in principles to extend it to other mobility. I admit not having examined other mobility solutions, even though it seems to me we did not lose generality by assuming MIP as mobility.


In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages.
Don't you think that the MN-AR signaling changes if there is an AR-AR signaling?
It does change as CT will add its own signaling to trigger the AR-AR signaling (which
contexts are transfered and such). I agree on the other hand that if no AR-AR signaling is available (not implemented/failure) then the MN-AR should be aware/able to recover

In case this all comes across as wildly vacuous, here are two lesser but concrete questions:
*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS?
First, by 'rohc world', do you mean some 'resource signaling protocol compression'?
I think we have to look back to the thread with seamoby. But my impression was that
seamoby would do QoS ct independently of NSIS, and that NSIS was not taking up redundant work with theirs.  As such, I'd use the first solution whenever CT is available.
The signaling compression interworking with CT is a neat idea, but seems much more difficult.

*) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable?
Well, the terms are from draft-koodli-seamoby-ct-03.txt.
[seamoby] is chartered to define context transfer protocol for QoS, and NSIS will not
recreate anything new there. So interworking these is not inevitable, but should be the primary choice.
Thanks for your comments,

Cedric.



cheers,

robert h.

-----Original Message-----
From: Gabor Fodor [mailto:erafodo@ESEALNT448.al.sw.ericsson.se]
Sent: 01 July 2002 18:32
To: cedric@iprg.nokia.com
Cc: nsis@ietf.org
Subject: Re: [NSIS] Re: Comments on
draft-westphal-nsis-qos-mobileip-00.txt


Hi Cedric, 

Thnaks for your answers, I would like to discuss
one of your points here, which I believe
is important:

[...]

 
[GF]
4
I am not sure that it is meaningful at this point to start
discussing specific solution approaches. You seem to propose
to use ICMP as a design base for both edge signaling and for
context transfer (AR to AR). At least for the edge signaling,
we need to consider the edge specific requirements before
we start discussing what existing or new protocol can be the
design base for that.
[GF]
Let me explain a bit here: the design base for edge signaling and
context transfer is
really 'A context transfer protocol for seamless mobility',
draft-koodli-seamoby-ctv6-03.txt.
Earlier version of draft-koodli-seamoby-ctv6 were ICMP 
based. However,
it is more general in this latest version, and not 
necessarily ICMP. As
a consequence, we mention ICMP
as a possible illustration. The main point is that QoS signaling is
redundant with context transfer, one object being 
transferred being QoS
context, and that CT signaling will do the job for the MN to AR QoS
signaling. 
We will clarify this point.
[GF]
We need to understand and analyze better the requirements on the edge
and the CT signaling protocols. You make a good point : the 
QoS signaling
is to a great extent redundant with context transfer 
(which makes the re-use of the same design attractive), but there
may as well be important differences that are connected to the
wireless interface itself. I believe that there are scenarios where
transferring the context from AR1 to AR2 is not sufficient to exercise
admission control at and make the mecessary configurations of the new
wireless link. I think we need to list the requirements for the edge
protocol and go check how those are fulfilled 
with differenet alternatives.
[GF]

/Gabor



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


========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.


The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------020306090904040405080101-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 18:33:29 2002 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 SAA19609 for ; Tue, 2 Jul 2002 18:33:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29125 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 18:34:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28103; Tue, 2 Jul 2002 18:17:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28072 for ; Tue, 2 Jul 2002 18:16:57 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18931 for ; Tue, 2 Jul 2002 18:16:09 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g62MKYj06712 for ; Tue, 2 Jul 2002 17:20:34 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Jul 2002 17:16:56 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 17:16:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: Comments on draft-westphal-nsis-qos-mobileip-00.txt Date: Tue, 2 Jul 2002 18:16:55 -0400 Message-ID: Thread-Topic: [NSIS] RE: Comments on draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcIhQR/qYlq6hFAdQh2CNjrWHlg0uQA0OSmA To: , Cc: X-OriginalArrivalTime: 02 Jul 2002 22:16:56.0496 (UTC) FILETIME=[2D54EB00:01C22216] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA28073 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Xiaoming: Please see inline: ------------------------------------snip--------------------------------------- [XF] I'm not of a security expert, but it seems to me the entity performing authentication for a QoS request is the crossover router. Is it sufficient enough? Again the resources in access networks are limited, what if a misbehaved router (between MN and crossover router) modifies a QoS request? Then rest of routers would better be untouched, instead of reserving resources on! [Hemant2] I think from security perspective (not DoS perspective though), it may suffice to do authentication in crossover router. This is because, crossover router happens to be on existing data path and it is reasonable to trust entities on the existing data path. [Hemant2] The kind of DoS attack that you mention is still possible. It is even possible from malicious "hosts" spoofing the QoS request. The malicious host may send many spoofed QoS requests, only to be later rejected by crossover router. With forward reservation approach, in addition to causing processing overhead of creating resource reservation and authentication, the host can even get a small burst of packets transmitted with QoS until authentication failure is detected. One can defer resource comittment until authentication succeeds (this can be implemented by CONFIRM message in the current solution). This prevents free QoS use for the small burst I mentioned above, but still causes processing overhead. But, if you do not use forward reservation approach, you loose on speed of QoS establishment front for genuine QoS requests. There is a tradeoff here. [Hemant2] However, we think that the current mechanism of authenticating QoS signaling does prevent a situation where malicious node disrupts the ongoing QoS of mobile node, either by sending QoS request to make it appear as if handoff has occured or by reducing the QoS requested. And what if an MN doesn't really want to consume QoS he requested? I think we should protect this DoS at the very edge (e.g., AR)! [Hemant2] What is the problem if MN does not consume the requested QoS, as long as it is paying for it? Nonetheless, it will be good if we can detect the DoS attacks of the kind mentioned above at AR itself. [XF] It looks like IPv6 signaling is your main focus (e.g., 3 > The draft talks about the negotiation procedures (in 4.2). > In my opinion the draft should identify the requirement more > clearly, preferably with a reference to either the NSIS or > the mobile IP requirement draft. Is there a difference between > negotiation (which takes place upon QoS initiation time) and > QoS adaptation signaling which may take place upon hand-over ? > > [Hemant] We have advocated one pass reservation approach in the interest of speed of QoS establishment (in other words, minimize the number of packets that may get default forwarding treatment after handoff, just because QoS signaling has not yet completed). In most of the handoff cases, the request will be granted. But, there could be cases when requested QoS < offered QoS, and then, MN may choose to have control over decision as to whether to continue or terminate the session. For this case, we have provided fallback mechanism in the form of negotiation procedure. If the MN knows at handoff time (e.g. handoff from 2.5G to WLAN or vice versa) as to whether it needs to adapt QoS after handover to the characteristics of new access, it will put the adapted QoS parameters in the QoS signaling packet in the first place. Even after that, if some router cannot offer the requested QoS, we have negotiation procedure as fallback. > [XF] In this way, you may implicate somewhat complicated application interface(s). How about push some complexity into the networks (though some violating Internet design principles, but maybe beneficial in wireless/mobile environments), say, put adaption QoS data in the AR (and let AR to decide whether to depreciate or increase a session's QoS - in fact ARs could know this e.g., by checking the AP interfaces)? An AR can gracefully forward on those info to new ARs given a first one by the MN. [Hemant2] Yes, ARs acting on behalf of MN is definitely possible and is within the scope of current solution framework. When we say, MN decides, it is perfectly OK that AR can decide on MN's behalf if AR knows MN's preferences. > 6 > You identify QoS release as a necessary functionality. > Here there is a need to identify if the protocol should > support soft state (in which case this explicit QoS release > may not be necessary) or not. > > [Hemant] In soft state approach, explicit TEAR DOWN may not be required. Of course, if inter-REFRESH period is chosen long enough to save REFRESH signaling overhead, TEAR DOWN can still help. Finally, if we go for soft state & no tear down approach, the TEAR DOWN part of the protocol can be gracefully omitted. > [XF] See above. Regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 2 23:28:41 2002 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 XAA01575 for ; Tue, 2 Jul 2002 23:28:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14239 for nsis-archive@odin.ietf.org; Tue, 2 Jul 2002 23:29:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13764; Tue, 2 Jul 2002 23:15:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13683 for ; Tue, 2 Jul 2002 23:15:38 -0400 (EDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01147 for ; Tue, 2 Jul 2002 23:14:46 -0400 (EDT) Received: from Freedom.icr.a-star.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g633GkBL013511; Wed, 3 Jul 2002 11:16:57 +0800 (SGT) Message-Id: <5.1.0.14.2.20020703104530.02a96830@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Jul 2002 11:14:50 +0800 To: "Hancock, Robert" , nsis@ietf.org From: "Charles Q. Shen" Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA40E@rsys002a.roke.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA13684 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, Robert Thanks for your reply. please see comments in line. At 10:12 2002-7-2 +0100, Hancock, Robert wrote: >Content-Type: text/plain; > charset="iso-8859-1" >X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id >FAA25345 > >Hi Charles, > >Sometimes my over-careful use of language may cause more confusion than it >prevents. Formally: >*) An NSIS-aware node is defined as anything which processes an NSIS >message for whatever reason. Ok. >*) There might be reasons to process NSIS messages other than resource >management. One reason might be to address-translate a flow definition. This is probably where I would like you to elaborate. So far my impression is that we haven't reached a sole conclusion for the addressing issue of a flow especially in the mobile case. (correct me if I am wrong or have misunderstood your meaning.) So what do you mean here "address translate a flow definition"? >*) There might be several types of resource being managed, and not all >nodes will do all of them. For example, a 'normal' interior router >probably _should_ ignore NSIS messages which are about signalling for >firewall pinholing. (But note: we aren't certain if the differences >between different types of resource will be opaque to NSIS or not. See >section 4.5.3.) This is exactly what I understand. >Having said that, I would not be surprised if 99% of NSIS nodes do >resource management for QoS for the forseeable future. But that's just a >personal view about how NSIS might be used, not a statement about how the >protocol should be designed. Agree. >The basic point we are trying to emphasise is that we should strictly >avoid identifying "NSIS aware node" = "router that does QoS management". >It's true that NSIS is about resource signalling; but the emphasis is that >NSIS is about _signalling_, not about _resources_. Can't agree more. >Is this any clearer? See above :) BR/ Charles >Cheers, > >Robert > > > -----Original Message----- > > From: Charles Q. Shen [mailto:shenqi@icr.a-star.edu.sg] > > Sent: 02 July 2002 07:03 > > To: Hancock, Robert; 'Zhigang.Kan@nokia.com'; nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > Hi Robert, > > > > >*) if an intermediate node is NSIS unaware, or is NSIS aware > > but doesn't > > >do any management for some particular resource, then there's > > nothing NSIS > > >can do directly to help the resource management at that > > node. That doesn't > > >stop you using some other technique to control the resource > > at that node > > >(some variant of SNMP or COPS or RMD or whatever), but so > > far as NSIS is > > >concerned, all of that would be hidden inside your RMF > > implementation. > > > > Do you mean an NSIS aware node is at least doing something regarding > > certain resources, although it might not be managing a > > particular resource > > in question, as we use resource as a general term for serval > > items? What > > actually confused me is I remember you said before: > > > > 2) even if a node does process NSIS messages, it might do so > > for reasons > > not associated with resource management. > > > > So can you elaborate on this point, if NSIS is all about resource > > signaling? (Unless you are talking about for example, in the > > case of NI and > > NR you may not have a RMF associated with it, but even in this case > > virtually the processing of NSIS message is still one segment > > in the whole > > resource management picture.) > > > > BR/Charles > > > > > > >i'll look forward to the 'modes of operation' questions! > > > > > >cheers, > > > > > >robert h. > > > > > >ps apologies about my email disclaimer, it's not entirely > > under my control > > >to fix it, though we're doing what we can. i am aware that i > > am sending > > >this email to a public mailing list ... > > > > > > > -----Original Message----- > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > Sent: 28 June 2002 11:08 > > > > To: Hancock, Robert; nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > Hi Robert, > > > > > > > > Till now, I understood the definition of NE. Thank you. :-) > > > > It is right that we must have the common understanding of the > > > > terms, so we can continue the discussion further. > > > > > > > > One more thing, If one/more router(s) on the data path does > > > > not support RMF (as you said: if you have a distributed > > > > approach to resource management, i guess we would typically > > > > expect most nodes would have a resource management > > > > responsibility, but there's no requirement for every node to > > > > do something with resource management.), how about in this > > > > case? Can the QoS of data on this path be affected by > > these routers? > > > > > > > > Next I would like to discuss the relationship of modes of > > > > NSIS protocol operation such as how the end-to-end, > > > > edge-to-edge, and end-to-edge signaling take effects when the > > > > per-flow/per-class-flow traffic is initiated by a host. > > > > > > > > Nice weekend. > > > > > > > > BR/Kan Zhigang > > > > > > > > -----Original Message----- > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: 2002å¹´6æoe^28æ-¥ 17:33 > > > > To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > hi - minor correction - in 3rd sentence below, s/nodes/hosts/. > > > > > > > > r. > > > > > > > > > -----Original Message----- > > > > > From: Hancock, Robert > > > > > Sent: 28 June 2002 10:31 > > > > > To: 'Zhigang.Kan@nokia.com'; nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > Hi Zhigang, > > > > > > > > > > Apologies for maybe informal language. By 'box' I really mean > > > > > typically a physical thing you plug into a power supply, with > > > > > wires carrying packets into and out of it. So, usually it's a > > > > > host or a router. If signalling only follows the data path > > > > > (which is considered at the router level, not the network > > > > > level), the only relevant nodes can be the data flow > > > > > endpoints, and the only relevant routers can be the routers > > > > > the flow passes through. > > > > > > > > > > We've tried to describe things in terms of signalling going > > > > > between signalling entities rather than hosts/routers and so > > > > > on; one of the goals of this is to aim for concepts and > > > > > terminology to describe the signalling that are re-usable > > > > > if/when we subsequently think about signalling paths that are > > > > > less constrained. > > > > > > > > > > It may be (I get the impression) that the level of > > > > > abstraction in the framework makes it hard to get a grip on. > > > > > I'm not sure what would be the best way to handle this (maybe > > > > > some concrete example scenarios or something). > > > > > > > > > > We didn't want to make all the definitions very concrete, > > > > > since that implies building in assumptions about particular > > > > > application domains. Specifically, we have two potential > > > > > degrees of freedom about NSIS applicability which we've tried > > > > > to reflect by using more abstract language: > > > > > *) what sort of resources are signalled for > > > > > *) what sort of signalling paths are traversed > > > > > Currently, the first is in scope and the second not. I hope > > > > > we can avoid too long confusion about the > > > > > node/entity/network/whatever issue, because if we can't, > > > > > we'll probably be encouraged to re-write everything in terms > > > > > of routers and hosts, which will make any future extension to > > > > > other cases much harder. > > > > > > > > > > Cheers, > > > > > > > > > > Robert H. > > > > > > > > > > ps apologies about my email disclaimer, it's not entirely > > > > > under my control to fix it, though we're doing what we can. i > > > > > am aware that i am sending this email to a public > > mailing list ... > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > > Sent: 28 June 2002 10:10 > > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > I am more confused about 'node' is for 'box', but what in the > > > > > > box, a part of netwok or a whole network or whatever? Does > > > > > > the data pass through the box? How to understand the data > > > > > > path, based on per-router or per-network? Is NSIS Framework > > > > > > independent of the true networks and is it only abstract > > > > > > concept over the different environments? I cannot image how > > > > > > to deploy it in the future. > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > > Sent: 2002å¹´6æoe^28æ-¥ 16:28 > > > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band > > > > > > > > > > > > > > > > > > Hi Zhigang, > > > > > > > > > > > > Please see inline below. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Robert H. > > > > > > > > > > > > ps apologies about my email disclaimer, it's not entirely > > > > > > under my control to fix it, though we're doing what we can. i > > > > > > am aware that i am sending this email to a public > > mailing list ... > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > > > Sent: 28 June 2002 08:43 > > > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & > > Out-of-Band > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > Q1: "Node" used in your terminology can be a router, an end > > > > > > > host or a server, right? > > > > > > > > > > > > [reh] yes, in the broadest sense ('node' is a fancy name for > > > > > > 'box'). if you respect the 'on-path' restriction, a node that > > > > > > processes NSIS signalling must be on the data path, which > > > > > > probably rules out the 'server' case. > > > > > > > > > > > > > In the case of distributed RMF, must > > > > > > > each node have the resource management function in a > > > > NSIS domain? > > > > > > > > > > > > [reh] if you have a distributed approach to resource > > > > > > management, i guess we would typically expect most nodes > > > > > > would have a resource management responsibility, but there's > > > > > > no requirement for every node to do something with resource > > > > > > management. in particular: > > > > > > 1) not every node has to process NSIS messages (cf. RSVP > > > > > > operation over non-RSVP clouds) > > > > > > 2) even if a node does process NSIS messages, it might do so > > > > > > for reasons not associated with resource management. > > > > > > > > > > > > > > > > > > > > Q2: The RMF is responsible for all network provisioning and > > > > > > > resource allocation functions, and "some" of the state > > > > > > > management is an RMF responsibility. How about the > > "other" of > > > > > > > the state management, and it is refered to the state > > > > > > > management mechanism of NSIS related with "Refresh" message? > > > > > > > If so, what relationship between these two parts of state > > > > > > > management? Is it out of the scope of NSIS? I hope > > answer is no. > > > > > > > > > > > > [reh] this is a hard question to answer, and a hard question > > > > > > in general. > > > > > > > > > > > > 1. It's clear that to do resource management, you need to > > > > > > store some state information. That information might be at > > > > > > the flow level, or some 'resource class' level, or something > > > > > > else. Because the state you need to store depends on the > > > > > > resource you are trying to manage and the precision with > > > > > > which you need to manage it, we don't think NSIS can define > > > > > > how this is done. > > > > > > > > > > > > 2. You also need state to make a protocol operate correctly. > > > > > > This could include all (or none) of: > > > > > > *) information about how to reverse-path route > > messages for a flow > > > > > > *) information about who to send an acknowledgement > > to and when > > > > > > *) information about when to send a refresh message > > > > > > *) information about who was authenticated when a > > > > > reservation was made > > > > > > *) and so on > > > > > > This is all in NSIS scope to worry about. Most of it > > is per-flow. > > > > > > > > > > > > 3. The relationship between these two types of state is > > > > > > something we discussed, but only in outline. I think a basic > > > > > > design goal could be stated as: > > > > > > "It should be possible to use [a|the] NSIS protocol in such a > > > > > > way that it only requires the minimum of state storage, in > > > > > > particular no more than the resource management mechanism > > > > > > that it is supporting." It's then (I think) mainly a job for > > > > > > the implementor to do both aspects of state management in an > > > > > > economical way (in particular, without duplication). So, I > > > > > > think we need to consider the possible interactions between > > > > > > the different parts of state management, and make sure they > > > > > > get reflected as goals for NSIS design in terms of > > > > > > flexibility and general usefulness of the protocol, but > > > > > > without defining details of exactly how the different types > > > > > > of state interact. > > > > > > > > > > > > This is actually a special case of a more general issue. Look > > > > > > also at draft-braden-2level-signal-arch-00.txt where there is > > > > > > the related question of the split between CSTP and ALSP. The > > > > > > general point is that we almost certainly can't have a pure > > > > > > structure of independent layers (I would expect the ALSP-like > > > > > > upper layer to hook into the operation of the lower layer > > > > > > quite intimately rather than the other way round, but that's > > > > > > more of a protocol design issue). The state management issue > > > > > > is just one aspect of this. > > > > > > > > > > > > So, I think the answer to your question is "yes and no" (if > > > > > > you see what I mean...) > > > > > > > > > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > > > Sent: 2002å¹´6æoe^27æ-¥ 19:02 > > > > > > > To: Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org > > > > > > > Subject: RE: [NSIS] New framework draft: In-Band & > > Out-of-Band > > > > > > > > > > > > > > > > > > > > > Hi Zhigang, > > > > > > > > > > > > > > Please see inline: > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > > > > Sent: 27 June 2002 11:53 > > > > > > > > To: Hancock, Robert; nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] New framework draft: In-Band > > & Out-of-Band > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > In the draft about In-Band & Out-of-Band: > > > > > > > > > > > > > > > > "In-band signaling means that the path followed > > by the user > > > > > > > > data packets is the same as the path followed by signaling > > > > > > > > messages. In other words, the signaling and data paths are > > > > > > > > identical. Out-of-band signaling means that the > > path followed > > > > > > > > by signaling messages might be different from the > > path used > > > > > > > > by the user data packets. " > > > > > > > > > > > > > > > > So in-band signaling is same as RSVP's operation mode? > > > > > > > > > > > > > > [reh] basically yes, from a topological ("where the messages > > > > > > > go") point of view. > > > > > > > > > > > > > > > And > > > > > > > > must it install soft states in each router it > > passed through > > > > > > > > based on per-flow or per-class-flow? > > > > > > > > > > > > > > [reh] that's one reasonable way for it to work. see > > 4.4 about > > > > > > > general state management issues; there are several different > > > > > > > sorts of state and several different ways to manage > > them. and > > > > > > > some of the state management is an RMF responsibility. > > > > > > > > > > > > > > > I think that it may be > > > > > > > > better if in-band signaling is used in access network and > > > > > > > > out-of-band signaling is used in backbone > > networks (i.e. the > > > > > > > > out-of-band signaling is used for communcation > > between RMFs > > > > > > > > which are responsible for the "resource" management > > > > > > > > independent of concrete user traffic in control plane). Is > > > > > > > > resource reservation really needed in backbone > > network now or > > > > > > > > in the future? > > > > > > > > > > > > > > [reh] that's a good question. however, in our framework we > > > > > > > tried hard to avoid saying that NSIS would work in > > particular > > > > > > > ways in particular network parts. (ideally, I think there > > > > > > > should be implementation and deployment flexibility within > > > > > > > the protocol to allow this.) > > > > > > > > > > > > > > > > > > > > > > > I don't know why "the initial goal of NSIS is to > > concentrate > > > > > > > > mainly on the in-band case". > > > > > > > > > > > > > > [reh] that's a WG chair/AD question. > > > > > > > > > > > > > > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Robert H. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Hancock, Robert > > [mailto:robert.hancock@roke.co.uk] > > > > > > > > Sent: 2002å¹´6æoe^24æ-¥ 19:47 > > > > > > > > To: NSIS > > > > > > > > Subject: [NSIS] New framework draft > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > > > > activities got together after the interim meeting to put > > > > > > > > together a joint framework document in the form > > of an all-new > > > > > > > > individual submission. It (roughly) follows the structure > > > > > > > > that was introduced and refined at that meeting. > > > > > > > > > > > > > > > > > > ============================================================== > > > > > > > > ============ > > > > > > > > Abstract > > > > > > > > > > > > > > > > The NSIS working group is considering protocol > > > > > developments in > > > > > > > > signaling for resources for a traffic flow along its > > > > > > path in the > > > > > > > > network. The requirements for such signaling are being > > > > > > > > developed in a > > > > > > > > separate document; This Internet Draft proposes a > > > > > > framework for > > > > > > > > such signaling. This initial version provides > > a model for > > > > > > > > describing > > > > > > > > the entities that take part in the signaling and the > > > > > > > ways in which > > > > > > > > they can be used in different modes of > > operation. It also > > > > > > > > discusses > > > > > > > > the overall structure of such a signaling protocol. > > > > > > Finally, it > > > > > > > > considers the possible interactions of NSIS signaling > > > > > > with other > > > > > > > > protocols and functions, including security issues. > > > > > > > > > > ============================================================== > > > > > > > > ============ > > > > > > > > > > > > > > > > While it works its way through the i-d editor > > queue, you can > > > > > > > > find a copy here: > > > > > > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > > > > highlights in section 3. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Robert Hancock > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >======================================================================================== >Permission is hereby granted to pass the contents of this communication to >third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 3 02:35:58 2002 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 CAA29656 for ; Wed, 3 Jul 2002 02:35:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14244 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 02:36:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13259; Wed, 3 Jul 2002 02:21:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13227 for ; Wed, 3 Jul 2002 02:21:36 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21250 for ; Wed, 3 Jul 2002 02:20:44 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g636LVrU004876; Wed, 3 Jul 2002 08:21:31 +0200 (MEST) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id IAA22590; Wed, 3 Jul 2002 08:21:31 +0200 Received: from wrtw014 by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id IAA03358; Wed, 3 Jul 2002 08:21:31 +0200 (MET DST) Message-Id: <200207030621.IAA03358@wrtw014.wrn.ki.sw.ericsson.se> Date: Wed, 3 Jul 2002 08:21:30 +0200 (MET DST) From: Gabor Fodor Reply-To: Gabor Fodor Subject: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t To: robert.hancock@roke.co.uk, nsis@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j/avSaSewMePADDP68YL7g== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert, All, I apologize if you receive this twice. ------------- Begin Forwarded Message ------------- Hi Robert, please see some in-line comments : > -----Original Message----- > > > hi Gabor, Cedric, all, > > I'd like to throw in some cents from a frameworker's > perspective, about the basic approaches to 'data path' and > 'edge' signalling, and how this draft might relate to the > framework stuff we have been doing. > > Background comment: There's an obvious range of choices for > us about how much to link an NSIS solution with some mobility > scheme. I'd try to summarise the approach we took in our > latest framework informally as: > "To use NSIS you have to be using XXX mobility protocols or > it won't work" - not OK. > "NSIS can be implemented so it works well with YYY mobility > protocols and any others with the same basic properties" - > the ideal case. > "You can build an integrated locally-applicable protocol > which does the job of NSIS and some aspect of mobility > management and fits into the rest of the NSIS framework" - > logically conceivable but not what we're going to look at first. So from this perspective we probably need to specify how the westphal-nsis draft relates to NSIS. Is it so that the draft actually proposes a specific protocol for the edge and the data path signaling (and also for the AR-AR case, but that is not NSIS anyway) ? Once we understand this, and we have a common view on where NSIS should be with respect to your 3 cases above, we need to re-examine the proposals in the westphal-nsis draft (and any other solution proposal), is this correct ? Then, under the assumption that we go for the "ideal" (i.e. second) case, (one of) the issue(s) becomes what we mean with the "same basic properties". But in any case, we should definitely avoid the first case. > > In the data path case, we tried to state what were the > requirements for NSIS signalling, regardless of what data > path update (mobility) solution was used. So far as I can > tell, the solution here would fit with that - in other words, > you could make it part of NSIS without restricting oneself to > Mobile IP as the only supported mobility mechanism. That's Yes, you could, in which case the proposal in the westphal-draft is one which is (at least in the data path case) a proposal for the RSVPv2, do I understand this correctly ? I am not saying it is a good or bad proposal, but we certainly need to examine a bunch of issues here. Just one example: with RSVPv1 host DS marking is supported by RFC2996 (DCLASS), how is that going to be in the ICMP based RSVPv2, etc, etc... > important, since the crossover router could be anywhere in > the Internet, so it's hard to make the selection of the > approach to path update handling a local choice. I'd be happy > to have this impression confirmed (since the title of the > draft gives the opposite impression, and it may be that I'm > missing something). [NB I have other questions about the data > path component, which I find very interesting, but they're > one level of detail further down, so I'll ask them separately.] > > In the 'edge' case, I think we should draw a clear line > between MN-AR signalling and AR-AR signalling. The first is > required in all cases, probably crosses a domain boundary, > and (I think) shouldn't be needlessly different from the > wired case, especially from the application perspective. The > second is an optimisation, probably intra-domain, and might > not even be implemented (or might fail). So, my dream > solution would be to have an NSIS protocol which provided an > MN-AR component which always worked, but which worked better > if a separate AR-AR protocol (not part of NSIS) was > available. We started the discussion in this direction in > 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, > the conceptual model is rather different from the one here, > even if it's just an issue of which protocol owns which messages. Yes, in an ideal solution the AR-AR signaling availability could be seen as an "add on" that improves performance, but even if it is not available, NSIS does its own job. NB, it does not mean that the (edge) NSIS and AR-AR will not be in some respects similar. (That is why I emphasized the importance of analyzing and comparing the requirements on these two pieces.) The more "similar" they are, probably the easier the inter-working of them will be (in e.g. an AR). > > In case this all comes across as wildly vacuous, here are two > lesser but concrete questions: > *) should we rely on CT supporting NSIS directly to do > over-the-air signalling reduction, mainly at handover? or > should we rely on something from the rohc world as a general > solution, and allow the compression to use CT if available, > invisibly to NSIS? As I said, ideally CT would improve performance, but I do not think that (edge) NSIS should rely on the availability or existence of it. And since rohc is very important, I think that it should be used and therefore probably your second alternative is more reasonable. > *) is it useful if the [opaque] resource descriptions (NSIS > fw term) and QPT/QoS object (draft-westphal-... terms) come > from the same universe? or do we accept that interworking > these is going to be inevitable? > Very good point, and I currently do not see where that "universe" is really discussed, are they in the scope of seamoby ? In any case, to me it looks like that NSIS will probably need to interwork with the AR-AR part. > cheers, > > robert h. /Gabor > > > -----Original Message----- > > From: Gabor Fodor [mailto:erafodo@ESEALNT448.al.sw.ericsson.se] > > Sent: 01 July 2002 18:32 > > To: cedric@iprg.nokia.com > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] Re: Comments on > > draft-westphal-nsis-qos-mobileip-00.txt > > > > > > Hi Cedric, > > > > Thnaks for your answers, I would like to discuss > > one of your points here, which I believe > > is important: > > > > [...] > > > > > > > > > > [GF] > > > 4 > > > I am not sure that it is meaningful at this point to start > > > discussing specific solution approaches. You seem to propose > > > to use ICMP as a design base for both edge signaling and for > > > context transfer (AR to AR). At least for the edge signaling, > > > we need to consider the edge specific requirements before > > > we start discussing what existing or new protocol can be the > > > design base for that. > > > [GF] > > > > > Let me explain a bit here: the design base for edge signaling and > > > context transfer is > > > really 'A context transfer protocol for seamless mobility', > > > draft-koodli-seamoby-ctv6-03.txt. > > > Earlier version of draft-koodli-seamoby-ctv6 were ICMP > > based. However, > > > it is more general in this latest version, and not > > necessarily ICMP. As > > > a consequence, we mention ICMP > > > as a possible illustration. The main point is that QoS > signaling is > > > redundant with context transfer, one object being > > transferred being QoS > > > context, and that CT signaling will do the job for the MN > to AR QoS > > > signaling. > > > We will clarify this point. > > > > [GF] > > We need to understand and analyze better the requirements > on the edge > > and the CT signaling protocols. You make a good point : the > > QoS signaling > > is to a great extent redundant with context transfer > > (which makes the re-use of the same design attractive), but there > > may as well be important differences that are connected to the > > wireless interface itself. I believe that there are scenarios where > > transferring the context from AR1 to AR2 is not sufficient > to exercise > > admission control at and make the mecessary configurations > of the new > > wireless link. I think we need to list the requirements for the edge > > protocol and go check how those are fulfilled > > with differenet alternatives. > > [GF] > > > > /Gabor > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > ------------- End Forwarded Message ------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 3 03:55:58 2002 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 DAA01150 for ; Wed, 3 Jul 2002 03:55:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18674 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 03:56:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17894; Wed, 3 Jul 2002 03:40:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17859 for ; Wed, 3 Jul 2002 03:40:17 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00831 for ; Wed, 3 Jul 2002 03:39:28 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g637eji13947 for ; Wed, 3 Jul 2002 10:40:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Jul 2002 10:40:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 10:40:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] requirements draft -03 Date: Wed, 3 Jul 2002 10:40:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655FF@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] requirements draft -03 Thread-Index: AcIhujfyhALKAec7T8WK31Q5hA3CjAAqn9tw To: , X-OriginalArrivalTime: 03 Jul 2002 07:40:16.0225 (UTC) FILETIME=[DF8A4510:01C22264] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA17861 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > I submitted the -03 version of the requirements draft yesterday (Monday) > but due to E-Mail problems too late. So potatially it will not show up on > the ftp, sorry for that. Nevertheless, you can get it here > > http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-03.txt I would suggest a careful read of this document, I would like to see if we could start a working group last call on this version, when it is published. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 10:05:40 2002 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 KAA14959 for ; Wed, 3 Jul 2002 10:05:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13666 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 10:06:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12282; Wed, 3 Jul 2002 09:51:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12248 for ; Wed, 3 Jul 2002 09:51:42 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13690 for ; Wed, 3 Jul 2002 09:50:51 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 14:51:29 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA41E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Charles Q. Shen'" , nsis@ietf.org Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band Date: Wed, 3 Jul 2002 14:51:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi Charles, a pleasure to un-spread confusion. one comment: [snip] > > >*) There might be reasons to process NSIS messages other > than resource > >management. One reason might be to address-translate a flow > definition. > > This is probably where I would like you to elaborate. So far > my impression > is that we haven't reached a sole conclusion for the > addressing issue of a > flow especially in the mobile case. (correct me if I am wrong or have > misunderstood your meaning.) So what do you mean here > "address translate a > flow definition"? One scenario could be: *) end system in a v4 world sends out an NSIS message (e.g. a sender initiated reservation) and fills in the flow information saying what packets the reservation is for; *) message makes its way through the network following normal L3 routing, i.e. (hopefully) the same route as the data packets; *) message hits a SIIT (v4-v6 translator), which will do header translation on the data packets; in order to request the resource for the right flow, the SIIT box has to rewrite the flow definition correspondingly. To clarify, I'm just raising this as an example of the sort of thing that could be done, not saying it definitely should be. Really, I'm just working through the question of whether there might be reasons for NSIS messages to have flow identification not as part of the opaque resource management information (this is one), and for them to be processed for non resource related reasons. (Note that this particular case is entirely independent of the mobile aspects, although mobility solutions might require similar message processing.) [snip snip snip snip] Cheers, Robert H. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 12:43:52 2002 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 MAA21367 for ; Wed, 3 Jul 2002 12:42:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23544 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 12:43:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16946; Wed, 3 Jul 2002 11:02:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16311 for ; Wed, 3 Jul 2002 11:00:01 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17338 for ; Wed, 3 Jul 2002 10:59:11 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g63ExrRb027631; Wed, 3 Jul 2002 16:59:53 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHM4VDFB; Wed, 3 Jul 2002 16:59:53 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 16:59:52 +0200 Message-ID: X-Sybari-Trust: 3b27af72 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'Alban.Couturier@alcatel.fr'" , "'Olov.Schelen@operax.com'" Cc: nsis@ietf.org Date: Wed, 3 Jul 2002 16:59:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-op opsig-00.txt) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear Olov and Alban I have read your draft and I have some comments mainly on Sections 3 and 4 (see below). Best Regards, Georgios Comments on Section 3.2.1: ------------------------------------ Comment_1 on Section 3.2.1: ----------------- You mention that: "The on-path signaling relies on the fundamental assumption that packets are all routed the same way, based on the IP destination address. This will be called in this draft the "traditional IP routing." [georgios] Right but, you should not exclude other types of routing. In my opinion an on path solution should consider the possible cases described in {RFC2992] regarding: "Analysis of an Equal-Cost Multi-Path Algorithm". In general, if the signalling protocol uses the same routing protocol as the data path then the signaling messages and their associated data path packets will have to follow the same path. Comment_2 on Section 3.2.1: ------------- I do not understand this comment: "In these cases, a signaling unaware cloud is not anymore a signaling carrier, as nothing assures it will forward the signal at the same place it will forward the dataflow." [georgios] If the signalling protocol uses the same routing protocol as the data path then the signaling messages and their associated data path packets will have to follow the same path. This will have to be ensured even if the signaling protocol is not used in a certain domain. A network provider may for example need to configure the network such that signalling path messages follow the same path as the data path messages. However, this is a reasonable requirement, since a network provider should be able to configure many other parameters in his network. ------------------------------------------------------------------------------------------------- Comment on Section 3.2.2 --------------------------- In this section you are talking about centralized policy servers. What about distributed policy servers? Distributed on the edge nodes of a domain! ------------------------------------------------------------------------------------------------- Comment on Section 3.2.3 ------------------- You mentioned: "One problem of RSVP and intserv is that every router in the network must implement intserv and RSVP in order to link the sink and the source with a chain of QoS capable routers that all allocate resources for the flow." [georgios] not all routers in a communication path have to implement Intserv. Actually, you mighty have domains that are overprovisioned and do not implement Intserv. What I try to say is that this issue applies to both types of architectures, i.e., on path and out of path. Therefore, it is not fair to presented here as an on path issue! ------------------------------------------------------------------------------------------------- Comment on Section 4.2.1 ----------------------------- You mention that there are benefits of using independent signaling plane and forwarding plane. This is only a benefit only when only you will assume that the forwarding plane is overprovisioned or, etc., You can get the same situation with an on path signaling when you will assume that a network consists of a concatenation of domains and the only routers that are using the NSIS protocol are only few edge nodes. This is after assuming that all the other routers are overprovisioned. Thus I do not see this issue as a benefit of the out of path architecture! ------------------------------------------------------------------------------------------------- Comment on Section 4.2.2 --------------- You mentioned that VoIP or multimedia network applications rely on servers such as soft switches, gatekeepers, etc.,,. You also mention that on-path signaling solutions require complex deployments that can be avoided thanks to the placement's flexibility associated to the off-path model. In my opinion the solutions that are needed for a centralized entity located out of path to efficiently configure, efficiently manage resources, and efficiently communicate with the routers that are on path and are not using the NSIS protocol are much more complicated than the solutions that you will need to use when the servers are located on path. Comment in Section 4.2.3 ------------------------------ This benefit is associated with an on path disadvantage given in Section 3.2.1. The comment that I gave there applies also here! In general, if the signalling protocol uses the same routing protocol as the data path then the signaling messages and their associated data path packets will have to follow the same path. Comment in Section 4.3 ---------------------------- I would like to add some more issues with the out of path signaling: The out of path signaling scenario, compared to the in-path signaling, introduces the need of a centralized architecture (which can in turn be distributed). Having an architecture with centralized decision-making capabilities means that certain kinds of issues must be handled: * There may be a single point of failure Failure detection and error recovery are tremendously important. * Checking for availability of resources within a domain may be based on either static or dynamic configuration data. If this is done dynamically, the RTT of the signalling protocol itself could be increased. This is an addition to the text that you propose in Section 4.3.2. * The centralized resource management entity might become congested faster due to the higher number of signaling requests compared to a distributed resource management architecture. * Sophisticated mechanisms for discovery of the centralized entities are needed. This is an addition to your Section 4.3.1. * Routing of signaling messages might affect the routing of data path. This is similar to the issue explained in Section 4.3.1. * Anytime a handover or a route change takes place, the routing of the data path may change. Mechanisms are needed to relate the path that signaling messages and data path packets follow. This is similar to the issue explained in Section 4.3.1. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 13:46:21 2002 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 NAA23112 for ; Wed, 3 Jul 2002 13:46:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25532 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 13:47:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19015; Wed, 3 Jul 2002 11:42:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18989 for ; Wed, 3 Jul 2002 11:42:23 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18680 for ; Wed, 3 Jul 2002 11:40:20 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g63En5x23827 for ; Wed, 3 Jul 2002 09:49:05 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Jul 2002 09:48:36 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 09:48:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t Date: Wed, 3 Jul 2002 10:48:35 -0400 Message-ID: Thread-Topic: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t Thread-Index: AcIiWfkUzhbJvGhdQwKGW/dbZQhFKgAQ+sNw To: Cc: , , X-OriginalArrivalTime: 03 Jul 2002 14:48:36.0493 (UTC) FILETIME=[B617F3D0:01C222A0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18990 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, -------------------------------------clip--------------------------------------- > hi Gabor, Cedric, all, > > I'd like to throw in some cents from a frameworker's > perspective, about the basic approaches to 'data path' and > 'edge' signalling, and how this draft might relate to the > framework stuff we have been doing. > > Background comment: There's an obvious range of choices for > us about how much to link an NSIS solution with some mobility > scheme. I'd try to summarise the approach we took in our > latest framework informally as: > "To use NSIS you have to be using XXX mobility protocols or > it won't work" - not OK. > "NSIS can be implemented so it works well with YYY mobility > protocols and any others with the same basic properties" - > the ideal case. > "You can build an integrated locally-applicable protocol > which does the job of NSIS and some aspect of mobility > management and fits into the rest of the NSIS framework" - > logically conceivable but not what we're going to look at first. So from this perspective we probably need to specify how the westphal-nsis draft relates to NSIS. Is it so that the draft actually proposes a specific protocol for the edge and the data path signaling (and also for the AR-AR case, but that is not NSIS anyway) ? Once we understand this, and we have a common view on where NSIS should be with respect to your 3 cases above, we need to re-examine the proposals in the westphal-nsis draft (and any other solution proposal), is this correct ? [Hemant] I think that the features fundamental to all (layer 3) mobility protocols are: (i) somehow layer 3 routing of packets through the network changes, and hence, we need to establish QoS along the new packet path. (ii) The old and new paths can intersect at some crossover router (QC actually) which may be a priori unknown. (iii) Movement of one endpoint may change packet paths in both directions. (iv) QoS must be established ASAP after the node is ready to send packet from the new point of attachment. (v) Security considerations. Any NSIS solution that claims to work with layer 3 mobility needs to address these issues independently (i.e. without relying on the specific features of a particular mobility management protocol). At the same time, NSIS has to address specific featurs of Mobile IP, such as (vi) CoA may change after handoff. (vii) Sensitivity to Mobile IP companion protocols (fast handoff, CT and CARD). This is because, realistically, Mobile IP will be the most (! only?) dominant layer 3 mobility protocol for the foreseeable future. -------------------------------------clip--------------------------------------------- [Hemant] Thanks, Hemant. > cheers, > > robert h. /Gabor > > > -----Original Message----- > > From: Gabor Fodor [mailto:erafodo@ESEALNT448.al.sw.ericsson.se] > > Sent: 01 July 2002 18:32 > > To: cedric@iprg.nokia.com > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] Re: Comments on > > draft-westphal-nsis-qos-mobileip-00.txt > > > > > > Hi Cedric, > > > > Thnaks for your answers, I would like to discuss > > one of your points here, which I believe > > is important: > > > > [...] > > > > > > > > > > [GF] > > > 4 > > > I am not sure that it is meaningful at this point to start > > > discussing specific solution approaches. You seem to propose > > > to use ICMP as a design base for both edge signaling and for > > > context transfer (AR to AR). At least for the edge signaling, > > > we need to consider the edge specific requirements before > > > we start discussing what existing or new protocol can be the > > > design base for that. > > > [GF] > > > > > Let me explain a bit here: the design base for edge signaling and > > > context transfer is > > > really 'A context transfer protocol for seamless mobility', > > > draft-koodli-seamoby-ctv6-03.txt. > > > Earlier version of draft-koodli-seamoby-ctv6 were ICMP > > based. However, > > > it is more general in this latest version, and not > > necessarily ICMP. As > > > a consequence, we mention ICMP > > > as a possible illustration. The main point is that QoS > signaling is > > > redundant with context transfer, one object being > > transferred being QoS > > > context, and that CT signaling will do the job for the MN > to AR QoS > > > signaling. > > > We will clarify this point. > > > > [GF] > > We need to understand and analyze better the requirements > on the edge > > and the CT signaling protocols. You make a good point : the > > QoS signaling > > is to a great extent redundant with context transfer > > (which makes the re-use of the same design attractive), but there > > may as well be important differences that are connected to the > > wireless interface itself. I believe that there are scenarios where > > transferring the context from AR1 to AR2 is not sufficient > to exercise > > admission control at and make the mecessary configurations > of the new > > wireless link. I think we need to list the requirements for the edge > > protocol and go check how those are fulfilled > > with differenet alternatives. > > [GF] > > > > /Gabor > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > ------------- End Forwarded Message ------------- _______________________________________________ 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 daemon@ns.ietf.org Wed Jul 3 13:59:07 2002 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 NAA24278 for ; Wed, 3 Jul 2002 13:59:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27108 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 13:59:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23224; Wed, 3 Jul 2002 12:33:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23195 for ; Wed, 3 Jul 2002 12:33:30 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20970 for ; Wed, 3 Jul 2002 12:32:41 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 17:16:49 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA428@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org Cc: erafodo@ESEALNT448.al.sw.ericsson.se, Cedric.Westphal@nokia.com Subject: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t Date: Wed, 3 Jul 2002 17:16:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi, [snip clip ...] > [Gabor] Once we understand this, and we have a common view on where > NSIS should > be with respect to your 3 cases above, we need to re-examine the > proposals in the westphal-nsis draft (and any other solution > proposal), > is this correct ? > > [Hemant] I think that the features fundamental to all (layer > 3) mobility protocols are: (i) somehow layer 3 routing of > packets through the network changes, and hence, we need to > establish QoS along the new packet path. (ii) The old and new > paths can intersect at some crossover router (QC actually) > which may be a priori unknown. (iii) Movement of one endpoint > may change packet paths in both directions. (iv) QoS must be > established ASAP after the node is ready to send packet from > the new point of attachment. (v) Security considerations. Any > NSIS solution that claims to work with layer 3 mobility needs > to address these issues independently (i.e. without relying > on the specific features of a particular mobility management > protocol). At the same time, NSIS has to address specific > featurs of Mobile IP, such as (vi) CoA may change after > handoff. (vii) Sensitivity to Mobile IP companion protocols > (fast handoff, CT and CARD). This is because, realistically, > Mobile IP will be the most (! > only?) dominant layer 3 mobility protocol for the foreseeable > future. > I can agree with all of this (i)-(v), and in fact i would say (vi) as well is common to most mobility protocols, at least those which have to be able to operate on a macro scale. We have a similar list in our framework document. This means that we have the same views about what data path signalling problems NSIS has to solve. What I'm not certain about is whether the scope of (vii) is clear, and the extent to which (vii) is Mobile-IP specific. This is why I am confused about the edge signalling part of the proposal. (This is what I tried to say in a previous email, but possibly in a somewhat opaque way.) Cheers, Robert H. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 14:18:30 2002 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 OAA25644 for ; Wed, 3 Jul 2002 14:18:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28869 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 14:19:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18080; Wed, 3 Jul 2002 11:30:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17899 for ; Wed, 3 Jul 2002 11:29:00 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18339 for ; Wed, 3 Jul 2002 11:28:12 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g63FS8Rb003149; Wed, 3 Jul 2002 17:28:08 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKSP1QR; Wed, 3 Jul 2002 17:28:08 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 17:28:08 +0200 Message-ID: X-Sybari-Trust: 63e79add 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Date: Wed, 3 Jul 2002 17:28:07 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven I will only reply to one of your statements/remarks, that is mainly representative also for some of the other statements/remarks that you have sent in your previous e-mail. Note that I am open on discussing and contributing to your draft. [georgios-first]>> I will only comment your draft starting from Section 5. [georgios-first]>> Main comment that I have is related to the fact that you somehow [georgios-first]>> emphasise that the per-class states complicate the failure notification [georgios-first]>> and recovery issues, while I think that failure notification and recovery [georgios-first]>> issues are independent of the type of these states. [sven] In general, per-class state has the effect of losing the link between a certain initiator and its associated reservation. As such, it causes an issues for failure notification because of the absence of state information on where to send the notification. [georgios] well, in both approaches (when a node uses a per flow state or a per class state), a failure can be notified to either another NF (NSIS Forwarder) or to a NSIS Initiator (NI). In the per-class state approach the failure can be notified to a NF (NSIS Forwarder) located at an edge node that can relate the per class state with a per flow state. This NF can subsequently notify the NSIS Initiator (NI) when needed. In the per flow state approach the failure can be notified to an NF (edge) or to an NI when needed. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 14:24:01 2002 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 OAA26058 for ; Wed, 3 Jul 2002 14:24:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29358 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 14:24:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18717; Wed, 3 Jul 2002 11:37:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18628 for ; Wed, 3 Jul 2002 11:37:37 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18527 for ; Wed, 3 Jul 2002 11:36:49 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 16:37:06 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA422@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Cedric Westphal'" , "'Gabor Fodor'" Cc: nsis@ietf.org, hemant.chaskar@nokia.com Subject: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-w estphal-nsis-qos-mobileip-00.txt) Date: Wed, 3 Jul 2002 16:37:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Cedric, Gabor, Hemant, all ... An attempted response to the edge related questions. (So far as I can tell, we don't see any mismatch in terms of scope or intention between this and our [individual] NSIS framework i-d; we tried to define a generic model for what has to be done in 5.4 of our draft, and I don't think this solution is any more specific to MIP than that. The main issue might have been the flow classification addresses, but you are assuming CoA like us.) On the 'edge signalling' case, I guess the main point is that I'm confused about the scope of seamoby CT. Specifically regarding MN-AR signalling (no issue about the AR-AR part): a) the koodli draft talks about a MN-AR CTIN message to be sent around the time of handover, which I read as the MN saying "please prepare to transfer some context". b) your draft talks about an MN-AR CIN message to be sent around the time of flow initiation, which I read as the MN saying "here are the QoS requirements for my flow which I may later want to transfer". (a) is what I thought CT was restricted to, and our fw considers interworking with such a function (5.3.5). (b) seems to overlap with NSIS end-to-edge case (3.2.3). Have I missed the point? do we expect a host to use different QoS signalling in the special case that it is connected to a CT-capable network (and what if we consider the scenario MN-->MR like in NEMO?) [without me understanding this aspect, i probably can't ask sensible questions about signalling reduction or resource formats.] cheers, robert h. [prior messages - format plain-textified] -----Original Message----- From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] Sent: 02 July 2002 20:40 To: Hancock, Robert Cc: 'Gabor Fodor'; nsis@ietf.org; hemant.chaskar@nokia.com Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t Hi Robert, I added Hemant to the cc:-list. I'll give my best shot at answering your comments. Hancock, Robert wrote: hi Gabor, Cedric, all,I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing. thanks. [cw] Hopefully our draft will fit in this framework:-) [reh] Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as:"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK."NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case."You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first. [cw] Our attempt in this draft was to present a somewhat restricted framework: QoS establishment for e2e can be down with existing tools (RSVP + slight modifications); edge signaling (for establishment or during handoff) can be done with tools under construction (context transfer); so NSIS should focus on the QoS re-establishment after a handoff. So our main working assumption is to deal with mobility. How to deal with mobility? I agree with you that "NSIS can be implemented so as to work well with YYY mobility protocols and other with the same properties". So the question is to figure out what set of properties the protocol YYY and others have that are of interest for NSIS. The mobility protocols used in our proposal are mobile IP and context transfer. There is little dependence on MIP in our framework. The second one is somewhat redundant with NSIS, and there has been a thread on this list cross-posted on seamoby about it. We suggest that as CT and NSIS share the same properties on the edge (CT by signaling which QoS context should be transfered, and nsis by signaling QoS itself), NSIS has no need signaling over the air interface whenever CT is available. However, as your first statement suggests, "Use NSIS with CT or it won't work" is unacceptable, as CT is not always successful or available. [reh] In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. [cw] The update on the data path is pretty much independent of mobility protocols. Let me state why: the trigger is a message independent of the mobility protocol. The mechanism to identify the crossover router is also independent of the mobility protocol, but based on the QoS session id jointly with a flow filter. I haven't looked at the details, but I would think it could be not based on Mobile IP. However, I for one want to make sure that it works well with MIP:-) [reh] That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.] [cw] The title expresses the incremental approach we considered. I think if you can get something to work with MIP (without dependencies) then MIP is general enough in principles to extend it to other mobility. I admit not having examined other mobility solutions, even though it seems to me we did not lose generality by assuming MIP as mobility. [reh] In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages. [cw] Don't you think that the MN-AR signaling changes if there is an AR-AR signaling? It does change as CT will add its own signaling to trigger the AR-AR signaling (which contexts are transfered and such). I agree on the other hand that if no AR-AR signaling is available (not implemented/failure) then the MN-AR should be aware/able to recover [reh] In case this all comes across as wildly vacuous, here are two lesser but concrete questions:*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS? [cw] First, by 'rohc world', do you mean some 'resource signaling protocol compression'? I think we have to look back to the thread with seamoby. But my impression was that seamoby would do QoS ct independently of NSIS, and that NSIS was not taking up redundant work with theirs. As such, I'd use the first solution whenever CT is available. The signaling compression interworking with CT is a neat idea, but seems much more difficult. [reh] *) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable? [cw] Well, the terms are from draft-koodli-seamoby-ct-03.txt. [seamoby] is chartered to define context transfer protocol for QoS, and NSIS will not recreate anything new there. So interworking these is not inevitable, but should be the primary choice. Thanks for your comments, Cedric. [snip] ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 14:41:43 2002 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 OAA28102 for ; Wed, 3 Jul 2002 14:41:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01302 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 14:42:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28134; Wed, 3 Jul 2002 14:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28103 for ; Wed, 3 Jul 2002 14:08:56 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24812 for ; Wed, 3 Jul 2002 14:08:07 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g63G9lRb009542; Wed, 3 Jul 2002 18:09:47 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKSPPWR; Wed, 3 Jul 2002 18:09:47 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 18:09:47 +0200 Message-ID: X-Sybari-Trust: 4529faf9 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Cc: "'john.loughney@nokia.com'" Date: Wed, 3 Jul 2002 18:09:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] FW: I-D ACTION:draft-demeer-nsis-analysis-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear all As you might know we have submitted an updated version of the Analysis draft, that has been announced yesterday (see below) and is available from the on-line Internet-Drafts directories: http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt Please note that several new issues are included in this draft, including a contribution on security from Hannes Tschofenig. John as I understood we can have a time slot of 5 minutes to present the issues emphasized in this draft. Best Regards, Georgios |-----Original Message----- |From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] |Sent: Tuesday, July 02, 2002 12:31 PM |Subject: I-D ACTION:draft-demeer-nsis-analysis-02.txt | | |A New Internet-Draft is available from the on-line |Internet-Drafts directories. | | | Title : Analysis of Existing QoS Solutions | Author(s) : H. De Meer et al. | Filename : draft-demeer-nsis-analysis-02.txt | Pages : 27 | Date : 01-Jul-02 | |This memo provides a brief analysis of existing IP quality of service |(QoS) solutions and the implied signalling issues. This analysis is |intended to point out open issues in QoS signalling. Moreover, this |analysis is done in order to understand whether the strict QoS |requirements imposed by future fixed and mobile applications are |satisfied by the existing IP QoS solutions. The existing IP QoS |solutions can be categorized as follows: |* End-to-end per-flow resource reservation protocols |* Integrated Services over Differentiated Services |* Statically assigned trunk reservations based on |Differentiated Services |* Dynamic trunk reservations with Aggregated RSVP | |A URL for this Internet-Draft is: |http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.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-demeer-nsis-analysis-02.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-demeer-nsis-analysis-02.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. | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 14:43:12 2002 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 OAA28289 for ; Wed, 3 Jul 2002 14:43:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01451 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 14:44:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28396; Wed, 3 Jul 2002 14:12:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28333 for ; Wed, 3 Jul 2002 14:12:18 -0400 (EDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25052 for ; Wed, 3 Jul 2002 14:11:29 -0400 (EDT) Message-Id: <200207031811.OAA25052@ietf.org> Received: from bdf (62.98.99.228) by smtp1.libero.it (6.5.015) id 3CFC3E5B00C95DE0 for nsis@ietf.org; Wed, 3 Jul 2002 17:04:13 +0200 From: Franco De nuzzo To: nsis@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2615.200 Reply-To: fdenuz@tin.it Date: Wed, 3 Jul 2002 17.09.16 +0100 Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Subject: [NSIS] Request / richiesta / requestes / italian - francais / english Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear, Friend! we are a warehouse of Mobilephone from italy (TORINO) We are lookingfor a big Quantity Almost 1000 or 2000 pieces of mobilephones : Ericsson model like series 8 ------ 628-688-788 -A2618 -A1018 - A2628 etc UNloked! EUROP USE! so if you have other offer different please send at me your well I'm waiting for your answer Best regards Franco De Nuzzo italy Torino tel 011 250013 mobile +393281495 Grazie (tanks a lot) ps sorry if you receive this email yet -------------------------------------------------------------------------------------------------------------- bonjour nous sommes une distributions des appareil telephonique maintenaint nous sommes a la recherche d'un gross quatitative des apparail (presque 1000 ou 2000 pieces ) avec le suivant caratteristique nuveaux nome : ERICSSON MODEL 628 - 688 - 788 - 1018 - 2618 -2628 pas ferme' la Sim aussi deja utlisee pourtant avec la garantie des troi ( 3 ) moins parceque l'utilisation n'est pas pour notre magasines mais puor notre client des 'allarme de maison si vous avez aussi autre material en offer svp envoie l'offer ici bon je rest et attend votre reponde suites mercie bien Franco De Nuzzo email:uno1@inwind.it italy Torino tel 011 250013 minitel +393281495 ------------------------------------------------------------------------------------------------------------------------------------------------------------- ps: excuse moi si vous avez deja recu ca email ----------------------------------------------------------------------------------------------------- Salve sono un grossista sto cercando un grosso quantitativo di cellulari inerenti a questi modelli Ericsson -628- 2618- 2628- 1018 Anche rigenerati con almeno 3 mesi di garanzia In attesa di una Vs Risposta vi auguro una buona giornata Brotel Franco De Nuzzo www.uno1.it Best regards, (None). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 15:21:28 2002 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 PAA01281 for ; Wed, 3 Jul 2002 15:21:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06473 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 15:22:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03783; Wed, 3 Jul 2002 14:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03678 for ; Wed, 3 Jul 2002 14:59:52 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29456 for ; Wed, 3 Jul 2002 14:59:02 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA13765; Wed, 3 Jul 2002 11:59:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g63IxKZ28361; Wed, 3 Jul 2002 11:59:20 -0700 X-mProtect: <200207031859> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.79.113, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOYid7d; Wed, 03 Jul 2002 11:59:15 PDT Message-ID: <3D234983.8060809@iprg.nokia.com> Date: Wed, 03 Jul 2002 11:59:15 -0700 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hancock, Robert" CC: "'Gabor Fodor'" , nsis@ietf.org, hemant.chaskar@nokia.com Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-w estphal-nsis-qos-mobileip-00.txt) References: <76C92FBBFB58D411AE760090271ED4181EA422@rsys002a.roke.co.uk> Content-Type: multipart/alternative; boundary="------------030205080008000304040903" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------030205080008000304040903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert, Hancock, Robert wrote: >Hi Cedric, Gabor, Hemant, all ... > >An attempted response to the edge related questions. > >(So far as I can tell, we don't see any mismatch in terms of scope or intention between this and our [individual] NSIS framework i-d; we tried to define a generic model for what has to be done in 5.4 of our draft, and I don't think this solution is any more specific to MIP than that. The main issue might have been the flow classification addresses, but you are assuming CoA like us.) > >On the 'edge signalling' case, I guess the main point is that I'm confused about the scope of seamoby CT. Specifically regarding MN-AR signalling (no issue about the AR-AR part): >a) the koodli draft talks about a MN-AR CTIN message to be sent around the time of handover, which I read as the MN saying "please prepare to transfer some context". >b) your draft talks about an MN-AR CIN message to be sent around the time of flow initiation, which I read as the MN saying "here are the QoS requirements for my flow which I may later want to transfer". > >(a) is what I thought CT was restricted to, and our fw considers interworking with such a function (5.3.5). (b) seems to overlap with NSIS end-to-edge case (3.2.3). Have I missed the point? do we expect a host to use different QoS signalling in the special case that it is connected to a CT-capable network (and what if we consider the scenario MN-->MR like in NEMO?) [without me understanding this aspect, i probably can't ask sensible questions about signalling reduction or resource formats.] > Oh, I see. We can go two ways; either [seamoby] goes (b), and then the edge signaling can be leverage from them, or [seamoby] goes (a), and the edge signaling can be leveraged from there only during handoff, and some other signaling should be created for session initiation. I do believe that a host will use different signaling if it's connected to a (pick from: CT-capable/wireless/wired) network. I understand now the mention you made yesterday about 'rohc world': well, I understand it as, 'is CT a layer 3 problem?' Meaning, do we want to define a QoS signaling stack that's the same for all environments, and get modified at the link layer, depending on the environment characteristics? Or, to get back to your (a) and (b)s: do we want the CT mechanism to acquire context the same way say rohc acquires compression state? It's an interesting idea, but I'd rather go with (a) personally. Cheers, Cedric. > > >cheers, > >robert h. > >[prior messages - format plain-textified] > >-----Original Message----- >From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] >Sent: 02 July 2002 20:40 >To: Hancock, Robert >Cc: 'Gabor Fodor'; nsis@ietf.org; hemant.chaskar@nokia.com >Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t > > >Hi Robert, > >I added Hemant to the cc:-list. I'll give my best shot at answering your comments. > >Hancock, Robert wrote: > >hi Gabor, Cedric, all,I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing. >thanks. > >[cw] >Hopefully our draft will fit in this framework:-) > >[reh] >Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as:"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK."NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case."You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first. > >[cw] >Our attempt in this draft was to present a somewhat restricted framework: QoS establishment for e2e can be down with existing tools (RSVP + slight modifications); edge signaling (for establishment or during handoff) can be done with tools under construction (context transfer); so NSIS should focus on the QoS re-establishment after a handoff. So our main working assumption is to deal with mobility. > >How to deal with mobility? I agree with you that "NSIS can be implemented so as to work well with YYY mobility protocols and other with the same properties". So the question is to figure out what set of properties the protocol YYY and others have that are of interest for NSIS. The mobility protocols used in our proposal are mobile IP and context transfer. > >There is little dependence on MIP in our framework. The second one is somewhat redundant with NSIS, and there has been a thread on this list cross-posted on seamoby about it. We suggest that as CT >and NSIS share the same properties on the edge (CT by signaling which QoS context should be transfered, and nsis by signaling QoS itself), NSIS has no need signaling over the air interface whenever CT is available. However, as your first statement suggests, "Use NSIS with CT or it won't work" is unacceptable, as CT is not always successful or available. > >[reh] >In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. > >[cw] >The update on the data path is pretty much independent of mobility protocols. Let me state why: the trigger is a message independent of the mobility protocol. The mechanism to identify the crossover router is also independent of the mobility protocol, but based on the QoS session id jointly with a flow filter. I haven't looked at the details, but I would think it could be not based on Mobile IP. However, I for one want to make sure that it works well with MIP:-) > >[reh] >That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.] > >[cw] >The title expresses the incremental approach we considered. I think if you can get something to work with MIP (without dependencies) then MIP is general enough in principles to extend it to other mobility. I admit not having examined other mobility solutions, even though it seems to me we did not lose generality by assuming MIP as mobility. > >[reh] >In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages. > >[cw] >Don't you think that the MN-AR signaling changes if there is an AR-AR signaling? >It does change as CT will add its own signaling to trigger the AR-AR signaling (which >contexts are transfered and such). I agree on the other hand that if no AR-AR signaling is available (not implemented/failure) then the MN-AR should be aware/able to recover > >[reh] >In case this all comes across as wildly vacuous, here are two lesser but concrete questions:*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS? > >[cw] >First, by 'rohc world', do you mean some 'resource signaling protocol compression'? >I think we have to look back to the thread with seamoby. But my impression was that >seamoby would do QoS ct independently of NSIS, and that NSIS was not taking up redundant work with theirs. As such, I'd use the first solution whenever CT is available. >The signaling compression interworking with CT is a neat idea, but seems much more difficult. > >[reh] >*) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable? > >[cw] >Well, the terms are from draft-koodli-seamoby-ct-03.txt. >[seamoby] is chartered to define context transfer protocol for QoS, and NSIS will not >recreate anything new there. So interworking these is not inevitable, but should be the primary choice. >Thanks for your comments, > >Cedric. > >[snip] >======================================================================================== >Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. > > >------------------------------------------------------------------------ > >The information contained in this e-mail and any attachments is confidential to Roke >Manor Research Ltd and must not be passed to any third party without permission. This >communication is for information only and shall not create or change any contractual >relationship. > --------------030205080008000304040903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Robert,

Hancock, Robert wrote:
Hi Cedric, Gabor, Hemant, all ...

An attempted response to the edge related questions.

(So far as I can tell, we don't see any mismatch in terms of scope or intention between this and our [individual] NSIS framework i-d; we tried to define a generic model for what has to be done in 5.4 of our draft, and I don't think this solution is any more specific to MIP than that. The main issue might have been the flow classification addresses, but you are assuming CoA like us.)

On the 'edge signalling' case, I guess the main point is that I'm confused about the scope of seamoby CT. Specifically regarding MN-AR signalling (no issue about the AR-AR part):
a) the koodli draft talks about a MN-AR CTIN message to be sent around the time of handover, which I read as the MN saying "please prepare to transfer some context". 
b) your draft talks about an MN-AR CIN message to be sent around the time of flow initiation, which I read as the MN saying "her
e are the QoS requirements for my flow which I may later want to transfer".

(a) is what I thought CT was restricted to, and our fw considers interworking with such a function (5.3.5). (b) seems to overlap with NSIS end-to-edge case (3.2.3). Have I missed the point? do we expect a host to use different QoS signalling in the special case that it is connected to a CT-capable network (and what if we consider the scenario MN-->MR like in NEMO?) [without me understanding this aspect, i probably can't ask sensible questions about signalling reduction or resource formats.]
Oh, I see. We can go two ways; either [seamoby] goes (b), and then the edge signaling can be leverage from them, or [seamoby] goes (a), and the edge signaling can be leveraged from there only during handoff, and some other signaling should be created for session initiation.

I do believe that a host will use different signaling if it's connected to a (pick from: CT-capable/wireless/wired) network. I understand now the mention you made yesterday about 'rohc world': well, I understand it as, 'is CT a layer 3 problem?' Meaning, do we want to define a QoS signaling stack that's the same for all environments, and get modified at the link layer, depending on the environment characteristics? Or, to get back to your (a) and (b)s: do we want the CT mechanism to acquire context the same way say rohc acquires compression state? It's an interesting idea, but I'd rather go with (a) personally.

Cheers,

Cedric.


cheers,

robert h.

[prior messages - format plain-textified]

-----Original Message-----
From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
Sent: 02 July 2002 20:40
To: Hancock, Robert
Cc: 'Gabor Fodor'; nsis@ietf.org; hemant.chaskar@nokia.com
Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t


Hi  Robert,

I added Hemant to the cc:-list. I'll give my best shot at answering your comments.

Hancock, Robert wrote:

hi Gabor, Cedric, all,I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing.
thanks
 

[cw]
Hopefully our draft will fit in this framework:-)

[reh]
Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as:"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK."NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case."You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first.

[cw]
Our attempt in this draft was to present a somewhat restricted framework: QoS establishment for e2e can be down with existing tools (RSVP + slight modifications); edge signaling (for establishment or during handoff) can be done
 with tools under construction (context transfer); so NSIS should focus on the QoS re-establishment after a handoff. So our main working assumption is to deal with mobility. 

How to deal with mobility? I agree with you that "NSIS can be implemented so as to work well with YYY mobility protocols and other with the same properties". So the question is to figure out what set of properties the protocol YYY and others have that are of interest for NSIS. The mobility protocols used in our proposal are mobile IP and context transfer.

There is little dependence on MIP in our framework. The second one is somewhat redundant with NSIS, and there has been a thread on this list cross-posted on seamoby about it.  We suggest that as CT
and NSIS share the same properties on the edge (CT by signaling which QoS context should be transfered, and nsis by signaling QoS itself), NSIS has no need signaling over the air interface whenever CT is available. However, as your first stat
ement suggests, "Use NSIS with CT or it won't work" is unacceptable, as CT is not always successful or available. 

[reh]
In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. 

[cw]
The update on the data path is pretty much independent of mobility protocols. Let me state why: the trigger is a message independent of the mobility protocol. The mechanism to identify the crossover router is also independent of the mobility protocol, but based on the QoS session id jointly with a flow filter. I haven't looked at the details, but I would think it could be not based on Mobile IP. However, I for one want to make sure that it works well with MIP:-)

[reh]
That's import
ant, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.]

[cw]
The title expresses the incremental approach we  considered. I think if you can get something to work with MIP (without dependencies) then MIP is general enough in principles to extend it to other mobility. I admit not having examined other mobility solutions, even though it seems to me we did not lose generality by assuming MIP as mobility.

[reh]
In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, pr
obably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages.

[cw]
Don't you think that the MN-AR signaling changes if there is an AR-AR signaling?
It does change as CT will add its own signaling to trigger the AR-AR signaling (which
contexts are transfered and such). I agree on the other hand that if no AR-AR signaling is available (not implemented/f
ailure) then the MN-AR should be aware/able to recover

[reh]
In case this all comes across as wildly vacuous, here are two lesser but concrete questions:*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS?

[cw]
First, by 'rohc world', do you mean some 'resource signaling protocol compression'?
I think we have to look back to the thread with seamoby. But my impression was that
seamoby would do QoS ct independently of NSIS, and that NSIS was not taking up redundant work with theirs.  As such, I'd use the first solution whenever CT is available. 
The signaling compression interworking with CT is a neat idea, but seems much more difficult.

[reh]
*) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westph
al-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable?

[cw]
Well, the terms are from draft-koodli-seamoby-ct-03.txt. 
[seamoby] is chartered to define context transfer protocol for QoS, and NSIS will not
recreate anything new there. So interworking these is not inevitable, but should be the primary choice. 
Thanks for your comments,

Cedric.

[snip]
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.


The information contained in this e-mail and any attachments is confidential to Roke 
Manor Research Ltd and must not be passed to any third party without permission. This 
communication is for information only and shall not create or change any contractual 
relationship.

--------------030205080008000304040903-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 3 17:20:53 2002 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 RAA07015 for ; Wed, 3 Jul 2002 17:20:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15240 for nsis-archive@odin.ietf.org; Wed, 3 Jul 2002 17:21:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12470; Wed, 3 Jul 2002 16:36:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12441 for ; Wed, 3 Jul 2002 16:36:17 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05535 for ; Wed, 3 Jul 2002 16:35:27 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g63KbqW15847 for ; Wed, 3 Jul 2002 23:37:52 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Jul 2002 23:35:57 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 23:35:57 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 15:35:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Date: Wed, 3 Jul 2002 16:34:51 -0400 Message-ID: Thread-Topic: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Thread-Index: AcIiqIdA5P2UmTP2RbCPyZN1t8UR+gAGe2Yw To: Cc: X-OriginalArrivalTime: 03 Jul 2002 20:35:07.0986 (UTC) FILETIME=[1ECA0320:01C222D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA12442 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, Comments inline -> -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 03. July 2002 11:37 To: Weshphal Cedric (IPRG/MtView); 'Gabor Fodor' Cc: nsis@ietf.org; Chaskar Hemant (NRC/Boston) Subject: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Hi Cedric, Gabor, Hemant, all ... An attempted response to the edge related questions. (So far as I can tell, we don't see any mismatch in terms of scope or intention between this and our [individual] NSIS framework i-d; we tried to define a generic model for what has to be done in 5.4 of our draft, and I don't think this solution is any more specific to MIP than that. The main issue might have been the flow classification addresses, but you are assuming CoA like us.) On the 'edge signalling' case, I guess the main point is that I'm confused about the scope of seamoby CT. Specifically regarding MN-AR signalling (no issue about the AR-AR part): a) the koodli draft talks about a MN-AR CTIN message to be sent around the time of handover, which I read as the MN saying "please prepare to transfer some context". b) your draft talks about an MN-AR CIN message to be sent around the time of flow initiation, which I read as the MN saying "here are the QoS requirements for my flow which I may later want to transfer". --- [Hemant] I admit that we should have distinguished cases (a) and (b) in the draft. QoS initiation, negotiation and release steps (steps i, ii and iv in Section 3 of the draft) could very well be done by NSIS protocol independent of CT. Those steps could even be out of the scope of handoff signaling tool as these will typically happen at the time of flow initiation. That way, NSIS can still run even if CT is not available at AR or host is using Simple IP. But, think when CT is available. Then, we end up with redundant messages (one NSIS and one CT) to acheive the same purpose: Send QoS requirements from MN to AR. So, why not make CTIN also NSIS MN-AR message. Anyway, neither CT nor NSIS has installed base in the Internet. Just a thought! --- (a) is what I thought CT was restricted to, and our fw considers interworking with such a function (5.3.5). (b) seems to overlap with NSIS end-to-edge case (3.2.3). Have I missed the point? --- [Hemant] While I understood your classification (a) and (b), I do not see why (b) overlaps with edge-to-edge case. Don't both (a) and (b) provide MN to AR signaling, both MN and AR being on the same side of network (i.e. at the same edge). --- do we expect a host to use different QoS signalling in the special case that it is connected to a CT-capable network (and what if we consider the scenario MN-->MR like in NEMO?) [without me understanding this aspect, i probably can't ask sensible questions about signalling reduction or resource formats.] cheers, robert h. [prior messages - format plain-textified] -----Original Message----- From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] Sent: 02 July 2002 20:40 To: Hancock, Robert Cc: 'Gabor Fodor'; nsis@ietf.org; hemant.chaskar@nokia.com Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t Hi Robert, I added Hemant to the cc:-list. I'll give my best shot at answering your comments. Hancock, Robert wrote: hi Gabor, Cedric, all,I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing. thanks. [cw] Hopefully our draft will fit in this framework:-) [reh] Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as:"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK."NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case."You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first. [cw] Our attempt in this draft was to present a somewhat restricted framework: QoS establishment for e2e can be down with existing tools (RSVP + slight modifications); edge signaling (for establishment or during handoff) can be done with tools under construction (context transfer); so NSIS should focus on the QoS re-establishment after a handoff. So our main working assumption is to deal with mobility. How to deal with mobility? I agree with you that "NSIS can be implemented so as to work well with YYY mobility protocols and other with the same properties". So the question is to figure out what set of properties the protocol YYY and others have that are of interest for NSIS. The mobility protocols used in our proposal are mobile IP and context transfer. There is little dependence on MIP in our framework. The second one is somewhat redundant with NSIS, and there has been a thread on this list cross-posted on seamoby about it. We suggest that as CT and NSIS share the same properties on the edge (CT by signaling which QoS context should be transfered, and nsis by signaling QoS itself), NSIS has no need signaling over the air interface whenever CT is available. However, as your first statement suggests, "Use NSIS with CT or it won't work" is unacceptable, as CT is not always successful or available. [reh] In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. [cw] The update on the data path is pretty much independent of mobility protocols. Let me state why: the trigger is a message independent of the mobility protocol. The mechanism to identify the crossover router is also independent of the mobility protocol, but based on the QoS session id jointly with a flow filter. I haven't looked at the details, but I would think it could be not based on Mobile IP. However, I for one want to make sure that it works well with MIP:-) [reh] That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.] [cw] The title expresses the incremental approach we considered. I think if you can get something to work with MIP (without dependencies) then MIP is general enough in principles to extend it to other mobility. I admit not having examined other mobility solutions, even though it seems to me we did not lose generality by assuming MIP as mobility. [reh] In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages. [cw] Don't you think that the MN-AR signaling changes if there is an AR-AR signaling? It does change as CT will add its own signaling to trigger the AR-AR signaling (which contexts are transfered and such). I agree on the other hand that if no AR-AR signaling is available (not implemented/failure) then the MN-AR should be aware/able to recover [reh] In case this all comes across as wildly vacuous, here are two lesser but concrete questions:*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS? [cw] First, by 'rohc world', do you mean some 'resource signaling protocol compression'? I think we have to look back to the thread with seamoby. But my impression was that seamoby would do QoS ct independently of NSIS, and that NSIS was not taking up redundant work with theirs. As such, I'd use the first solution whenever CT is available. The signaling compression interworking with CT is a neat idea, but seems much more difficult. [reh] *) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable? [cw] Well, the terms are from draft-koodli-seamoby-ct-03.txt. [seamoby] is chartered to define context transfer protocol for QoS, and NSIS will not recreate anything new there. So interworking these is not inevitable, but should be the primary choice. Thanks for your comments, Cedric. [snip] ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 02:37:13 2002 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 CAA09178 for ; Thu, 4 Jul 2002 02:37:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28240 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 02:38:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27296; Thu, 4 Jul 2002 02:20:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27265 for ; Thu, 4 Jul 2002 02:20:09 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08831 for ; Thu, 4 Jul 2002 02:19:19 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g646Fr607422; Thu, 4 Jul 2002 08:15:53 +0200 Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 4 Jul 2002 08:19:29 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/04/2002 08:19:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, Thanks for your comments. I think you are making two important assumptions, that may be specific to a particular scenario: 1. Some of the NFs keep per-flow state, some do not (the 'edges' as you call them) 2. The NF that detects the failure and the NF that needs to be informed see the same network (otherwise, how will the per-class NF know which other NFs to contact) Now there are three possibilities: 1. The scenario you have in mind does not have some the issues described in the draft. They can, however, remain valid for other scenarios. 2. The scenario you have in mind can have some of the issues described in the draft. In that case, it is covered. 3. The scenario you have in mind has issues that are not mentioned in the draft. In that case, of course, we should add them. We might try to link specific issues to scenarios (like we discussed for the requirements draft). What do you think? Sven. "Georgios Karagiannis (ELN)" @ietf.org on 03/07/2002 17:28:07 Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi Sven I will only reply to one of your statements/remarks, that is mainly representative also for some of the other statements/remarks that you have sent in your previous e-mail. Note that I am open on discussing and contributing to your draft. [georgios-first]>> I will only comment your draft starting from Section 5. [georgios-first]>> Main comment that I have is related to the fact that you somehow [georgios-first]>> emphasise that the per-class states complicate the failure notification [georgios-first]>> and recovery issues, while I think that failure notification and recovery [georgios-first]>> issues are independent of the type of these states. [sven] In general, per-class state has the effect of losing the link between a certain initiator and its associated reservation. As such, it causes an issues for failure notification because of the absence of state information on where to send the notification. [georgios] well, in both approaches (when a node uses a per flow state or a per class state), a failure can be notified to either another NF (NSIS Forwarder) or to a NSIS Initiator (NI). In the per-class state approach the failure can be notified to a NF (NSIS Forwarder) located at an edge node that can relate the per class state with a per flow state. This NF can subsequently notify the NSIS Initiator (NI) when needed. In the per flow state approach the failure can be notified to an NF (edge) or to an NI when needed. Best Regards, Georgios _______________________________________________ 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 daemon@optimus.ietf.org Thu Jul 4 03:54:07 2002 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 DAA10818 for ; Thu, 4 Jul 2002 03:54:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA01669 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 03:54:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01142; Thu, 4 Jul 2002 03:41:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01111 for ; Thu, 4 Jul 2002 03:41:08 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10576 for ; Thu, 4 Jul 2002 03:40:17 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g647f5Rb019031 for ; Thu, 4 Jul 2002 09:41:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 09:41:05 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546021B80DA@esealnt448.al.sw.ericsson.se> From: "Gabor Fodor (EAB)" To: "'nsis@ietf.org'" Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Thu, 4 Jul 2002 09:38:55 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org -----Original Message----- Hi Hemant, Robert, All, my understanding is that a MN should be able to use NSIS for edge signaling irrespective of the AR being CT capable able or not. But, NSIS could use CTIN at QoS initiation time (as in case a)). Then, the issue for the MN becomes how it will know whether or not it needs to send the context to the new AR, depending on whether CT is done by the ARs or not. There are probably different ways to provide this information to the MN, for instance the AR can signal back to MN during QoS context initiation time. (Depending on the assumption that if the "first" AR is CT capable, then subsequent AR will also be that.) In the NEMO case (www.ietf.org/ietf/02jul/nemo.txt) it is also important to establish QoS along the hops "before" the AR (e.g. between MN and a wireless gateway on a bus), in which case the context has to be sent from the MN to this moving router ("wireless gateway") even if CT is done between the AR's. /Gabor > [Robert] > > On the 'edge signalling' case, I guess the main point is that > I'm confused about the scope of seamoby CT. Specifically > regarding MN-AR signalling (no issue about the AR-AR part): > a) the koodli draft talks about a MN-AR CTIN message to be > sent around the time of handover, which I read as the MN > saying "please prepare to transfer some context". > b) your draft talks about an MN-AR CIN message to be sent > around the time of flow initiation, which I read as the MN > saying "here are the QoS requirements for my flow which I may > later want to transfer". > --- > [Hemant] > > I admit that we should have distinguished cases (a) and (b) > in the draft. QoS initiation, negotiation and release steps > (steps i, ii and iv in Section 3 of the draft) could very > well be done by NSIS protocol independent of CT. Those steps > could even be out of the scope of handoff signaling tool as > these will typically happen at the time of flow initiation. > That way, NSIS can still run even if CT is not available at > AR or host is using Simple IP. But, think when CT is > available. Then, we end up with redundant messages (one NSIS > and one CT) to acheive the same purpose: Send QoS > requirements from MN to AR. So, why not make CTIN also NSIS > MN-AR message. Anyway, neither CT nor NSIS has installed base > in the Internet. Just a thought! > --- > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 04:52:17 2002 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 EAA11817 for ; Thu, 4 Jul 2002 04:52:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05207 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 04:53:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04164; Thu, 4 Jul 2002 04:34:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04137 for ; Thu, 4 Jul 2002 04:34:52 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11497 for ; Thu, 4 Jul 2002 04:34:02 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648XMd01385 for ; Thu, 4 Jul 2002 11:33:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 11:34:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:34:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] FW: I-D ACTION:draft-demeer-nsis-analysis-02.txt Date: Thu, 4 Jul 2002 11:34:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6562C@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] FW: I-D ACTION:draft-demeer-nsis-analysis-02.txt Thread-Index: AcIiw8RSUqAAHWoTRL+6OQCpFDUGcwAccGhA To: , X-OriginalArrivalTime: 04 Jul 2002 08:34:51.0389 (UTC) FILETIME=[AA1A62D0:01C22335] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA04138 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > John as I understood we can have a time slot of 5 minutes > to present the issues emphasized in this draft. Currently, the agenda is not set. It seems that we have about 3.5 hours of discussion possible and need to fit it into 2.5 hours. One way to resolve this would be to focus on work which has open issues & has been discussed on the mailing list. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 04:53:16 2002 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 EAA11843 for ; Thu, 4 Jul 2002 04:53:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05237 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 04:54:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04072; Thu, 4 Jul 2002 04:33:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04039 for ; Thu, 4 Jul 2002 04:33:20 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11484 for ; Thu, 4 Jul 2002 04:32:29 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648Vod00643 for ; Thu, 4 Jul 2002 11:31:50 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 11:33:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:33:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Date: Thu, 4 Jul 2002 11:33:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6562B@esebe004.NOE.Nokia.com> Thread-Topic: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Thread-Index: AcIityVdg1vVDzLiTeOJl0lCl5sYhQAfiLhA To: , , Cc: , X-OriginalArrivalTime: 04 Jul 2002 08:33:18.0664 (UTC) FILETIME=[72D5AC80:01C22335] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA04041 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, > On the 'edge signalling' case, I guess the main point is that > I'm confused about the scope of seamoby CT. Specifically > regarding MN-AR signalling (no issue about the AR-AR part): From my viewpoint, CT is not required for NSIS. I view CT as one tool that an NSIS solution could use. So, I definately think that at some point, we will need some sort of applicability statement describing how to use CT for NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 05:05:13 2002 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 FAA11999 for ; Thu, 4 Jul 2002 05:05:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA06133 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 05:06:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04902; Thu, 4 Jul 2002 04:46:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04873 for ; Thu, 4 Jul 2002 04:46:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11705 for ; Thu, 4 Jul 2002 04:45:37 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648kti03912 for ; Thu, 4 Jul 2002 11:46:55 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Jul 2002 11:46:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:46:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 4 Jul 2002 11:46:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6562D@esebe004.NOE.Nokia.com> Thread-Topic: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-w estphal-nsis-qos-mobileip-00.txt) Thread-Index: AcIixVm2KGa/bdpYQ7OjEYhPfJPOJwAcdv8A To: X-OriginalArrivalTime: 04 Jul 2002 08:46:24.0081 (UTC) FILETIME=[46FACC10:01C22337] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA04874 Subject: [NSIS] NSIS Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Thus far, I've been able to fit the NSIS agenda to look like this. Please let me know if I have missed anything. John NSIS IETF 54 Agenda =================== MONDAY, July 15, 2002 0900-1130 Morning Session Agenda Bashing and Status Report - 15 minutes Requirements - 30 minutes NSIS Requirements http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt NSIS Threats & Security requirements http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt NSIS Resilience http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt Framework - 60 minutes Next Steps in Signaling: A Framework Proposal http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt 2 Level Signaling Architecture http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-00.txt Framework Structure for QoS Signaling http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt Analysis - 30 minutes Analysis of Existing QoS Solutions http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt On path and off path signaling for NSIS http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt RSVP Security Properties http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-sec-properties-00.txt Analysis on RSVP Regarding Multicast http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-00.txt Next Steps - 15 minutes Other Middlebox Signaling in a NSIS framework http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt Consideration of RSVP-TE Extension for Metro Network http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt The Features of IPv6 Signaling http://opticalip.icu.ac.kr/draft-choi-ipv6-signaling-02.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 08:24:22 2002 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 IAA16075 for ; Thu, 4 Jul 2002 08:24:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16178 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 08:25:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15407; Thu, 4 Jul 2002 08:10:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15375 for ; Thu, 4 Jul 2002 08:10:32 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15753 for ; Thu, 4 Jul 2002 08:09:41 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g64CALrU015200; Thu, 4 Jul 2002 14:10:21 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHM48TR8; Thu, 4 Jul 2002 14:10:21 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 14:10:20 +0200 Message-ID: X-Sybari-Trust: e12596eb 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Date: Thu, 4 Jul 2002 14:10:07 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven What I tried to say in the previous e-mail is that the resilience issues that will have to be taken into consideration in NSIS are failure notification and for some extend failure recovery! Now these are resilience issues that have to be covered by NSIS anyway, independently if a NF is using a per flow state or a per class state. The way (i.e., the solution) of how the failure notification and failure recovery is done is different for these two cases, but the issues that are relevant for NSIS and have to be considered by NSIS are the same. Best Regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: Thursday, July 04, 2002 8:19 AM To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi Georgios, Thanks for your comments. I think you are making two important assumptions, that may be specific to a particular scenario: 1. Some of the NFs keep per-flow state, some do not (the 'edges' as you call them) 2. The NF that detects the failure and the NF that needs to be informed see the same network (otherwise, how will the per-class NF know which other NFs to contact) Now there are three possibilities: 1. The scenario you have in mind does not have some the issues described in the draft. They can, however, remain valid for other scenarios. 2. The scenario you have in mind can have some of the issues described in the draft. In that case, it is covered. 3. The scenario you have in mind has issues that are not mentioned in the draft. In that case, of course, we should add them. We might try to link specific issues to scenarios (like we discussed for the requirements draft). What do you think? Sven. "Georgios Karagiannis (ELN)" @ietf.org on 03/07/2002 17:28:07 Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-vandenbosch-nsis-resilience-00.txt Hi Sven I will only reply to one of your statements/remarks, that is mainly representative also for some of the other statements/remarks that you have sent in your previous e-mail. Note that I am open on discussing and contributing to your draft. [georgios-first]>> I will only comment your draft starting from Section 5. [georgios-first]>> Main comment that I have is related to the fact that you somehow [georgios-first]>> emphasise that the per-class states complicate the failure notification [georgios-first]>> and recovery issues, while I think that failure notification and recovery [georgios-first]>> issues are independent of the type of these states. [sven] In general, per-class state has the effect of losing the link between a certain initiator and its associated reservation. As such, it causes an issues for failure notification because of the absence of state information on where to send the notification. [georgios] well, in both approaches (when a node uses a per flow state or a per class state), a failure can be notified to either another NF (NSIS Forwarder) or to a NSIS Initiator (NI). In the per-class state approach the failure can be notified to a NF (NSIS Forwarder) located at an edge node that can relate the per class state with a per flow state. This NF can subsequently notify the NSIS Initiator (NI) when needed. In the per flow state approach the failure can be notified to an NF (edge) or to an NI when needed. Best Regards, Georgios _______________________________________________ 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 daemon@optimus.ietf.org Thu Jul 4 08:36:42 2002 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 IAA16203 for ; Thu, 4 Jul 2002 08:36:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16916 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 08:37:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16091; Thu, 4 Jul 2002 08:23:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16060 for ; Thu, 4 Jul 2002 08:23:32 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16056 for ; Thu, 4 Jul 2002 08:22:41 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64CM0d06111 for ; Thu, 4 Jul 2002 15:22:00 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Jul 2002 15:23:28 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 15:23:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] NSIS Agenda Date: Thu, 4 Jul 2002 15:23:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65643@esebe004.NOE.Nokia.com> Thread-Topic: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-w estphal-nsis-qos-mobileip-00.txt) Thread-Index: AcIixVm2KGa/bdpYQ7OjEYhPfJPOJwAcdv8AAAd8hkA= To: , X-OriginalArrivalTime: 04 Jul 2002 12:23:28.0145 (UTC) FILETIME=[99ED4010:01C22355] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA16061 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Please note that it is expected that folks have read the drafts listed below before the meeting. Therefore, there will be no presentation of the drafts - just a discussion on the open issues. Additionally, as we are dangerously overbooked, we may need to drop some of the drafts from our agenda. Drafts without prior discussion on the mailing list are the first to be dropped from the agenda. John NSIS IETF 54 Agenda =================== MONDAY, July 15, 2002 0900-1130 Morning Session Agenda Bashing and Status Report - 15 minutes Requirements - 30 minutes NSIS Requirements http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt NSIS Threats & Security requirements http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt NSIS Resilience http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt Framework - 60 minutes Next Steps in Signaling: A Framework Proposal http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt 2 Level Signaling Architecture http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-00.txt Framework Structure for QoS Signaling http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt Analysis - 30 minutes Analysis of Existing QoS Solutions http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt On path and off path signaling for NSIS http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt RSVP Security Properties http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-sec-properties-00.txt Analysis on RSVP Regarding Multicast http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-00.txt Next Steps - 15 minutes Other Middlebox Signaling in a NSIS framework http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt Consideration of RSVP-TE Extension for Metro Network http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt The Features of IPv6 Signaling http://opticalip.icu.ac.kr/draft-choi-ipv6-signaling-02.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 10:18:29 2002 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 KAA17841 for ; Thu, 4 Jul 2002 10:18:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21646 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 10:19:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20917; Thu, 4 Jul 2002 10:05:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20824 for ; Thu, 4 Jul 2002 10:05:09 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17585 for ; Thu, 4 Jul 2002 10:04:17 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 4 Jul 2002 16:03:47 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3H1PAHR2>; Thu, 4 Jul 2002 16:04:35 +0200 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-op opsig-00.txt) Date: Thu, 4 Jul 2002 16:04:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA20825 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, my comments are in line. Regards, Rüdiger > Comment_2 on Section 3.2.1: > ------------- > I do not understand this comment: > "In these cases, a signaling unaware cloud is not anymore a > signaling carrier, as nothing assures it will forward the > signal at the same place it will forward the dataflow." On path signaling only recognizes layer 3 routing. I guess the authors here refer to DiffServ aware traffic engineering. There traffic of different traffic classes may be forwarded along different routes - depending on their traffic class. Signaling messages are probably Best Effort, so QoS enabled data will in fact travel a different MPLS route. The issue is that NSIS signaling is limited to layer 3 (which I strongly appreciate). An on path solution is layer 2 blind while an off path based solution doesn't have to be. That's a clear benefit if off path signaling is used. > Comment on Section 3.2.3 > ------------------- > You mentioned: > "One problem of RSVP and intserv is that every router in the > network must implement intserv and RSVP in order to link the > sink and the source with a chain of QoS capable routers that > all allocate resources for the flow." > > [georgios] not all routers in a communication path have to > implement Intserv. Actually, you mighty have domains that > are overprovisioned and do not implement Intserv. > What I try to say is that this issue applies to both types of > architectures, i.e., on path and out of path. Therefore, it > is not fair to presented here as an on path issue! Section 4.3.1 of the draft states that an off path QoS controller must be topology aware and therfore tap routing. So overprovisioning is an option in domains using off path QoS controllers, while it is a requirement for a domain using on path signaling unless all routers passed must evaluate the signaling information. This too is a clear benefit of an off path solution. > * There may be a single point of failure > > Failure detection and error recovery are tremendously > important. Good point. I support your suggestion to add this issue to the list of issues. > * Sophisticated mechanisms for discovery of the centralized > entities are needed. This is an addition to your > Section 4.3.1. Yes, true. AAA or COPS may be checked to look for existing standard methods. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 4 10:48:43 2002 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 KAA18751 for ; Thu, 4 Jul 2002 10:48:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23344 for nsis-archive@odin.ietf.org; Thu, 4 Jul 2002 10:49:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22624; Thu, 4 Jul 2002 10:31:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22593 for ; Thu, 4 Jul 2002 10:31:54 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18115 for ; Thu, 4 Jul 2002 10:31:02 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 4 Jul 2002 16:30:33 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3H1PA2Y5>; Thu, 4 Jul 2002 16:31:21 +0200 Message-Id: From: "Geib, Ruediger" To: Alban.Couturier@alcatel.fr, Olov.Schelen@operax.com Cc: nsis@ietf.org Date: Thu, 4 Jul 2002 16:31:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA22594 Subject: [NSIS] Off Path analysis - further benefits (CT and L3/L2 service interw orking) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Alban, Olov, thanks for creating your draft. I'd like to add some facets: Hybrid solutions are indeed very important. I'm considering a roaming wireless terminal signaling for QoS. It can't be aware of an off path signaling units Ip address and the simplest solution is that it doesn't have to be. However the access router of the network it is signaling too could be well aware of the off path signaling system controling service within it's domain. It forwards the NSIS message there. COPS is working similar. What I like about this architecture is that it provides a simple context transfer solution. Once a hand off occurs, the new access router asks its domains off path system for the terminals QoS context and gets it in response. This CT mechanism works fast and is simple by operations and signaling requirements. Maybe such a scenario could be added to section 5.1. Another advantage of an off path signaling method is, that it could also be used to provide service below layer 3. This is especially relevant if MPLS based TE solutions are used by a domain. The MPLS network and its elements are invisible to on path signaling - they don't have to be to a service management system using off path signaling. Could this be clarified in your draft, I think simplified layer 3 to layer 2 service interworking is a clear advantage of off path signaling. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 03:37:18 2002 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 DAA14206 for ; Fri, 5 Jul 2002 03:37:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13607 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 03:38:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12504; Fri, 5 Jul 2002 03:24:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12473 for ; Fri, 5 Jul 2002 03:24:12 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13897 for ; Fri, 5 Jul 2002 03:23:20 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g657O2Rb001485; Fri, 5 Jul 2002 09:24:10 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKS90WQ; Fri, 5 Jul 2002 09:24:02 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 09:24:02 +0200 Message-ID: X-Sybari-Trust: 17d1e776 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: nsis@ietf.org Date: Fri, 5 Jul 2002 09:23:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] commentson on draft-ietf-nsis-req-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear Marcus Please receive some comments on version 3 of the requirements draft: draft-ietf-nsis-req-03.txt ----------------------------------------------- Comment_1: general: There are many requirements that are affected by the fact that NSIS will have to concentrate mainly on the in-band (in-path case). What should we do with them? maybe list them as optional and to be done in the future? --------------------------------------------------------------------------------------- Comment_2: Section 2: Terminology: (page 6): I propose to use the terms given in draft-hancock-nsis-fw-00.txt regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder (instead of QoS Controller) and NSIS Responder. This applies also for other additional terms that are included into draft-hancock-nsis-fw-00.txt and are not included into the requirements draft. ---------------------------------------------------------------------------------------- Comment_3: Section 3: Problem statement and scope (Page 9): Please remove or signifficantly modify bullet 2: "We see the network at the level of domains/subdomains rather than individual routers ...... Aggregation can also take place at subdomain boundaries." The reasonsof asking this are: * not each domain but any router that implements a QoS controller or QoS initiator can use NSIS signaling; * It is contradictory with bullet 4 (of the same section) that mentions: " Each router on the data path implements a QoS controller and QoS initiator." ---------------------------------------------------------------------------------------- Comment_4: Section 4.1: Assumptions and exclusions (Page 11): Bullet 6: Please change the text: "NSIS assumes to operate with networks using standard ("normal") L3 routing" INTO "NSIS assumes to operate with networks using standard ("normal") L3 routing as described in RFC 2993." ---------------------------------------------------------------------------------------- Comment_5: Section 4.2: Assumptions and exclusions (Page 11): Issue 3: Please add a sentance after: "Specific mechanisms for QoS provisioning withis a domain/subdomain are not considered." As follows: "Specific mechanisms for QoS provisioning withis a domain/subdomain are not considered. However, NSIS can be used for signaling within a domain/subdomain." ---------------------------------------------------------------------------------------- Comment_6: Section 5.8 General (Page 20): Many of the security requirements mention that the signaling protocol must provide means to provide security. I would prefer to mention somewhere, maybe in the introduction of section 5.8 that: "The NSIS protcol must provide means to provide security, but it is not mandatory that all nodes that use NSIS signalling will have to apply these means for security." ---------------------------------------------------------------------------------------- Comment_7: Section 5.10.5: Interworking with seamless handoff protocols: Mention that this interworking should not duplicate functionality. ---------------------------------------------------------------------------------------- Comment_8: Open Issue 2: page 44: I prefer: "should be optimized for sender initiated" --------------------------------------------------------------------- Comment_9: Regarding open Issues 53, 59, 65 and 72 I propose that Sven and myself try to propose some text that solves all these issues: Sven do you agree? ----------------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 03:40:19 2002 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 DAA14241 for ; Fri, 5 Jul 2002 03:40:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13661 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 03:41:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12645; Fri, 5 Jul 2002 03:27:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12610 for ; Fri, 5 Jul 2002 03:27:50 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14004 for ; Fri, 5 Jul 2002 03:26:58 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g657RlRb002452; Fri, 5 Jul 2002 09:27:47 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHMV12V0; Fri, 5 Jul 2002 09:27:47 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 09:27:47 +0200 Message-ID: X-Sybari-Trust: 6676095f 7216406a 0b6f7280 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] NSIS Agenda Date: Fri, 5 Jul 2002 09:27:44 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John Regarding "=Analysis of Existing QoS Solutions http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt " We got comments on the NSIS intrim meeting and we updated the draft according to the comments. Moreover, Hannes has contributed with new text! Therefore, I would very much appreciate if you can keep it fro presentation! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, July 04, 2002 2:23 PM To: john.loughney@nokia.com; nsis@ietf.org Subject: RE: [NSIS] NSIS Agenda Hi all, Please note that it is expected that folks have read the drafts listed below before the meeting. Therefore, there will be no presentation of the drafts - just a discussion on the open issues. Additionally, as we are dangerously overbooked, we may need to drop some of the drafts from our agenda. Drafts without prior discussion on the mailing list are the first to be dropped from the agenda. John NSIS IETF 54 Agenda =================== MONDAY, July 15, 2002 0900-1130 Morning Session Agenda Bashing and Status Report - 15 minutes Requirements - 30 minutes NSIS Requirements http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt NSIS Threats & Security requirements http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt NSIS Resilience http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt Framework - 60 minutes Next Steps in Signaling: A Framework Proposal http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt 2 Level Signaling Architecture http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-00.txt Framework Structure for QoS Signaling http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt Analysis - 30 minutes Analysis of Existing QoS Solutions http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt On path and off path signaling for NSIS http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt RSVP Security Properties http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-sec-properties-00.txt Analysis on RSVP Regarding Multicast http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-00.txt Next Steps - 15 minutes Other Middlebox Signaling in a NSIS framework http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt Consideration of RSVP-TE Extension for Metro Network http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt The Features of IPv6 Signaling http://opticalip.icu.ac.kr/draft-choi-ipv6-signaling-02.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 daemon@optimus.ietf.org Fri Jul 5 04:03:30 2002 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 EAA14633 for ; Fri, 5 Jul 2002 04:03:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15245 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 04:04:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14180; Fri, 5 Jul 2002 03:50:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14150 for ; Fri, 5 Jul 2002 03:50:40 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14430 for ; Fri, 5 Jul 2002 03:49:49 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 08:49:52 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA436@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-opopsig-00.txt) Date: Fri, 5 Jul 2002 08:49:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to try to make one general comment about the on/off path = question, namely that it really needs to be carefully distinguished = from the question of whether protocol messages are implicitly or = explicitly along whatever path. The latter question is really about = NSIS addressing: we identified both modes in our latest framework = document (section 3.3.4 if you're interested) and called them e2e and = peer-session addressing respectively. Both are applicable in the = on-path case; the off-path case basically requires the peer-session = mode. With peer-session addressing it's clear that you need to work out the = address of the NSIS peer. I guess the emphasis on the on-path case = means that we aren't going to put a lot of effort into working out the = addresses of off-path peers. But (personally) I'd be worried if we = built assumptions about the addressing model into other aspects of the = protocol, and so it's unfair to say that an on path protocol is = fundamentally unable to cope with traffic engineered networks - it's = just that maybe NSIS won't provide all the address discovery mechanisms = in this (fundamentally harder) case. Cheers, Robert H. PS As an example, RSVP PATH messages are e2e addressed (in our = terminology) whereas RSVP RESV messages are peer-session addressed. I = don't think this makes RSVP an off path solution. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 04 July 2002 15:05 > To: Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments on draft in-path and out of path > (draft-schel en-nsis-op opsig-00.txt) >=20 >=20 > Hi Georgios, >=20 > my comments are in line. >=20 > Regards, R=FCdiger >=20 > > Comment_2 on Section 3.2.1:=20 > > ------------- > > I do not understand this comment: > > "In these cases, a signaling unaware cloud is not anymore a=20 > > signaling carrier, as nothing assures it will forward the > > signal at the same place it will forward the dataflow." >=20 > On path signaling only recognizes layer 3 routing.=20 > I guess the authors here refer to DiffServ aware=20 > traffic engineering. There traffic of different=20 > traffic classes may be forwarded along different routes > - depending on their traffic class. Signaling messages > are probably Best Effort, so QoS enabled data will in=20 > fact travel a different MPLS route. > The issue is that NSIS signaling is limited to layer 3 > (which I strongly appreciate). An on path solution is=20 > layer 2 blind while an off path based solution doesn't > have to be. That's a clear benefit if off path signaling > is used. >=20 > > Comment on Section 3.2.3 > > ------------------- > > You mentioned: > > "One problem of RSVP and intserv is that every router in the=20 > > network must implement intserv and RSVP in order to link the > > sink and the source with a chain of QoS capable routers that > > all allocate resources for the flow." > >=20 > > [georgios] not all routers in a communication path have to=20 > > implement Intserv. Actually, you mighty have domains that > > are overprovisioned and do not implement Intserv. > > What I try to say is that this issue applies to both types of=20 > > architectures, i.e., on path and out of path. Therefore, it > > is not fair to presented here as an on path issue! >=20 > Section 4.3.1 of the draft states that an off path QoS controller > must be topology aware and therfore tap routing. So=20 > overprovisioning is an option in domains using off path QoS=20 > controllers, while it is a requirement for a domain using on > path signaling unless all routers passed must evaluate the=20 > signaling information. > This too is a clear benefit of an off path solution. >=20 > > * There may be a single point of failure > >=20 > > Failure detection and error recovery are tremendously > > important. >=20 > Good point. I support your suggestion to add this issue to=20 > the list of issues. >=20 > > * Sophisticated mechanisms for discovery of the centralized > > entities are needed. This is an addition to your=20 > > Section 4.3.1. >=20 > Yes, true. AAA or COPS may be checked to look for existing=20 > standard methods. >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 04:38:03 2002 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 EAA15162 for ; Fri, 5 Jul 2002 04:38:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17014 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 04:38:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15880; Fri, 5 Jul 2002 04:23:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15847 for ; Fri, 5 Jul 2002 04:23:18 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14936 for ; Fri, 5 Jul 2002 04:22:27 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g658Nli21542 for ; Fri, 5 Jul 2002 11:23:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 11:23:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 11:23:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-opopsig-00.txt) Date: Fri, 5 Jul 2002 11:23:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EA5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-opopsig-00.txt) Thread-Index: AcIj+jRQeMkJipgJSIuFPGVvLMcsfAAAZZJQ To: , , Cc: X-OriginalArrivalTime: 05 Jul 2002 08:23:16.0238 (UTC) FILETIME=[362C82E0:01C223FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15848 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, First off, let me say something about on-path vs. off-path signaling. The intention of NSIS is to work on standardizing a solution for on-path signaling - that means the signaling follows the path which the data packets follow. If there is non-standard routing of packets, then the signaling will follow. Please note the Area Directors realize that off-path signaing is interesting and may have use, but NSIS is not chartered to do that work. It may be possible to work on this after we have fulfilled our initial charter. > I'd like to try to make one general comment about the on/off > path question, namely that it really needs to be carefully > distinguished from the question of whether protocol messages > are implicitly or explicitly along whatever path. The latter > question is really about NSIS addressing: we identified both > modes in our latest framework document (section 3.3.4 if > you're interested) and called them e2e and peer-session > addressing respectively. Both are applicable in the on-path > case; the off-path case basically requires the peer-session mode. Agreed. > With peer-session addressing it's clear that you need to work > out the address of the NSIS peer. I guess the emphasis on the > on-path case means that we aren't going to put a lot of > effort into working out the addresses of off-path peers. But > (personally) I'd be worried if we built assumptions about the > addressing model into other aspects of the protocol, and so > it's unfair to say that an on path protocol is fundamentally > unable to cope with traffic engineered networks - it's just > that maybe NSIS won't provide all the address discovery > mechanisms in this (fundamentally harder) case. Agreed. I think address discovery (& service discovery) are very difficult issues and are out of scope for NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 04:44:55 2002 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 EAA15276 for ; Fri, 5 Jul 2002 04:44:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17166 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 04:45:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16699; Fri, 5 Jul 2002 04:31:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16661 for ; Fri, 5 Jul 2002 04:31:51 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15024 for ; Fri, 5 Jul 2002 04:30:59 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g658WKi27962 for ; Fri, 5 Jul 2002 11:32:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 11:31:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 11:31:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Fri, 5 Jul 2002 11:31:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EA6@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] commentson on draft-ietf-nsis-req-03.txt Thread-Index: AcIj+wldd57Fzr0jRHiZAQhvmmoecwAAjFvA To: , Cc: X-OriginalArrivalTime: 05 Jul 2002 08:31:49.0106 (UTC) FILETIME=[67DDF520:01C223FE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA16662 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, Good points, some comments: > Comment_1: general: > There are many requirements that are affected by the fact > that NSIS will have > to concentrate mainly on the in-band (in-path case). > What should we do with them? maybe list them as optional and > to be done in the future? I think that we need to seperate off-path requirements from the main document. In my opinion, these are non-requirements for the current charter. I would support moving these into an appendix, which discusses off-path signaling. > I propose to use the terms given in draft-hancock-nsis-fw-00.txt > regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder > (instead of QoS Controller) and NSIS Responder. This applies also > for other additional terms that are > included into draft-hancock-nsis-fw-00.txt and are not > included into the requirements draft. I support this, but I think we should have some WG discussion on this. > Please remove or signifficantly modify bullet 2: > "We see the network at the level of domains/subdomains rather > than individual routers ...... Aggregation can also take > place at subdomain boundaries." > > The reasonsof asking this are: > * not each domain but any router that implements a QoS > controller or QoS initiator can use NSIS signaling; > * It is contradictory with bullet 4 (of the same > section) that mentions: > " Each router on the data path implements a QoS > controller and QoS initiator." I don't see your point. If we are signaling for some 'NSIS resource' - does each router on the path suply this resource, is it aggregated or not? We are not designing a specific host to router, or router to router protocol; in my opinion we are doing something a bit broader. However, what we do may be applicable to this. > Comment_4: Section 4.1: Assumptions and exclusions (Page 11): > > Bullet 6: > Please change the text: > "NSIS assumes to operate with networks using standard > ("normal") L3 routing" > > INTO > > "NSIS assumes to operate with networks using standard > ("normal") L3 routing as described in RFC 2993." I am perplexed at this reference - 2993 is "Architectural Implications of NAT" - what does this have to do with NSIS? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 05:12:24 2002 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 FAA15611 for ; Fri, 5 Jul 2002 05:12:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18750 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 05:13:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17714; Fri, 5 Jul 2002 04:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17683 for ; Fri, 5 Jul 2002 04:59:55 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15445 for ; Fri, 5 Jul 2002 04:59:04 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g658tW404974; Fri, 5 Jul 2002 10:55:32 +0200 Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt To: john.loughney@nokia.com Cc: , , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 5 Jul 2002 10:59:10 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/05/2002 10:59:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Georgios, I am not sure if we can split the requirements without pre-supposing a solution. Ideally, the requirements should cover the problem space (signaling for resources) without doing that. I think we already had a similar discussion once when we talked about 'parts of the network'. The feedback we got at the meeting was that we should not restrict the requirements to a particular architecture. Some offline discussion resulted in keeping the requirements listed as they were in order to avoid duplication and left the possibility open to add a section indicating in which case they would apply. As an alternative to such an additional section, I think it would be perfectly OK for a particular solution to state that it is not affected by or inherently fulfills some of the requirements. Would you feel any of these to be an appropriate solution in this case as well? Sven. john.loughney@nokia.com@ietf.org on 05/07/2002 10:31:48 Sent by: nsis-admin@ietf.org To: , cc: Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Hi Georgios, Good points, some comments: > Comment_1: general: > There are many requirements that are affected by the fact > that NSIS will have > to concentrate mainly on the in-band (in-path case). > What should we do with them? maybe list them as optional and > to be done in the future? I think that we need to seperate off-path requirements from the main document. In my opinion, these are non-requirements for the current charter. I would support moving these into an appendix, which discusses off-path signaling. > I propose to use the terms given in draft-hancock-nsis-fw-00.txt > regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder > (instead of QoS Controller) and NSIS Responder. This applies also > for other additional terms that are > included into draft-hancock-nsis-fw-00.txt and are not > included into the requirements draft. I support this, but I think we should have some WG discussion on this. > Please remove or signifficantly modify bullet 2: > "We see the network at the level of domains/subdomains rather > than individual routers ...... Aggregation can also take > place at subdomain boundaries." > > The reasonsof asking this are: > * not each domain but any router that implements a QoS > controller or QoS initiator can use NSIS signaling; > * It is contradictory with bullet 4 (of the same > section) that mentions: > " Each router on the data path implements a QoS > controller and QoS initiator." I don't see your point. If we are signaling for some 'NSIS resource' - does each router on the path suply this resource, is it aggregated or not? We are not designing a specific host to router, or router to router protocol; in my opinion we are doing something a bit broader. However, what we do may be applicable to this. > Comment_4: Section 4.1: Assumptions and exclusions (Page 11): > > Bullet 6: > Please change the text: > "NSIS assumes to operate with networks using standard > ("normal") L3 routing" > > INTO > > "NSIS assumes to operate with networks using standard > ("normal") L3 routing as described in RFC 2993." I am perplexed at this reference - 2993 is "Architectural Implications of NAT" - what does this have to do with NSIS? 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 daemon@optimus.ietf.org Fri Jul 5 05:14:24 2002 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 FAA15642 for ; Fri, 5 Jul 2002 05:14:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18809 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 05:15:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18344; Fri, 5 Jul 2002 05:01:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18311 for ; Fri, 5 Jul 2002 05:01:20 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15460 for ; Fri, 5 Jul 2002 05:00:28 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6590cI20784; Fri, 5 Jul 2002 11:00:38 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA19902; Fri, 5 Jul 2002 11:01:06 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 722174A186; Fri, 5 Jul 2002 11:01:06 +0200 (CEST) Date: Fri, 05 Jul 2002 11:01:09 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Message-ID: <1778327.1025866869@[192.168.102.207]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EA6@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EA6@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Freitag, 5. Juli 2002 11:31 +0300 john.loughney@nokia.com wrote: > Hi Georgios, > > Good points, some comments: > >> Comment_1: general: >> There are many requirements that are affected by the fact >> that NSIS will have >> to concentrate mainly on the in-band (in-path case). >> What should we do with them? maybe list them as optional and >> to be done in the future? > > I think that we need to seperate off-path requirements from the main > document. In my opinion, these are non-requirements for the current > charter. I would support moving these into an appendix, > which discusses off-path signaling. I still don't see what problem people have with off-path signaling (and I would call tunneling off-path as well). If the working group agrees to remove some of the req fine, let me know which ones. > >> I propose to use the terms given in draft-hancock-nsis-fw-00.txt >> regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder >> (instead of QoS Controller) and NSIS Responder. This applies also >> for other additional terms that are >> included into draft-hancock-nsis-fw-00.txt and are not >> included into the requirements draft. > > I support this, but I think we should have some WG discussion on > this. Yes, sure, but I can a that point in time not rely on a personal submission. And the terms showed up first in the req draft. I agree that there are good reasons to change them, but we need consensus on that. >> Please remove or signifficantly modify bullet 2: >> "We see the network at the level of domains/subdomains rather >> than individual routers ...... Aggregation can also take >> place at subdomain boundaries." >> >> The reasonsof asking this are: >> * not each domain but any router that implements a QoS >> controller or QoS initiator can use NSIS signaling; >> * It is contradictory with bullet 4 (of the same >> section) that mentions: >> " Each router on the data path implements a QoS >> controller and QoS initiator." > > I don't see your point. If we are signaling for some 'NSIS > resource' - does each router on the path suply this resource, > is it aggregated or not? We are not designing a specific > host to router, or router to router protocol; in my opinion > we are doing something a bit broader. However, what we do > may be applicable to this. > I don't understand georgios point but I think we need to modify section 3 anyway (or even remove it, because most of the stuff is framework related. >> Comment_4: Section 4.1: Assumptions and exclusions (Page 11): >> >> Bullet 6: >> Please change the text: >> "NSIS assumes to operate with networks using standard >> ("normal") L3 routing" >> >> INTO >> >> "NSIS assumes to operate with networks using standard >> ("normal") L3 routing as described in RFC 2993." > > I am perplexed at this reference - 2993 is "Architectural Implications > of NAT" - what does this have to do with NSIS? Here I don't want to include any reference, The fuzzyness is on purpose. If you start talking about NATs this might be an issue for NSIS, whether NSIS must work over NATs or not or don't care. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 05:18:15 2002 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 FAA15684 for ; Fri, 5 Jul 2002 05:18:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18937 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 05:19:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18559; Fri, 5 Jul 2002 05:05:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18515 for ; Fri, 5 Jul 2002 05:05:36 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15526 for ; Fri, 5 Jul 2002 05:04:44 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6594pI21128; Fri, 5 Jul 2002 11:04:51 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA19964; Fri, 5 Jul 2002 11:05:19 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5B872482B9; Fri, 5 Jul 2002 11:05:19 +0200 (CEST) Date: Fri, 05 Jul 2002 11:05:22 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, robert.hancock@roke.co.uk, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Message-ID: <2031290.1025867122@[192.168.102.207]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6562B@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6562B@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I see CT as an optimization only and not required for NSIS. However, since there is a tendency to support only on-path signaling, this would not work anyway (because CT would need off-path signaling for at least some time). Marcus --On Donnerstag, 4. Juli 2002 11:33 +0300 john.loughney@nokia.com wrote: > Hi Robert, > >> On the 'edge signalling' case, I guess the main point is that >> I'm confused about the scope of seamoby CT. Specifically >> regarding MN-AR signalling (no issue about the AR-AR part): > > From my viewpoint, CT is not required for NSIS. I view CT as > one tool that an NSIS solution could use. So, I definately think > that at some point, we will need some sort of applicability > statement describing how to use CT for NSIS. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 05:48:43 2002 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 FAA16084 for ; Fri, 5 Jul 2002 05:48:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20539 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 05:49:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20064; Fri, 5 Jul 2002 05:35:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19975 for ; Fri, 5 Jul 2002 05:35:07 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15862 for ; Fri, 5 Jul 2002 05:34:17 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 10:34:48 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA438@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 10:34:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi all, I don't think there's any disagreement that CT is a tool that NSIS could use (as an optimisation). What's entirely unclear to me is what sort of tool CT is: is it a hammer or a screwdriver or a combination of the two? I guess this is more a question for the seamoby people, but we need to know the answer to know how to use it. More formally, there seem to be two extremes: a) NSIS is used for MN-AR resource (QoS) signalling, and AR-rest of world signalling; CT can be used to transfer state (both resource state and NSIS protocol state) between ARs at handover, but if this involves any MN-AR messages (e.g. CTIN) they aren't QoS related. NSIS-CT interaction can occur at the ARs to do state transfer at handover time. b) CT messages (e.g. CIN) can be used by the MN to set up QoS context in the AR, which it can then later transfer to a new AR. NSIS is used to signal QoS for AR-rest of network. NSIS-CT interaction takes place at the AR to interwork flow setup and resource descriptions, and this interaction takes place at flow setup time. (Essentially, CT provides a QoS signalling protocol for the edge of the network, which NSIS would have to interwork with, in the same way that it has to interwork with RSVP/Intserv.) our framework draft-hancock-nsis-fw-00.txt basically assumes (a). this draft-westphal-nsis-qos-mobileip-00.txt basically assumes (b) so far as I can tell. I'm not trying to argue which of (a) or (b) is 'correct' at this stage, just establish that they are not the same. (And so we probably have to make a choice, although I suppose you could allow both models...) Cheers, Robert H. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 05 July 2002 10:05 > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > draft-westphal-nsis-qos-mobileip-00.txt) > > > I see CT as an optimization only and not required for NSIS. > However, since > there is a tendency to support only on-path signaling, this > would not work > anyway (because CT would need off-path signaling for at least > some time). > > Marcus > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > john.loughney@nokia.com wrote: > > > Hi Robert, > > > >> On the 'edge signalling' case, I guess the main point is that > >> I'm confused about the scope of seamoby CT. Specifically > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > one tool that an NSIS solution could use. So, I definately think > > that at some point, we will need some sort of applicability > > statement describing how to use CT for NSIS. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:01:41 2002 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 GAA16204 for ; Fri, 5 Jul 2002 06:01:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21350 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:02:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20524; Fri, 5 Jul 2002 05:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20492 for ; Fri, 5 Jul 2002 05:49:13 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16081 for ; Fri, 5 Jul 2002 05:48:22 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g659nfi22841 for ; Fri, 5 Jul 2002 12:49:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 12:49:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 12:49:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Off Path analysis - further benefits (CT and L3/L2 service interworking) Date: Fri, 5 Jul 2002 12:49:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EA8@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Off Path analysis - further benefits (CT and L3/L2 service interworking) Thread-Index: AcIjahA9K6UZ3Kq3QXaxYABE3sySVAAnqVQg To: , , Cc: X-OriginalArrivalTime: 05 Jul 2002 09:49:10.0293 (UTC) FILETIME=[363AE450:01C22409] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA20493 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, > Hybrid solutions are indeed very important. I'm > considering a roaming wireless terminal signaling > for QoS. It can't be aware of an off path > signaling units Ip address and the simplest > solution is that it doesn't have to be. However > the access router of the network it is signaling > too could be well aware of the off path signaling > system controling service within it's domain. It > forwards the NSIS message there. COPS is working > similar. I think this kind of scenario could be very useful. However, NSIS first needs to work on on-path signaling. Once we do this, we could work on off-path signaling. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:14:31 2002 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 GAA16397 for ; Fri, 5 Jul 2002 06:14:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21793 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:15:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20732; Fri, 5 Jul 2002 05:58:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20699 for ; Fri, 5 Jul 2002 05:58:38 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16170 for ; Fri, 5 Jul 2002 05:57:48 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 10:58:35 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA439@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Gabor Fodor (EAB)'" , "'nsis@ietf.org'" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 10:58:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi gabor, comments in line... [snip] > -----Original Message----- > Hi Hemant, Robert, All, > > my understanding is that a MN should be able to use NSIS > for edge signaling irrespective of > the AR being CT capable able or not. > > But, NSIS could use CTIN at QoS initiation time (as in case a)). [reh] arrggh! surely CTIN is used by the mobility aware entity in the node at handover time? i don't think the NSIS entity in the node should generate this message. > Then, the issue for the MN becomes how it will know whether or not > it needs to send the context to the new AR, depending on whether > CT is done by the ARs or not. > > There are probably different ways to provide this information > to the MN, for instance the AR can signal back to MN during > QoS context initiation time. > (Depending on the assumption that > if the "first" AR is CT capable, then subsequent AR will also be > that.) [reh] i'd be worried about setting up this information at flow initiation time - after all, you don't know who you are going to handover to, and that might impact on whether CT will be possible. my personal preference is that NSIS could have its own very simple status messages, which the NSIS implementation at the AR could decide to send depending on whether CT had taken place (successfully) or not. (but we're getting into protocol design here.) > > In the NEMO case (www.ietf.org/ietf/02jul/nemo.txt) > it is also important to establish QoS along the > hops "before" the AR (e.g. between MN and a wireless gateway > on a bus), > in which case the context has to be sent from the MN > to this moving router ("wireless gateway") > even if CT is done between the AR's. [reh] absolutely, and I assume NSIS should be used to set this context (sorry, state) up - after all, the MN might not even know it was within a mobile network of this sort. (If CT messages are used for this, I suspect life will get complicated.) /reh > > /Gabor > > > [Robert] > > > > On the 'edge signalling' case, I guess the main point is that > > I'm confused about the scope of seamoby CT. Specifically > > regarding MN-AR signalling (no issue about the AR-AR part): > > a) the koodli draft talks about a MN-AR CTIN message to be > > sent around the time of handover, which I read as the MN > > saying "please prepare to transfer some context". > > b) your draft talks about an MN-AR CIN message to be sent > > around the time of flow initiation, which I read as the MN > > saying "here are the QoS requirements for my flow which I may > > later want to transfer". > > --- > > [Hemant] > > > > I admit that we should have distinguished cases (a) and (b) > > in the draft. QoS initiation, negotiation and release steps > > (steps i, ii and iv in Section 3 of the draft) could very > > well be done by NSIS protocol independent of CT. Those steps > > could even be out of the scope of handoff signaling tool as > > these will typically happen at the time of flow initiation. > > That way, NSIS can still run even if CT is not available at > > AR or host is using Simple IP. But, think when CT is > > available. Then, we end up with redundant messages (one NSIS > > and one CT) to acheive the same purpose: Send QoS > > requirements from MN to AR. So, why not make CTIN also NSIS > > MN-AR message. Anyway, neither CT nor NSIS has installed base > > in the Internet. Just a thought! > > --- > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:25:25 2002 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 GAA16595 for ; Fri, 5 Jul 2002 06:25:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22266 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:26:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21622; Fri, 5 Jul 2002 06:10:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21591 for ; Fri, 5 Jul 2002 06:10:56 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16321 for ; Fri, 5 Jul 2002 06:10:06 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g65ABPi08576 for ; Fri, 5 Jul 2002 13:11:25 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 13:10:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 13:10:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Fri, 5 Jul 2002 13:10:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6565D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] commentson on draft-ietf-nsis-req-03.txt Thread-Index: AcIkC1i7EeMpd4k0SDe74asnttCGmAAAJaVA To: , Cc: X-OriginalArrivalTime: 05 Jul 2002 10:10:54.0115 (UTC) FILETIME=[3F5E5730:01C2240C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA21592 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > > I think that we need to seperate off-path requirements from the main > > document. In my opinion, these are non-requirements for the current > > charter. I would support moving these into an appendix, > > which discusses off-path signaling. > > I still don't see what problem people have with off-path signaling (and I > would call tunneling off-path as well). If the working group agrees to > remove some of the req fine, let me know which ones. I can review the current document. My basic point is that NSIS is not specifying off-path signaling, therefore NSIS should not make any specific requirements for off-path signaling. Lest time I looked, there wasn't anything I though was especially problematic, but I will review it. > If you start talking about NATs this might be an issue for > NSIS, whether NSIS must work over NATs or not or don't care. Right now, I'm happy with not caring. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:25:26 2002 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 GAA16600 for ; Fri, 5 Jul 2002 06:25:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22277 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:26:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21678; Fri, 5 Jul 2002 06:11:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21647 for ; Fri, 5 Jul 2002 06:11:27 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16328 for ; Fri, 5 Jul 2002 06:10:36 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g65ABti09130 for ; Fri, 5 Jul 2002 13:11:55 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 13:11:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 13:11:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments ondraft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 13:11:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6565E@esebe004.NOE.Nokia.com> Thread-Topic: what is edge signalling? (was: RE: [NSIS] Re: Comments ondraft-westphal-nsis-qos-mobileip-00.txt) Thread-Index: AcIkCvJQE+7r4X4dQ9uuZDG81EosKAAAU/NA To: , , , Cc: , X-OriginalArrivalTime: 05 Jul 2002 10:11:24.0463 (UTC) FILETIME=[517513F0:01C2240C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA21648 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > I see CT as an optimization only and not required for NSIS. However, since > there is a tendency to support only on-path signaling, this would not work > anyway (because CT would need off-path signaling for at least > some time). I think your point is reasonable. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:28:31 2002 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 GAA16656 for ; Fri, 5 Jul 2002 06:28:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22473 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:29:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21884; Fri, 5 Jul 2002 06:16:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21855 for ; Fri, 5 Jul 2002 06:16:00 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16431 for ; Fri, 5 Jul 2002 06:15:10 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g65AFRI24773; Fri, 5 Jul 2002 12:15:27 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA20792; Fri, 5 Jul 2002 12:15:56 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E00474B2B9; Fri, 5 Jul 2002 12:15:55 +0200 (CEST) Date: Fri, 05 Jul 2002 12:15:56 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "'Geib, Ruediger'" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-opopsig-00.txt) Message-ID: <6268433.1025871356@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA436@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA436@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA21856 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Robert, --On Freitag, 5. Juli 2002 08:49 +0100 "Hancock, Robert" wrote: > Hi all, > > I'd like to try to make one general comment about the on/off path > question, namely that it really needs to be carefully distinguished from > the question of whether protocol messages are implicitly or explicitly > along whatever path. The latter question is really about NSIS addressing: > we identified both modes in our latest framework document (section 3.3.4 > if you're interested) and called them e2e and peer-session addressing > respectively. Both are applicable in the on-path case; the off-path case > basically requires the peer-session mode. > What you define as peer-session mode I alrady would call off-path, since it does not need to run hop-by-hop (according to your definition). So to be exact you have to say that peer-session addressing with one hop-peers can be used in the on-path case. > With peer-session addressing it's clear that you need to work out the > address of the NSIS peer. I guess the emphasis on the on-path case means > that we aren't going to put a lot of effort into working out the > addresses of off-path peers. But (personally) I'd be worried if we built > assumptions about the addressing model into other aspects of the > protocol, and so it's unfair to say that an on path protocol is > fundamentally unable to cope with traffic engineered networks - it's just > that maybe NSIS won't provide all the address discovery mechanisms in > this (fundamentally harder) case. I don't get your point. And I don't see how the hell you are able to cope with traffic engineered networks in the on-path case using "normal" routing. > Cheers, > > Robert H. > > PS As an example, RSVP PATH messages are e2e addressed (in our > terminology) whereas RSVP RESV messages are peer-session addressed. I > don't think this makes RSVP an off path solution. Here I think again we need to differentiate the peer-session hop-by-hop or over several hops. And the RSVP RESV message hop objects even has local (interface number) information circumventing normal routing. Marcus >> -----Original Message----- >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >> Sent: 04 July 2002 15:05 >> To: Georgios.Karagiannis@eln.ericsson.se >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] comments on draft in-path and out of path >> (draft-schel en-nsis-op opsig-00.txt) >> >> >> Hi Georgios, >> >> my comments are in line. >> >> Regards, Rüdiger >> >> > Comment_2 on Section 3.2.1: >> > ------------- >> > I do not understand this comment: >> > "In these cases, a signaling unaware cloud is not anymore a >> > signaling carrier, as nothing assures it will forward the >> > signal at the same place it will forward the dataflow." >> >> On path signaling only recognizes layer 3 routing. >> I guess the authors here refer to DiffServ aware >> traffic engineering. There traffic of different >> traffic classes may be forwarded along different routes >> - depending on their traffic class. Signaling messages >> are probably Best Effort, so QoS enabled data will in >> fact travel a different MPLS route. >> The issue is that NSIS signaling is limited to layer 3 >> (which I strongly appreciate). An on path solution is >> layer 2 blind while an off path based solution doesn't >> have to be. That's a clear benefit if off path signaling >> is used. >> >> > Comment on Section 3.2.3 >> > ------------------- >> > You mentioned: >> > "One problem of RSVP and intserv is that every router in the >> > network must implement intserv and RSVP in order to link the >> > sink and the source with a chain of QoS capable routers that >> > all allocate resources for the flow." >> > >> > [georgios] not all routers in a communication path have to >> > implement Intserv. Actually, you mighty have domains that >> > are overprovisioned and do not implement Intserv. >> > What I try to say is that this issue applies to both types of >> > architectures, i.e., on path and out of path. Therefore, it >> > is not fair to presented here as an on path issue! >> >> Section 4.3.1 of the draft states that an off path QoS controller >> must be topology aware and therfore tap routing. So >> overprovisioning is an option in domains using off path QoS >> controllers, while it is a requirement for a domain using on >> path signaling unless all routers passed must evaluate the >> signaling information. >> This too is a clear benefit of an off path solution. >> >> > * There may be a single point of failure >> > >> > Failure detection and error recovery are tremendously >> > important. >> >> Good point. I support your suggestion to add this issue to >> the list of issues. >> >> > * Sophisticated mechanisms for discovery of the centralized >> > entities are needed. This is an addition to your >> > Section 4.3.1. >> >> Yes, true. AAA or COPS may be checked to look for existing >> standard methods. >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:35:14 2002 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 GAA17242 for ; Fri, 5 Jul 2002 06:35:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23344 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:36:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22093; Fri, 5 Jul 2002 06:22:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22060 for ; Fri, 5 Jul 2002 06:22:32 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16513 for ; Fri, 5 Jul 2002 06:21:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g65ALrI25043; Fri, 5 Jul 2002 12:21:53 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA20845; Fri, 5 Jul 2002 12:22:21 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F1CCC4B987; Fri, 5 Jul 2002 12:22:20 +0200 (CEST) Date: Fri, 05 Jul 2002 12:22:21 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Message-ID: <6653517.1025871741@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA438@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA438@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Actually, I have so far assumed (a) as well. And I like (a) because NSIS is not influenced by CT. Marcus --On Freitag, 5. Juli 2002 10:34 +0100 "Hancock, Robert" wrote: > Hi all, > > I don't think there's any disagreement that CT is a tool that NSIS could > use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is it a hammer > or a screwdriver or a combination of the two? I guess this is more a > question for the seamoby people, but we need to know the answer to know > how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and AR-rest of world > signalling; CT can be used to transfer state (both resource state and > NSIS protocol state) between ARs at handover, but if this involves any > MN-AR messages (e.g. CTIN) they aren't QoS related. NSIS-CT interaction > can occur at the ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS context in > the AR, which it can then later transfer to a new AR. NSIS is used to > signal QoS for AR-rest of network. NSIS-CT interaction takes place at the > AR to interwork flow setup and resource descriptions, and this > interaction takes place at flow setup time. (Essentially, CT provides a > QoS signalling protocol for the edge of the network, which NSIS would > have to interwork with, in the same way that it has to interwork with > RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically assumes (b) so far > as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at this stage, > just establish that they are not the same. (And so we probably have to > make a choice, although I suppose you could allow both models...) > > Cheers, > > Robert H. > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 05 July 2002 10:05 >> To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; >> erafodo@ESEALNT448.al.sw.ericsson.se >> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com >> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on >> draft-westphal-nsis-qos-mobileip-00.txt) >> >> >> I see CT as an optimization only and not required for NSIS. >> However, since >> there is a tendency to support only on-path signaling, this >> would not work >> anyway (because CT would need off-path signaling for at least >> some time). >> >> Marcus >> >> --On Donnerstag, 4. Juli 2002 11:33 +0300 >> john.loughney@nokia.com wrote: >> >> > Hi Robert, >> > >> >> On the 'edge signalling' case, I guess the main point is that >> >> I'm confused about the scope of seamoby CT. Specifically >> >> regarding MN-AR signalling (no issue about the AR-AR part): >> > >> > From my viewpoint, CT is not required for NSIS. I view CT as >> > one tool that an NSIS solution could use. So, I definately think >> > that at some point, we will need some sort of applicability >> > statement describing how to use CT for NSIS. >> > >> > John >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> > ========================================================================= > =============== Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 06:37:23 2002 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 GAA17742 for ; Fri, 5 Jul 2002 06:37:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23757 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 06:38:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22186; Fri, 5 Jul 2002 06:24:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22156 for ; Fri, 5 Jul 2002 06:24:45 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16561 for ; Fri, 5 Jul 2002 06:23:54 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g65AOBI25120; Fri, 5 Jul 2002 12:24:11 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA20857; Fri, 5 Jul 2002 12:24:39 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 31BDA48F5E; Fri, 5 Jul 2002 12:24:39 +0200 (CEST) Date: Fri, 05 Jul 2002 12:24:40 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Message-ID: <6791826.1025871880@[192.168.102.207]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6565D@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6565D@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Freitag, 5. Juli 2002 13:10 +0300 john.loughney@nokia.com wrote: > Hi Marcus, > >> > I think that we need to seperate off-path requirements from the main >> > document. In my opinion, these are non-requirements for the current >> > charter. I would support moving these into an appendix, >> > which discusses off-path signaling. >> >> I still don't see what problem people have with off-path signaling (and >> I would call tunneling off-path as well). If the working group agrees >> to remove some of the req fine, let me know which ones. > > I can review the current document. My basic point is that NSIS is not > specifying off-path signaling, therefore NSIS should not make any > specific requirements for off-path signaling. Lest time I looked, > there wasn't anything I though was especially problematic, but I will > review it. I understand that, and I have not see a requirement opposing to it. therefore I asked Georgios to name the reqs which do cover off-path only issues. Marcus > >> If you start talking about NATs this might be an issue for >> NSIS, whether NSIS must work over NATs or not or don't care. > > Right now, I'm happy with not caring. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 07:03:08 2002 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 HAA18606 for ; Fri, 5 Jul 2002 07:03:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25007 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 07:03:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24049; Fri, 5 Jul 2002 06:46:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23953 for ; Fri, 5 Jul 2002 06:46:32 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18127 for ; Fri, 5 Jul 2002 06:45:42 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 11:46:26 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA43B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , "'Geib, Ruediger'" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-opopsig-00.txt) Date: Fri, 5 Jul 2002 11:46:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Marcus, The question of one IP hop or many is again a different issue. As an example (but I think it clarifies everything), RSVP operates over non-RSVP clouds; this means that RSVP RESV messages are peer-session addressed in all cases, over one IP hop or several. (And in fact, I can't recall if the message processing even changes at all between the two cases.) In terms of NSIS coping with traffic engineered networks, I'd consider a breakdown of NSIS functionality as follows: 1) There is a means for NSIS entities to work out how to address outgoing messages. This requires 1a) Outgoing interface selection (and in fact this is all you need for on-path signalling if all hops are NSIS-aware), or more generally 1b) Next NSIS neighbour addressing (explicit or implicit) (if it might be more than one hop away) 2) Everything else - state management, error handling, security, you name it. In a traditionally routed network, (1b) is easy in all cases (RSVP PATH). In a non-traditionally routed network, where all the nodes are NSIS aware, you just need to modify (1a), but the NSIS protocol could already contain all the information that implementation needs to work on (i.e. the flow information), so this is just an implementation issue. There's no rule which says that NSIS has to use the node's routing table to do interface selection. And (2) should be unchanged. If not all the nodes are NSIS aware, it's true that you need to do something new for (1b). But again, (2) should be unchanged (or rather, I think that should be a design goal for us). So, I'm not claiming to be able to cope with traffic engineered networks with normal routing. I'm just claiming that we should be able to design NSIS so that _most_ of the protocol isn't affected by the issue, and that in the case of all nodes being NSIS aware it should be an implementation matter. Robert > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 05 July 2002 11:16 > To: Hancock, Robert; 'Geib, Ruediger'; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments on draft in-path and out of path > (draft-schel en-nsis-opopsig-00.txt) > > > Robert, > > > --On Freitag, 5. Juli 2002 08:49 +0100 "Hancock, Robert" > wrote: > > > Hi all, > > > > I'd like to try to make one general comment about the on/off path > > question, namely that it really needs to be carefully > distinguished from > > the question of whether protocol messages are implicitly or > explicitly > > along whatever path. The latter question is really about > NSIS addressing: > > we identified both modes in our latest framework document > (section 3.3.4 > > if you're interested) and called them e2e and peer-session > addressing > > respectively. Both are applicable in the on-path case; the > off-path case > > basically requires the peer-session mode. > > > > What you define as peer-session mode I alrady would call > off-path, since it > does not need to run hop-by-hop (according to your definition). > So to be exact you have to say that peer-session addressing with one > hop-peers can be used in the on-path case. > > > With peer-session addressing it's clear that you need to > work out the > > address of the NSIS peer. I guess the emphasis on the > on-path case means > > that we aren't going to put a lot of effort into working out the > > addresses of off-path peers. But (personally) I'd be > worried if we built > > assumptions about the addressing model into other aspects of the > > protocol, and so it's unfair to say that an on path protocol is > > fundamentally unable to cope with traffic engineered > networks - it's just > > that maybe NSIS won't provide all the address discovery > mechanisms in > > this (fundamentally harder) case. > > I don't get your point. And I don't see how the hell you are > able to cope > with traffic engineered networks in the on-path case using > "normal" routing. > > > > Cheers, > > > > Robert H. > > > > PS As an example, RSVP PATH messages are e2e addressed (in our > > terminology) whereas RSVP RESV messages are peer-session > addressed. I > > don't think this makes RSVP an off path solution. > > Here I think again we need to differentiate the peer-session > hop-by-hop or > over several hops. And the RSVP RESV message hop objects even > has local > (interface number) information circumventing normal routing. > > Marcus > > >> -----Original Message----- > >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > >> Sent: 04 July 2002 15:05 > >> To: Georgios.Karagiannis@eln.ericsson.se > >> Cc: nsis@ietf.org > >> Subject: RE: [NSIS] comments on draft in-path and out of path > >> (draft-schel en-nsis-op opsig-00.txt) > >> > >> > >> Hi Georgios, > >> > >> my comments are in line. > >> > >> Regards, Rüdiger > >> > >> > Comment_2 on Section 3.2.1: > >> > ------------- > >> > I do not understand this comment: > >> > "In these cases, a signaling unaware cloud is not anymore a > >> > signaling carrier, as nothing assures it will forward the > >> > signal at the same place it will forward the dataflow." > >> > >> On path signaling only recognizes layer 3 routing. > >> I guess the authors here refer to DiffServ aware > >> traffic engineering. There traffic of different > >> traffic classes may be forwarded along different routes > >> - depending on their traffic class. Signaling messages > >> are probably Best Effort, so QoS enabled data will in > >> fact travel a different MPLS route. > >> The issue is that NSIS signaling is limited to layer 3 > >> (which I strongly appreciate). An on path solution is > >> layer 2 blind while an off path based solution doesn't > >> have to be. That's a clear benefit if off path signaling > >> is used. > >> > >> > Comment on Section 3.2.3 > >> > ------------------- > >> > You mentioned: > >> > "One problem of RSVP and intserv is that every router in the > >> > network must implement intserv and RSVP in order to link the > >> > sink and the source with a chain of QoS capable routers that > >> > all allocate resources for the flow." > >> > > >> > [georgios] not all routers in a communication path have to > >> > implement Intserv. Actually, you mighty have domains that > >> > are overprovisioned and do not implement Intserv. > >> > What I try to say is that this issue applies to both types of > >> > architectures, i.e., on path and out of path. Therefore, it > >> > is not fair to presented here as an on path issue! > >> > >> Section 4.3.1 of the draft states that an off path QoS controller > >> must be topology aware and therfore tap routing. So > >> overprovisioning is an option in domains using off path QoS > >> controllers, while it is a requirement for a domain using on > >> path signaling unless all routers passed must evaluate the > >> signaling information. > >> This too is a clear benefit of an off path solution. > >> > >> > * There may be a single point of failure > >> > > >> > Failure detection and error recovery are tremendously > >> > important. > >> > >> Good point. I support your suggestion to add this issue to > >> the list of issues. > >> > >> > * Sophisticated mechanisms for discovery of the centralized > >> > entities are needed. This is an addition to your > >> > Section 4.3.1. > >> > >> Yes, true. AAA or COPS may be checked to look for existing > >> standard methods. > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 08:04:46 2002 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 IAA20652 for ; Fri, 5 Jul 2002 08:04:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27821 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 08:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26783; Fri, 5 Jul 2002 07:51:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26745 for ; Fri, 5 Jul 2002 07:51:42 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20050 for ; Fri, 5 Jul 2002 07:50:49 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g65Bjab04307; Fri, 5 Jul 2002 13:45:36 +0200 To: "Hancock, Robert" Cc: "'brunner@ccrle.nec.de'" , "'Geib, Ruediger'" , Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 5 Jul 2002 13:49:15 +0200 Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-opopsig-00.txt) X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/05/2002 13:49:17 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256BED00408A148f9e8a93df938690918cC1256BED00408A14" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --0__=C1256BED00408A148f9e8a93df938690918cC1256BED00408A14 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Robert, There is one other traffic engineering issue related to point 1a (outgo= ing interface selection). The (traditional) route towards a destination can= change. During this change, it is possible that data flow temporarily d= oes not go on the reserved path. Traffic engineering techniques such as load-balancing on inter-domain links by means of dynamically changing t= he AS prepending could significantly increase the occurence of such change= s. It is then not the cause of a new issue but of the increased importance= of an existing one. Sven "Hancock, Robert" @ietf.org on 05/07/2002 12:46:24 Sent by: nsis-admin@ietf.org To: "'brunner@ccrle.nec.de'" , "'Geib, Ruediger= '" , Georgios.Karagiannis@eln.ericsson.= se cc: nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-s= chel en-nsis-opopsig-00.txt) Marcus, The question of one IP hop or many is again a different issue. As an example (but I think it clarifies everything), RSVP operates over non-R= SVP clouds; this means that RSVP RESV messages are peer-session addressed i= n all cases, over one IP hop or several. (And in fact, I can't recall if = the message processing even changes at all between the two cases.) In terms of NSIS coping with traffic engineered networks, I'd consider = a breakdown of NSIS functionality as follows: 1) There is a means for NSIS entities to work out how to address outgoi= ng messages. This requires 1a) Outgoing interface selection (and in fact this is all you need for on-path signalling if all hops are NSIS-aware), or more generally 1b) Next NSIS neighbour addressing (explicit or implicit) (if it might = be more than one hop away) 2) Everything else - state management, error handling, security, you na= me it. In a traditionally routed network, (1b) is easy in all cases (RSVP PATH= ). In a non-traditionally routed network, where all the nodes are NSIS awa= re, you just need to modify (1a), but the NSIS protocol could already conta= in all the information that implementation needs to work on (i.e. the flow= information), so this is just an implementation issue. There's no rule which says that NSIS has to use the node's routing table to do interfac= e selection. And (2) should be unchanged. If not all the nodes are NSIS aware, it's true that you need to do something new for (1b). But again, (2) should be unchanged (or rather, = I think that should be a design goal for us). So, I'm not claiming to be able to cope with traffic engineered network= s with normal routing. I'm just claiming that we should be able to design= NSIS so that _most_ of the protocol isn't affected by the issue, and th= at in the case of all nodes being NSIS aware it should be an implementatio= n matter. Robert > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 05 July 2002 11:16 > To: Hancock, Robert; 'Geib, Ruediger'; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] comments on draft in-path and out of path > (draft-schel en-nsis-opopsig-00.txt) > > > Robert, > > > --On Freitag, 5. Juli 2002 08:49 +0100 "Hancock, Robert" > wrote: > > > Hi all, > > > > I'd like to try to make one general comment about the on/off path > > question, namely that it really needs to be carefully > distinguished from > > the question of whether protocol messages are implicitly or > explicitly > > along whatever path. The latter question is really about > NSIS addressing: > > we identified both modes in our latest framework document > (section 3.3.4 > > if you're interested) and called them e2e and peer-session > addressing > > respectively. Both are applicable in the on-path case; the > off-path case > > basically requires the peer-session mode. > > > > What you define as peer-session mode I alrady would call > off-path, since it > does not need to run hop-by-hop (according to your definition). > So to be exact you have to say that peer-session addressing with one > hop-peers can be used in the on-path case. > > > With peer-session addressing it's clear that you need to > work out the > > address of the NSIS peer. I guess the emphasis on the > on-path case means > > that we aren't going to put a lot of effort into working out the > > addresses of off-path peers. But (personally) I'd be > worried if we built > > assumptions about the addressing model into other aspects of the > > protocol, and so it's unfair to say that an on path protocol is > > fundamentally unable to cope with traffic engineered > networks - it's just > > that maybe NSIS won't provide all the address discovery > mechanisms in > > this (fundamentally harder) case. > > I don't get your point. And I don't see how the hell you are > able to cope > with traffic engineered networks in the on-path case using > "normal" routing. > > > > Cheers, > > > > Robert H. > > > > PS As an example, RSVP PATH messages are e2e addressed (in our > > terminology) whereas RSVP RESV messages are peer-session > addressed. I > > don't think this makes RSVP an off path solution. > > Here I think again we need to differentiate the peer-session > hop-by-hop or > over several hops. And the RSVP RESV message hop objects even > has local > (interface number) information circumventing normal routing. > > Marcus > > >> -----Original Message----- > >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > >> Sent: 04 July 2002 15:05 > >> To: Georgios.Karagiannis@eln.ericsson.se > >> Cc: nsis@ietf.org > >> Subject: RE: [NSIS] comments on draft in-path and out of path > >> (draft-schel en-nsis-op opsig-00.txt) > >> > >> > >> Hi Georgios, > >> > >> my comments are in line. > >> > >> Regards, R=FCdiger > >> > >> > Comment_2 on Section 3.2.1: > >> > ------------- > >> > I do not understand this comment: > >> > "In these cases, a signaling unaware cloud is not anymore a > >> > signaling carrier, as nothing assures it will forward the > >> > signal at the same place it will forward the dataflow." > >> > >> On path signaling only recognizes layer 3 routing. > >> I guess the authors here refer to DiffServ aware > >> traffic engineering. There traffic of different > >> traffic classes may be forwarded along different routes > >> - depending on their traffic class. Signaling messages > >> are probably Best Effort, so QoS enabled data will in > >> fact travel a different MPLS route. > >> The issue is that NSIS signaling is limited to layer 3 > >> (which I strongly appreciate). An on path solution is > >> layer 2 blind while an off path based solution doesn't > >> have to be. That's a clear benefit if off path signaling > >> is used. > >> > >> > Comment on Section 3.2.3 > >> > ------------------- > >> > You mentioned: > >> > "One problem of RSVP and intserv is that every router in the > >> > network must implement intserv and RSVP in order to link the > >> > sink and the source with a chain of QoS capable routers that > >> > all allocate resources for the flow." > >> > > >> > [georgios] not all routers in a communication path have to > >> > implement Intserv. Actually, you mighty have domains that > >> > are overprovisioned and do not implement Intserv. > >> > What I try to say is that this issue applies to both types of > >> > architectures, i.e., on path and out of path. Therefore, it > >> > is not fair to presented here as an on path issue! > >> > >> Section 4.3.1 of the draft states that an off path QoS controller > >> must be topology aware and therfore tap routing. So > >> overprovisioning is an option in domains using off path QoS > >> controllers, while it is a requirement for a domain using on > >> path signaling unless all routers passed must evaluate the > >> signaling information. > >> This too is a clear benefit of an off path solution. > >> > >> > * There may be a single point of failure > >> > > >> > Failure detection and error recovery are tremendously > >> > important. > >> > >> Good point. I support your suggestion to add this issue to > >> the list of issues. > >> > >> > * Sophisticated mechanisms for discovery of the centralized > >> > entities are needed. This is an addition to your > >> > Section 4.3.1. > >> > >> Yes, true. AAA or COPS may be checked to look for existing > >> standard methods. > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > =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=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 Permission is hereby granted to pass the contents of this communication= to third parties and any restrictions regarding confidentiality do not app= ly. (See attached file: RMRL-Disclaimer.txt) = --0__=C1256BED00408A148f9e8a93df938690918cC1256BED00408A14 Content-type: application/octet-stream; name="=?iso-8859-1?Q?RMRL-Disclaimer.txt?=" Content-Disposition: attachment; filename="=?iso-8859-1?Q?RMRL-Disclaimer.txt?=" Content-Transfer-Encoding: base64 VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCB0byBSb2tlIA0KTWFub3IgUmVzZWFyY2ggTHRkIGFuZCBtdXN0 IG5vdCBiZSBwYXNzZWQgdG8gYW55IHRoaXJkIHBhcnR5IHdpdGhvdXQgcGVybWlzc2lvbi4gVGhp cyANCmNvbW11bmljYXRpb24gaXMgZm9yIGluZm9ybWF0aW9uIG9ubHkgYW5kIHNoYWxsIG5vdCBj cmVhdGUgb3IgY2hhbmdlIGFueSBjb250cmFjdHVhbCANCnJlbGF0aW9uc2hpcC4NCg== --0__=C1256BED00408A148f9e8a93df938690918cC1256BED00408A14-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 08:05:15 2002 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 IAA20681 for ; Fri, 5 Jul 2002 08:05:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27832 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 08:06:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26597; Fri, 5 Jul 2002 07:46:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26566 for ; Fri, 5 Jul 2002 07:46:30 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19752 for ; Fri, 5 Jul 2002 07:45:37 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g65BjsI28080; Fri, 5 Jul 2002 13:45:55 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA21813; Fri, 5 Jul 2002 13:46:23 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 32ECC48F5E; Fri, 5 Jul 2002 13:46:22 +0200 (CEST) Date: Fri, 05 Jul 2002 13:46:23 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , "'Geib, Ruediger'" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-opopsig-00.txt) Message-ID: <11695997.1025876783@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA43B@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA43B@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA26567 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit --On Freitag, 5. Juli 2002 11:46 +0100 "Hancock, Robert" wrote: > Marcus, > > The question of one IP hop or many is again a different issue. As an > example (but I think it clarifies everything), RSVP operates over > non-RSVP clouds; this means that RSVP RESV messages are peer-session > addressed in all cases, over one IP hop or several. (And in fact, I can't > recall if the message processing even changes at all between the two > cases.) They are not only peer-session adressed but also forced to use a certain path, which might be different than the normal routing would prescribe. I don't think it is a different issue. I see it as the main differece between on and off path signaling. Allowing peer-session mode enables off-path signaling, whether you like it or not, whereas end-to-end addressing rules out off-path signalling. In peer-session adressing the next question is how to find the next NSIS aware hop, this is in fact then a different question. > > In terms of NSIS coping with traffic engineered networks, I'd consider a > breakdown of NSIS functionality as follows: 1) There is a means for NSIS > entities to work out how to address outgoing messages. This requires 1a) > Outgoing interface selection (and in fact this is all you need for > on-path signalling if all hops are NSIS-aware), or more generally 1b) > Next NSIS neighbour addressing (explicit or implicit) (if it might be > more than one hop away) 2) Everything else - state management, error > handling, security, you name it. > In a traditionally routed network, (1b) is easy in all cases (RSVP PATH). > > In a non-traditionally routed network, where all the nodes are NSIS > aware, you just need to modify (1a), but the NSIS protocol could already > contain all the information that implementation needs to work on (i.e. > the flow information), so this is just an implementation issue. There's > no rule which says that NSIS has to use the node's routing table to do > interface selection. And (2) should be unchanged. What else should it use than the routing table? The MPLS forwarding table? You don't even know where an LSP is destined to (again in the general case). But I think we can rule out non-traditional routing anyway. Marcus > If not all the nodes are NSIS aware, it's true that you need to do > something new for (1b). But again, (2) should be unchanged (or rather, I > think that should be a design goal for us). > So, I'm not claiming to be able to cope with traffic engineered networks > with normal routing. I'm just claiming that we should be able to design > NSIS so that _most_ of the protocol isn't affected by the issue, and that > in the case of all nodes being NSIS aware it should be an implementation > matter. > > Robert > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 05 July 2002 11:16 >> To: Hancock, Robert; 'Geib, Ruediger'; >> Georgios.Karagiannis@eln.ericsson.se >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] comments on draft in-path and out of path >> (draft-schel en-nsis-opopsig-00.txt) >> >> >> Robert, >> >> >> --On Freitag, 5. Juli 2002 08:49 +0100 "Hancock, Robert" >> wrote: >> >> > Hi all, >> > >> > I'd like to try to make one general comment about the on/off path >> > question, namely that it really needs to be carefully >> distinguished from >> > the question of whether protocol messages are implicitly or >> explicitly >> > along whatever path. The latter question is really about >> NSIS addressing: >> > we identified both modes in our latest framework document >> (section 3.3.4 >> > if you're interested) and called them e2e and peer-session >> addressing >> > respectively. Both are applicable in the on-path case; the >> off-path case >> > basically requires the peer-session mode. >> > >> >> What you define as peer-session mode I alrady would call >> off-path, since it >> does not need to run hop-by-hop (according to your definition). >> So to be exact you have to say that peer-session addressing with one >> hop-peers can be used in the on-path case. >> >> > With peer-session addressing it's clear that you need to >> work out the >> > address of the NSIS peer. I guess the emphasis on the >> on-path case means >> > that we aren't going to put a lot of effort into working out the >> > addresses of off-path peers. But (personally) I'd be >> worried if we built >> > assumptions about the addressing model into other aspects of the >> > protocol, and so it's unfair to say that an on path protocol is >> > fundamentally unable to cope with traffic engineered >> networks - it's just >> > that maybe NSIS won't provide all the address discovery >> mechanisms in >> > this (fundamentally harder) case. >> >> I don't get your point. And I don't see how the hell you are >> able to cope >> with traffic engineered networks in the on-path case using >> "normal" routing. >> >> >> > Cheers, >> > >> > Robert H. >> > >> > PS As an example, RSVP PATH messages are e2e addressed (in our >> > terminology) whereas RSVP RESV messages are peer-session >> addressed. I >> > don't think this makes RSVP an off path solution. >> >> Here I think again we need to differentiate the peer-session >> hop-by-hop or >> over several hops. And the RSVP RESV message hop objects even >> has local >> (interface number) information circumventing normal routing. >> >> Marcus >> >> >> -----Original Message----- >> >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >> >> Sent: 04 July 2002 15:05 >> >> To: Georgios.Karagiannis@eln.ericsson.se >> >> Cc: nsis@ietf.org >> >> Subject: RE: [NSIS] comments on draft in-path and out of path >> >> (draft-schel en-nsis-op opsig-00.txt) >> >> >> >> >> >> Hi Georgios, >> >> >> >> my comments are in line. >> >> >> >> Regards, Rüdiger >> >> >> >> > Comment_2 on Section 3.2.1: >> >> > ------------- >> >> > I do not understand this comment: >> >> > "In these cases, a signaling unaware cloud is not anymore a >> >> > signaling carrier, as nothing assures it will forward the >> >> > signal at the same place it will forward the dataflow." >> >> >> >> On path signaling only recognizes layer 3 routing. >> >> I guess the authors here refer to DiffServ aware >> >> traffic engineering. There traffic of different >> >> traffic classes may be forwarded along different routes >> >> - depending on their traffic class. Signaling messages >> >> are probably Best Effort, so QoS enabled data will in >> >> fact travel a different MPLS route. >> >> The issue is that NSIS signaling is limited to layer 3 >> >> (which I strongly appreciate). An on path solution is >> >> layer 2 blind while an off path based solution doesn't >> >> have to be. That's a clear benefit if off path signaling >> >> is used. >> >> >> >> > Comment on Section 3.2.3 >> >> > ------------------- >> >> > You mentioned: >> >> > "One problem of RSVP and intserv is that every router in the >> >> > network must implement intserv and RSVP in order to link the >> >> > sink and the source with a chain of QoS capable routers that >> >> > all allocate resources for the flow." >> >> > >> >> > [georgios] not all routers in a communication path have to >> >> > implement Intserv. Actually, you mighty have domains that >> >> > are overprovisioned and do not implement Intserv. >> >> > What I try to say is that this issue applies to both types of >> >> > architectures, i.e., on path and out of path. Therefore, it >> >> > is not fair to presented here as an on path issue! >> >> >> >> Section 4.3.1 of the draft states that an off path QoS controller >> >> must be topology aware and therfore tap routing. So >> >> overprovisioning is an option in domains using off path QoS >> >> controllers, while it is a requirement for a domain using on >> >> path signaling unless all routers passed must evaluate the >> >> signaling information. >> >> This too is a clear benefit of an off path solution. >> >> >> >> > * There may be a single point of failure >> >> > >> >> > Failure detection and error recovery are tremendously >> >> > important. >> >> >> >> Good point. I support your suggestion to add this issue to >> >> the list of issues. >> >> >> >> > * Sophisticated mechanisms for discovery of the centralized >> >> > entities are needed. This is an addition to your >> >> > Section 4.3.1. >> >> >> >> Yes, true. AAA or COPS may be checked to look for existing >> >> standard methods. >> >> >> >> _______________________________________________ >> >> nsis mailing list >> >> nsis@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> > ========================================================================= > =============== Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 08:53:05 2002 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 IAA22547 for ; Fri, 5 Jul 2002 08:53:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29969 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 08:53:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29357; Fri, 5 Jul 2002 08:34:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29265 for ; Fri, 5 Jul 2002 08:34:19 -0400 (EDT) Received: from operax.com (aurorum86-0.aurorum.se [213.88.249.86]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21872 for ; Fri, 5 Jul 2002 08:33:27 -0400 (EDT) Received: (qmail 93979 invoked by uid 0); 5 Jul 2002 12:33:46 -0000 Received: from detrol.operax.com (HELO operax.com) (192.168.1.15) by treo.operax.com with SMTP; 5 Jul 2002 12:33:46 -0000 Message-ID: <3D2591C6.EC6765D5@operax.com> Date: Fri, 05 Jul 2002 14:32:07 +0200 From: Olov =?iso-8859-1?Q?Schel=E9n?= X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: "'Alban.Couturier@alcatel.fr'" , nsis@ietf.org Subject: Re: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-opopsig-00.txt) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Georgious, thank you for your comments. I have included my response below. /Olov "Georgios Karagiannis (ELN)" wrote: > Dear Olov and Alban > > I have read your draft and I have some comments mainly on Sections 3 and 4 (see below). > > Best Regards, > Georgios > > Comments on Section 3.2.1: > ------------------------------------ > > Comment_1 on Section 3.2.1: > ----------------- > You mention that: > "The on-path signaling relies on the fundamental assumption that packets are all routed the > same way, based on the IP destination address. This will be called in this draft the > "traditional IP routing." > [georgios] Right but, you should not exclude other types of routing. In my opinion an > on path solution should consider > the possible cases described in {RFC2992] regarding: > "Analysis of an Equal-Cost Multi-Path Algorithm". > In general, if the signalling protocol uses the same routing protocol as the data > path then the signaling > messages and their associated data path packets will have to follow the same path. > In RFC2992, nothing is said on that load-balancing is REQUIRED to be based on source-destination pairs of addresses only. The same holds for any traffic engineering methods. How this is done by real implementations I am not sure about, but would appreciate feedback on this. My understanding is that divergence of signalling-path and data-path can happen, at least at some points in the network. With MPLS there may be an approach for sending real-time traffic (e.g. VoIP) on separate LSPs and also to transfer the traffic to next domain on different interfaces. > > Comment_2 on Section 3.2.1: > ------------- > I do not understand this comment: > "In these cases, a signaling unaware cloud is not anymore a signaling carrier, > as nothing assures it > will forward the signal at the same place it will forward the dataflow." > > [georgios] If the signalling protocol uses the same routing protocol as the data path then the > signaling messages and their associated data path packets will have to follow the same path. > This will have to be ensured even if the signaling protocol is not used in a certain domain. > A network provider may for example need to configure the network such that signalling path > messages follow the same path as the data path messages. However, this is a reasonable > requirement, since a network provider should be able to configure many other parameters > in his network. The problem here is that there may be domains along the path (perhaps over-provisioned and not signalling-aware) that do not follow this recomendation. In the backbone there is probably multiple peering-points, so once the signalling has diverted it may enter following domains at different ingresses. > > ------------------------------------------------------------------------------------------------- > > Comment on Section 3.2.2 > --------------------------- > In this section you are talking about centralized policy servers. > What about distributed policy servers? Distributed on the edge nodes of a domain! > ------------------------------------------------------------------------------------------------- > Yes they can be distributed physically, but they are logically centralized in the sense that they have a common understanding the commitments and resource availability in the domain. > > Comment on Section 3.2.3 > ------------------- > You mentioned: > "One problem of RSVP and intserv is that every router in the network must implement > intserv and RSVP in order to link the sink and the source with a chain of QoS capable > routers that all allocate > resources for the flow." > > [georgios] not all routers in a communication path have to implement Intserv. > Actually, you mighty have domains that are overprovisioned and do not implement Intserv. > What I try to say is that this issue applies to both types of architectures, > i.e., on path and out of path. Therefore, it is not fair to presented here as an on > path issue! Yes, there may be over-provisioned and QoS un-aware doamins in both cases, so ensuring e2e QoS is difficult in both models. We do here however emphasise the need for having the signalling support in routers at all. Although only in edge-routers (as we explain) there are plenty of edge routers that need to handle this signalling. This is to compare with off-path (application-level) signalling that does not require particular support in routers at all. > > ------------------------------------------------------------------------------------------------- > > Comment on Section 4.2.1 > ----------------------------- > You mention that there are benefits of using independent signaling plane and forwarding plane. > This is only a benefit only when only you will assume that the forwarding plane is > overprovisioned or, etc., > You can get the same situation with an on path signaling when you will assume that > a network consists of a concatenation of domains and the only routers that are using > the NSIS protocol are only few edge nodes. This is after assuming that all the other routers > are overprovisioned. > Thus I do not see this issue as a benefit of the out of path architecture! > ------------------------------------------------------------------------------------------------- > I refer to my response to your previous comment. > > Comment on Section 4.2.2 > --------------- > You mentioned that VoIP or multimedia network applications rely on servers > such as soft switches, gatekeepers, etc.,,. > You also mention that on-path signaling solutions require complex deployments that can be > avoided thanks to the placement's flexibility associated to the off-path model. > In my opinion the solutions that are needed for a centralized entity located out of path > to efficiently configure, efficiently manage resources, and efficiently communicate with > the routers that are on path and are not using the NSIS protocol are much more complicated than > the solutions that you will need to use when the servers are located on path. Standards-wise the off-path model only needs a high-level protocol to be set (e.g. containers over TCP and possibly also over some well known applicaton level protocol). In addition, it would be nice to use an efficient standard for setting traffic conditioners at edges (e.g., COPS-PR plus standardised PIBs, SNMPCONF plus standardised MIBs, etc). Standards-wise this is simpler, relatively speaking. Note that conditioners would only be operated at microflow-level at accesses, while the rest would be on larger aggregates (constrained on destination prefixes, etc) . Implementation-wise I see only your opinion, so I respond only by ensuring that there are solutions that are just running fine. > > Comment in Section 4.2.3 > ------------------------------ > This benefit is associated with an on path disadvantage given in Section 3.2.1. > The comment that I gave there applies also here! > In general, if the signalling protocol uses the same routing protocol as the data path > then the signaling > messages and their associated data path packets will have to follow the same path. Our intent here is to state exactly what you say, i.e., that the problem of keeping track of non-traditional routing applies also in the off-path case. > > Comment in Section 4.3 > ---------------------------- > > I would like to add some more issues with the out of path signaling: > The out of path signaling scenario, compared to the in-path > signaling, introduces the need of a centralized architecture > (which can in turn be distributed). Having an architecture > with centralized decision-making capabilities means that > certain kinds of issues must be handled: > > * There may be a single point of failure > > Failure detection and error recovery are tremendously > important. > Failure detection are tremendously important in both models. In the off-path model there is no single point of failure when the implementation is distributed (and nodes can operate independently ). I see that the same problem applies for on-path, so I agree that we should add this as an importand issue in general. > > > * Checking for availability of resources within a domain may be > based on either static or dynamic configuration data. > If this is done dynamically, the RTT of the signalling > protocol itself could be increased. This is an addition to the text > that you propose in Section 4.3.2. Well, thats true if you prefer to do it that way. However, instant traffic measures are often not a good basis for predicting the future. Rather you would rely on periodic feedback and perhaps heuristics. Anyway this information will be collected as a background process that does not affect the RTT of the signalling itself. > > > * The centralized resource management entity might become > congested faster due to the higher number of signaling > requests compared to a distributed resource management > architecture. It is very hard to make definite statements about performance in both models. Evaluation by real operators is probably the best way to go. However, servers are dealing with this kind of computational tasks quite well, while routers are good at packet forwarding (not known for handling slow-path tasks very efficiently). Also hierarchical aggregation keeps down the overhead. > > > * Sophisticated mechanisms for discovery of the centralized > entities are needed. This is an addition to your Section 4.3.1. > QoS controlers can also be configured with peering relations (much like BGP-routers are configured with peering-relations today). For end-hosts (in case it would be desirable for hosts to be initiators), configuration could be through dhcp-like mechanism. > > * Routing of signaling messages might affect the routing of > data path. This is similar to the issue explained in > Section 4.3.1. > > * Anytime a handover or a route change takes place, the > routing of the data path may change. Mechanisms are needed > to relate the path that signaling messages and data path > packets follow. This is similar to the issue explained in > Section 4.3.1. > > _ For these two, see previous responds. > ______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Olov Schelén, CTO Operax AB Tel +46 920 7 5516 Aurorum 8 Mobile +46 705 79 5516 SE 977 75 Luleå olov.schelen@operax.com www.operax.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 10:41:48 2002 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 KAA27505 for ; Fri, 5 Jul 2002 10:41:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05866 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 10:42:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04800; Fri, 5 Jul 2002 10:26:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04769 for ; Fri, 5 Jul 2002 10:26:48 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26805 for ; Fri, 5 Jul 2002 10:25:55 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65ELk305738; Fri, 5 Jul 2002 10:21:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 10:21:46 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BD9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, robert.hancock@roke.co.uk, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 10:21:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2242F.4A304D1C" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2242F.4A304D1C Content-Type: text/plain; charset="iso-8859-1" No matter how you define it, handover requires "off-path signalling", as the purpose is to change the path. Most of this path set up operation can be stuffed down into the link layer (and one can argue the pros and cons), but not all of the IP services can be pushed to the link layer. If NSIS is constrained to be "along the (IP forwarding) path" then it is of limited use in mobility situations. Indeed, it could only be used to re-establish services once the new path is established, which means, in the instances NSIS is invoked, the handover will not be seamless, or smooth, or whatever. The point being that it does not appear that NSIS has much of a useful role for the majority of handover situations, and CT, or some similar off-path state relocation/ re-establishment signalling mechanism, will be required. gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: July 5, 2002 05:05 > To: john.loughney@nokia.com; robert.hancock@roke.co.uk; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > draft-westphal-nsis-qos-mobileip-00.txt) > > > I see CT as an optimization only and not required for NSIS. > However, since > there is a tendency to support only on-path signaling, this > would not work > anyway (because CT would need off-path signaling for at least > some time). > > Marcus > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > john.loughney@nokia.com wrote: > > > Hi Robert, > > > >> On the 'edge signalling' case, I guess the main point is that > >> I'm confused about the scope of seamoby CT. Specifically > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > one tool that an NSIS solution could use. So, I definately think > > that at some point, we will need some sort of applicability > > statement describing how to use CT for NSIS. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C2242F.4A304D1C Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt)

No matter how you define it, handover requires "off-path signalling",
as the purpose is to change the path. Most of this path set up
operation can be stuffed down into the link layer (and one can argue
the pros and cons), but not all of the IP services can be pushed to the
link layer.

If NSIS is constrained to be "along the (IP forwarding) path" then it
is of limited use in mobility situations. Indeed, it could only be used
to re-establish services once the new path is established, which means,
in the instances NSIS is invoked, the handover will not be seamless, or
smooth, or whatever.

The point being that it does not appear that NSIS has much of a useful
role for the majority of handover situations, and CT, or some similar
off-path state relocation/ re-establishment signalling mechanism, will
be required.

gary

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: July 5, 2002 05:05
> To: john.loughney@nokia.com; robert.hancock@roke.co.uk;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> draft-westphal-nsis-qos-mobileip-00.txt)
>
>
> I see CT as an optimization only and not required for NSIS.
> However, since
> there is a tendency to support only on-path signaling, this
> would not work
> anyway (because CT would need off-path signaling for at least
> some time).
>
> Marcus
>
> --On Donnerstag, 4. Juli 2002 11:33 +0300
> john.loughney@nokia.com wrote:
>
> > Hi Robert,
> >
> >> On the 'edge signalling' case, I guess the main point is that
> >> I'm confused about the scope of seamoby CT. Specifically
> >> regarding MN-AR signalling (no issue about the AR-AR part):
> >
> > From my viewpoint, CT is not required for NSIS. I view CT as
> > one tool that an NSIS solution could use.  So, I definately think
> > that at some point, we will need some sort of applicability
> > statement describing how to use CT for NSIS.
> >
> > John
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C2242F.4A304D1C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 10:53:26 2002 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 KAA28014 for ; Fri, 5 Jul 2002 10:53:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06328 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 10:54:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05739; Fri, 5 Jul 2002 10:39:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05680 for ; Fri, 5 Jul 2002 10:39:25 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27359; Fri, 5 Jul 2002 10:38:29 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65EYc306653; Fri, 5 Jul 2002 10:34:38 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 10:34:37 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BDA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 10:34:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22431.15039930" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22431.15039930 Content-Type: text/plain; charset="iso-8859-1" Robert: In your discussion of CT, you are presupposing a wg solution for CT that does not exist. The work on the CT protocol has not begun in Seamoby. Indeed, if you examine the CT requirements, signalling from the MN to the access network is prohibited. The reason being is that the sole purpose of CT is to enable a fast, smooth, seamless handover. Signalling over the air simply takes too much time, and the value of signalling from MN to AR has never been clearly identified. This issue was debated extensively in the CT design group and on the Seamoby list. I understand that there are people who feel otherwise, and please, let's not regurgitate the arguments here. As the requirements currently stand, CT is an AR to AR protocol. One source of confusion might be the work on the discovery protocol. It is my, admittedly minority opinion, that the use of MN to AR signalling to perform CT was moved into the discovery solution. And again, nothing can be done between the MN and an AR that cannot be done more efficiently, and faster, between two ARs. The way I see the directions of the two solutions lining up so far, NSIS and CT have little interaction. NSIS could be invoked if a CT attempt fails, but the restriction to have NSIS along the path implies that some path must exist before NSIS can be invoked. Thus, NSIS can be used only *after* a handover has completed, and thus there is no opportunity for interaction. Of course, all of this depends on what you define as a "path" - I am assuming that it is the IP forwarding path for the MNs bearer traffic. gary > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 05:35 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > Hi all, > > I don't think there's any disagreement that CT is a tool that > NSIS could use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is > it a hammer or a screwdriver or a combination of the two? I > guess this is more a question for the seamoby people, but we > need to know the answer to know how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and > AR-rest of world signalling; CT can be used to transfer state > (both resource state and NSIS protocol state) between ARs at > handover, but if this involves any MN-AR messages (e.g. CTIN) > they aren't QoS related. NSIS-CT interaction can occur at the > ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS > context in the AR, which it can then later transfer to a new > AR. NSIS is used to signal QoS for AR-rest of network. > NSIS-CT interaction takes place at the AR to interwork flow > setup and resource descriptions, and this interaction takes > place at flow setup time. (Essentially, CT provides a QoS > signalling protocol for the edge of the network, which NSIS > would have to interwork with, in the same way that it has to > interwork with RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically > assumes (b) so far as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at > this stage, just establish that they are not the same. (And > so we probably have to make a choice, although I suppose you > could allow both models...) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: 05 July 2002 10:05 > > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se > > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > draft-westphal-nsis-qos-mobileip-00.txt) > > > > > > I see CT as an optimization only and not required for NSIS. > > However, since > > there is a tendency to support only on-path signaling, this > > would not work > > anyway (because CT would need off-path signaling for at least > > some time). > > > > Marcus > > > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > > john.loughney@nokia.com wrote: > > > > > Hi Robert, > > > > > >> On the 'edge signalling' case, I guess the main point is that > > >> I'm confused about the scope of seamoby CT. Specifically > > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > > one tool that an NSIS solution could use. So, I definately think > > > that at some point, we will need some sort of applicability > > > statement describing how to use CT for NSIS. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > ------_=_NextPart_001_01C22431.15039930 Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs.

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer traffic.


gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: July 5, 2002 05:35
> To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> Hi all,
>
> I don't think there's any disagreement that CT is a tool that
> NSIS could use (as an optimisation).
>
> What's entirely unclear to me is what sort of tool CT is: is
> it a hammer or a screwdriver or a combination of the two? I
> guess this is more a question for the seamoby people, but we
> need to know the answer to know how to use it.
>
> More formally, there seem to be two extremes:
>
> a) NSIS is used for MN-AR resource (QoS) signalling, and
> AR-rest of world signalling; CT can be used to transfer state
> (both resource state and NSIS protocol state) between ARs at
> handover, but if this involves any MN-AR messages (e.g. CTIN)
> they aren't QoS related. NSIS-CT interaction can occur at the
> ARs to do state transfer at handover time.
>
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS
> context in the AR, which it can then later transfer to a new
> AR. NSIS is used to signal QoS for AR-rest of network.
> NSIS-CT interaction takes place at the AR to interwork flow
> setup and resource descriptions, and this interaction takes
> place at flow setup time. (Essentially, CT provides a QoS
> signalling protocol for the edge of the network, which NSIS
> would have to interwork with, in the same way that it has to
> interwork with RSVP/Intserv.)
>
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically
> assumes (b) so far as I can tell.
>
> I'm not trying to argue which of (a) or (b) is 'correct' at
> this stage, just establish that they are not the same. (And
> so we probably have to make a choice, although I suppose you
> could allow both models...)
>
> Cheers,
>
> Robert H.
>
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: 05 July 2002 10:05
> > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se
> > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > I see CT as an optimization only and not required for NSIS.
> > However, since
> > there is a tendency to support only on-path signaling, this
> > would not work
> > anyway (because CT would need off-path signaling for at least
> > some time).
> >
> > Marcus
> >
> > --On Donnerstag, 4. Juli 2002 11:33 +0300
> > john.loughney@nokia.com wrote:
> >
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
> ==============================================================
> ==========================
> Permission is hereby granted to pass the contents of this
> communication to third parties and any restrictions regarding
> confidentiality do not apply.
>

------_=_NextPart_001_01C22431.15039930-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 11:16:16 2002 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 LAA29057 for ; Fri, 5 Jul 2002 11:16:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07740 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 11:17:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06591; Fri, 5 Jul 2002 10:59:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06430 for ; Fri, 5 Jul 2002 10:59:14 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28226; Fri, 5 Jul 2002 10:58:20 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 15:58:54 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA43D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Gary Kenward'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 15:58:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22434.7ABEC65C" ------_=_NextPart_001_01C22434.7ABEC65C Content-Type: text/plain; charset="iso-8859-1" hi gary, my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about). in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft. our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway). i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air. cheers, robert h. PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 05 July 2002 15:35 To: Hancock, Robert; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Robert: In your discussion of CT, you are presupposing a wg solution for CT that does not exist. The work on the CT protocol has not begun in Seamoby. Indeed, if you examine the CT requirements, signalling from the MN to the access network is prohibited. The reason being is that the sole purpose of CT is to enable a fast, smooth, seamless handover. Signalling over the air simply takes too much time, and the value of signalling from MN to AR has never been clearly identified. This issue was debated extensively in the CT design group and on the Seamoby list. I understand that there are people who feel otherwise, and please, let's not regurgitate the arguments here. As the requirements currently stand, CT is an AR to AR protocol. One source of confusion might be the work on the discovery protocol. It is my, admittedly minority opinion, that the use of MN to AR signalling to perform CT was moved into the discovery solution. And again, nothing can be done between the MN and an AR that cannot be done more efficiently, and faster, between two ARs. The way I see the directions of the two solutions lining up so far, NSIS and CT have little interaction. NSIS could be invoked if a CT attempt fails, but the restriction to have NSIS along the path implies that some path must exist before NSIS can be invoked. Thus, NSIS can be used only *after* a handover has completed, and thus there is no opportunity for interaction. Of course, all of this depends on what you define as a "path" - I am assuming that it is the IP forwarding path for the MNs bearer traffic. gary > -----Original Message----- > From: Hancock, Robert [ mailto:robert.hancock@roke.co.uk ] > Sent: July 5, 2002 05:35 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > Hi all, > > I don't think there's any disagreement that CT is a tool that > NSIS could use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is > it a hammer or a screwdriver or a combination of the two? I > guess this is more a question for the seamoby people, but we > need to know the answer to know how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and > AR-rest of world signalling; CT can be used to transfer state > (both resource state and NSIS protocol state) between ARs at > handover, but if this involves any MN-AR messages (e.g. CTIN) > they aren't QoS related. NSIS-CT interaction can occur at the > ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS > context in the AR, which it can then later transfer to a new > AR. NSIS is used to signal QoS for AR-rest of network. > NSIS-CT interaction takes place at the AR to interwork flow > setup and resource descriptions, and this interaction takes > place at flow setup time. (Essentially, CT provides a QoS > signalling protocol for the edge of the network, which NSIS > would have to interwork with, in the same way that it has to > interwork with RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically > assumes (b) so far as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at > this stage, just establish that they are not the same. (And > so we probably have to make a choice, although I suppose you > could allow both models...) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Marcus Brunner [ mailto:brunner@ccrle.nec.de ] > > Sent: 05 July 2002 10:05 > > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se > > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > draft-westphal-nsis-qos-mobileip-00.txt) > > > > > > I see CT as an optimization only and not required for NSIS. > > However, since > > there is a tendency to support only on-path signaling, this > > would not work > > anyway (because CT would need off-path signaling for at least > > some time). > > > > Marcus > > > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > > john.loughney@nokia.com wrote: > > > > > Hi Robert, > > > > > >> On the 'edge signalling' case, I guess the main point is that > > >> I'm confused about the scope of seamoby CT. Specifically > > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > > one tool that an NSIS solution could use. So, I definately think > > > that at some point, we will need some sort of applicability > > > statement describing how to use CT for NSIS. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > ============================================================== ========================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. ------_=_NextPart_001_01C22434.7ABEC65C Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about).
in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem.
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 05 July 2002 15:35
To: Hancock, Robert; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs.

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer traffic.


gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: July 5, 2002 05:35
> To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> Hi all,
>
> I don't think there's any disagreement that CT is a tool that
> NSIS could use (as an optimisation).
>
> What's entirely unclear to me is what sort of tool CT is: is
> it a hammer or a screwdriver or a combination of the two? I
> guess this is more a question for the seamoby people, but we
> need to know the answer to know how to use it.
>
> More formally, there seem to be two extremes:
>
> a) NSIS is used for MN-AR resource (QoS) signalling, and
> AR-rest of world signalling; CT can be used to transfer state
> (both resource state and NSIS protocol state) between ARs at
> handover, but if this involves any MN-AR messages (e.g. CTIN)
> they aren't QoS related. NSIS-CT interaction can occur at the
> ARs to do state transfer at handover time.
>
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS
> context in the AR, which it can then later transfer to a new
> AR. NSIS is used to signal QoS for AR-rest of network.
> NSIS-CT interaction takes place at the AR to interwork flow
> setup and resource descriptions, and this interaction takes
> place at flow setup time. (Essentially, CT provides a QoS
> signalling protocol for the edge of the network, which NSIS
> would have to interwork with, in the same way that it has to
> interwork with RSVP/Intserv.)
>
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically
> assumes (b) so far as I can tell.
>
> I'm not trying to argue which of (a) or (b) is 'correct' at
> this stage, just establish that they are not the same. (And
> so we probably have to make a choice, although I suppose you
> could allow both models...)
>
> Cheers,
>
> Robert H.
>
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: 05 July 2002 10:05
> > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se
> > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > I see CT as an optimization only and not required for NSIS.
> > However, since
> > there is a tendency to support only on-path signaling, this
> > would not work
> > anyway (because CT would need off-path signaling for at least
> > some time).
> >
> > Marcus
> >
> > --On Donnerstag, 4. Juli 2002 11:33 +0300
> > john.loughney@nokia.com wrote:
> >
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
============================================================== 
========================== 
Permission is hereby granted to pass the contents of this 
communication to third parties and any restrictions regarding 
confidentiality do not apply.   

------_=_NextPart_001_01C22434.7ABEC65C-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 11:48:30 2002 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 LAA00599 for ; Fri, 5 Jul 2002 11:48:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09128 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 11:49:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08664; Fri, 5 Jul 2002 11:33:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08607 for ; Fri, 5 Jul 2002 11:33:44 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29806; Fri, 5 Jul 2002 11:32:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65FWl311631; Fri, 5 Jul 2002 11:32:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 11:32:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 11:32:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22439.366620D6" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22439.366620D6 Content-Type: text/plain; charset="iso-8859-1" Robert: I will have to read Cedric's draft. I wasn't aware that it discussed CT. With deference to Cedric, and what I am sure is a thoughtful analysis, it seems to me that understanding the relationship between CT and NSIS would require, at the very least, a CT solution, or something close to a CT solution. Clearly there is a difference of opinion as to what CT should be (the requirements draft is apparently going to go through another revision, so who knows?). In my view, if CT is in place, then NSIS should not be invoked as a result of a handover. A pretty simple relationship. The only exception that I can imagine is if there is some impact on a service that is not provided at an ANR (i.e. an AR or an internal router), then NSIS may be required to maintain that service. However, I could not name this service at this point. -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: July 5, 2002 10:59 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) hi gary, my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about). in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft. our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway). i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air. cheers, robert h. PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem. [gwk] I agree. I was not trying to be as much pessimistic, as I was pushing back against this concept that NSIS + LMM => Seamless Mobility. To be more precise, if it takes longer then a few 10s of ms to set up the new, conditioned path, then the handover will likely not be seamless in 3G. Signalling, particularly over the air (again, 3G), takes relatively significant amount of time to complete. 10s of ms is a rough approximation, but if you are running voice frames, more then, say 20ms of additional handover delay will start impinging on the service requirements for the voice - i.e. either frames have to be dropped or delayed beyond the performance constraint. It is difficult to pin down these numbers, particularly in an IETF email list, but any delay budget analysis that I have seen usually yields numbers in the stated range (keep in mind that delay/drop allowances have to be budgeted for other components of the access network and for the link layer handover). NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine, but given what I understand about what NSIS is, and is not, it can never be any where near as seamless as a solution that incorporates CT. Is CT simply an "optimization" - well, that depends on how much service disruption the user can tolerate. Usually, there is a threshold where the service is simply considered unusable. Cheers, Gary ------_=_NextPart_001_01C22439.366620D6 Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
Robert:
 
  I will have to read Cedric's draft. I wasn't aware that it discussed CT. With deference to Cedric, and what I am sure is a thoughtful
analysis, it seems to me that understanding the relationship between CT and NSIS would require, at the very least, a CT solution, or
something close to a CT solution. Clearly there is a difference of opinion as to what CT should be (the requirements draft is apparently
going to go through another revision, so who knows?).
 
  In my view, if CT is in place, then NSIS should not be invoked as a result of a handover. A pretty simple relationship. The only exception
that I can imagine is if there is some impact on a service that is not provided at an ANR (i.e. an AR or an internal router), then NSIS may
be required to maintain that service. However, I could not name this service at this point.
-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: July 5, 2002 10:59
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about).
in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem.
[gwk] I agree. I was not trying to be as much pessimistic, as I was pushing back against this concept that NSIS + LMM => Seamless Mobility. To be more precise,
if it takes longer then a few 10s of ms to set up the new, conditioned path, then the handover will likely not be seamless in 3G. Signalling, particularly over the
air (again, 3G), takes relatively significant amount of time to complete. 10s of ms is a rough approximation, but if you are running voice frames, more then, say
20ms of additional handover delay will start  impinging on the service requirements for the voice - i.e. either frames have to be dropped or delayed beyond
the performance constraint. It is difficult to pin down these numbers, particularly in an IETF email list, but any delay budget analysis that I have seen usually
yields numbers in the stated range (keep in mind that delay/drop allowances have to be budgeted for other components of the access network and for the
link layer handover).
 
NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine, but given what I understand about what NSIS is, and is not, it can never be
any where near as seamless as a solution that incorporates CT. Is CT simply an "optimization" - well, that depends on how much service disruption the user
can tolerate. Usually, there is a threshold where the service is simply considered unusable.
 
Cheers,
Gary
------_=_NextPart_001_01C22439.366620D6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 12:41:44 2002 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 MAA03470 for ; Fri, 5 Jul 2002 12:41:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12823 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 12:42:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12008; Fri, 5 Jul 2002 12:29:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11977 for ; Fri, 5 Jul 2002 12:29:23 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02941 for ; Fri, 5 Jul 2002 12:28:33 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id <31HZG9YP>; Fri, 5 Jul 2002 11:40:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: nsis@ietf.org Subject: RE: [NSIS] NSIS Agenda Date: Fri, 5 Jul 2002 11:40:47 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt This draft which I was to discuss at the IETF meeting has been superseded by a new version, -01.txt. Please refer to that version for the meeting. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 13:31:38 2002 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 NAA05655 for ; Fri, 5 Jul 2002 13:31:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15162 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 13:32:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14226; Fri, 5 Jul 2002 13:17:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14195 for ; Fri, 5 Jul 2002 13:17:25 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04924 for ; Fri, 5 Jul 2002 13:16:35 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65HGr317786 for ; Fri, 5 Jul 2002 13:16:54 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 13:16:53 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BE0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: cedric@iprg.nokia.com, Seamless Mobility Working Group , "'NSIS'" Subject: RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: C omments on draft-westphal-nsis-qos-mobileip-00.txt) Date: Fri, 5 Jul 2002 13:16:49 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Charlie: (I am cross posting this to NSIS to correct the misconception that I generated concerning the wg requirements. This will be my last cross post). > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 5, 2002 12:37 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: cedric@iprg.nokia.com; Seamless Mobility Working Group > Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: > [NSIS] Re: > Comments on draft-westphal-nsis-qos-mobileip-00.txt) > > > > Hello Gary, > > I was startled by a statement in your message: I didn't mean to startle you, honest... > > Gary Kenward wrote: > > > Indeed, if you examine the CT requirements, > > signalling from the MN to the access network is prohibited. > > What if the mobile node wants to tell the access network > that it's time to do a context transfer? Surely that's not > prohibited. If so, then this is a major problem with the > requirements draft and I just missed it. Well, can you elaborate on the "what if"? There has to be a purpose, and the situations that I can imagine the MN might want to perform such an action can be covered (better, IMHO) within the network (or between networks). I was incorrect concerning the wg requirements draft. There was a requirement in the draft at one time. It was removed simply because the controversy could not be resolved during requirements definition. I appologize for the confusion. However, there seems to be a growing belief, particularly within NSIS, that CT is MN centric. While I must concede that this option meets the requirements, it is by no means the best approach (IMHO), and at the very least, is not the wg consensus (at least, so far) and should not be represented as such. My main purpose of posting to the NSIS working group was to clarify this misconception, which was leading to further misconceptions of the relationship between CT and NSIS as bearer path signalling solutions. > > Besides that: > > > In your discussion of CT, you are presupposing a wg solution > > for CT that does not exist. The work on the CT protocol has > not begun > > in Seamoby. > > That's a pretty strong statement. We've done a lot of > work on a CT protocol, and we have tried to represent > that work in the [seamoby] group. Maybe you meant > that there isn't yet a working group document that > specifies any CT protocol. That is what I meant, of course. There are a number of us that have been working on CT solutions, some of us are waiting for the proper opportunity to submit drafts to the wg for consideration as wg solutions It is my understanding that these drafts cannot be considered until the requirements draft is approved, or, perhaps, until the wg chairs say so (I don't know which is the gating function). > > > > The > > reason being is that the sole purpose of CT is to enable a fast, > > smooth, > > seamless handover. Signalling over the air simply takes too > much time, > > > > and the value of signalling from MN to AR has never been clearly > > identified. > > If the mobile node is the only node that "knows" that > it's time to do the handover, then it has to use a few > bits to deliver the indication to one of the access routers. I am curious as to how the mobile node can be the only node that "knows". Since in order for an MN to "know" that there is a network to handover to, communications with the network must be possible, which means that the AP at the new network has to "know", *and* the MN has to know that the AP knows and visa versa. It is not a big step to assume that if the AP knows, the AR knows (this is the case for cellular networks). In addition, in order to complete a "seamless" handover between networks, the networks must have a trust relationship, and must be able to exchange information on accounting etc. Thus, there must be a communications path between the networks, at the very least. IEEE 802.11 APs currently do not support handover, but this is situation is being changed with a new standard for inter-AP signalling. Cheers, Gary > > > Regards, > Charlie P. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 5 14:07:34 2002 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 OAA07711 for ; Fri, 5 Jul 2002 14:07:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17342 for nsis-archive@odin.ietf.org; Fri, 5 Jul 2002 14:08:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15776; Fri, 5 Jul 2002 13:46:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15747 for ; Fri, 5 Jul 2002 13:46:13 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06283 for ; Fri, 5 Jul 2002 13:45:22 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05521; Fri, 5 Jul 2002 10:45:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g65HjeE26748; Fri, 5 Jul 2002 10:45:40 -0700 X-mProtect: <200207051745> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGUhSRO; Fri, 05 Jul 2002 10:45:38 PDT Message-ID: <3D25DAEA.209AC28A@iprg.nokia.com> Date: Fri, 05 Jul 2002 10:44:10 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: Seamless Mobility Working Group , "'NSIS'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BE0@zcard031.ca.nortel.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, Gary Kenward wrote: > > What if the mobile node wants to tell the access network > > that it's time to do a context transfer? Surely that's not > > prohibited. If so, then this is a major problem with the > > requirements draft and I just missed it. > > Well, can you elaborate on the "what if"? There has to be a purpose, > and the situations that I can imagine the MN might want to perform > such an action can be covered (better, IMHO) within the network > (or between networks). Suppose the mobile node hears an advertisement from a new access router, and wants to ask its old access router to transfer some context. That is something we should allow. > I am curious as to how the mobile node can be the only node that > "knows". Since in order for an MN to "know" that there is a network > to handover to, communications with the network must be possible, > which means that the AP at the new network has to "know", *and* > the MN has to know that the AP knows and visa versa. It is not > a big step to assume that if the AP knows, the AR knows (this is > the case for cellular networks). It is a big step. What about my example above? The handover could be between different physical media. IP provides a nice communications path, but it may not be profitable to spend a lot of time trying to define "the network" in this case. Regards, Charlie P. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jul 7 12:28:01 2002 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 MAA25081 for ; Sun, 7 Jul 2002 12:28:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12762 for nsis-archive@odin.ietf.org; Sun, 7 Jul 2002 12:28:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12060; Sun, 7 Jul 2002 12:10:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12028 for ; Sun, 7 Jul 2002 12:10:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24164; Sun, 7 Jul 2002 12:10:03 -0400 (EDT) Message-Id: <200207071610.MAA24164@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: Sun, 07 Jul 2002 12:10:03 -0400 Subject: [NSIS] I-D ACTION:draft-tschofenig-nsis-threats-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS Threats Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-threats-01.txt Pages : 12 Date : 05-Jul-02 As the work in the NSIS working has begun to describe requirements and the framework people started thinking about possible security implication. This document should provide a starting point for the discussion at the NSIS working group mailing list regarding the security issues that have to be addressed by a protocol or within the framework. This document does not describe vulnerabilities of a particular protocol or threats of published NSIS framework proposals. This memo is furthermore meant to create awareness for security issues within the NSIS group. Security requirements related to the threat scenarios are described in [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.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-tschofenig-nsis-threats-01.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-tschofenig-nsis-threats-01.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: <20020705141906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-nsis-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-nsis-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141906.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 05:08:33 2002 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 FAA08554 for ; Mon, 8 Jul 2002 05:08:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03907 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 05:09:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02744; Mon, 8 Jul 2002 04:53:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02713 for ; Mon, 8 Jul 2002 04:53:47 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08312 for ; Mon, 8 Jul 2002 04:52:53 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g688qHRb012247; Mon, 8 Jul 2002 10:52:17 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKTS3LY; Mon, 8 Jul 2002 10:52:17 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:46:32 +0200 Message-ID: X-Sybari-Trust: 63511e1a 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Mon, 8 Jul 2002 10:52:08 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John Please see some remarks in line (moreover please note that I meant RFC2992 and not RFC2993): > Comment_1: general: > There are many requirements that are affected by the fact > that NSIS will have > to concentrate mainly on the in-band (in-path case). > What should we do with them? maybe list them as optional and > to be done in the future? [john] I think that we need to seperate off-path requirements from the main [john] document. In my opinion, these are non-requirements for the current [john] charter. I would support moving these into an appendix, [john] which discusses off-path signaling. [georgios] Agree! However, I am open also to other solutions > I propose to use the terms given in draft-hancock-nsis-fw-00.txt > regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder > (instead of QoS Controller) and NSIS Responder. This applies also > for other additional terms that are > included into draft-hancock-nsis-fw-00.txt and are not > included into the requirements draft. [john] I support this, but I think we should have some WG discussion on this. [georgios] agree! > Please remove or signifficantly modify bullet 2: > "We see the network at the level of domains/subdomains rather > than individual routers ...... Aggregation can also take > place at subdomain boundaries." > > The reasonsof asking this are: > * not each domain but any router that implements a QoS > controller or QoS initiator can use NSIS signaling; > * It is contradictory with bullet 4 (of the same > section) that mentions: > " Each router on the data path implements a QoS > controller and QoS initiator." [john] I don't see your point. If we are signaling for some 'NSIS [john] resource' - does each router on the path suply this resource, [john] is it aggregated or not? We are not designing a specific [john] host to router, or router to router protocol; in my opinion [john] we are doing something a bit broader. However, what we do [john] may be applicable to this. [georgios] good point! What about changing bullet 2 in Section 3 as follows (adding a paragraph at the end of bullet 2): "2. We 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. Subdomains are introduced to allow the fact a given QoS provisioning mechanism may only be used within a part of a domain, typically for a particular subnetwork technology boundary. Aggregation can also take place at subdomain boundaries. However, each router on the data path may implement a QoS controller and/or QoS initiator and therefore, any router on the data path may use the NSIS signalling." > Comment_4: Section 4.1: Assumptions and exclusions (Page 11): > > Bullet 6: > Please change the text: > "NSIS assumes to operate with networks using standard > ("normal") L3 routing" > > INTO > > "NSIS assumes to operate with networks using standard > ("normal") L3 routing as described in RFC 2993." [john] I am perplexed at this reference - 2993 is "Architectural Implications [john] of NAT" - what does this have to do with NSIS? [georgios] I am very sorry, I meant RFC2992,"Analysis of an Equal-Cost [georgios] Multi-Path Algorithm", located at: http://www.ietf.org/rfc/rfc2992.txt?number=2992 Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 05:20:54 2002 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 FAA08803 for ; Mon, 8 Jul 2002 05:20:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04293 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 05:21:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03877; Mon, 8 Jul 2002 05:07:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03842 for ; Mon, 8 Jul 2002 05:07:56 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08546 for ; Mon, 8 Jul 2002 05:07:02 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6896XRb016316; Mon, 8 Jul 2002 11:07:53 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKTS4JP; Mon, 8 Jul 2002 11:06:33 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 11:06:32 +0200 Message-ID: X-Sybari-Trust: d53f942f 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Mon, 8 Jul 2002 11:06:22 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please see my remarks in line: > I think that we need to seperate off-path requirements from the main > document. In my opinion, these are non-requirements for the current > charter. I would support moving these into an appendix, > which discusses off-path signaling. [marcus] I still don't see what problem people have with off-path signaling (and I [marcus] would call tunneling off-path as well). If the working group agrees to [marcus] remove some of the req fine, let me know which ones. [georgios] well we do not have to remove them, but we have to emphasise that [georgios] they are very optional. John propsed to move thaem in an appendix. [georgios] If you want I can make a list with them. > >> I propose to use the terms given in draft-hancock-nsis-fw-00.txt >> regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder >> (instead of QoS Controller) and NSIS Responder. This applies also >> for other additional terms that are >> included into draft-hancock-nsis-fw-00.txt and are not >> included into the requirements draft. > > [john] I support this, but I think we should have some WG discussion on > [john] this. [marcus] Yes, sure, but I can a that point in time not rely on a personal [marcus] submission. And the terms showed up first in the req draft. I agree that [marcus] there are good reasons to change them, but we need consensus on that. [georgios] agree, we should have a consensus on that! >> Please remove or signifficantly modify bullet 2: >> "We see the network at the level of domains/subdomains rather >> than individual routers ...... Aggregation can also take >> place at subdomain boundaries." >> >> The reasonsof asking this are: >> * not each domain but any router that implements a QoS >> controller or QoS initiator can use NSIS signaling; >> * It is contradictory with bullet 4 (of the same >> section) that mentions: >> " Each router on the data path implements a QoS >> controller and QoS initiator." > [john]> I don't see your point. If we are signaling for some 'NSIS [john]> resource' - does each router on the path suply this resource, [john]> is it aggregated or not? We are not designing a specific [john]> host to router, or router to router protocol; in my opinion [john]> we are doing something a bit broader. However, what we do [john]> may be applicable to this. > [marcus]I don't understand georgios point but I think we need to modify section 3 [marcus] anyway (or even remove it, because most of the stuff is framework related. [georgios] What about the last proposal that I sent as reply to John's e-mail. >> Comment_4: Section 4.1: Assumptions and exclusions (Page 11): >> >> Bullet 6: >> Please change the text: >> "NSIS assumes to operate with networks using standard >> ("normal") L3 routing" >> >> INTO >> >> "NSIS assumes to operate with networks using standard >> ("normal") L3 routing as described in RFC 2993." > [john]> I am perplexed at this reference - 2993 is "Architectural Implications [john]> of NAT" - what does this have to do with NSIS? [marcus] Here I don't want to include any reference, The fuzzyness is on purpose. [marcus] If you start talking about NATs this might be an issue for NSIS, whether [marcus] NSIS must work over NATs or not or don't care. [georgios] I am very sorry, I meant RFC2992,"Analysis of an Equal-Cost [georgios] Multi-Path Algorithm", located at: http://www.ietf.org/rfc/rfc2992.txt?number=2992 Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 05:28:34 2002 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 FAA08889 for ; Mon, 8 Jul 2002 05:28:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04449 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 05:29:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03665; Mon, 8 Jul 2002 05:03:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03600 for ; Mon, 8 Jul 2002 05:03:06 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08447; Mon, 8 Jul 2002 05:02:13 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g688RwI96995; Mon, 8 Jul 2002 10:27:58 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA19353; Mon, 8 Jul 2002 10:28:16 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AFE0651C48; Mon, 8 Jul 2002 10:27:56 +0200 (CEST) Date: Mon, 08 Jul 2002 10:28:15 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Gary Kenward , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Message-ID: <1534506.1026124095@[192.168.102.207]> In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com > X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. A pretty simple relationship. The only exception > that I can imagine is if there is some impact on a service that is not > provided at an ANR (i.e. an AR or an internal router), then NSIS may be > required to maintain that service. However, I could not name this service > at this point. I don't see how CT can work without NSIS in the general case. If all your AR are connected to the swame next hop router, it may work. Generally, you might need to signal to the far end after handover. Marcus > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 10:59 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > hi gary, > > my comments are purely on draft-westphal-nsis-qos-mobileip and associated > email discussions (since that's been the only input I have seen recently > which explicitly discusses the relationship between CT and NSIS, and > which I had worries about). in particular, any comments I make about > MN-AR signalling are really to emphasise the difference between the cases > of a) not having CT signalling that carries QoS information MN-AR (if > there is or isn't other CT signalling I don't really care), and b) > having CT signalling that does carry QoS information MN-AR, which seems > to be the assumption of the mentioned draft. > our recent framework activities assumed (a). if you're saying that the > seamoby w.g. requirements also impose (a), that's fine by me. i also > don't want to re-open old discussions (certainly not on the nsis list, > anyway). > i suspect we're basically in agreement about NSIS/CT relationships: after > a handover, if CT happened, it should be possible to have less NSIS > signalling on the on-path segment which goes over the air. > cheers, > > robert h. > > PS referring to a previous email, i think the view that NSIS is "likely > to be of limited use in mobility situations" is rather pessimistic. i > would rather say that if you want the resources signalled for by NSIS to > be available seamlessly over handovers, you'll need something else as > well, which could be CT. the basic point seems to be that NSIS shouldn't > try to solve the cross-path context/state transfer problem - any more > than CT should try to solve the along-path context/state establishment > problem. [gwk] I agree. I was not trying to be as much pessimistic, as I > was pushing back against this concept that NSIS + LMM => Seamless > Mobility. To be more precise, if it takes longer then a few 10s of ms to > set up the new, conditioned path, then the handover will likely not be > seamless in 3G. Signalling, particularly over the air (again, 3G), takes > relatively significant amount of time to complete. 10s of ms is a rough > approximation, but if you are running voice frames, more then, say 20ms > of additional handover delay will start impinging on the service > requirements for the voice - i.e. either frames have to be dropped or > delayed beyond the performance constraint. It is difficult to pin down > these numbers, particularly in an IETF email list, but any delay budget > analysis that I have seen usually yields numbers in the stated range > (keep in mind that delay/drop allowances have to be budgeted for other > components of the access network and for the link layer handover). > > NSIS + LMM (or some variant of MIP) might be one approach to mobility. > Fine, but given what I understand about what NSIS is, and is not, it can > never be any where near as seamless as a solution that incorporates CT. > Is CT simply an "optimization" - well, that depends on how much service > disruption the user can tolerate. Usually, there is a threshold where > the service is simply considered unusable. > Cheers, > Gary > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 06:45:24 2002 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 GAA09902 for ; Mon, 8 Jul 2002 06:45:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08129 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 06:46:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07627; Mon, 8 Jul 2002 06:31:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07598 for ; Mon, 8 Jul 2002 06:31:22 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09655 for ; Mon, 8 Jul 2002 06:30:28 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g68A4TI06500; Mon, 8 Jul 2002 12:04:29 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA20404; Mon, 8 Jul 2002 12:04:28 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D258B52056; Mon, 8 Jul 2002 12:04:27 +0200 (CEST) Date: Mon, 08 Jul 2002 12:04:28 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Message-ID: <7326334.1026129868@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Georgios, Yes, please make a list and post it to the list. We can discuss it. Evenso, myself and John (if I understood him right) think the req are not containing any point which are off-path specific. But corr4ect me if you find some. Marcus --On Montag, 8. Juli 2002 11:06 +0200 "Georgios Karagiannis (ELN)" wrote: > > Hi Marcus > Please see my remarks in line: > >> I think that we need to seperate off-path requirements from the main >> document. In my opinion, these are non-requirements for the current >> charter. I would support moving these into an appendix, >> which discusses off-path signaling. > > [marcus] I still don't see what problem people have with off-path > signaling (and I [marcus] would call tunneling off-path as well). If the > working group agrees to [marcus] remove some of the req fine, let me > know which ones. > > [georgios] well we do not have to remove them, but we have to emphasise > that [georgios] they are very optional. John propsed to move thaem in an > appendix. [georgios] If you want I can make a list with them. > >> >>> I propose to use the terms given in draft-hancock-nsis-fw-00.txt >>> regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder >>> (instead of QoS Controller) and NSIS Responder. This applies also >>> for other additional terms that are >>> included into draft-hancock-nsis-fw-00.txt and are not >>> included into the requirements draft. >> >> [john] I support this, but I think we should have some WG discussion on >> [john] this. > > [marcus] Yes, sure, but I can a that point in time not rely on a personal > [marcus] submission. And the terms showed up first in the req draft. I > agree that [marcus] there are good reasons to change them, but we need > consensus on that. [georgios] agree, we should have a consensus on that! > > >>> Please remove or signifficantly modify bullet 2: >>> "We see the network at the level of domains/subdomains rather >>> than individual routers ...... Aggregation can also take >>> place at subdomain boundaries." >>> >>> The reasonsof asking this are: >>> * not each domain but any router that implements a QoS >>> controller or QoS initiator can use NSIS signaling; >>> * It is contradictory with bullet 4 (of the same >>> section) that mentions: >>> " Each router on the data path implements a QoS >>> controller and QoS initiator." >> > [john]> I don't see your point. If we are signaling for some 'NSIS > [john]> resource' - does each router on the path suply this resource, > [john]> is it aggregated or not? We are not designing a specific > [john]> host to router, or router to router protocol; in my opinion > [john]> we are doing something a bit broader. However, what we do > [john]> may be applicable to this. >> > [marcus]I don't understand georgios point but I think we need to modify > section 3 [marcus] anyway (or even remove it, because most of the stuff > is framework related. > > [georgios] What about the last proposal that I sent as reply to John's > e-mail. > > >>> Comment_4: Section 4.1: Assumptions and exclusions (Page 11): >>> >>> Bullet 6: >>> Please change the text: >>> "NSIS assumes to operate with networks using standard >>> ("normal") L3 routing" >>> >>> INTO >>> >>> "NSIS assumes to operate with networks using standard >>> ("normal") L3 routing as described in RFC 2993." >> > [john]> I am perplexed at this reference - 2993 is "Architectural > Implications [john]> of NAT" - what does this have to do with NSIS? > > [marcus] Here I don't want to include any reference, The fuzzyness is on > purpose. > > [marcus] If you start talking about NATs this might be an issue for NSIS, > whether [marcus] NSIS must work over NATs or not or don't care. > > [georgios] I am very sorry, I meant RFC2992,"Analysis of an Equal-Cost > [georgios] Multi-Path Algorithm", located at: > http://www.ietf.org/rfc/rfc2992.txt?number=2992 > > Best Regards, > Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 09:20:37 2002 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 JAA13597 for ; Mon, 8 Jul 2002 09:20:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15760 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 09:21:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14894; Mon, 8 Jul 2002 09:04:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14867 for ; Mon, 8 Jul 2002 09:04:40 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12791 for ; Mon, 8 Jul 2002 09:03:44 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68D36Rb015086; Mon, 8 Jul 2002 15:04:26 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHMVZGXZ; Mon, 8 Jul 2002 15:03:06 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 15:03:06 +0200 Message-ID: X-Sybari-Trust: 8e2b3f69 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Mon, 8 Jul 2002 15:02:58 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus In my opinion, the main requirements that are affected by the in-path and out of path discussions are: * Requirement 5.2.2: "No constraint of the QoS signaling Controllers to be in the data path" You could remove this requirement! * Requirement 5.7.2: "Flexibility in the placement of the QoS initiator" In my opinion the way of how the network initiated reservations are explained ion this section, are mainly out of path. Please remove the sentence that describes network initiated reservations. * Requirement 5.7.3: "Flexibility in the initiation of re-negotiation (QoS change requests)" In my opinion the way of how the network initiated reservations are explained ion this section, are mainly out of path. Please remove the sentence that describes network initiated reservations. Best regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Monday, July 08, 2002 12:04 PM To: Georgios Karagiannis (ELN); john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Georgios, Yes, please make a list and post it to the list. We can discuss it. Evenso, myself and John (if I understood him right) think the req are not containing any point which are off-path specific. But corr4ect me if you find some. Marcus --On Montag, 8. Juli 2002 11:06 +0200 "Georgios Karagiannis (ELN)" wrote: > > Hi Marcus > Please see my remarks in line: > >> I think that we need to seperate off-path requirements from the main >> document. In my opinion, these are non-requirements for the current >> charter. I would support moving these into an appendix, >> which discusses off-path signaling. > > [marcus] I still don't see what problem people have with off-path > signaling (and I [marcus] would call tunneling off-path as well). If the > working group agrees to [marcus] remove some of the req fine, let me > know which ones. > > [georgios] well we do not have to remove them, but we have to emphasise > that [georgios] they are very optional. John propsed to move thaem in an > appendix. [georgios] If you want I can make a list with them. > >> >>> I propose to use the terms given in draft-hancock-nsis-fw-00.txt >>> regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder >>> (instead of QoS Controller) and NSIS Responder. This applies also >>> for other additional terms that are >>> included into draft-hancock-nsis-fw-00.txt and are not >>> included into the requirements draft. >> >> [john] I support this, but I think we should have some WG discussion on >> [john] this. > > [marcus] Yes, sure, but I can a that point in time not rely on a personal > [marcus] submission. And the terms showed up first in the req draft. I > agree that [marcus] there are good reasons to change them, but we need > consensus on that. [georgios] agree, we should have a consensus on that! > > >>> Please remove or signifficantly modify bullet 2: >>> "We see the network at the level of domains/subdomains rather >>> than individual routers ...... Aggregation can also take >>> place at subdomain boundaries." >>> >>> The reasonsof asking this are: >>> * not each domain but any router that implements a QoS >>> controller or QoS initiator can use NSIS signaling; >>> * It is contradictory with bullet 4 (of the same >>> section) that mentions: >>> " Each router on the data path implements a QoS >>> controller and QoS initiator." >> > [john]> I don't see your point. If we are signaling for some 'NSIS > [john]> resource' - does each router on the path suply this resource, > [john]> is it aggregated or not? We are not designing a specific > [john]> host to router, or router to router protocol; in my opinion > [john]> we are doing something a bit broader. However, what we do > [john]> may be applicable to this. >> > [marcus]I don't understand georgios point but I think we need to modify > section 3 [marcus] anyway (or even remove it, because most of the stuff > is framework related. > > [georgios] What about the last proposal that I sent as reply to John's > e-mail. > > >>> Comment_4: Section 4.1: Assumptions and exclusions (Page 11): >>> >>> Bullet 6: >>> Please change the text: >>> "NSIS assumes to operate with networks using standard >>> ("normal") L3 routing" >>> >>> INTO >>> >>> "NSIS assumes to operate with networks using standard >>> ("normal") L3 routing as described in RFC 2993." >> > [john]> I am perplexed at this reference - 2993 is "Architectural > Implications [john]> of NAT" - what does this have to do with NSIS? > > [marcus] Here I don't want to include any reference, The fuzzyness is on > purpose. > > [marcus] If you start talking about NATs this might be an issue for NSIS, > whether [marcus] NSIS must work over NATs or not or don't care. > > [georgios] I am very sorry, I meant RFC2992,"Analysis of an Equal-Cost > [georgios] Multi-Path Algorithm", located at: > http://www.ietf.org/rfc/rfc2992.txt?number=2992 > > Best Regards, > Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ 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 daemon@optimus.ietf.org Mon Jul 8 09:27:08 2002 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 JAA13744 for ; Mon, 8 Jul 2002 09:27:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16053 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 09:27:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15404; Mon, 8 Jul 2002 09:14:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15377 for ; Mon, 8 Jul 2002 09:14:13 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13271 for ; Mon, 8 Jul 2002 09:13:18 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68DE4Rc017715; Mon, 8 Jul 2002 15:14:04 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKTVQ0Y; Mon, 8 Jul 2002 15:14:04 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 15:14:04 +0200 Message-ID: X-Sybari-Trust: c705f37d 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'Cedric Westphal'" , hemant.chaskar@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] QoS framework. Date: Mon, 8 Jul 2002 15:14:00 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cedric and Hemant I have read your draft. In my opinion this draft is too much oriented on seamoby and mobileip WG solutions. In the draft "draft-hancock-nsis-fw-00.txt" we describe similar mobility issues to what you tried to describe in your draft, but we presented the solutions in a more general way without excluding other solutions then seamoby and mobileip WG like solutions. Probably this draft is more suitable to be used as a solution specific draft. In my opinion the framework draft should be open to more than one type of solutions. Best Regards, Georgios -----Original Message----- From: Cedric Westphal [mailto:cedric@iprg.nokia.com] Sent: Monday, June 24, 2002 7:47 PM To: nsis@ietf.org Cc: hemant.chaskar@nokia.com Subject: [NSIS] QoS framework. Hi all, we put together a document representing our perspective on a NSIS qos signaling framework. Here is the abstract: Abstract This draft provides a framework for QoS signaling that is optimized for Mobile IP handoffs. It covers the horizontal signaling between access routers (ARs) as well as the vertical signaling along the packet data path, both of which are triggered by handoff of mobile node (MN). The key design goals are wireless bandwidth economy, fast QoS establishment along the new data path after handoff and secure protocol operation. The document will eventually be available from the i-d editor queue. However, only after Yokohama meeting. You can find it at: http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt in the meantime. Please send your comments, Cedric & Hemant. _______________________________________________ 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 daemon@optimus.ietf.org Mon Jul 8 09:55:37 2002 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 JAA14800 for ; Mon, 8 Jul 2002 09:55:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17977 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 09:56:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17252; Mon, 8 Jul 2002 09:40:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17219 for ; Mon, 8 Jul 2002 09:40:45 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14140 for ; Mon, 8 Jul 2002 09:39:53 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68DeBRb024780; Mon, 8 Jul 2002 15:40:11 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKTV673; Mon, 8 Jul 2002 15:40:11 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 15:40:11 +0200 Message-ID: X-Sybari-Trust: fda70543 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'Shahrier, Sharif M.'" , "'nsis@ietf.org'" Date: Mon, 8 Jul 2002 15:40:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA17220 Subject: [NSIS] Comments on draft-shahrier-nsis-framework-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif I have read your draft located at: http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-01.txt Actually I am very confused. In bullet 6) you mention: " 6) The Acceptance message follows the same path that carried the Setup message from the Originator end point. The Acceptanceö message carries the final resources that are needed to be installed in the various hops along the signaling route." Do you mean that the bi-directional reservation, i.e., reservation from "Originator" to "Terminator" and reservation from "Terminator" to "Originator", will be initiated and maintained on the same routing path. But how will you then enforce that the user data packets that are travelling from "Terminator" to "Originator" will follow exactly the same routing path as the user data packets that are travelling from "Originator" to "Terminator". Best Regards, Georgios -----Original Message----- From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: Friday, July 05, 2002 5:41 PM To: nsis@ietf.org Subject: RE: [NSIS] NSIS Agenda A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt This draft which I was to discuss at the IETF meeting has been superseded by a new version, -01.txt. Please refer to that version for the meeting. Sharif. _______________________________________________ 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 09:58:04 2002 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 JAA14876 for ; Mon, 8 Jul 2002 09:58:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18053 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 09:58:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17093; Mon, 8 Jul 2002 09:37:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16997 for ; Mon, 8 Jul 2002 09:37:42 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14045 for ; Mon, 8 Jul 2002 09:36:50 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68DbdRb024248; Mon, 8 Jul 2002 15:37:39 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKTV50G; Mon, 8 Jul 2002 15:37:39 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 15:37:39 +0200 Message-ID: X-Sybari-Trust: 55381578 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'Shahrier, Sharif M.'" , nsis@ietf.org Subject: RE: [NSIS] NSIS Agenda Date: Mon, 8 Jul 2002 15:37:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA16998 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif I have read your draft located at: http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-01.txt Actually I am very confused. In bullet 6) you mention: " 6) The Acceptance message follows the same path that carried the Setup message from the Originator end point. The Acceptanceö message carries the final resources that are needed to be installed in the various hops along the signaling route." Do you mean that the bi-directional reservation, i.e., reservation from "Originator" to "Terminator" and reservation from "Terminator" to "Originator", will be initiated and maintained on the same routing path. But how will you then enforce that the user data packets that are travelling from "Terminator" to "Originator" will follow exactly the same routing path as the user data packets that are travelling from "Originator" to "Terminator". Best Regards, Georgios -----Original Message----- From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: Friday, July 05, 2002 5:41 PM To: nsis@ietf.org Subject: RE: [NSIS] NSIS Agenda A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-00.txt This draft which I was to discuss at the IETF meeting has been superseded by a new version, -01.txt. Please refer to that version for the meeting. Sharif. _______________________________________________ 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 daemon@optimus.ietf.org Mon Jul 8 10:50:40 2002 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 KAA17614 for ; Mon, 8 Jul 2002 10:50:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21858 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 10:51:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19244; Mon, 8 Jul 2002 10:17:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19196 for ; Mon, 8 Jul 2002 10:17:39 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15923; Mon, 8 Jul 2002 10:16:47 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA15938; Mon, 8 Jul 2002 07:17:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68EH4t26649; Mon, 8 Jul 2002 07:17:04 -0700 X-mProtect: <200207081417> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxpq7Th; Mon, 08 Jul 2002 07:17:02 PDT Message-ID: <3D299E8D.9E31EFD2@iprg.nokia.com> Date: Mon, 08 Jul 2002 07:15:41 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, I have a comment on another point in your earlier message. Gary Kenward wrote: > In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. Suppose a handover has occurred, and some QoS has been negotiated via CT between two access routers to support the mobile node at the new access routers. This could involve having the new router making sure it has sufficient capacity to support the mobile device, and making sure that the tunnel between the two routers can be managed with small enough delay. Then, after the handover is complete, it might be better to renegotiate QoS so that the previous access router no longer was required to maintain the excess capacity needed to serve the tunnel to the new access router. This could involve signaling so that packets are routed directly to the new access router, presumably with some QoS negotiation. This could involve NSIS. Thus, I don't agree with your statement above. But I am willing to agree that CT should not necessarily be intertwined with NSIS. Regards, Charlie P. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 10:57:04 2002 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 KAA17906 for ; Mon, 8 Jul 2002 10:57:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22086 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 10:57:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21132; Mon, 8 Jul 2002 10:38:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21070 for ; Mon, 8 Jul 2002 10:37:57 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17001; Mon, 8 Jul 2002 10:37:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Eb3I09546; Mon, 8 Jul 2002 10:37:03 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:37:02 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BE9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: nsis@ietf.org, "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: C omments on draft-westphal-nsis-qos-mobileip-00.txt) Date: Mon, 8 Jul 2002 10:36:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268C.E78AED56" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268C.E78AED56 Content-Type: text/plain; charset="iso-8859-1" Charlie: I guess the word "negotiate" really trips me up here. CT is a protocol for transferring forwarding service context, not for negotiating services between ARs. If service negotiation is required, then NSIS could be the protocol to be used. In my statement that you quote below, I used the words "should not": in the normal course of a handover, service negotiation must be rare. Negotiation, by definition, takes time, and anything that takes time will generally delay the service from being supported at the new AR. In the normal course of a handover, less signalling is always better. In wireless, of course, the exception is the rule, and so there must be contingencies for service negotiation. This would be NSIS' role. And so, I did not make my point clear. My main intent was to emphasize that if there is a link between CT and NSIS, it is a very simple one: if CT fails to provide a context that is useable by the new AR, then NSIS may be used to negotiate a suitable service with the network (and thus establish suitable context at the new AR). Cheers, Gary > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 8, 2002 10:16 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org; 'seamoby@ietf.org' > Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: > [NSIS] Re: > Comments on draft-westphal-nsis-qos-mobileip-00.txt) > > > > Hello Gary, > > I have a comment on another point in your earlier message. > > Gary Kenward wrote: > > > In my view, if CT is in place, then NSIS should not be invoked as a > > result of a handover. > > Suppose a handover has occurred, and some QoS has been negotiated > via CT between two access routers to support the mobile node > at the new > access routers. This could involve having the new router making sure > it has sufficient capacity to support the mobile device, and > making sure > > that the tunnel between the two routers can be managed with small > enough delay. > > Then, after the handover is complete, it might be better to > renegotiate > QoS so that the previous access router no longer was required to > maintain the excess capacity needed to serve the tunnel to the new > access router. This could involve signaling so that packets are > routed directly to the new access router, presumably with some QoS > negotiation. This could involve NSIS. > > Thus, I don't agree with your statement above. But I am willing to > agree > that CT should not necessarily be intertwined with NSIS. > > Regards, > Charlie P. > > > > > > > ------_=_NextPart_001_01C2268C.E78AED56 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt)

Charlie:

  I guess the word "negotiate" really trips me up here. CT is a
protocol for transferring forwarding service context, not for negotiating
services between ARs. If service negotiation is required, then NSIS could be
the protocol to be used.

  In my statement that you quote below, I used the words "should not": in
the normal course of a handover, service negotiation must be rare. Negotiation,
by definition, takes time, and anything that takes time will generally delay
the service from being supported at the new AR. In the normal course of a handover,
less signalling is always better.

  In wireless, of course, the exception is the rule, and so there must be
contingencies for service negotiation. This would be NSIS' role.

  And so, I did not make my point clear. My main intent was to emphasize that
if there is a link between CT and NSIS, it is a very simple one: if CT fails
to provide a context that is useable by the new AR, then NSIS may be used to
negotiate a suitable service with the network (and thus establish suitable
context at the new AR).

Cheers,
Gary


> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 8, 2002 10:16
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org; 'seamoby@ietf.org'
> Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE:
> [NSIS] Re:
> Comments on draft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
> Hello Gary,
>
> I have a comment on another point in your earlier message.
>
> Gary Kenward wrote:
>
> > In my view, if CT is in place, then NSIS should not be invoked as a
> > result of a handover.
>
> Suppose a handover has occurred, and some QoS has been negotiated
> via CT between two access routers to support the mobile node
> at the new
> access routers.  This could involve having the new router making sure
> it has sufficient capacity to support the mobile device, and
> making sure
>
> that the tunnel between the two routers can be managed with small
> enough delay.
>
> Then, after the handover is complete, it might be better to
> renegotiate
> QoS so that the previous access router no longer was required to
> maintain the excess capacity needed to serve the tunnel to the new
> access router.  This could involve signaling so that packets are
> routed directly to the new access router, presumably with some QoS
> negotiation.  This could involve NSIS.
>
> Thus, I don't agree with your statement above.  But I am willing to
> agree
> that CT should not necessarily be intertwined with NSIS.
>
> Regards,
> Charlie P.
>
>
>
> >
>
>

------_=_NextPart_001_01C2268C.E78AED56-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 11:13:12 2002 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 LAA18800 for ; Mon, 8 Jul 2002 11:13:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23649 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 11:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22281; Mon, 8 Jul 2002 10:58:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22118 for ; Mon, 8 Jul 2002 10:58:19 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17918; Mon, 8 Jul 2002 10:57:25 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68EtxI11578; Mon, 8 Jul 2002 10:55:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:55:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Mon, 8 Jul 2002 10:55:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268F.7DD7EA5A" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/plain; charset="iso-8859-1" Marcus: If I understand your comment, I believe there are two responses: first, CT need not be confined to context transfers between ARs, although this is definitely the most straightforward application of CT; second, and probably most important, there are access network solutions that do not require services to be established at the IR on a per flow basis - the per flow management happens only at the edges. It is worth noting that if NSIS *is* required to negotiate services between the MN and any ANR for every handover, then CT is not needed (if an IR must be signalled from the MN, then the AR will receive the signalling first; if ARs are signalling each other using NSIS, then why bother with CT?). I emphasize, again, that building signalling into each and every handover, particularly at the IP layer, is not conducive to seamless handover. It is very difficult to make a case for this assertion without discussing numbers - hopefully it is enough to observe that any exchange of information between the MN and the AN during or after a handover has a great potential for disrupting the service, particularly if resource allocations are delayed. I am not sure of what you mean by the "far end": are you suggesting end-to- end signalling with each handover? Or, by far end do you mean the AN to core network edge? If so for what purpose? Is there an edge based approach that would eliminated the need for access edge to "far edge" signalling with each handover? Regards, Gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: July 8, 2002 04:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > In my view, if CT is in place, then NSIS should not be > invoked as a > > result of a handover. A pretty simple relationship. The > only exception > > that I can imagine is if there is some impact on a service > that is not > > provided at an ANR (i.e. an AR or an internal router), then > NSIS may be > > required to maintain that service. However, I could not > name this service > > at this point. > > I don't see how CT can work without NSIS in the general case. > If all your > AR are connected to the swame next hop router, it may work. > Generally, you > might need to signal to the far end after handover. > > Marcus > > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: July 5, 2002 10:59 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > > john.loughney@nokia.com; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > hi gary, > > > > my comments are purely on draft-westphal-nsis-qos-mobileip > and associated > > email discussions (since that's been the only input I have > seen recently > > which explicitly discusses the relationship between CT and NSIS, and > > which I had worries about). in particular, any comments I > make about > > MN-AR signalling are really to emphasise the difference > between the cases > > of a) not having CT signalling that carries QoS > information MN-AR (if > > there is or isn't other CT signalling I don't really care), and b) > > having CT signalling that does carry QoS information MN-AR, > which seems > > to be the assumption of the mentioned draft. > > our recent framework activities assumed (a). if you're > saying that the > > seamoby w.g. requirements also impose (a), that's fine by me. i also > > don't want to re-open old discussions (certainly not on the > nsis list, > > anyway). > > i suspect we're basically in agreement about NSIS/CT > relationships: after > > a handover, if CT happened, it should be possible to have less NSIS > > signalling on the on-path segment which goes over the air. > > cheers, > > > > robert h. > > > > PS referring to a previous email, i think the view that > NSIS is "likely > > to be of limited use in mobility situations" is rather > pessimistic. i > > would rather say that if you want the resources signalled > for by NSIS to > > be available seamlessly over handovers, you'll need > something else as > > well, which could be CT. the basic point seems to be that > NSIS shouldn't > > try to solve the cross-path context/state transfer problem > - any more > > than CT should try to solve the along-path context/state > establishment > > problem. [gwk] I agree. I was not trying to be as much > pessimistic, as I > > was pushing back against this concept that NSIS + LMM => Seamless > > Mobility. To be more precise, if it takes longer then a > few 10s of ms to > > set up the new, conditioned path, then the handover will > likely not be > > seamless in 3G. Signalling, particularly over the air > (again, 3G), takes > > relatively significant amount of time to complete. 10s of > ms is a rough > > approximation, but if you are running voice frames, more > then, say 20ms > > of additional handover delay will start impinging on the service > > requirements for the voice - i.e. either frames have to be > dropped or > > delayed beyond the performance constraint. It is difficult > to pin down > > these numbers, particularly in an IETF email list, but any > delay budget > > analysis that I have seen usually yields numbers in the > stated range > > (keep in mind that delay/drop allowances have to be > budgeted for other > > components of the access network and for the link layer handover). > > > > NSIS + LMM (or some variant of MIP) might be one approach > to mobility. > > Fine, but given what I understand about what NSIS is, and > is not, it can > > never be any where near as seamless as a solution that > incorporates CT. > > Is CT simply an "optimization" - well, that depends on how > much service > > disruption the user can tolerate. Usually, there is a > threshold where > > the service is simply considered unusable. > > Cheers, > > Gary > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Marcus:

  If I understand your comment, I believe there are two responses:
first, CT need not be confined to context transfers between ARs,
although this is definitely the most straightforward application of CT;
second, and probably most important, there are access network solutions
that do not require services to be established at the IR on a per flow
basis - the per flow management happens only at the edges.

  It is worth noting that if NSIS *is* required to negotiate services between
the MN and any ANR for every handover, then CT is not needed (if an IR must be
signalled from the MN, then the AR will receive the signalling first; if ARs
are signalling each other using NSIS, then why bother with CT?).

  I emphasize, again, that building signalling into each and every
handover, particularly at the IP layer, is not conducive to seamless
handover. It is very difficult to make a case for this assertion without
discussing numbers - hopefully it is enough to observe that any exchange
of information between the MN and the AN during or after a handover has
a great potential for disrupting the service, particularly if resource
allocations are delayed.

  I am not sure of what you mean by the "far end": are you suggesting end-to-
end signalling with each handover? Or, by far end do you mean the AN to
core network edge? If so for what purpose? Is there an edge based approach
that would eliminated the need for access edge to "far edge" signalling
with each handover?

Regards,
Gary

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: July 8, 2002 04:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert';
> john.loughney@nokia.com; cedric@iprg.nokia.com;
> erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
>
> >   In my view, if CT is in place, then NSIS should not be
> invoked as a
> > result of a handover. A pretty simple relationship. The
> only exception
> > that I can imagine is if there is some impact on a service
> that is not
> > provided at an ANR (i.e. an AR or an internal router), then
> NSIS may  be
> > required to maintain that service. However, I could not
> name this service
> > at this point.
>
> I don't see how CT can work without NSIS in the general case.
> If all your
> AR are connected to the swame next hop router, it may work.
> Generally, you
> might need to signal to the far end after handover.
>
> Marcus
>
> >
> >
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> > Sent: July 5, 2002 10:59
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de';
> > john.loughney@nokia.com; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org;
> > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > dra ft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > hi gary,
> >
> > my comments are purely on draft-westphal-nsis-qos-mobileip
> and associated
> > email discussions (since that's been the only input I have
> seen recently
> > which explicitly discusses the relationship between CT and NSIS, and
> > which I had worries about).  in particular, any comments I
> make about
> > MN-AR signalling are really to emphasise the difference
> between the cases
> > of  a) not having CT signalling that carries QoS
> information MN-AR (if
> > there is or isn't other CT signalling I don't really care), and  b)
> > having CT signalling that does carry QoS information MN-AR,
> which seems
> > to be the assumption of the mentioned draft.
> > our recent framework activities assumed (a). if you're
> saying that the
> > seamoby w.g. requirements also impose (a), that's fine by me. i also
> > don't want to re-open old discussions (certainly not on the
> nsis list,
> > anyway).
> > i suspect we're basically in agreement about NSIS/CT
> relationships: after
> > a handover, if CT happened, it should be possible to have less NSIS
> > signalling on the on-path segment which goes over the air.
> > cheers,
> >
> > robert h.
> >
> > PS referring to a previous email, i think the view that
> NSIS is "likely
> > to be of limited use in mobility situations" is rather
> pessimistic. i
> > would rather say that if you want the resources signalled
> for by NSIS to
> > be available seamlessly over handovers, you'll need
> something else as
> > well, which could be CT. the basic point seems to be that
> NSIS shouldn't
> > try to solve the cross-path context/state transfer problem
> - any more
> > than CT should try to solve the along-path context/state
> establishment
> > problem.  [gwk] I agree. I was not trying to be as much
> pessimistic, as I
> > was pushing back against this concept that NSIS + LMM => Seamless
> > Mobility. To be more precise,  if it takes longer then a
> few 10s of ms to
> > set up the new, conditioned path, then the handover will
> likely not be
> > seamless in 3G. Signalling, particularly over the  air
> (again, 3G), takes
> > relatively significant amount of time to complete. 10s of
> ms is a rough
> > approximation, but if you are running voice frames, more
> then, say  20ms
> > of additional handover delay will start  impinging on the service
> > requirements for the voice - i.e. either frames have to be
> dropped or
> > delayed beyond  the performance constraint. It is difficult
> to pin down
> > these numbers, particularly in an IETF email list, but any
> delay budget
> > analysis that I have seen usually  yields numbers in the
> stated range
> > (keep in mind that delay/drop allowances have to be
> budgeted for other
> > components of the access network and for the  link layer handover).
> >
> > NSIS + LMM (or some variant of MIP) might be one approach
> to mobility.
> > Fine, but given what I understand about what NSIS is, and
> is not, it can
> > never be  any where near as seamless as a solution that
> incorporates CT.
> > Is CT simply an "optimization" - well, that depends on how
> much service
> > disruption the user  can tolerate. Usually, there is a
> threshold where
> > the service is simply considered unusable.
> > Cheers,
> > Gary
> >
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>

------_=_NextPart_001_01C2268F.7DD7EA5A-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 11:22:35 2002 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 LAA19334 for ; Mon, 8 Jul 2002 11:22:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24305 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 11:23:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23381; Mon, 8 Jul 2002 11:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23351 for ; Mon, 8 Jul 2002 11:09:22 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18563 for ; Mon, 8 Jul 2002 11:08:30 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68F9px03207 for ; Mon, 8 Jul 2002 10:09:51 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 10:09:19 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 10:09:14 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] QoS framework. X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 11:09:13 -0400 Message-ID: Thread-Topic: [NSIS] QoS framework. Thread-Index: AcImgV1hAWIFa3iLT8u9EhpDc2iBoQADGUiw To: , Cc: X-OriginalArrivalTime: 08 Jul 2002 15:09:14.0397 (UTC) FILETIME=[6C01DCD0:01C22691] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23352 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios: Please see inline: -----Original Message----- From: ext Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: 08. July 2002 9:14 To: Weshphal Cedric (IPRG/MtView); Chaskar Hemant (NRC/Boston) Cc: nsis@ietf.org Subject: RE: [NSIS] QoS framework. Hi Cedric and Hemant I have read your draft. In my opinion this draft is too much oriented on seamoby and mobileip WG solutions. [Hemant] Thanks for reading the draft and subsequent comments. I am inclined to diagree with your assessment that the draft has specific (too much!) orientation towards Seamoby or Mobile IP. The only place where I see some connection to Seamoby is the proposal to use CIN message for MN-AR signaling. But, we can always substitute it with NSIS message (as we have been discussing on the NSIS list for past few days). Beyond that, there isn't much, if any, orientation towards Seamoby or MobileIP. I think that the draft is in good agreement with NSIS framework document. In the draft "draft-hancock-nsis-fw-00.txt" we describe similar mobility issues to what you tried to describe in your draft, but we presented the solutions in a more general way without excluding other solutions then seamoby and mobileip WG like solutions. [Hemant] IMHO, draft-hancock is a very high level view at the framework issues (which is invaluable anyway). Proceeding to solution may require much deeper look at individual signaling tools optimized to specific use cases. Thus, the intent of draft-westphal was to present a framework for specific use case of layer 3 handoff. It can serve as intermediary between high level framework and specific solution for layer 3 handoff case. Probably this draft is more suitable to be used as a solution specific draft. [Hemant] As we move along with discussions and revisions, I can foresee this draft becoming a solution draft for layer 3 handoff case in the future. In my opinion the framework draft should be open to more than one type of solutions. [Hemant] I agree with you on this. Best Regards, Georgios [Hemant] Thanks, Hemant -----Original Message----- From: Cedric Westphal [mailto:cedric@iprg.nokia.com] Sent: Monday, June 24, 2002 7:47 PM To: nsis@ietf.org Cc: hemant.chaskar@nokia.com Subject: [NSIS] QoS framework. Hi all, we put together a document representing our perspective on a NSIS qos signaling framework. Here is the abstract: Abstract This draft provides a framework for QoS signaling that is optimized for Mobile IP handoffs. It covers the horizontal signaling between access routers (ARs) as well as the vertical signaling along the packet data path, both of which are triggered by handoff of mobile node (MN). The key design goals are wireless bandwidth economy, fast QoS establishment along the new data path after handoff and secure protocol operation. The document will eventually be available from the i-d editor queue. However, only after Yokohama meeting. You can find it at: http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt in the meantime. Please send your comments, Cedric & Hemant. _______________________________________________ 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 daemon@optimus.ietf.org Mon Jul 8 11:47:22 2002 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 LAA20655 for ; Mon, 8 Jul 2002 11:47:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26517 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 11:48:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24453; Mon, 8 Jul 2002 11:24:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24422 for ; Mon, 8 Jul 2002 11:24:04 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19396 for ; Mon, 8 Jul 2002 11:23:12 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g68FO2D29056; Mon, 8 Jul 2002 08:24:02 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id PAA17157; Mon, 8 Jul 2002 15:24:02 GMT Date: Mon, 8 Jul 2002 15:24:02 GMT Message-Id: <200207081524.PAA17157@gra.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] Internet Draft on 2-level signaling architecture Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I am on the NSIS agenda to talk briefly about my Internet Draft "A Two-Level Architecture for Internet Signaling", draft-braden-2level-signaling-00.txt, in Yokahama. Unfortunately, this draft has just expired (sorry to have not noticed that before.) It is available on the RSVP web page (http://www.isi.edu/rsvp) under "Publication", then "RSVP-Related Internet Drafts". Or you can find it at http://www.isi.edu/~braden/draft-braden-2level-signaling-00.txt. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 12:17:21 2002 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 MAA22591 for ; Mon, 8 Jul 2002 12:17:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00345 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 12:18:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27926; Mon, 8 Jul 2002 12:00:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27702 for ; Mon, 8 Jul 2002 12:00:34 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21318 for ; Mon, 8 Jul 2002 11:59:37 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Fxw920541 for ; Mon, 8 Jul 2002 11:59:58 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 11:59:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" , "'NSIS'" Date: Mon, 8 Jul 2002 11:59:51 -0400 Sensitivity: Company-Confidential X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I finally managed to find time to read through Cedric's and Hemant's draft. Overally, I think it is a good description of one possible integrated approach. The one general comment I would like to offer up at this time, is that while the draft does a good job of integrating MIP, CT and NSIS concepts, the proposed solutions for QoS negotiation between MN and AN (e.g. the use of the CIN message) is NSIS not CT. CT is concerned with the transfer of forwarding service context between ANRs. NSIS is concerned with the signalling of service requirements. Thus, the issue is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how the CIN, etc., form part of the NSIS solution. This is not simply an issue of adherence to Seamoby/NSIS models or charters. The intention has always been that CT work as a context transfer mechanism with a variety of mobility and service signalling solutions. There is a significant benefit in the real world to be realized in keeping the context transfer solution (CT) independent from the service signalling solution (NSIS) (and the mobility solution - MIP or whatever). I would think that there is also a benefit to keeping the MN to AR service signalling independent of CT. Stated a different way, do we really need two separate solutions for over the air (MN to AN) service signalling? Regards, Gary Kenward _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 12:34:32 2002 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 MAA23495 for ; Mon, 8 Jul 2002 12:34:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02259 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 12:35:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00562; Mon, 8 Jul 2002 12:20:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00504 for ; Mon, 8 Jul 2002 12:20:37 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22698; Mon, 8 Jul 2002 12:19:38 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68GOCj11255; Mon, 8 Jul 2002 11:24:12 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 11:20:30 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 11:20:24 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 12:20:23 -0400 Message-ID: Thread-Topic: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImmMjymZiFaTWITiG8gRYc39SSCQAANpPQ Sensitivity: Company-Confidential To: , , X-OriginalArrivalTime: 08 Jul 2002 16:20:24.0550 (UTC) FILETIME=[5D378060:01C2269B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA00507 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary: Some comments inline: -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 08. July 2002 12:00 To: 'seamoby@ietf.org'; 'NSIS' Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Sensitivity: Confidential I finally managed to find time to read through Cedric's and Hemant's draft. Overally, I think it is a good description of one possible integrated approach. [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. The one general comment I would like to offer up at this time, is that while the draft does a good job of integrating MIP, CT and NSIS concepts, the proposed solutions for QoS negotiation between MN and AN (e.g. the use of the CIN message) is NSIS not CT. [Hemant] Point well taken. CT is concerned with the transfer of forwarding service context between ANRs. NSIS is concerned with the signalling of service requirements. Thus, the issue is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how the CIN, etc., form part of the NSIS solution. [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. [Hemant] Thanks, Hemant This is not simply an issue of adherence to Seamoby/NSIS models or charters. The intention has always been that CT work as a context transfer mechanism with a variety of mobility and service signalling solutions. There is a significant benefit in the real world to be realized in keeping the context transfer solution (CT) independent from the service signalling solution (NSIS) (and the mobility solution - MIP or whatever). I would think that there is also a benefit to keeping the MN to AR service signalling independent of CT. Stated a different way, do we really need two separate solutions for over the air (MN to AN) service signalling? Regards, Gary Kenward _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 12:40:23 2002 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 MAA23768 for ; Mon, 8 Jul 2002 12:40:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02840 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 12:41:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00970; Mon, 8 Jul 2002 12:24:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00891 for ; Mon, 8 Jul 2002 12:24:35 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22914; Mon, 8 Jul 2002 12:23:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA21543; Mon, 8 Jul 2002 09:24:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68GO2e16659; Mon, 8 Jul 2002 09:24:02 -0700 X-mProtect: <200207081624> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF3kG5q; Mon, 08 Jul 2002 09:24:00 PDT Message-ID: <3D29BCA0.50D6211E@iprg.nokia.com> Date: Mon, 08 Jul 2002 09:24:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BE9@zcard031.ca.nortel.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, Thanks for your note. It seems to me that, with your further explanation, we are in agreement. And, I agree that during CT there typically shouldn't be any service negotiation, maybe even never. If it occurs, it should be considered to be part of CAR discovery, not CT. Regards, Charlie P. > Gary Kenward wrote: > > Charlie: > > I guess the word "negotiate" really trips me up here. CT is a > protocol for transferring forwarding service context, not for negotiating > services between ARs. If service negotiation is required, then NSIS could be > the protocol to be used. > > In my statement that you quote below, I used the words "should not": in > the normal course of a handover, service negotiation must be rare. > Negotiation, > by definition, takes time, and anything that takes time will generally delay > the service from being supported at the new AR. In the normal course of a > handover, > less signalling is always better. > > In wireless, of course, the exception is the rule, and so there must be > contingencies for service negotiation. This would be NSIS' role. > > And so, I did not make my point clear. My main intent was to emphasize that > if there is a link between CT and NSIS, it is a very simple one: if CT fails > to provide a context that is useable by the new AR, then NSIS may be used to > negotiate a suitable service with the network (and thus establish suitable > context at the new AR). > > Cheers, > Gary _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 12:56:01 2002 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 MAA24785 for ; Mon, 8 Jul 2002 12:56:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03991 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 12:56:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02815; Mon, 8 Jul 2002 12:41:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02733 for ; Mon, 8 Jul 2002 12:41:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23756; Mon, 8 Jul 2002 12:40:10 -0400 (EDT) Message-ID: <016701c2269d$ffbc32c0$4f6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 09:39:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Could CT be viewed as an optimization of NSIS signaling? jak ----- Original Message ----- From: To: ; ; Sent: Monday, July 08, 2002 9:20 AM Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Hi Gary: > > Some comments inline: > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 08. July 2002 12:00 > To: 'seamoby@ietf.org'; 'NSIS' > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Sensitivity: Confidential > > > I finally managed to find time to read through Cedric's and Hemant's draft. > Overally, I think it is a good description of one possible integrated > approach. > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > The one general comment I would like to offer up at this time, is that while > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > the > CIN message) is NSIS not CT. > > [Hemant] Point well taken. > > CT is concerned with the transfer of forwarding service context between > ANRs. > NSIS is concerned with the signalling of service requirements. Thus, the > issue > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > how > the CIN, etc., form part of the NSIS solution. > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. > > [Hemant] Thanks, Hemant > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > The intention has always been that CT work as a context transfer mechanism > with a variety of mobility and service signalling solutions. There is a > significant > benefit in the real world to be realized in keeping the context transfer > solution > (CT) independent from the service signalling solution (NSIS) (and the > mobility > solution - MIP or whatever). I would think that there is also a benefit to > keeping > the MN to AR service signalling independent of CT. > > Stated a different way, do we really need two separate solutions for over > the air > (MN to AN) service signalling? > > Regards, > Gary Kenward > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 13:23:40 2002 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 NAA26391 for ; Mon, 8 Jul 2002 13:23:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06184 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 13:24:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05027; Mon, 8 Jul 2002 13:05:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04988 for ; Mon, 8 Jul 2002 13:05:36 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25330; Mon, 8 Jul 2002 13:04:44 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68H9Gj19579; Mon, 8 Jul 2002 12:09:16 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 12:05:33 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 12:04:37 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 13:04:36 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImnjwicOWGywY0SGyWtZe2Im4KQQAAIWpg To: , , , X-OriginalArrivalTime: 08 Jul 2002 17:04:37.0145 (UTC) FILETIME=[8A496090:01C226A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA04991 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James: I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 08. July 2002 12:39 To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Could CT be viewed as an optimization of NSIS signaling? jak ----- Original Message ----- From: To: ; ; Sent: Monday, July 08, 2002 9:20 AM Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Hi Gary: > > Some comments inline: > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 08. July 2002 12:00 > To: 'seamoby@ietf.org'; 'NSIS' > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Sensitivity: Confidential > > > I finally managed to find time to read through Cedric's and Hemant's draft. > Overally, I think it is a good description of one possible integrated > approach. > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > The one general comment I would like to offer up at this time, is that while > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > the > CIN message) is NSIS not CT. > > [Hemant] Point well taken. > > CT is concerned with the transfer of forwarding service context between > ANRs. > NSIS is concerned with the signalling of service requirements. Thus, the > issue > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > how > the CIN, etc., form part of the NSIS solution. > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. > > [Hemant] Thanks, Hemant > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > The intention has always been that CT work as a context transfer mechanism > with a variety of mobility and service signalling solutions. There is a > significant > benefit in the real world to be realized in keeping the context transfer > solution > (CT) independent from the service signalling solution (NSIS) (and the > mobility > solution - MIP or whatever). I would think that there is also a benefit to > keeping > the MN to AR service signalling independent of CT. > > Stated a different way, do we really need two separate solutions for over > the air > (MN to AN) service signalling? > > Regards, > Gary Kenward > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 13:35:19 2002 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 NAA26863 for ; Mon, 8 Jul 2002 13:35:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07436 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 13:36:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05858; Mon, 8 Jul 2002 13:18:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05733 for ; Mon, 8 Jul 2002 13:18:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26034; Mon, 8 Jul 2002 13:17:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68HHE901854; Mon, 8 Jul 2002 13:17:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 13:17:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Hemant.Chaskar@nokia.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 8 Jul 2002 13:17:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226A3.49C8C2B6" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/plain; charset="iso-8859-1" James: In a way, yes. But if CT is present, and succeeds, then there should be no need for MN-AN signalling, thus CT optimizes NSIS completely away during handover (in this preferred scenario). Note that I specifically identified MN-AN NSIS, as I think what happens within the interior of the AN is a broader discussion. From a seamless perspective, one would hope that no signalling would be required. However, this objective may not be possible with some service topologies (e.g. Int Serv QoS). As I hinted earlier, one could assume the use of CT for internal router context transfer (e.g. Int Serv configuration/state between IRs), unfortunately, there are some serious discover/topological issues that arise. NSIS may be the best possible general approach for per flow IR service configuration with handovers. On the other hand, some may be willing to live with topological constraints (PDP context relocation comes to mind here). Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 8, 2002 12:39 > To: Hemant.Chaskar@nokia.com; Kenward, Gary [WDLN2:AN10:EXCH]; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and > Hemant's draft. > > Overally, I think it is a good description of one possible > integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and > AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on > each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at > handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this > time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS > concepts, the > > proposed solutions for QoS negotiation between MN and AN > (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service > context between > > ANRs. > > NSIS is concerned with the signalling of service > requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with > NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help > avoid MN-new AR NSIS signaling at handoff time, it is a good > proposition. > Note that context can be constructed at old AR using the > information supplied to it by NSIS MN-old AR message at > session initiation, > which can be transported to new AR in CT. If CT fails, one > should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS > models or charters. > > The intention has always been that CT work as a context > transfer mechanism > > with a variety of mobility and service signalling > solutions. There is a > > significant > > benefit in the real world to be realized in keeping the > context transfer > > solution > > (CT) independent from the service signalling solution > (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is > also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate > solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt

James:

  In a way, yes. But if CT is present, and = succeeds, then there
should be no need for MN-AN signalling, thus CT = optimizes NSIS completely
away during handover (in this preferred = scenario).

  Note that I specifically identified MN-AN = NSIS, as I think what happens
within the interior of the AN is a broader = discussion. From a seamless
perspective, one would hope that no signalling would = be required. However,
this objective may not be possible with some service = topologies (e.g. Int
Serv QoS). As I hinted earlier, one could assume the = use of CT for internal
router context transfer (e.g. Int Serv = configuration/state between IRs),
unfortunately, there are some serious = discover/topological issues that arise.
NSIS may be the best possible general approach for = per flow IR service
configuration with handovers. On the other hand, = some may be willing to live
with topological constraints (PDP context relocation = comes to mind here).

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 8, 2002 12:39
> To: Hemant.Chaskar@nokia.com; Kenward, Gary = [WDLN2:AN10:EXCH];
> seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> Could CT be viewed as an optimization of NSIS = signaling?
>
>          = ;   jak
>
> ----- Original Message -----
> From: <Hemant.Chaskar@nokia.com>
> To: <gkenward@nortelnetworks.com>; = <seamoby@ietf.org>; <nsis@ietf.org>
> Sent: Monday, July 08, 2002 9:20 AM
> Subject: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> > Hi Gary:
> >
> > Some comments inline:
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> > Sent: 08. July 2002 12:00
> > To: 'seamoby@ietf.org'; 'NSIS'
> > Subject: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt
> > Sensitivity: Confidential
> >
> >
> > I finally managed to find time to read = through Cedric's and
> Hemant's draft.
> > Overally, I think it is a good description = of one possible
> integrated
> > approach.
> >
> > [Hemant] Please note that the Edge = Signaling (MN-AR and
> AR-AR) and Data Path Signaling (e2e if you = will) are not "tightly
> integrated", i.e., they help each other = but do not rely on
> each other (though I admit that the current = writeup makes that
> impression). In other words, Data Path = Signaling can work (at
> handoff time) even if Edge Signaling = fails.
> >
> > The one general comment I would like to = offer up at this
> time, is that while
> >
> > the draft does a good job of integrating = MIP, CT and NSIS
> concepts, the
> > proposed solutions for QoS negotiation = between MN and AN
> (e.g. the use of
> > the
> > CIN message) is NSIS not CT.
> >
> > [Hemant] Point well taken.
> >
> > CT is concerned with the transfer of = forwarding service
> context between
> > ANRs.
> > NSIS is concerned with the signalling of = service
> requirements. Thus, the
> > issue
> > is not how to interwork the "CT" = CIN, for example, with
> NSIS signalling, but
> > how
> > the CIN, etc., form part of the NSIS = solution.
> >
> > [Hemant] I agree. The basic idea is that = if CT can help
> avoid MN-new AR NSIS signaling at handoff time, = it is a good
> proposition.
> Note that context can be constructed at old AR = using the
> information supplied to it by NSIS MN-old AR = message at
> session initiation,
> which can be transported to new AR in CT. If CT = fails, one
> should use MN-new AR NSIS signaling at handoff = time, albeit at certain
> loss of seamlessness.
> >
> > [Hemant] Thanks, Hemant
> >
> > This is not simply an issue of adherence = to Seamoby/NSIS
> models or charters.
> > The intention has always been that CT work = as a context
> transfer mechanism
> > with a variety of mobility and service = signalling
> solutions. There is a
> > significant
> > benefit in the real world to be realized = in keeping the
> context transfer
> > solution
> > (CT) independent from the service = signalling solution
> (NSIS) (and the
> > mobility
> > solution - MIP or whatever). I would think = that there is
> also a benefit to
> > keeping
> > the MN to AR service signalling = independent of CT.
> >
> > Stated a different way, do we really need = two separate
> solutions for over
> > the air
> > (MN to AN) service signalling?
> >
> > Regards,
> > Gary Kenward
> >
> >
> >
> > = _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis=
> >
> > = _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C226A3.49C8C2B6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 14:43:38 2002 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 OAA01339 for ; Mon, 8 Jul 2002 14:43:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12021 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 14:44:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10774; Mon, 8 Jul 2002 14:30:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10697 for ; Mon, 8 Jul 2002 14:30:18 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00167; Mon, 8 Jul 2002 14:29:25 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g68ITjv03128; Mon, 8 Jul 2002 13:29:45 -0500 (CDT) Message-ID: <3D29DA39.1090405@alcatel.com> Date: Mon, 08 Jul 2002 13:30:17 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: multipart/alternative; boundary="------------060308060208010408090808" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------060308060208010408090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hemant, The relationship between nsis and CT, as far as I know is that of uncertainty. nsis which started out to develop signaling for QoS now changed to only signaling, CT is going nowhere at Seamoby. The only sure thing is that the links have CT quite well defined, IEEE defined for 802.11 links and 3G links also have well defined context transfer protocols. In order to add to the present confusion, let me note the new BOF called: Topology-Insensitive Service Traversal which is probably going to deal with RSVP based signaling. My 0.03 euros (increased due to recent increase in value of the Euro). Hemant.Chaskar@nokia.com wrote: >Hi James: > >I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. > >If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > >Hemant > >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: 08. July 2002 12:39 >To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; >seamoby@ietf.org; nsis@ietf.org >Subject: Re: [Seamoby] RE: [NSIS] Re: >draft-westphal-nsis-qos-mobileip-00.txt > > >Could CT be viewed as an optimization of NSIS signaling? > > jak > >----- Original Message ----- >From: >To: ; ; >Sent: Monday, July 08, 2002 9:20 AM >Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > >>Hi Gary: >> >>Some comments inline: >> >>-----Original Message----- >>From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] >>Sent: 08. July 2002 12:00 >>To: 'seamoby@ietf.org'; 'NSIS' >>Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt >>Sensitivity: Confidential >> >> >>I finally managed to find time to read through Cedric's and Hemant's draft. >>Overally, I think it is a good description of one possible integrated >>approach. >> >>[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly >> >integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that >impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > >>The one general comment I would like to offer up at this time, is that while >> >>the draft does a good job of integrating MIP, CT and NSIS concepts, the >>proposed solutions for QoS negotiation between MN and AN (e.g. the use of >>the >>CIN message) is NSIS not CT. >> >>[Hemant] Point well taken. >> >>CT is concerned with the transfer of forwarding service context between >>ANRs. >>NSIS is concerned with the signalling of service requirements. Thus, the >>issue >>is not how to interwork the "CT" CIN, for example, with NSIS signalling, but >>how >>the CIN, etc., form part of the NSIS solution. >> >>[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. >> >Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, >which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain >loss of seamlessness. > >>[Hemant] Thanks, Hemant >> >>This is not simply an issue of adherence to Seamoby/NSIS models or charters. >>The intention has always been that CT work as a context transfer mechanism >>with a variety of mobility and service signalling solutions. There is a >>significant >>benefit in the real world to be realized in keeping the context transfer >>solution >>(CT) independent from the service signalling solution (NSIS) (and the >>mobility >>solution - MIP or whatever). I would think that there is also a benefit to >>keeping >>the MN to AR service signalling independent of CT. >> >>Stated a different way, do we really need two separate solutions for over >>the air >>(MN to AN) service signalling? >> >>Regards, >>Gary Kenward >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > -- Behcet --------------060308060208010408090808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hemant,
 The relationship between nsis and CT, as far as I know is
that of uncertainty.
nsis which started out to develop signaling for QoS now changed to only signaling,
CT is going nowhere at Seamoby.
  The only sure thing is that the links have CT quite well defined, IEEE defined for 802.11 links and 3G links also have well defined context transfer protocols.
  In order to add to the present confusion, let me note the new BOF called:
Topology-Insensitive Service Traversal
which is probably going to deal with RSVP based signaling.

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

Hemant.Chaskar@nokia.com wrote:
Hi James: 

I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR.

If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path al
so before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: 08. July 2002 12:39
To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com;
seamoby@ietf.org; nsis@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Re:
draft-westphal-nsis-qos-mobileip-00.txt


Could CT be viewed as an optimization of NSIS signaling?

            jak

----- Original Message -----
From: <Hemant.Chaskar@nokia.com>
To: <gkenward@nortelnetworks.com>; <seamoby@ietf.org>; <nsis@ietf.org>
Sent: Monday, July 08, 2002 9:20 AM
Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt


Hi Gary:

Some comments inline:

-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 08. July 2002 12:00
To: 'seamoby@ietf.org'; 'NSIS'
Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Sensitivity: Confidential


I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly
integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that
impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails.
The one general comment I would like to offer up at this time, is that while

the draft does a good job of integrating MIP, CT and NSIS concepts, the
proposed solutions for QoS negotiation between MN and AN (e.g. the use of
the
CIN message) is NSIS not CT.

[Hemant] Point well taken.

CT is concerned with the transfer of forwarding service context between
ANRs.
NSIS is concerned with the signalling of service requirements. Thus, the
issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but
how
the CIN, etc., form part of the NSIS solution.

[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition.
Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation,
which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain
loss of seamlessness.
[Hemant] Thanks, Hemant

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a
significant
benefit in the real world to be realized in keeping the context transfer
solution
(CT) independent from the service signalling solution (NSIS) (and the
mobility
solution - MIP or whatever). I would think that there is also a benefit to
keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over
the air
(MN to AN) service signalling?

Regards,
Gary Kenward



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

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



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

-- 
Behcet

--------------060308060208010408090808-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 14:50:08 2002 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 OAA01923 for ; Mon, 8 Jul 2002 14:50:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12438 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 14:51:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11500; Mon, 8 Jul 2002 14:36:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11459 for ; Mon, 8 Jul 2002 14:36:50 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00656 for ; Mon, 8 Jul 2002 14:35:57 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g68Id08m005604; Mon, 8 Jul 2002 13:39:00 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g68IYAq13398; Mon, 8 Jul 2002 13:34:10 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <3G6CC8AB>; Mon, 8 Jul 2002 13:35:14 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB63@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'brunner@ccrle.nec.de'" , "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Date: Mon, 8 Jul 2002 13:35:14 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus, Sorry for the very delayed reply. Allow me to quote for an earlier reply to Georgios: "In my mind this requirement has do with the layering relationship between QOS Signaling and Routing. In a hard-state solution once the QOS path is created it does not unchange. The signaling protocol uses input from the routing protocol to create this path. The path created is static. In an RSVP style solution without route pinning we have a reactive distributed algorithm that takes the default routing path as its input. While it should be possible to do this style of path that is dynamically determined by the default destination based routing, it must also be possible to build the path once based upon an initial set of inputs." The fact that one can work around the deficiencies of a protocol layering design does not mean the design is sound. Regarding Item 1: take care by introducing new links into your topology, something you might want to do on lightly loaded metworks anyway. 1) The introduction of new links should not affect existing connections. 2) More specifically the operator should not have to be concerned with whether addition of links could affect existing connections. Regarding Item 2: I am not sure how constraint/qos routing goes into the mechanism of provisioning. In fact the two are unrelated in IMHO. I do agree that QOS routing appears to be out of scope. Marco > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Friday, June 07, 2002 10:19 AM > To: Schneider, Marco; 'nsis@ietf.org' > Cc: 'sven.van_den_bosch@alcatel.be' > Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow > reservations and default routing > > > Marco, > > IMHO the problem you have shown in the example can be solved > in 2 ways, and > both are IMO out of scope for NSIS. > 1) take care by introducing new links into your topology, > something you > might want to do on lightly loaded metworks anyway. > > 2) I think an other solution would be constraint/QoS routing, > which is more > going into the mechanis of provisioning, which is again out of scope. > > > Marcus > > > > --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" > wrote: > > > Hi All, > > > > One of the Open issues mentioned in the current > requirements draft is > > Route Pinning (item 47). In the following I discuss a very strong > > motivation for the ability to do route pinning if a soft > state solution > > is used for NSIS. I have tried to express this as a > requirement upon NSIS > > rather than the mechanism (route pinning being the obvious > one) by which > > this requirement may be achieved. > > > > Requirement: NSIS must directly support the ability to > insulate a flow > > reservation from changes in the default routing behaviour > except in those > > cases where said changes result from loss of resources > (layer 3 hops, > > capacity etc.) along the existing flow reservation path. > > > > For instance, utilizing traffic engineering in a layer 2 > network (e.g. > > MPLS or ATM) we may provision additional links or change > the resources > > associated with existing links. Additionally failures in > the network may > > cause changes. Such changes must not affect existing layer > 3 reservation > > paths with the exception of those cases where the existing > reservation > > path no longer exists or no longer has capacity to support the flow > > reservation. > > > > As a simple example consider a network with two routers A > and B and assume > > that the shortest path from A to B is two hops. Based upon > NSIS signaling, > > as directed by default routing based upon number of hops, a > reservation > > path is setup from A to B along a path of two hops, where > both hops have a > > capacity of 10 and the reservation uses a capacity of 6. > Now let us assume > > that a direct link with capacity 5 is provisioned between A and B > > resulting in a new and direct default route of 1 hop. If > NSIS uses a soft > > state solution without route pinning then the existing flow > reservation > > will be redirected along the new link, which cannot support > it. Thus the > > existing flow reservation is lost due a change in the > network unrelated > > to its current path. In fact thousands of reservations may have been > > routed along the original path and would now be disrupted. > Such protocol > > behaviour is not acceptable. > > > > Best Regards, > > Marco > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 14:54:08 2002 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 OAA02277 for ; Mon, 8 Jul 2002 14:54:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12965 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 14:55:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11732; Mon, 8 Jul 2002 14:41:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11701 for ; Mon, 8 Jul 2002 14:41:14 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01012 for ; Mon, 8 Jul 2002 14:40:20 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g68IhU8m005619; Mon, 8 Jul 2002 13:43:30 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g68IcfT13581; Mon, 8 Jul 2002 13:38:41 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <3G6CC8BG>; Mon, 8 Jul 2002 13:39:45 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB64@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'brunner@ccrle.nec.de'" , "'nsis@ietf.org'" Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Date: Mon, 8 Jul 2002 13:39:45 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Marcus, Actually, during the meeting I raised my concerns and was asked to post an example to the mailing list which I did. In reponse to your question, I am not sure what "non-traditional L3 routing" is. I am not sure I see the relationship between the two issues. Can you further elaborate. Thanks, Marco > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Friday, June 07, 2002 10:35 AM > To: Schneider, Marco; 'nsis@ietf.org' > Subject: req proposal (was Re: [NSIS] NSIS Requirement: > Independence of > existing flow reservations and default routing > > > Marco, > > We discussed the issue of route pinning and traffic engineering in > Helsinki. The conclusion during the meeting was that we want > to add an > assuption saying: NSIS assumes normal/standard L3 routing > > Plus we add a requirement saying that NSIS protocol should > not be broken by > networks which do non-traditional L3 routing. > > Does this cover your concern? Do we really need to add that > NSIS must work > with default routing changes? > > Marcus > > NSIS should not be broken by networks which do > non-traditional L3 routing. > > --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" > wrote: > > > Hi All, > > > > One of the Open issues mentioned in the current > requirements draft is > > Route Pinning (item 47). In the following I discuss a very strong > > motivation for the ability to do route pinning if a soft > state solution > > is used for NSIS. I have tried to express this as a > requirement upon NSIS > > rather than the mechanism (route pinning being the obvious > one) by which > > this requirement may be achieved. > > > > Requirement: NSIS must directly support the ability to > insulate a flow > > reservation from changes in the default routing behaviour > except in those > > cases where said changes result from loss of resources > (layer 3 hops, > > capacity etc.) along the existing flow reservation path. > > > > For instance, utilizing traffic engineering in a layer 2 > network (e.g. > > MPLS or ATM) we may provision additional links or change > the resources > > associated with existing links. Additionally failures in > the network may > > cause changes. Such changes must not affect existing layer > 3 reservation > > paths with the exception of those cases where the existing > reservation > > path no longer exists or no longer has capacity to support the flow > > reservation. > > > > As a simple example consider a network with two routers A > and B and assume > > that the shortest path from A to B is two hops. Based upon > NSIS signaling, > > as directed by default routing based upon number of hops, a > reservation > > path is setup from A to B along a path of two hops, where > both hops have a > > capacity of 10 and the reservation uses a capacity of 6. > Now let us assume > > that a direct link with capacity 5 is provisioned between A and B > > resulting in a new and direct default route of 1 hop. If > NSIS uses a soft > > state solution without route pinning then the existing flow > reservation > > will be redirected along the new link, which cannot support > it. Thus the > > existing flow reservation is lost due a change in the > network unrelated > > to its current path. In fact thousands of reservations may have been > > routed along the original path and would now be disrupted. > Such protocol > > behaviour is not acceptable. > > > > Best Regards, > > Marco > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 15:20:53 2002 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 PAA04122 for ; Mon, 8 Jul 2002 15:20:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15548 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 15:21:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14212; Mon, 8 Jul 2002 15:05:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14179 for ; Mon, 8 Jul 2002 15:05:30 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03199 for ; Mon, 8 Jul 2002 15:04:37 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g68J7p8m005846; Mon, 8 Jul 2002 14:07:51 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g68J31w14640; Mon, 8 Jul 2002 14:03:01 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <3G6CC8GB>; Mon, 8 Jul 2002 14:04:05 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB65@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing Date: Mon, 8 Jul 2002 14:04:05 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, As per my response to Marcus: I raised my concerns during the meeting and was asked to post an example, which I did. As for the text, I guess it is not clear to me whether this addresses the issue. In my opinion the example I gave does not have anything to do with non-traditional L3 routing. Marco > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, June 10, 2002 8:29 AM > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > Hi Marco & Marcus, > > We discussed the issue of route pinning and traffic engineering in > > Helsinki. The conclusion during the meeting was that we > want to add an > > assuption saying: NSIS assumes normal/standard L3 routing > > > > Plus we add a requirement saying that NSIS protocol should > not be broken by > > networks which do non-traditional L3 routing. > > > > Does this cover your concern? Do we really need to add that > NSIS must work > > with default routing changes? > > I agree with Marcus that this is what we are trying to say. > Marco, is this > text OK with you? > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 15:49:02 2002 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 PAA05284 for ; Mon, 8 Jul 2002 15:49:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18409 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 15:49:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16832; Mon, 8 Jul 2002 15:32:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16706 for ; Mon, 8 Jul 2002 15:32:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04572; Mon, 8 Jul 2002 15:31:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA02525; Mon, 8 Jul 2002 12:32:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68JW6s31258; Mon, 8 Jul 2002 12:32:06 -0700 X-mProtect: <200207081932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd69jaUF; Mon, 08 Jul 2002 12:32:04 PDT Message-ID: <3D29E8B4.71E86F9A@iprg.nokia.com> Date: Mon, 08 Jul 2002 12:32:04 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hemant, Hemant.Chaskar@nokia.com wrote: > Hi James: > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is CT is an optimization to avoid signaling and the associated overheads, and maintain desirable transport (RTP/TCP)performance. A historical note: CT was not designed to be an optimization for NSIS. > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. This was discussed earlier. In essence, - with some standard Profile Types, you would expect participating routers to support a majority of the feature contexts. In the absence of additional protocol support (e.g., CARD), transferring what you have is just fine. The receiving router ignores the context(s) it does not understand. London IETF was where we specifically had this discussion in depth. - when a feature context type is not understood, CT should provide a notification. Such a notification is also useful when a feature context is partially understood. This notification could be used as a trigger to engage in NSIS signaling. This was presented at the NSIS interim WG meeting. > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > Ok. When CARD is available, it can provide input to CT. -Rajeev > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 08. July 2002 12:39 > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > Overally, I think it is a good description of one possible integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service context between > > ANRs. > > NSIS is concerned with the signalling of service requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > The intention has always been that CT work as a context transfer mechanism > > with a variety of mobility and service signalling solutions. There is a > > significant > > benefit in the real world to be realized in keeping the context transfer > > solution > > (CT) independent from the service signalling solution (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 16:54:09 2002 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 QAA08361 for ; Mon, 8 Jul 2002 16:54:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23949 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 16:55:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22516; Mon, 8 Jul 2002 16:40:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22458 for ; Mon, 8 Jul 2002 16:40:38 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07527 for ; Mon, 8 Jul 2002 16:39:44 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g68KiDgc006466; Mon, 8 Jul 2002 15:44:13 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g68KdNF18152; Mon, 8 Jul 2002 15:39:24 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <3G6CC8XB>; Mon, 8 Jul 2002 15:40:27 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB68@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Hancock, Robert'" , "'Zhigang.Kan@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Mon, 8 Jul 2002 15:40:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA22490 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, all I find our mapping of distinctions to terms confusing. The term QOS is of course short for Quality of Service. This begs the question "what or which service". In our context we seem to be speaking of packet transport: A QOS (quality of service) service being the ability to specify the quality of said packet transport service. For me, strictly speaking, QOS is not an example of a resource but rather a type of service that can reasonably be thought of to require resource reservations in a network. What resources are actually reserved or utilized to achieve QOS is beyond the scope of our work. Put another way a service is an abstraction of network resources/capabilities and whether or not the service implementation uses said abstractions is beyond scope. Marco > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Thursday, June 27, 2002 5:45 AM > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function > > > Hi Zhigang, > > 'QoS' is one example of 'resource'. > > I'm actually not sure it is possible to define 'resource' > precisely. The basic point is that NSIS should provide a > generally useful signalling capability, which you could use > for various types of resource; exactly what types is going to > be defined implicitly by whether the NSIS capabilities are > appropriate to the resource type needs. In that sense, > there's a benefit in vagueness. > > An RMF is absolutely not a BB. In our framework, "RMF" is > just a name for what NSIS offloads certain problems in > resource management to, it's a way to talk about the boundary > of the NSIS problem space. NSIS doesn't care how the RMF is > implemented; it should be possible to support both > centralised and distributed resource management strategies > with the same NSIS protocol. The one thing that is ruled out > (initially) is NSIS signalling directly to a centralised > (off-path) entity; this is a consequence of recent scope > guidance. Please see especially section 5.1 of the draft (the > hardest section to write, by the way). > > Yours, > > Robert H. > > > > > -----Original Message----- > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > Sent: 27 June 2002 11:11 > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource > Management Function > > v.s. QoS Management Function > > > > > > Hi all, > > > > Maybe we don't care what term/name is called. The most > > important is that the "resources" and "resource management" > > should be defined exactly, and the relationship between > > resource and QoS should be clarified. Is RMF similar as BB? > > > > BR/Kan Zhigang > > > > -----Original Message----- > > From: ext Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 2002å¹´6月27æ—¥ 17:47 > > To: 'Hancock, Robert' > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource Management > > Function v. > > s. QoS Management Function > > > > > > Hi all > > > > I agree with the explanation given by Robert regarding RMF. I am in > > favor of keeping the term RMF. > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, June 27, 2002 11:39 AM > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource > Management Function > > v.s. QoS Management Function > > > > > > hi all, > > > > I think it's valuable for Zhigang to highlight the point, > > because this is one of the major changes in this NSIS > > framework input compared to (most?) previous ones (certainly > > the ones I have been involved in). One of the consequences of > > the email discussions around the time of the interim meeting > > (e.g. > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > msg01378.html) was that we should look at more general > > resources than just QOS. (IMHO, this is still not obvious > > even in the post-interim clarified charter, BTW.) > > > > This has quite a big impact on what we write, at least. We > > still need a good name for this "thing we are signalling > > for", "resource" (and hence RMF) is a first guess. 'Service' > > seems to me to be too general. The key point which is special > > about NSIS is that the relevant resources are those which > > have to be provided by entities along the data path, but I > > can't think of a snappy term for that. > > > > The other impact is that we might need to broaden our > > thinking about how such a signalling protocol might fit into > > an overall solution to some resource management problem > > (hence my interest in Marcus' firewall draft). Certainly, the > > relationship between nsis and midcom/tist activities seems > > important to understand. > > > > Robert H. > > > > > -----Original Message----- > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > Sent: 27 June 2002 10:10 > > > To: Zhigang.Kan@nokia.com > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > Hi Kan, > > > > > > > Resource Management Function is introduced in this draft as > > > > "RMF: an abstract concept, representing the management of > > > > resources in a domain or a node". I think that this > > > > definition is not appropriate for the aim of NSIS which is > > > > Signaling QoS, not Signaling resource. > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > is not only about QoS signaling, it is about service related > > > signaling in general. What about calling the above system > > > "Service Management Function"? > > > > > > Regards, Rüdiger > > > > > > > > > > Hi all, > > > > > > > > A group of us who were involved in past NSIS framework > > > > activities got together after the interim meeting to put > > > > together a joint framework document in the form of an all-new > > > > individual submission. It (roughly) follows the structure > > > > that was introduced and refined at that meeting. > > > > > > > > ============================================================== > > > > ============ > > > > Abstract > > > > > > > > The NSIS working group is considering protocol > developments in > > > > signaling for resources for a traffic flow along its > > path in the > > > > network. The requirements for such signaling are being > > > > developed in a > > > > separate document; This Internet Draft proposes a > > framework for > > > > such signaling. This initial version provides a model for > > > > describing > > > > the entities that take part in the signaling and the > > > ways in which > > > > they can be used in different modes of operation. It also > > > > discusses > > > > the overall structure of such a signaling protocol. > > Finally, it > > > > considers the possible interactions of NSIS signaling > > with other > > > > protocols and functions, including security issues. > > > > ============================================================== > > > > ============ > > > > > > > > While it works its way through the i-d editor queue, you can > > > > find a copy here: > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > Comments are welcome. There is a list of open issue > > > > highlights in section 3. > > > > > > > > Cheers, > > > > > > > > Robert Hancock > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 daemon@optimus.ietf.org Mon Jul 8 17:51:17 2002 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 RAA13121 for ; Mon, 8 Jul 2002 17:51:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29982 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 17:52:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28762; Mon, 8 Jul 2002 17:38:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28704 for ; Mon, 8 Jul 2002 17:38:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12229; Mon, 8 Jul 2002 17:37:47 -0400 (EDT) Message-ID: <021401c226c7$91cc54f0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , Cc: , , References: <3D29E8B4.71E86F9A@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 14:36:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 17:53:34 2002 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 RAA13183 for ; Mon, 8 Jul 2002 17:53:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00076 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 17:54:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28883; Mon, 8 Jul 2002 17:40:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28848 for ; Mon, 8 Jul 2002 17:40:08 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12309; Mon, 8 Jul 2002 17:39:13 -0400 (EDT) Message-ID: <022501c226c7$c8f3bf40$4f6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , Cc: , References: <3D29DA39.1090405@alcatel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 14:38:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > CT is going nowhere at Seamoby. Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements. jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 17:58:02 2002 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 RAA13400 for ; Mon, 8 Jul 2002 17:58:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00539 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 17:58:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29266; Mon, 8 Jul 2002 17:44:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29203 for ; Mon, 8 Jul 2002 17:44:03 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12492; Mon, 8 Jul 2002 17:43:07 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68Llej03128; Mon, 8 Jul 2002 16:47:40 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 16:43:58 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 16:43:58 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 17:43:57 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImtifUuI8DrDTlR82P34Xy7o1IaAAAQf9QAARgF6A= To: , X-OriginalArrivalTime: 08 Jul 2002 21:43:58.0303 (UTC) FILETIME=[90B71EF0:01C226C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA29206 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rajeev: Some questions inline: -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: 08. July 2002 15:32 To: Chaskar Hemant (NRC/Boston) Cc: kempf@docomolabs-usa.com; gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Hemant, Hemant.Chaskar@nokia.com wrote: > Hi James: > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is CT is an optimization to avoid signaling and the associated overheads, and maintain desirable transport (RTP/TCP)performance. A historical note: CT was not designed to be an optimization for NSIS. [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR - MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you suggesting that NSIS should design its independent AR-AR protocol.? > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. This was discussed earlier. In essence, - with some standard Profile Types, you would expect participating routers to support a majority of the feature contexts. In the absence of additional protocol support (e.g., CARD), transferring what you have is just fine. The receiving router ignores the context(s) it does not understand. London IETF was where we specifically had this discussion in depth. [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa). - when a feature context type is not understood, CT should provide a notification. Such a notification is also useful when a feature context is partially understood. This notification could be used as a trigger to engage in NSIS signaling. This was presented at the NSIS interim WG meeting. > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > Ok. When CARD is available, it can provide input to CT. [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed? [Hemant] Hemant -Rajeev > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 08. July 2002 12:39 > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > Overally, I think it is a good description of one possible integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service context between > > ANRs. > > NSIS is concerned with the signalling of service requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > The intention has always been that CT work as a context transfer mechanism > > with a variety of mobility and service signalling solutions. There is a > > significant > > benefit in the real world to be realized in keeping the context transfer > > solution > > (CT) independent from the service signalling solution (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 18:18:45 2002 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 SAA14191 for ; Mon, 8 Jul 2002 18:18:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02171 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 18:19:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01548; Mon, 8 Jul 2002 18:06:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01511 for ; Mon, 8 Jul 2002 18:06:12 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13722 for ; Mon, 8 Jul 2002 18:05:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA10700; Mon, 8 Jul 2002 15:05:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68M5eH22274; Mon, 8 Jul 2002 15:05:40 -0700 X-mProtect: <200207082205> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.79.113, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXzbpOZ; Mon, 08 Jul 2002 15:05:35 PDT Message-ID: <3D2A0CA8.8060507@iprg.nokia.com> Date: Mon, 08 Jul 2002 15:05:28 -0700 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020618 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: john.loughney@nokia.com, robert.hancock@roke.co.uk, erafodo@ESEALNT448.al.sw.ericsson.se, nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6562B@esebe004.NOE.Nokia.com> <2031290.1025867122@[192.168.102.207]> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Marcus, sorry for being late here... Marcus Brunner wrote: > I see CT as an optimization only and not required for NSIS. However, > since there is a tendency to support only on-path signaling, this > would not work anyway (because CT would need off-path signaling for at > least some time). I do not understand your first statement. Could you explain it to me a bit more? Are you saying that an optimized solution should not be considered? Your requirement draft requires the air interface to be 'efficient'. What is the difference between 'efficient' and 'optimized'? If you mean to say that: in a first phase, the design should focus on making NSIS a stand-alone protocol, and the later integrate CT, then I totally agree with you. I just hope that this is being kept in mind while designing this first phase. Actually, I don't inderstand the second statement either. Technically, CT signaling is not part of NSIS, so whether it is on or off-line does not make much of a difference from NSIS perspective. From AR on, NSIS takes over, and is on-line if you wish so. In your draft terms, the AR functions as the initiator. I hope that you don't mean to say that it won't be possible to integrate CT with NSIS in a second phase of design, as it is off-path. Could you please clarify? Thanks, Cedric. > > > Marcus > > --On Donnerstag, 4. Juli 2002 11:33 +0300 john.loughney@nokia.com wrote: > >> Hi Robert, >> >>> On the 'edge signalling' case, I guess the main point is that >>> I'm confused about the scope of seamoby CT. Specifically >>> regarding MN-AR signalling (no issue about the AR-AR part): >> >> >> From my viewpoint, CT is not required for NSIS. I view CT as >> one tool that an NSIS solution could use. So, I definately think >> that at some point, we will need some sort of applicability >> statement describing how to use CT for NSIS. >> >> John >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Mon Jul 8 19:15:11 2002 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 TAA16515 for ; Mon, 8 Jul 2002 19:15:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06682 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 19:16:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05703; Mon, 8 Jul 2002 19:02:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05643 for ; Mon, 8 Jul 2002 19:01:56 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15912; Mon, 8 Jul 2002 19:01:04 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA14127; Mon, 8 Jul 2002 16:01:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68N1Nk25328; Mon, 8 Jul 2002 16:01:23 -0700 X-mProtect: <200207082301> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNMXJ4N; Mon, 08 Jul 2002 16:01:21 PDT Message-ID: <3D2A19C2.CB8889D9@iprg.nokia.com> Date: Mon, 08 Jul 2002 16:01:22 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Hemant.Chaskar@nokia.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: <3D29E8B4.71E86F9A@iprg.nokia.com> <021401c226c7$91cc54f0$4f6015ac@T23KEMPF> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > > CT is an optimization to avoid signaling and the associated overheads, and maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. > I meant when CT got started, there was no NSIS. However, our objective has been to avoid signaling overheads (bandwidth, delay, unreliable link effects,..) and (hence) maintain desirable transport performance. -Rajeev > > jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 19:58:19 2002 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 TAA18213 for ; Mon, 8 Jul 2002 19:58:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA09196 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 19:59:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08834; Mon, 8 Jul 2002 19:45:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08709 for ; Mon, 8 Jul 2002 19:45:45 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17658; Mon, 8 Jul 2002 19:44:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA16466; Mon, 8 Jul 2002 16:45:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68NjBN08913; Mon, 8 Jul 2002 16:45:11 -0700 X-mProtect: <200207082345> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEsWp86; Mon, 08 Jul 2002 16:45:08 PDT Message-ID: <3D2A2405.9E4B33B9@iprg.nokia.com> Date: Mon, 08 Jul 2002 16:45:09 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hemant.Chaskar@nokia.com wrote: > > > Hi James: > > > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is > > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > > [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR - If there is a need for re-establishing QoS along the new path, then yes. And, CT can trigger such a signaling when needed, and NSIS is probably the right place for this signaling. In the NSIS interim meeting, there seemed to be favorable response to this thinking when I made this point. > MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you Ofcourse CT is meant to enable "seamless handover", which includes transport protocol performance. > suggesting that NSIS should design its independent AR-AR protocol.? No. I am not saying that NSIS should design its own AR-AR protocol. However, it's for NSIS folks to decide why/when/how such a thing is needed :-) BTW, what I meant in my previous e-mail was that CT was conceived when NSIS was not on radar. I see NSIS might be useful in providing a MN - AR signaling mechanism that would establish feature contexts. However, feature contexts could be established by other means as well. > > > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. > > This was discussed earlier. In essence, > > - with some standard Profile Types, you would expect participating routers to > support a majority of the feature contexts. In the absence of additional > protocol support (e.g., CARD), transferring what you have is just fine. The > receiving router ignores the context(s) it does not understand. > London IETF was where we specifically had this discussion in depth. > > [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa). > A Profile Type could encode the parameter values. > > - when a feature context type is not understood, CT should provide a notification. > Such a notification is also useful when a feature context is partially understood. > This notification could be used as a trigger to engage in NSIS signaling. > This was presented at the NSIS interim WG meeting. > > > > > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > > > > Ok. When CARD is available, it can provide input to CT. > > [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed? > What is CARD doing here ? Figuring out capability or actually transferring contexts ? I am not sure.. I think the two should be treated separately. -Rajeev > > [Hemant] Hemant > > -Rajeev > > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 08. July 2002 12:39 > > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > > seamoby@ietf.org; nsis@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Re: > > draft-westphal-nsis-qos-mobileip-00.txt > > > > Could CT be viewed as an optimization of NSIS signaling? > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Monday, July 08, 2002 9:20 AM > > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > > > Hi Gary: > > > > > > Some comments inline: > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: 08. July 2002 12:00 > > > To: 'seamoby@ietf.org'; 'NSIS' > > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Sensitivity: Confidential > > > > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > > Overally, I think it is a good description of one possible integrated > > > approach. > > > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > > > The one general comment I would like to offer up at this time, is that while > > > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > > the > > > CIN message) is NSIS not CT. > > > > > > [Hemant] Point well taken. > > > > > > CT is concerned with the transfer of forwarding service context between > > > ANRs. > > > NSIS is concerned with the signalling of service requirements. Thus, the > > > issue > > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > > how > > > the CIN, etc., form part of the NSIS solution. > > > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > > loss of seamlessness. > > > > > > [Hemant] Thanks, Hemant > > > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > > The intention has always been that CT work as a context transfer mechanism > > > with a variety of mobility and service signalling solutions. There is a > > > significant > > > benefit in the real world to be realized in keeping the context transfer > > > solution > > > (CT) independent from the service signalling solution (NSIS) (and the > > > mobility > > > solution - MIP or whatever). I would think that there is also a benefit to > > > keeping > > > the MN to AR service signalling independent of CT. > > > > > > Stated a different way, do we really need two separate solutions for over > > > the air > > > (MN to AN) service signalling? > > > > > > Regards, > > > Gary Kenward > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 8 23:58:20 2002 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 XAA01500 for ; Mon, 8 Jul 2002 23:58:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA20639 for nsis-archive@odin.ietf.org; Mon, 8 Jul 2002 23:59:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20360; Mon, 8 Jul 2002 23:45:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20305 for ; Mon, 8 Jul 2002 23:45:03 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01081; Mon, 8 Jul 2002 23:44:08 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g693kxW27986; Tue, 9 Jul 2002 06:46:59 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Jul 2002 06:45:00 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 06:45:00 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jul 2002 06:44:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6568E@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImnk1mQ3tCY3p6QGmketUOdjRSZgAXGCeg To: , , , , X-OriginalArrivalTime: 09 Jul 2002 03:45:00.0496 (UTC) FILETIME=[00637500:01C226FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA20308 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James, > Could CT be viewed as an optimization of NSIS signaling? I would not state it that way. NSIS is working on on-path signaling; CT is decidedly off-path. CT is a tool that NSIS could co-operate with to ensure QoS, etc. for mobility. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 03:49:19 2002 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 DAA15392 for ; Tue, 9 Jul 2002 03:49:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11726 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 03:50:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11060; Tue, 9 Jul 2002 03:35:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11028 for ; Tue, 9 Jul 2002 03:35:48 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15077 for ; Tue, 9 Jul 2002 03:34:56 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDCKH>; Tue, 9 Jul 2002 08:35:15 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA447@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Hemant.Chaskar@nokia.com'" , cedric@iprg.nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] QoS framework. Date: Tue, 9 Jul 2002 08:35:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Hemant, I think it's clear that a higher level view of these issues is helpful as a prelude to discussion of particular potential protocols. What I'd really like to do is work out a clear boundary between CT and NSIS considered as black boxes, to see how they can support (or conversely work without) each other. Then we (in NSIS) could abstract that interaction into a requirement for more generic NSIS capability and reflect it in the framework, so it should be useful whatever specific protocol(s) NSIS was being used with. Unfortunately, I have difficulty working out the details of this boundary from pure requirements documents and have to try to reverse engineer it from protocols; hence my 'confusion' about things like whether CIN is a CT message or a proposed part of the NSIS solution. Any comments you could make on our (nb individual submission) framework draft would be helpful insights in this direction. In particular, I can imagine options as to whether: a) CT is used to transfer resource specific information (e.g. QoS) and then trigger NSIS to re-establish it in the network (and over the air if necessary), or b) CT is used to transfer protocol state (e.g. NSIS and whatever state information it is maintaining), and then let the protocol do its worst, or c) CT can be used to transfer anything. There are probably similar questions about CARD, but I haven't looked at it so closely. Actually, CARD seems to bring in questions about pre-authorisation and negotiation (maybe along the rest of the data path), so it's probably a much much harder issue. Oh dear... Cheers, Robert H. PS I guess these questions could be aimed at the wider seamoby community as well as NSIS; however, I'm posing it first at you and Cedric as people who are clearly interested in both. > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: 08 July 2002 16:09 > To: Georgios.Karagiannis@eln.ericsson.se; cedric@iprg.nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] QoS framework. > > > Hi Georgios: > > Please see inline: > > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 08. July 2002 9:14 > To: Weshphal Cedric (IPRG/MtView); Chaskar Hemant (NRC/Boston) > Cc: nsis@ietf.org > Subject: RE: [NSIS] QoS framework. > > > Hi Cedric and Hemant > > I have read your draft. In my opinion > this draft is too much oriented on seamoby and mobileip WG solutions. > > [Hemant] Thanks for reading the draft and subsequent > comments. I am inclined to diagree with your assessment that > the draft has specific (too much!) orientation towards > Seamoby or Mobile IP. The only place where I see some > connection to Seamoby is the proposal to use CIN message for > MN-AR signaling. But, we can always substitute it with NSIS > message (as we have been discussing on the NSIS list for past > few days). Beyond that, there isn't much, if any, orientation > towards Seamoby or MobileIP. I think that the draft is in > good agreement with NSIS framework document. > > In the draft "draft-hancock-nsis-fw-00.txt" we describe similar > mobility issues to what you tried to describe in your draft, but > we presented the solutions in a more general way without excluding > other solutions then seamoby and mobileip WG like solutions. > > [Hemant] IMHO, draft-hancock is a very high level view at the > framework issues (which is invaluable anyway). Proceeding to > solution may require much deeper look at individual signaling > tools optimized to specific use cases. Thus, the intent of > draft-westphal was to present a framework for specific use > case of layer 3 handoff. It can serve as intermediary between > high level framework and specific solution for layer 3 handoff case. > > Probably this draft is more suitable to be > used as a solution specific draft. > > [Hemant] As we move along with discussions and revisions, I > can foresee this draft becoming a solution draft for layer 3 > handoff case in the future. > > In my opinion the framework draft should be open to > more than one type of solutions. > > [Hemant] I agree with you on this. > > Best Regards, > Georgios > > [Hemant] Thanks, Hemant > > > > -----Original Message----- > From: Cedric Westphal [mailto:cedric@iprg.nokia.com] > Sent: Monday, June 24, 2002 7:47 PM > To: nsis@ietf.org > Cc: hemant.chaskar@nokia.com > Subject: [NSIS] QoS framework. > > > Hi all, > > we put together a document representing our perspective on a > NSIS qos signaling framework. > > Here is the abstract: > > Abstract > > This draft provides a framework for QoS signaling that is optimized > for Mobile IP handoffs. It covers the horizontal signaling between > access routers (ARs) as well as the vertical signaling along the > packet data path, both of which are triggered by handoff of mobile > node (MN). The key design goals are wireless bandwidth economy, > fast QoS establishment along the new data path after handoff and > secure protocol operation. > > > The document will eventually be available from the i-d editor > queue. However, > only after Yokohama meeting. You can find it at: > http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos -mobileip-00.txt in the meantime. Please send your comments, Cedric & Hemant. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 03:49:28 2002 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 DAA15406 for ; Tue, 9 Jul 2002 03:49:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11745 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 03:50:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11101; Tue, 9 Jul 2002 03:35:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11051 for ; Tue, 9 Jul 2002 03:35:50 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15080 for ; Tue, 9 Jul 2002 03:34:57 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDCK2>; Tue, 9 Jul 2002 08:35:34 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA448@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Schneider, Marco'" , nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing Date: Tue, 9 Jul 2002 08:35:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Marco, I think I understand your concerns and your example. I'm still not sure it translates into an NSIS requirement. To paraphrase (I hope correctly) your example as you describe it: 1. You have a flow which is taking a certain path through the network. 1a. NSIS messages are following that path, and reserving resources for it. Because there are enough resources on the particular path, the reservation is successful. 2. Someone adds a new link to the network, which changes the path in question. The new path is incapable of carrying the flow. 3. The reservation is routed along the new path. It's rejected (too little capacity) and all reservations associated with it are dropped. Clearly, that's undesirable. However, the problem is not with the NSIS signalling, so NSIS can't fix it: At point (2), if you are in a normal connectionless network, the flow will also be routed along the new path. NSIS is just (correctly) reflecting the fact that routing hasn't found the real 'best' route through the network. In other words, the real solution to the problem has to come from some routing trick which keeps the flow on the old path, and we referred to things in this class as 'non-traditional L3 routing' . If you can find a method to do this, then we want NSIS to continue to work if you are using it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or impossible is another question, but that seems to be the requirement.) Cheers, Robert H. > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: 08 July 2002 20:04 > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > John, > > As per my response to Marcus: I raised my concerns during the > meeting and > was asked to post an example, which I did. > > As for the text, I guess it is not clear to me whether this > addresses the > issue. In my opinion the example I gave does not have > anything to do with > non-traditional L3 routing. > > Marco > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Monday, June 10, 2002 8:29 AM > > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > Hi Marco & Marcus, > > > We discussed the issue of route pinning and traffic > engineering in > > > Helsinki. The conclusion during the meeting was that we > > want to add an > > > assuption saying: NSIS assumes normal/standard L3 routing > > > > > > Plus we add a requirement saying that NSIS protocol should > > not be broken by > > > networks which do non-traditional L3 routing. > > > > > > Does this cover your concern? Do we really need to add that > > NSIS must work > > > with default routing changes? > > > > I agree with Marcus that this is what we are trying to say. > > Marco, is this > > text OK with you? > > > > John > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 04:05:05 2002 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 EAA15626 for ; Tue, 9 Jul 2002 04:05:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12956 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 04:05:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11800; Tue, 9 Jul 2002 03:50:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11767 for ; Tue, 9 Jul 2002 03:50:51 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15439 for ; Tue, 9 Jul 2002 03:49:58 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDCLR>; Tue, 9 Jul 2002 08:50:47 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA44A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Schneider, Marco'" Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Tue, 9 Jul 2002 08:50:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="utf-8" Hi Marco, Maybe my one line clarification was a bit glib. What I really wanted to say was that there may be many 'reasons' for doing this signalling, and to emphasise that QoS is just one of them. Whether NSIS is about resources or services or applications or quality thereof is a rather separate issue. I agree that we've not found it easy to specify the meanings of any of these terms or indeed think of better ones. So, any lightweight suggestions on this front would be helpful. Robert H. > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: 08 July 2002 21:40 > To: Hancock, Robert; 'Zhigang.Kan@nokia.com'; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] New framework draft: Resource Management Function > v.s. QoS Management Function > > > Hi Robert, all > > I find our mapping of distinctions to terms confusing. The > term QOS is of > course short for Quality of Service. This begs the question > "what or which > service". In our context we seem to be speaking of packet > transport: A QOS > (quality of service) service being the ability to specify the > quality of > said packet transport service. For me, strictly speaking, QOS > is not an > example of a resource but rather a type of service that can > reasonably be > thought of to require resource reservations in a network. > What resources are > actually reserved or utilized to achieve QOS is beyond the > scope of our > work. Put another way a service is an abstraction of network > resources/capabilities and whether or not the service > implementation uses > said abstractions is beyond scope. > > Marco > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, June 27, 2002 5:45 AM > > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource > Management Function > > v.s. QoS Management Function > > > > > > Hi Zhigang, > > > > 'QoS' is one example of 'resource'. > > > > I'm actually not sure it is possible to define 'resource' > > precisely. The basic point is that NSIS should provide a > > generally useful signalling capability, which you could use > > for various types of resource; exactly what types is going to > > be defined implicitly by whether the NSIS capabilities are > > appropriate to the resource type needs. In that sense, > > there's a benefit in vagueness. > > > > An RMF is absolutely not a BB. In our framework, "RMF" is > > just a name for what NSIS offloads certain problems in > > resource management to, it's a way to talk about the boundary > > of the NSIS problem space. NSIS doesn't care how the RMF is > > implemented; it should be possible to support both > > centralised and distributed resource management strategies > > with the same NSIS protocol. The one thing that is ruled out > > (initially) is NSIS signalling directly to a centralised > > (off-path) entity; this is a consequence of recent scope > > guidance. Please see especially section 5.1 of the draft (the > > hardest section to write, by the way). > > > > Yours, > > > > Robert H. > > > > > > > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 27 June 2002 11:11 > > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > Hi all, > > > > > > Maybe we don't care what term/name is called. The most > > > important is that the "resources" and "resource management" > > > should be defined exactly, and the relationship between > > > resource and QoS should be clarified. Is RMF similar as BB? > > > > > > BR/Kan Zhigang > > > > > > -----Original Message----- > > > From: ext Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 2002å¹´6月27æ—¥ 17:47 > > > To: 'Hancock, Robert' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource Management > > > Function v. > > > s. QoS Management Function > > > > > > > > > Hi all > > > > > > I agree with the explanation given by Robert regarding > RMF. I am in > > > favor of keeping the term RMF. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Thursday, June 27, 2002 11:39 AM > > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > hi all, > > > > > > I think it's valuable for Zhigang to highlight the point, > > > because this is one of the major changes in this NSIS > > > framework input compared to (most?) previous ones (certainly > > > the ones I have been involved in). One of the consequences of > > > the email discussions around the time of the interim meeting > > > (e.g. > > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > > msg01378.html) was that we should look at more general > > > resources than just QOS. (IMHO, this is still not obvious > > > even in the post-interim clarified charter, BTW.) > > > > > > This has quite a big impact on what we write, at least. We > > > still need a good name for this "thing we are signalling > > > for", "resource" (and hence RMF) is a first guess. 'Service' > > > seems to me to be too general. The key point which is special > > > about NSIS is that the relevant resources are those which > > > have to be provided by entities along the data path, but I > > > can't think of a snappy term for that. > > > > > > The other impact is that we might need to broaden our > > > thinking about how such a signalling protocol might fit into > > > an overall solution to some resource management problem > > > (hence my interest in Marcus' firewall draft). Certainly, the > > > relationship between nsis and midcom/tist activities seems > > > important to understand. > > > > > > Robert H. > > > > > > > -----Original Message----- > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > Sent: 27 June 2002 10:10 > > > > To: Zhigang.Kan@nokia.com > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > Hi Kan, > > > > > > > > > Resource Management Function is introduced in this draft as > > > > > "RMF: an abstract concept, representing the management of > > > > > resources in a domain or a node". I think that this > > > > > definition is not appropriate for the aim of NSIS which is > > > > > Signaling QoS, not Signaling resource. > > > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > > is not only about QoS signaling, it is about service related > > > > signaling in general. What about calling the above system > > > > "Service Management Function"? > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > Hi all, > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > activities got together after the interim meeting to put > > > > > together a joint framework document in the form of an all-new > > > > > individual submission. It (roughly) follows the structure > > > > > that was introduced and refined at that meeting. > > > > > > > > > > ============================================================== > > > > > ============ > > > > > Abstract > > > > > > > > > > The NSIS working group is considering protocol > > developments in > > > > > signaling for resources for a traffic flow along its > > > path in the > > > > > network. The requirements for such signaling are being > > > > > developed in a > > > > > separate document; This Internet Draft proposes a > > > framework for > > > > > such signaling. This initial version provides a model for > > > > > describing > > > > > the entities that take part in the signaling and the > > > > ways in which > > > > > they can be used in different modes of operation. It also > > > > > discusses > > > > > the overall structure of such a signaling protocol. > > > Finally, it > > > > > considers the possible interactions of NSIS signaling > > > with other > > > > > protocols and functions, including security issues. > > > > > ============================================================== > > > > > ============ > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > find a copy here: > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > highlights in section 3. > > > > > > > > > > Cheers, > > > > > > > > > > Robert Hancock > > > > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 04:05:14 2002 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 EAA15639 for ; Tue, 9 Jul 2002 04:05:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12976 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 04:06:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11940; Tue, 9 Jul 2002 03:52:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11911 for ; Tue, 9 Jul 2002 03:52:05 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15461 for ; Tue, 9 Jul 2002 03:51:12 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g697lbB09780; Tue, 9 Jul 2002 09:47:37 +0200 To: "Hancock, Robert" Cc: "'Schneider, Marco'" , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 9 Jul 2002 09:51:24 +0200 Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/09/2002 09:51:25 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256BF1002A8CDC8f9e8a93df938690918cC1256BF1002A8CDC" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --0__=C1256BF1002A8CDC8f9e8a93df938690918cC1256BF1002A8CDC Content-type: text/plain; charset=us-ascii Hi Robert, Marco, I am not sure that NSIS has nothing to do with the fix of the problem described by Marco. If you have the capability to do routing of this displaced flow in a non-traditional way, then wouldn't you like NSIS not to tear down the existing reservations (I assume in your example you would have the reservations taken down, then start new NSIS signalling indicating the 'non-traditional' path) while you updating the signalling? Of course, if you want to support such a function you would need to be sure that the old path is still available. This requires the ability to distinguish between a failure on the old path and the availability of a new path. CU, Sven. "Hancock, Robert" @ietf.org on 09/07/2002 09:35:34 Sent by: nsis-admin@ietf.org To: "'Schneider, Marco'" , nsis@ietf.org cc: Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing Hi Marco, I think I understand your concerns and your example. I'm still not sure it translates into an NSIS requirement. To paraphrase (I hope correctly) your example as you describe it: 1. You have a flow which is taking a certain path through the network. 1a. NSIS messages are following that path, and reserving resources for it. Because there are enough resources on the particular path, the reservation is successful. 2. Someone adds a new link to the network, which changes the path in question. The new path is incapable of carrying the flow. 3. The reservation is routed along the new path. It's rejected (too little capacity) and all reservations associated with it are dropped. Clearly, that's undesirable. However, the problem is not with the NSIS signalling, so NSIS can't fix it: At point (2), if you are in a normal connectionless network, the flow will also be routed along the new path. NSIS is just (correctly) reflecting the fact that routing hasn't found the real 'best' route through the network. In other words, the real solution to the problem has to come from some routing trick which keeps the flow on the old path, and we referred to things in this class as 'non-traditional L3 routing' . If you can find a method to do this, then we want NSIS to continue to work if you are using it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or impossible is another question, but that seems to be the requirement.) Cheers, Robert H. > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: 08 July 2002 20:04 > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > John, > > As per my response to Marcus: I raised my concerns during the > meeting and > was asked to post an example, which I did. > > As for the text, I guess it is not clear to me whether this > addresses the > issue. In my opinion the example I gave does not have > anything to do with > non-traditional L3 routing. > > Marco > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Monday, June 10, 2002 8:29 AM > > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > Hi Marco & Marcus, > > > We discussed the issue of route pinning and traffic > engineering in > > > Helsinki. The conclusion during the meeting was that we > > want to add an > > > assuption saying: NSIS assumes normal/standard L3 routing > > > > > > Plus we add a requirement saying that NSIS protocol should > > not be broken by > > > networks which do non-traditional L3 routing. > > > > > > Does this cover your concern? Do we really need to add that > > NSIS must work > > > with default routing changes? > > > > I agree with Marcus that this is what we are trying to say. > > Marco, is this > > text OK with you? > > > > John > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > (See attached file: RMRL-Disclaimer.txt) --0__=C1256BF1002A8CDC8f9e8a93df938690918cC1256BF1002A8CDC Content-type: application/octet-stream; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: base64 VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCB0byBSb2tlIA0KTWFub3IgUmVzZWFyY2ggTHRkIGFuZCBtdXN0 IG5vdCBiZSBwYXNzZWQgdG8gYW55IHRoaXJkIHBhcnR5IHdpdGhvdXQgcGVybWlzc2lvbi4gVGhp cyANCmNvbW11bmljYXRpb24gaXMgZm9yIGluZm9ybWF0aW9uIG9ubHkgYW5kIHNoYWxsIG5vdCBj cmVhdGUgb3IgY2hhbmdlIGFueSBjb250cmFjdHVhbCANCnJlbGF0aW9uc2hpcC4NCg== --0__=C1256BF1002A8CDC8f9e8a93df938690918cC1256BF1002A8CDC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 04:30:46 2002 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 EAA16477 for ; Tue, 9 Jul 2002 04:30:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14481 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 04:31:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13398; Tue, 9 Jul 2002 04:17:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13304 for ; Tue, 9 Jul 2002 04:17:49 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16262 for ; Tue, 9 Jul 2002 04:16:56 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDC3R>; Tue, 9 Jul 2002 09:17:39 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA44B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" Cc: "'Schneider, Marco'" , nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing Date: Tue, 9 Jul 2002 09:17:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Sven, I'm confused by the phrase 'routing of the displaced flow'. I assumed that the whole point was to avoid displacing the flow in the first place. In fact, whether the path is determined by normal L3 routing or abnormal routing or any other mechanism is rather a second order problem. The fundamental aspect is that NSIS (I assume) has no role in determining that path, it takes the path as given and has to live with it. What would be helpful for me would be if someone could give an example of how the _flow_ (not the signalling) is going to get restricted to the old path. Then we could see if any special tricks would be needed to make NSIS work after this had been done. At the moment, I can't see what they would be. Cheers, Robert H. PS I'm sure that a topology aware system could do some sort of traffic engineering by setting up tunnels and so on. Whether this is a good thing to do I make no comment on; but I don't see what additional requirements would be needed to make NSIS work in such an environment. In any case, I get the feeling there's a danger that we're trying to use NSIS to recreate MPLS on the IP layer. One MPLS is enough for me... > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 09 July 2002 08:51 > To: Hancock, Robert > Cc: 'Schneider, Marco'; nsis@ietf.org > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > Hi Robert, Marco, > > I am not sure that NSIS has nothing to do with the fix of the problem > described by Marco. If you have the capability to do routing of this > displaced flow in a non-traditional way, then wouldn't you > like NSIS not to > tear down the existing reservations (I assume in your example > you would > have the reservations taken down, then start new NSIS > signalling indicating > the 'non-traditional' path) while you updating the > signalling? Of course, > if you want to support such a function you would need to be > sure that the > old path is still available. This requires the ability to distinguish > between a failure on the old path and the availability of a new path. > > CU, > Sven. > > > > > > "Hancock, Robert" @ietf.org on 09/07/2002 > 09:35:34 > > Sent by: nsis-admin@ietf.org > > > To: "'Schneider, Marco'" , nsis@ietf.org > cc: > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > Hi Marco, > > I think I understand your concerns and your example. I'm > still not sure it > translates into an NSIS requirement. > > To paraphrase (I hope correctly) your example as you describe it: > 1. You have a flow which is taking a certain path through the network. > 1a. NSIS messages are following that path, and reserving > resources for it. > Because there are enough resources on the particular path, > the reservation > is successful. > 2. Someone adds a new link to the network, which changes the path in > question. The new path is incapable of carrying the flow. > 3. The reservation is routed along the new path. It's > rejected (too little > capacity) and all reservations associated with it are dropped. > > Clearly, that's undesirable. However, the problem is not with the NSIS > signalling, so NSIS can't fix it: At point (2), if you are in a normal > connectionless network, the flow will also be routed along > the new path. > NSIS is just (correctly) reflecting the fact that routing > hasn't found the > real 'best' route through the network. > > In other words, the real solution to the problem has to come from some > routing trick which keeps the flow on the old path, and we referred to > things in this class as 'non-traditional L3 routing' . If you > can find a > method to do this, then we want NSIS to continue to work if > you are using > it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or > impossible is another question, but that seems to be the requirement.) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > Sent: 08 July 2002 20:04 > > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > John, > > > > As per my response to Marcus: I raised my concerns during the > > meeting and > > was asked to post an example, which I did. > > > > As for the text, I guess it is not clear to me whether this > > addresses the > > issue. In my opinion the example I gave does not have > > anything to do with > > non-traditional L3 routing. > > > > Marco > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Monday, June 10, 2002 8:29 AM > > > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > > Independence > > > ofexisting flow reservations and default routing > > > > > > > > > Hi Marco & Marcus, > > > > We discussed the issue of route pinning and traffic > > engineering in > > > > Helsinki. The conclusion during the meeting was that we > > > want to add an > > > > assuption saying: NSIS assumes normal/standard L3 routing > > > > > > > > Plus we add a requirement saying that NSIS protocol should > > > not be broken by > > > > networks which do non-traditional L3 routing. > > > > > > > > Does this cover your concern? Do we really need to add that > > > NSIS must work > > > > with default routing changes? > > > > > > I agree with Marcus that this is what we are trying to say. > > > Marco, is this > > > text OK with you? > > > > > > John > > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 04:56:16 2002 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 EAA16846 for ; Tue, 9 Jul 2002 04:56:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15686 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 04:57:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14779; Tue, 9 Jul 2002 04:36:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14751 for ; Tue, 9 Jul 2002 04:36:41 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16587 for ; Tue, 9 Jul 2002 04:35:48 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g698WJ331058; Tue, 9 Jul 2002 10:32:19 +0200 To: "Hancock, Robert" Cc: "'Schneider, Marco'" , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 9 Jul 2002 10:36:06 +0200 Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/09/2002 10:36:07 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256BF1002E01488f9e8a93df938690918cC1256BF1002E0148" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --0__=C1256BF1002E01488f9e8a93df938690918cC1256BF1002E0148 Content-type: text/plain; charset=us-ascii Hi Robert, I have some comments inline. CU, Sven. "Hancock, Robert" on 09/07/2002 10:17:38 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: "'Schneider, Marco'" , nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing Hi Sven, I'm confused by the phrase 'routing of the displaced flow'. I assumed that the whole point was to avoid displacing the flow in the first place. [Sven] I think there are two possible scenarios 1) The flow is displaced and NSIS will adapt its signalling (which will follow the new route). NSIS might need to do something during this transient, especially since it may be used to set up reservations on the new path (segment) 2) The flow is not displaced because it has been determined that the reservation on the new path is not feasible or because it is undesirable to move existing flows. In that case NSIS signalling needs to be able to indicate that its path should not be changed (maybe it has recorded the old path while it was being set up?) In both cases, there seems to be a need to defer the decision to reroute/re-reserve/re-establish until some check on the new path has been performed. I am wondering if this could have impact on NSIS. In fact, whether the path is determined by normal L3 routing or abnormal routing or any other mechanism is rather a second order problem. The fundamental aspect is that NSIS (I assume) has no role in determining that path, it takes the path as given and has to live with it. [Sven] Would it be possible for NSIS to record the path it has been given at setup time and express its requirement to stay on it? What would be helpful for me would be if someone could give an example of how the _flow_ (not the signalling) is going to get restricted to the old path. Then we could see if any special tricks would be needed to make NSIS work after this had been done. At the moment, I can't see what they would be. [Sven] Suppose a single route towards a destination is announced and later on another route towards that destination is announced with a QoS attribute. Then the flow could remain on that route, although a new (best-effort) route becomes available. Would that be a valid example? Cheers, Robert H. PS I'm sure that a topology aware system could do some sort of traffic engineering by setting up tunnels and so on. Whether this is a good thing to do I make no comment on; but I don't see what additional requirements would be needed to make NSIS work in such an environment. In any case, I get the feeling there's a danger that we're trying to use NSIS to recreate MPLS on the IP layer. One MPLS is enough for me... > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 09 July 2002 08:51 > To: Hancock, Robert > Cc: 'Schneider, Marco'; nsis@ietf.org > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > Hi Robert, Marco, > > I am not sure that NSIS has nothing to do with the fix of the problem > described by Marco. If you have the capability to do routing of this > displaced flow in a non-traditional way, then wouldn't you > like NSIS not to > tear down the existing reservations (I assume in your example > you would > have the reservations taken down, then start new NSIS > signalling indicating > the 'non-traditional' path) while you updating the > signalling? Of course, > if you want to support such a function you would need to be > sure that the > old path is still available. This requires the ability to distinguish > between a failure on the old path and the availability of a new path. > > CU, > Sven. > > > > > > "Hancock, Robert" @ietf.org on 09/07/2002 > 09:35:34 > > Sent by: nsis-admin@ietf.org > > > To: "'Schneider, Marco'" , nsis@ietf.org > cc: > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > Independence > ofexisting flow reservations and default routing > > > Hi Marco, > > I think I understand your concerns and your example. I'm > still not sure it > translates into an NSIS requirement. > > To paraphrase (I hope correctly) your example as you describe it: > 1. You have a flow which is taking a certain path through the network. > 1a. NSIS messages are following that path, and reserving > resources for it. > Because there are enough resources on the particular path, > the reservation > is successful. > 2. Someone adds a new link to the network, which changes the path in > question. The new path is incapable of carrying the flow. > 3. The reservation is routed along the new path. It's > rejected (too little > capacity) and all reservations associated with it are dropped. > > Clearly, that's undesirable. However, the problem is not with the NSIS > signalling, so NSIS can't fix it: At point (2), if you are in a normal > connectionless network, the flow will also be routed along > the new path. > NSIS is just (correctly) reflecting the fact that routing > hasn't found the > real 'best' route through the network. > > In other words, the real solution to the problem has to come from some > routing trick which keeps the flow on the old path, and we referred to > things in this class as 'non-traditional L3 routing' . If you > can find a > method to do this, then we want NSIS to continue to work if > you are using > it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or > impossible is another question, but that seems to be the requirement.) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > Sent: 08 July 2002 20:04 > > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > John, > > > > As per my response to Marcus: I raised my concerns during the > > meeting and > > was asked to post an example, which I did. > > > > As for the text, I guess it is not clear to me whether this > > addresses the > > issue. In my opinion the example I gave does not have > > anything to do with > > non-traditional L3 routing. > > > > Marco > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Monday, June 10, 2002 8:29 AM > > > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > > Independence > > > ofexisting flow reservations and default routing > > > > > > > > > Hi Marco & Marcus, > > > > We discussed the issue of route pinning and traffic > > engineering in > > > > Helsinki. The conclusion during the meeting was that we > > > want to add an > > > > assuption saying: NSIS assumes normal/standard L3 routing > > > > > > > > Plus we add a requirement saying that NSIS protocol should > > > not be broken by > > > > networks which do non-traditional L3 routing. > > > > > > > > Does this cover your concern? Do we really need to add that > > > NSIS must work > > > > with default routing changes? > > > > > > I agree with Marcus that this is what we are trying to say. > > > Marco, is this > > > text OK with you? > > > > > > John > > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. (See attached file: RMRL-Disclaimer.txt) --0__=C1256BF1002E01488f9e8a93df938690918cC1256BF1002E0148 Content-type: application/octet-stream; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: base64 VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCB0byBSb2tlIA0KTWFub3IgUmVzZWFyY2ggTHRkIGFuZCBtdXN0 IG5vdCBiZSBwYXNzZWQgdG8gYW55IHRoaXJkIHBhcnR5IHdpdGhvdXQgcGVybWlzc2lvbi4gVGhp cyANCmNvbW11bmljYXRpb24gaXMgZm9yIGluZm9ybWF0aW9uIG9ubHkgYW5kIHNoYWxsIG5vdCBj cmVhdGUgb3IgY2hhbmdlIGFueSBjb250cmFjdHVhbCANCnJlbGF0aW9uc2hpcC4NCg== --0__=C1256BF1002E01488f9e8a93df938690918cC1256BF1002E0148-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 06:22:46 2002 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 GAA18619 for ; Tue, 9 Jul 2002 06:22:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21422 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 06:23:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20386; Tue, 9 Jul 2002 06:07:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20355 for ; Tue, 9 Jul 2002 06:07:44 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18210 for ; Tue, 9 Jul 2002 06:06:50 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g69A7drU006678; Tue, 9 Jul 2002 12:07:39 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKBL6RF; Tue, 9 Jul 2002 12:07:39 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 12:07:38 +0200 Message-ID: X-Sybari-Trust: 048f4a9d 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'Cedric Westphal'" , brunner@ccrle.nec.de Cc: john.loughney@nokia.com, robert.hancock@roke.co.uk, erafodo@ESEALNT448.al.sw.ericsson.se, nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Date: Tue, 9 Jul 2002 12:01:49 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cedric What Marcus means is that CT may be used to optimise the QoS process during handoff, but it is not mandatory to use CT in NSIS. You could for example, perform a handoff and use NSIS for QoS without applying context transfers. Best Regards, Georgios -----Original Message----- From: Cedric Westphal [mailto:cedric@iprg.nokia.com] Sent: Tuesday, July 09, 2002 12:05 AM To: brunner@ccrle.nec.de Cc: john.loughney@nokia.com; robert.hancock@roke.co.uk; erafodo@ESEALNT448.al.sw.ericsson.se; nsis@ietf.org; Hemant.Chaskar@nokia.com Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Marcus, sorry for being late here... Marcus Brunner wrote: > I see CT as an optimization only and not required for NSIS. However, > since there is a tendency to support only on-path signaling, this > would not work anyway (because CT would need off-path signaling for at > least some time). I do not understand your first statement. Could you explain it to me a bit more? Are you saying that an optimized solution should not be considered? Your requirement draft requires the air interface to be 'efficient'. What is the difference between 'efficient' and 'optimized'? If you mean to say that: in a first phase, the design should focus on making NSIS a stand-alone protocol, and the later integrate CT, then I totally agree with you. I just hope that this is being kept in mind while designing this first phase. Actually, I don't inderstand the second statement either. Technically, CT signaling is not part of NSIS, so whether it is on or off-line does not make much of a difference from NSIS perspective. From AR on, NSIS takes over, and is on-line if you wish so. In your draft terms, the AR functions as the initiator. I hope that you don't mean to say that it won't be possible to integrate CT with NSIS in a second phase of design, as it is off-path. Could you please clarify? Thanks, Cedric. > > > Marcus > > --On Donnerstag, 4. Juli 2002 11:33 +0300 john.loughney@nokia.com wrote: > >> Hi Robert, >> >>> On the 'edge signalling' case, I guess the main point is that >>> I'm confused about the scope of seamoby CT. Specifically >>> regarding MN-AR signalling (no issue about the AR-AR part): >> >> >> From my viewpoint, CT is not required for NSIS. I view CT as >> one tool that an NSIS solution could use. So, I definately think >> that at some point, we will need some sort of applicability >> statement describing how to use CT for NSIS. >> >> John >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 12:01:29 2002 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 MAA00777 for ; Tue, 9 Jul 2002 12:01:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16460 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 12:02:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12512; Tue, 9 Jul 2002 11:34:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12481 for ; Tue, 9 Jul 2002 11:34:10 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29368 for ; Tue, 9 Jul 2002 11:33:17 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g69FY8Rb010667; Tue, 9 Jul 2002 17:34:08 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKBPTBB; Tue, 9 Jul 2002 17:34:08 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 17:34:08 +0200 Message-ID: X-Sybari-Trust: 43ab6f96 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: =?iso-8859-1?Q?=27Olov_Schel=E9n=27?= Cc: "'Alban.Couturier@alcatel.fr'" , nsis@ietf.org Subject: RE: [NSIS] comments on draft in-path and out of path (draft-sche len-nsis-opopsig-00.txt) Date: Tue, 9 Jul 2002 17:30:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12482 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Olov Please my remarks/comments in line and after the word [georgios]! Best Regards, Georgios -----Original Message----- From: Olov Schelén [mailto:olov.schelen@operax.com] Sent: Friday, July 05, 2002 2:32 PM To: Georgios Karagiannis (ELN) Cc: 'Alban.Couturier@alcatel.fr'; nsis@ietf.org Subject: Re: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-opopsig-00.txt) Georgious, thank you for your comments. I have included my response below. /Olov "Georgios Karagiannis (ELN)" wrote: > Dear Olov and Alban > > I have read your draft and I have some comments mainly on Sections 3 and 4 (see below). > > Best Regards, > Georgios > > Comments on Section 3.2.1: > ------------------------------------ > > Comment_1 on Section 3.2.1: > ----------------- > You mention that: > "The on-path signaling relies on the fundamental assumption that packets are all routed the > same way, based on the IP destination address. This will be called in this draft the > "traditional IP routing." > [georgios] Right but, you should not exclude other types of routing. In my opinion an > on path solution should consider > the possible cases described in {RFC2992] regarding: > "Analysis of an Equal-Cost Multi-Path Algorithm". > In general, if the signalling protocol uses the same routing protocol as the data > path then the signaling > messages and their associated data path packets will have to follow the same path. > [Olov] In RFC2992, nothing is said on that load-balancing is REQUIRED to be based on source-destination pairs of addresses only. The same holds for any traffic engineering methods. How this is done by real implementations I am not sure about, but would appreciate feedback on this. My understanding is that divergence of signalling-path and data-path can happen, at least at some points in the network. With MPLS there may be an approach for sending real-time traffic (e.g. VoIP) on separate LSPs and also to transfer the traffic to next domain on different interfaces. [georgios] What I tried to say is that what is described in RFC2992 should also be considered as traditional L3 routing. MPLS is not L3 traditional routing. > > Comment_2 on Section 3.2.1: > ------------- > I do not understand this comment: > "In these cases, a signaling unaware cloud is not anymore a signaling carrier, > as nothing assures it > will forward the signal at the same place it will forward the dataflow." > > [georgios] If the signalling protocol uses the same routing protocol as the data path then the > signaling messages and their associated data path packets will have to follow the same path. > This will have to be ensured even if the signaling protocol is not used in a certain domain. > A network provider may for example need to configure the network such that signalling path > messages follow the same path as the data path messages. However, this is a reasonable > requirement, since a network provider should be able to configure many other parameters > in his network. [olov] The problem here is that there may be domains along the path (perhaps over-provisioned and not signalling-aware) that do not follow this recomendation. In the backbone there is probably multiple peering-points, so once the signalling has diverted it may enter following domains at different ingresses. [georgios] Yes, but this then will also held for the out of path approach! Therefore, this issue is not only an on path issue, but also an out of path issue! Please be fair with your comparison! > > ------------------------------------------------------------------------------------------------- > > Comment on Section 3.2.2 > --------------------------- > In this section you are talking about centralized policy servers. > What about distributed policy servers? Distributed on the edge nodes of a domain! > ------------------------------------------------------------------------------------------------- > [olov] Yes they can be distributed physically, but they are logically centralized in the sense that they have a common understanding the commitments and resource availability in the domain. [georgios] In this situation the distributed policy servers are on path. But the way of how the common understanding is provided is out of scope of NSIS. > > Comment on Section 3.2.3 > ------------------- > You mentioned: > "One problem of RSVP and intserv is that every router in the network must implement > intserv and RSVP in order to link the sink and the source with a chain of QoS capable > routers that all allocate > resources for the flow." > > [georgios] not all routers in a communication path have to implement Intserv. > Actually, you mighty have domains that are overprovisioned and do not implement Intserv. > What I try to say is that this issue applies to both types of architectures, > i.e., on path and out of path. Therefore, it is not fair to presented here as an on > path issue! [olov] Yes, there may be over-provisioned and QoS un-aware doamins in both cases, so ensuring e2e QoS is difficult in both models. We do here however emphasise the need for having the signalling support in routers at all. Although only in edge-routers (as we explain) there are plenty of edge routers that need to handle this signalling. This is to compare with off-path (application-level) signalling that does not require particular support in routers at all. [georgios] yes e2e is difficult in both models, but ensuring out of path QoS support is more difficult than the in path QoS support. What I tried to emphasize here is that we need to be fair in the comparison of these two approaches. > > ------------------------------------------------------------------------------------------------- > > Comment on Section 4.2.1 > ----------------------------- > You mention that there are benefits of using independent signaling plane and forwarding plane. > This is only a benefit only when only you will assume that the forwarding plane is > overprovisioned or, etc., > You can get the same situation with an on path signaling when you will assume that > a network consists of a concatenation of domains and the only routers that are using > the NSIS protocol are only few edge nodes. This is after assuming that all the other routers > are overprovisioned. > Thus I do not see this issue as a benefit of the out of path architecture! > ------------------------------------------------------------------------------------------------- > [olov] I refer to my response to your previous comment. [georgios] I also refer to my previous reply to your previous remark. > > Comment on Section 4.2.2 > --------------- > You mentioned that VoIP or multimedia network applications rely on servers > such as soft switches, gatekeepers, etc.,,. > You also mention that on-path signaling solutions require complex deployments that can be > avoided thanks to the placement's flexibility associated to the off-path model. > In my opinion the solutions that are needed for a centralized entity located out of path > to efficiently configure, efficiently manage resources, and efficiently communicate with > the routers that are on path and are not using the NSIS protocol are much more complicated than > the solutions that you will need to use when the servers are located on path. [olov] Standards-wise the off-path model only needs a high-level protocol to be set (e.g. containers over TCP and possibly also over some well known applicaton level protocol). In addition, it would be nice to use an efficient standard for setting traffic conditioners at edges (e.g., COPS-PR plus standardised PIBs, SNMPCONF plus standardised MIBs, etc). Standards-wise this is simpler, relatively speaking. Note that conditioners would only be operated at microflow-level at accesses, while the rest would be on larger aggregates (constrained on destination prefixes, etc) . Implementation-wise I see only your opinion, so I respond only by ensuring that there are solutions that are just running fine. [georgios] In my remark I wanted to emphasize that a centralized entity located out of path needs to efficiently configure, efficiently manage resources, and efficiently communicate with the routers that are on path and are not using the NSIS protocol. When these procedures have to be performed on demand (and online) are more complicated then the procedures that have to be used for an on-path approach. > > Comment in Section 4.2.3 > ------------------------------ > This benefit is associated with an on path disadvantage given in Section 3.2.1. > The comment that I gave there applies also here! > In general, if the signalling protocol uses the same routing protocol as the data path > then the signaling > messages and their associated data path packets will have to follow the same path. [olov] Our intent here is to state exactly what you say, i.e., that the problem of keeping track of non-traditional routing applies also in the off-path case. [georgios] Yes, but you present it as a benefit of the out of path approach (not as a benefit for the on-path approach). Please be fair with your comparison! > > Comment in Section 4.3 > ---------------------------- > > I would like to add some more issues with the out of path signaling: > The out of path signaling scenario, compared to the in-path > signaling, introduces the need of a centralized architecture > (which can in turn be distributed). Having an architecture > with centralized decision-making capabilities means that > certain kinds of issues must be handled: > > * There may be a single point of failure > > Failure detection and error recovery are tremendously > important. > [olov] Failure detection are tremendously important in both models. In the off-path model there is no single point of failure when the implementation is distributed (and nodes can operate independently ). I see that the same problem applies for on-path, so I agree that we should add this as an importand issue in general. [georgios] Yes, in the situation that the implementation is distributed and out of path there will not be a single point of failure. However, I think that there will be much less points of failures than in an on-path approach. Thus, the failure detection and error recovery procedures are much more important in the out of path approach, compared to the on-path approach. > > > * Checking for availability of resources within a domain may be > based on either static or dynamic configuration data. > If this is done dynamically, the RTT of the signalling > protocol itself could be increased. This is an addition to the text > that you propose in Section 4.3.2. [olov] Well, thats true if you prefer to do it that way. However, instant traffic measures are often not a good basis for predicting the future. Rather you would rely on periodic feedback and perhaps heuristics. Anyway this information will be collected as a background process that does not affect the RTT of the signalling itself. > > > * The centralized resource management entity might become > congested faster due to the higher number of signaling > requests compared to a distributed resource management > architecture. [olov] It is very hard to make definite statements about performance in both models. Evaluation by real operators is probably the best way to go. However, servers are dealing with this kind of computational tasks quite well, while routers are good at packet forwarding (not known for handling slow-path tasks very efficiently). Also hierarchical aggregation keeps down the overhead. [georgios] Well, there are a lot of studies that show that centralized entities in networks are performance bottlenecks. > > > * Sophisticated mechanisms for discovery of the centralized > entities are needed. This is an addition to your Section 4.3.1. > [olov] QoS controlers can also be configured with peering relations (much like BGP-routers are configured with peering-relations today). For end-hosts (in case it would be desirable for hosts to be initiators), configuration could be through dhcp-like mechanism. [georgios] Only if the number of the out of path entities is limited! > > * Routing of signaling messages might affect the routing of > data path. This is similar to the issue explained in > Section 4.3.1. > > * Anytime a handover or a route change takes place, the > routing of the data path may change. Mechanisms are needed > to relate the path that signaling messages and data path > packets follow. This is similar to the issue explained in > Section 4.3.1. > > _ [olov] For these two, see previous responds. [georgios] Please see also my previous responds. > ______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Olov Schelén, CTO Operax AB Tel +46 920 7 5516 Aurorum 8 Mobile +46 705 79 5516 SE 977 75 Luleå olov.schelen@operax.com www.operax.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 12:05:26 2002 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 MAA00952 for ; Tue, 9 Jul 2002 12:05:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16631 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 12:06:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14090; Tue, 9 Jul 2002 11:51:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13995 for ; Tue, 9 Jul 2002 11:51:38 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00185 for ; Tue, 9 Jul 2002 11:50:42 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g69FtGj28966 for ; Tue, 9 Jul 2002 10:55:16 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Jul 2002 10:51:34 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 10:51:33 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] QoS framework. Date: Tue, 9 Jul 2002 11:51:31 -0400 Message-ID: Thread-Topic: [NSIS] QoS framework. Thread-Index: AcInG0aq2dB1hSurRVCfg/drFnHnyAAQ/cQA To: , Cc: X-OriginalArrivalTime: 09 Jul 2002 15:51:33.0890 (UTC) FILETIME=[80137E20:01C22760] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14000 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, A picture is worth thousand words :-). What do you think about the following picture as a depiction of CT-NSIS relationship, with the side note that both of these models MUST be possible. Legend: ---- NSIS signaling --- CT ---- 1. No CT-NSIS interaction ^ ^ || || || || Old AR New AR || || MN(Initiator) MN (Initiator) 2. CT as optimization for NSIS: Here CT merely empowers new AR to be NSIS message initiator on behalf of arriving MN. ^ ^ || || || CT || Old AR---->New AR (Initiator) || MN (Initiator) MN (Here, CT is merely transfering QoS description at old AR to new AR and new AR initiates NSIS signaling using this description. But, what if new path can support better or worse QoS than the old one? Then, NSIS should adapt while MN is connected to new AR.) Hemant -----Original Message----- From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 09. July 2002 3:35 To: Chaskar Hemant (NRC/Boston); Weshphal Cedric (IPRG/MtView) Cc: nsis@ietf.org Subject: RE: [NSIS] QoS framework. Hi Hemant, I think it's clear that a higher level view of these issues is helpful as a prelude to discussion of particular potential protocols. What I'd really like to do is work out a clear boundary between CT and NSIS considered as black boxes, to see how they can support (or conversely work without) each other. Then we (in NSIS) could abstract that interaction into a requirement for more generic NSIS capability and reflect it in the framework, so it should be useful whatever specific protocol(s) NSIS was being used with. Unfortunately, I have difficulty working out the details of this boundary from pure requirements documents and have to try to reverse engineer it from protocols; hence my 'confusion' about things like whether CIN is a CT message or a proposed part of the NSIS solution. Any comments you could make on our (nb individual submission) framework draft would be helpful insights in this direction. In particular, I can imagine options as to whether: a) CT is used to transfer resource specific information (e.g. QoS) and then trigger NSIS to re-establish it in the network (and over the air if necessary), or b) CT is used to transfer protocol state (e.g. NSIS and whatever state information it is maintaining), and then let the protocol do its worst, or c) CT can be used to transfer anything. There are probably similar questions about CARD, but I haven't looked at it so closely. Actually, CARD seems to bring in questions about pre-authorisation and negotiation (maybe along the rest of the data path), so it's probably a much much harder issue. Oh dear... Cheers, Robert H. PS I guess these questions could be aimed at the wider seamoby community as well as NSIS; however, I'm posing it first at you and Cedric as people who are clearly interested in both. > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: 08 July 2002 16:09 > To: Georgios.Karagiannis@eln.ericsson.se; cedric@iprg.nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] QoS framework. > > > Hi Georgios: > > Please see inline: > > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 08. July 2002 9:14 > To: Weshphal Cedric (IPRG/MtView); Chaskar Hemant (NRC/Boston) > Cc: nsis@ietf.org > Subject: RE: [NSIS] QoS framework. > > > Hi Cedric and Hemant > > I have read your draft. In my opinion > this draft is too much oriented on seamoby and mobileip WG solutions. > > [Hemant] Thanks for reading the draft and subsequent > comments. I am inclined to diagree with your assessment that > the draft has specific (too much!) orientation towards > Seamoby or Mobile IP. The only place where I see some > connection to Seamoby is the proposal to use CIN message for > MN-AR signaling. But, we can always substitute it with NSIS > message (as we have been discussing on the NSIS list for past > few days). Beyond that, there isn't much, if any, orientation > towards Seamoby or MobileIP. I think that the draft is in > good agreement with NSIS framework document. > > In the draft "draft-hancock-nsis-fw-00.txt" we describe similar > mobility issues to what you tried to describe in your draft, but > we presented the solutions in a more general way without excluding > other solutions then seamoby and mobileip WG like solutions. > > [Hemant] IMHO, draft-hancock is a very high level view at the > framework issues (which is invaluable anyway). Proceeding to > solution may require much deeper look at individual signaling > tools optimized to specific use cases. Thus, the intent of > draft-westphal was to present a framework for specific use > case of layer 3 handoff. It can serve as intermediary between > high level framework and specific solution for layer 3 handoff case. > > Probably this draft is more suitable to be > used as a solution specific draft. > > [Hemant] As we move along with discussions and revisions, I > can foresee this draft becoming a solution draft for layer 3 > handoff case in the future. > > In my opinion the framework draft should be open to > more than one type of solutions. > > [Hemant] I agree with you on this. > > Best Regards, > Georgios > > [Hemant] Thanks, Hemant > > > > -----Original Message----- > From: Cedric Westphal [mailto:cedric@iprg.nokia.com] > Sent: Monday, June 24, 2002 7:47 PM > To: nsis@ietf.org > Cc: hemant.chaskar@nokia.com > Subject: [NSIS] QoS framework. > > > Hi all, > > we put together a document representing our perspective on a > NSIS qos signaling framework. > > Here is the abstract: > > Abstract > > This draft provides a framework for QoS signaling that is optimized > for Mobile IP handoffs. It covers the horizontal signaling between > access routers (ARs) as well as the vertical signaling along the > packet data path, both of which are triggered by handoff of mobile > node (MN). The key design goals are wireless bandwidth economy, > fast QoS establishment along the new data path after handoff and > secure protocol operation. > > > The document will eventually be available from the i-d editor > queue. However, > only after Yokohama meeting. You can find it at: > http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos -mobileip-00.txt in the meantime. Please send your comments, Cedric & Hemant. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 12:19:40 2002 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 MAA01641 for ; Tue, 9 Jul 2002 12:19:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17318 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 12:20:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14507; Tue, 9 Jul 2002 11:57:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14476 for ; Tue, 9 Jul 2002 11:57:31 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00398 for ; Tue, 9 Jul 2002 11:56:37 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g69FqGm82848; Tue, 9 Jul 2002 17:52:16 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA04056; Tue, 9 Jul 2002 17:52:12 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 945A0B93B; Tue, 9 Jul 2002 17:52:11 +0200 (CEST) Date: Tue, 09 Jul 2002 17:52:11 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Schneider, Marco" , "'nsis@ietf.org'" Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Message-ID: <32776470.1026237131@[192.168.102.207]> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB64@TRIMAIL2.ad.tri.sbc.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB64@TRIMAIL2.ad.tri.sbc.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Probably you should ask the ADs or John. I think this was a requirement from there side, that we only regard traditional routing. In view, this means no load sharing, no trafic engineering. The latter might even not be a problem. Marcus --On Montag, 8. Juli 2002 13:39 -0500 "Schneider, Marco" wrote: > Marcus, > > Actually, during the meeting I raised my concerns and was asked to post an > example to the mailing list which I did. > > In reponse to your question, I am not sure what "non-traditional L3 > routing" is. I am not sure I see the relationship between the two issues. > Can you further elaborate. > > Thanks, > Marco > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: Friday, June 07, 2002 10:35 AM >> To: Schneider, Marco; 'nsis@ietf.org' >> Subject: req proposal (was Re: [NSIS] NSIS Requirement: >> Independence of >> existing flow reservations and default routing >> >> >> Marco, >> >> We discussed the issue of route pinning and traffic engineering in >> Helsinki. The conclusion during the meeting was that we want >> to add an >> assuption saying: NSIS assumes normal/standard L3 routing >> >> Plus we add a requirement saying that NSIS protocol should >> not be broken by >> networks which do non-traditional L3 routing. >> >> Does this cover your concern? Do we really need to add that >> NSIS must work >> with default routing changes? >> >> Marcus >> >> NSIS should not be broken by networks which do >> non-traditional L3 routing. >> >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" >> wrote: >> >> > Hi All, >> > >> > One of the Open issues mentioned in the current >> requirements draft is >> > Route Pinning (item 47). In the following I discuss a very strong >> > motivation for the ability to do route pinning if a soft >> state solution >> > is used for NSIS. I have tried to express this as a >> requirement upon NSIS >> > rather than the mechanism (route pinning being the obvious >> one) by which >> > this requirement may be achieved. >> > >> > Requirement: NSIS must directly support the ability to >> insulate a flow >> > reservation from changes in the default routing behaviour >> except in those >> > cases where said changes result from loss of resources >> (layer 3 hops, >> > capacity etc.) along the existing flow reservation path. >> > >> > For instance, utilizing traffic engineering in a layer 2 >> network (e.g. >> > MPLS or ATM) we may provision additional links or change >> the resources >> > associated with existing links. Additionally failures in >> the network may >> > cause changes. Such changes must not affect existing layer >> 3 reservation >> > paths with the exception of those cases where the existing >> reservation >> > path no longer exists or no longer has capacity to support the flow >> > reservation. >> > >> > As a simple example consider a network with two routers A >> and B and assume >> > that the shortest path from A to B is two hops. Based upon >> NSIS signaling, >> > as directed by default routing based upon number of hops, a >> reservation >> > path is setup from A to B along a path of two hops, where >> both hops have a >> > capacity of 10 and the reservation uses a capacity of 6. >> Now let us assume >> > that a direct link with capacity 5 is provisioned between A and B >> > resulting in a new and direct default route of 1 hop. If >> NSIS uses a soft >> > state solution without route pinning then the existing flow >> reservation >> > will be redirected along the new link, which cannot support >> it. Thus the >> > existing flow reservation is lost due a change in the >> network unrelated >> > to its current path. In fact thousands of reservations may have been >> > routed along the original path and would now be disrupted. >> Such protocol >> > behaviour is not acceptable. >> > >> > Best Regards, >> > Marco >> > >> > >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 12:49:19 2002 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 MAA02805 for ; Tue, 9 Jul 2002 12:49:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20635 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 12:50:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16563; Tue, 9 Jul 2002 12:05:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16534 for ; Tue, 9 Jul 2002 12:05:27 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00880 for ; Tue, 9 Jul 2002 12:04:32 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g69G14m83204; Tue, 9 Jul 2002 18:01:04 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA04149; Tue, 9 Jul 2002 18:01:00 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AE6714DF3E; Tue, 9 Jul 2002 18:00:59 +0200 (CEST) Date: Tue, 09 Jul 2002 18:01:00 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Schneider, Marco" , "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Message-ID: <33305060.1026237660@[192.168.102.207]> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB63@TRIMAIL2.ad.tri.sbc.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB63@TRIMAIL2.ad.tri.sbc.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Marco, see inline --On Montag, 8. Juli 2002 13:35 -0500 "Schneider, Marco" wrote: > Hi Marcus, > > Sorry for the very delayed reply. Allow me to quote for an earlier reply > to Georgios: > > "In my mind this requirement has do with the layering relationship between > QOS Signaling and Routing. In a hard-state solution once the QOS path is > created it does not unchange. The signaling protocol uses input from the > routing protocol to create this path. The path created is static. In an > RSVP style solution without route pinning we have a reactive distributed > algorithm that takes the default routing path as its input. While it > should be possible to do this style of path that is dynamically > determined by the default destination based routing, it must also be > possible to build the path once based upon an initial set of inputs." > > The fact that one can work around the deficiencies of a protocol layering > design does not mean the design is sound. > > Regarding Item 1: take care by introducing new links into your topology, > something you might want to do on lightly loaded metworks anyway. > > 1) The introduction of new links should not affect existing connections. you mean the path of existing reservations should not change? Is this a general operator requirement? With RSVP style siganling it definitly affects existing pathes. > 2) More specifically the operator should not have to be concerned with > whether addition of links could affect existing connections. I would assume that in most cases, and done on lightly loaded networks, this would not affect existing services. However, this can definitly happen, in certqain cases. Again do you feel other operators have similar concerns? > > Regarding Item 2: > I am not sure how constraint/qos routing goes into the mechanism of > provisioning. In fact the two are unrelated in IMHO. I do agree that QOS > routing appears to be out of scope. In QoS routing you choose the path not based on "normal routing", but based on resource availabiliy, which I relate to a function of the provisioning process (I agree in a sloppy way). Marcus > Marco > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: Friday, June 07, 2002 10:19 AM >> To: Schneider, Marco; 'nsis@ietf.org' >> Cc: 'sven.van_den_bosch@alcatel.be' >> Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow >> reservations and default routing >> >> >> Marco, >> >> IMHO the problem you have shown in the example can be solved >> in 2 ways, and >> both are IMO out of scope for NSIS. >> 1) take care by introducing new links into your topology, >> something you >> might want to do on lightly loaded metworks anyway. >> >> 2) I think an other solution would be constraint/QoS routing, >> which is more >> going into the mechanis of provisioning, which is again out of scope. >> >> >> Marcus >> >> >> >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" >> wrote: >> >> > Hi All, >> > >> > One of the Open issues mentioned in the current >> requirements draft is >> > Route Pinning (item 47). In the following I discuss a very strong >> > motivation for the ability to do route pinning if a soft >> state solution >> > is used for NSIS. I have tried to express this as a >> requirement upon NSIS >> > rather than the mechanism (route pinning being the obvious >> one) by which >> > this requirement may be achieved. >> > >> > Requirement: NSIS must directly support the ability to >> insulate a flow >> > reservation from changes in the default routing behaviour >> except in those >> > cases where said changes result from loss of resources >> (layer 3 hops, >> > capacity etc.) along the existing flow reservation path. >> > >> > For instance, utilizing traffic engineering in a layer 2 >> network (e.g. >> > MPLS or ATM) we may provision additional links or change >> the resources >> > associated with existing links. Additionally failures in >> the network may >> > cause changes. Such changes must not affect existing layer >> 3 reservation >> > paths with the exception of those cases where the existing >> reservation >> > path no longer exists or no longer has capacity to support the flow >> > reservation. >> > >> > As a simple example consider a network with two routers A >> and B and assume >> > that the shortest path from A to B is two hops. Based upon >> NSIS signaling, >> > as directed by default routing based upon number of hops, a >> reservation >> > path is setup from A to B along a path of two hops, where >> both hops have a >> > capacity of 10 and the reservation uses a capacity of 6. >> Now let us assume >> > that a direct link with capacity 5 is provisioned between A and B >> > resulting in a new and direct default route of 1 hop. If >> NSIS uses a soft >> > state solution without route pinning then the existing flow >> reservation >> > will be redirected along the new link, which cannot support >> it. Thus the >> > existing flow reservation is lost due a change in the >> network unrelated >> > to its current path. In fact thousands of reservations may have been >> > routed along the original path and would now be disrupted. >> Such protocol >> > behaviour is not acceptable. >> > >> > Best Regards, >> > Marco >> > >> > >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 13:51:58 2002 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 NAA05035 for ; Tue, 9 Jul 2002 13:51:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24963 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 13:52:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24270; Tue, 9 Jul 2002 13:32:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24204 for ; Tue, 9 Jul 2002 13:32:21 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04560 for ; Tue, 9 Jul 2002 13:31:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA26703; Tue, 9 Jul 2002 10:31:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69HVmD08888; Tue, 9 Jul 2002 10:31:48 -0700 X-mProtect: <200207091731> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.96, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGgIunP; Tue, 09 Jul 2002 10:31:39 PDT Message-ID: <3D2B1DF2.3020706@iprg.nokia.com> Date: Tue, 09 Jul 2002 10:31:30 -0700 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020618 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: brunner@ccrle.nec.de, john.loughney@nokia.com, robert.hancock@roke.co.uk, erafodo@ESEALNT448.al.sw.ericsson.se, nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) References: Content-Type: multipart/alternative; boundary="------------040309030309080602000406" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------040309030309080602000406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Georgios, then we are all in agreement. CT might not be available, or might fail, so NSIS cannot depend on it. 100% agree. I like Robert's way of phrasing it, actually, in terms of black boxes. Then the interfaces have to be specified so the black boxes can work with or without each other.. Cheers, Cedric. Georgios Karagiannis (ELN) wrote: >Hi Cedric > >What Marcus means is that CT may be used to optimise >the QoS process during handoff, but it is not mandatory to use >CT in NSIS. >You could for example, perform a handoff and use NSIS for QoS without >applying context transfers. > >Best Regards, >Georgios > > > > > > >-----Original Message----- >From: Cedric Westphal [mailto:cedric@iprg.nokia.com] >Sent: Tuesday, July 09, 2002 12:05 AM >To: brunner@ccrle.nec.de >Cc: john.loughney@nokia.com; robert.hancock@roke.co.uk; >erafodo@ESEALNT448.al.sw.ericsson.se; nsis@ietf.org; >Hemant.Chaskar@nokia.com >Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on >draft-westphal-nsis-qos-mobileip-00.txt) > > >Marcus, > >sorry for being late here... > >Marcus Brunner wrote: > > > >>I see CT as an optimization only and not required for NSIS. However, >>since there is a tendency to support only on-path signaling, this >>would not work anyway (because CT would need off-path signaling for at >>least some time). >> >> > >I do not understand your first statement. Could you explain it to me a >bit more? >Are you saying that an optimized solution should not be considered? Your >requirement draft requires the air interface to be 'efficient'. What is >the difference between 'efficient' and >'optimized'? If you mean to say that: in a first phase, the design >should focus on making NSIS >a stand-alone protocol, and the later integrate CT, then I totally agree >with you. I just hope that this is being kept in mind while designing >this first phase. > >Actually, I don't inderstand the second statement either. Technically, >CT signaling is not part of NSIS, so whether it is on or off-line does >not make much of a difference from NSIS perspective. From AR on, NSIS >takes over, and is on-line if you wish so. In your draft terms, the AR >functions as the initiator. I hope that you don't mean to say that it >won't be possible to integrate CT with NSIS in a second phase of design, >as it is off-path. Could you please clarify? Thanks, > >Cedric. > > > >>Marcus >> >>--On Donnerstag, 4. Juli 2002 11:33 +0300 john.loughney@nokia.com wrote: >> >> >> >>>Hi Robert, >>> >>> >>> >>>>On the 'edge signalling' case, I guess the main point is that >>>>I'm confused about the scope of seamoby CT. Specifically >>>>regarding MN-AR signalling (no issue about the AR-AR part): >>>> >>>> >>>From my viewpoint, CT is not required for NSIS. I view CT as >>>one tool that an NSIS solution could use. So, I definately think >>>that at some point, we will need some sort of applicability >>>statement describing how to use CT for NSIS. >>> >>>John >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >> >> >>-------------------------------------- >>Dr. Marcus Brunner >>Network Laboratories >>NEC Europe Ltd. >> >>E-Mail: brunner@ccrle.nec.de >>WWW: http://www.ccrle.nec.de/ >>personal home page: http://www.brubers.org/marcus >> >> >> >>_______________________________________________ >>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 > > --------------040309030309080602000406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Georgios,

then we are all in agreement. CT might not be available, or might fail,
so NSIS cannot depend on it. 100% agree.  I like Robert's way of
phrasing it, actually, in terms of black boxes. Then the interfaces have
to be specified so the black boxes can work with or without each other..
Cheers,

Cedric.

Georgios Karagiannis (ELN) wrote:
Hi Cedric

What Marcus means is that CT may be used to optimise 
the QoS process during handoff, but it is not mandatory to use 
CT in NSIS.
You could for example, perform a handoff and use NSIS for QoS without 
applying context transfers.

Best Regards,
Georgios






-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: Tuesday, July 09, 2002 12:05 AM
To: brunner@ccrle.nec.de
Cc: john.loughney@nokia.com; robert.hancock@roke.co.uk;
erafodo@ESEALNT448.al.sw.ericsson.se; nsis@ietf.org;
Hemant.Chaskar@nokia.com
Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on
draft-westphal-nsis-qos-mobileip-00.txt)


Marcus,

sorry for being late here...

Marcus Brunner wrote:

  
I see CT as an optimization only and not required for NSIS. However, 
since there is a tendency to support only on-path signaling, this 
would not work anyway (because CT would need off-path signaling for at 
least some time). 
    

I do not understand your first statement. Could you explain it to me a 
bit more?
Are you saying that an optimized solution should not be considered? Your 
requirement draft requires the air interface to be 'efficient'. What is 
the difference between 'efficient' and
'optimized'? If you mean to say that: in a first phase, the design 
should focus on making NSIS
a stand-alone protocol, and the later integrate CT, then I totally agree 
with you. I just hope that this is being kept in mind while designing 
this first phase.

Actually, I don't inderstand the second statement either. Technically, 
CT signaling is not part of NSIS, so whether it is on or off-line does 
not make much of a difference from NSIS perspective. From AR on, NSIS 
takes over, and is on-line if you wish so. In your draft terms, the AR 
functions as the initiator. I hope that you don't mean to say that it 
won't be possible to integrate CT with NSIS in a second phase of design, 
as it is off-path. Could you please clarify? Thanks,

Cedric.

  
Marcus

--On Donnerstag, 4. Juli 2002 11:33 +0300 john.loughney@nokia.com wrote:

    
Hi Robert,

      
On the 'edge signalling' case, I guess the main point is that
I'm confused about the scope of seamoby CT. Specifically
regarding MN-AR signalling (no issue about the AR-AR part):
        
From my viewpoint, CT is not required for NSIS. I view CT as
one tool that an NSIS solution could use.  So, I definately think
that at some point, we will need some sort of applicability
statement describing how to use CT for NSIS.

John

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


--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



_______________________________________________
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

--------------040309030309080602000406-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 15:49:44 2002 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 PAA14980 for ; Tue, 9 Jul 2002 15:49:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03337 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 15:50:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01314; Tue, 9 Jul 2002 15:25:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01283 for ; Tue, 9 Jul 2002 15:25:42 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13901 for ; Tue, 9 Jul 2002 15:24:46 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 17S0bh-00067Q-00; Tue, 09 Jul 2002 21:25:05 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g69JP5t29654; Tue, 9 Jul 2002 21:25:05 +0200 Message-ID: <3D2B3891.57EF2FF1@ee.tu-berlin.de> Date: Tue, 09 Jul 2002 21:25:05 +0200 From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Organization: Telecommunication Networks Group, Technical University Berlin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-686 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: Bob Braden CC: NSIS Subject: Re: [NSIS] Internet Draft on 2-level signaling architecture References: <200207081524.PAA17157@gra.isi.edu> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Bob, I have a comment regarding the usage of Ack/NAck message in your draft. I think one may use Ack/NAck either functionally or only informatively: - if one desires a quickest way to re-adjust/release installed states, it might be benificial for the last hop which deals with NEW (Mod?) message to piggyback some target (e.g., bottleneck capacity found of the route for Ack, or the IP address of the last failed hop), to do re-adjust or release in the reverse route. For NAck message it is mentioned in your draft, but I suspect Ack message can also be used this way. Whether to enable this capability could be indicated by the NEW/Mod message. This also implies PHOP information is needed in the states. - if one want a unified way to create/mod/remove from one single direction, Ack/NAck could be just informative, and will be returned silently to the initiator(, then a new Mod/Tear process could be started by the initiator). Cheers, Xiaoming Bob Braden wrote: > > I am on the NSIS agenda to talk briefly about my Internet Draft > "A Two-Level Architecture for Internet Signaling", > draft-braden-2level-signaling-00.txt, in Yokahama. > > Unfortunately, this draft has just expired (sorry to have not noticed > that before.) It is available on the RSVP web page > (http://www.isi.edu/rsvp) under "Publication", then "RSVP-Related > Internet Drafts". Or you can find it at > http://www.isi.edu/~braden/draft-braden-2level-signaling-00.txt. > > Bob Braden > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Jul 9 15:54:44 2002 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 PAA15149 for ; Tue, 9 Jul 2002 15:54:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03664 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 15:55:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02523; Tue, 9 Jul 2002 15:35:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02492 for ; Tue, 9 Jul 2002 15:35:23 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14350 for ; Tue, 9 Jul 2002 15:34:28 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA03637; Tue, 9 Jul 2002 12:35:09 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA26680; Tue, 9 Jul 2002 12:35:08 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA10131; Tue, 9 Jul 2002 15:35:07 -0400 (EDT) Message-ID: <3D2B3AEB.C9A0CB9E@dma.isg.mot.com> Date: Tue, 09 Jul 2002 15:35:07 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Schneider, Marco" CC: "'Hancock, Robert'" , Zhigang.Kan@nokia.com, Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: Re: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB68@TRIMAIL2.ad.tri.sbc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Perhaps what is missing is a definition of Quality of Service. This has been a long standing problem in the RFC series: I'm not aware of a single place where the term is defined. It is also true that the industry has no single accepted definition. While I'm not convinced that this is the right place to put such definitions, there doesn't seem to be a better one right now. The following may be a good start toward working definitons: Quality-of-Service(QoS): A set of attributes and their values that, taken together, characterize the performance experienced by a flow. End-to-end QoS: A set of attributes and their values that, taken together, characterize the performance experienced by an end-to-end flow, i.e., as observed by protocols above the IP layer Edge-to-edge QoS: A set of attributes and their values, that, taken together, characterize the performance experienced by a flow from the point where it enters a domain (or a concatenation of domains) to the point(s) where it leaves that (those) domain(s). Agreed QoS: A set of attributes and their values that have been agreed between a network (or concatentation of networks) and two (or more) hosts. This set characterizes the performance the network(s) agree that a flow will experience for a defined period. The agreement can be reached through signalling or administratively. Actual QoS: The measured values of a set of QoS attributes. "Schneider, Marco" wrote: > Hi Robert, all > > I find our mapping of distinctions to terms confusing. The term QOS is of > course short for Quality of Service. This begs the question "what or which > service". In our context we seem to be speaking of packet transport: A QOS > (quality of service) service being the ability to specify the quality of > said packet transport service. For me, strictly speaking, QOS is not an > example of a resource but rather a type of service that can reasonably be > thought of to require resource reservations in a network. What resources are > actually reserved or utilized to achieve QOS is beyond the scope of our > work. Put another way a service is an abstraction of network > resources/capabilities and whether or not the service implementation uses > said abstractions is beyond scope. > > Marco > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, June 27, 2002 5:45 AM > > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource Management Function > > v.s. QoS Management Function > > > > > > Hi Zhigang, > > > > 'QoS' is one example of 'resource'. > > > > I'm actually not sure it is possible to define 'resource' > > precisely. The basic point is that NSIS should provide a > > generally useful signalling capability, which you could use > > for various types of resource; exactly what types is going to > > be defined implicitly by whether the NSIS capabilities are > > appropriate to the resource type needs. In that sense, > > there's a benefit in vagueness. > > > > An RMF is absolutely not a BB. In our framework, "RMF" is > > just a name for what NSIS offloads certain problems in > > resource management to, it's a way to talk about the boundary > > of the NSIS problem space. NSIS doesn't care how the RMF is > > implemented; it should be possible to support both > > centralised and distributed resource management strategies > > with the same NSIS protocol. The one thing that is ruled out > > (initially) is NSIS signalling directly to a centralised > > (off-path) entity; this is a consequence of recent scope > > guidance. Please see especially section 5.1 of the draft (the > > hardest section to write, by the way). > > > > Yours, > > > > Robert H. > > > > > > > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 27 June 2002 11:11 > > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > Hi all, > > > > > > Maybe we don't care what term/name is called. The most > > > important is that the "resources" and "resource management" > > > should be defined exactly, and the relationship between > > > resource and QoS should be clarified. Is RMF similar as BB? > > > > > > BR/Kan Zhigang > > > > > > -----Original Message----- > > > From: ext Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 2002å¹´6月27æ—¥ 17:47 > > > To: 'Hancock, Robert' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource Management > > > Function v. > > > s. QoS Management Function > > > > > > > > > Hi all > > > > > > I agree with the explanation given by Robert regarding RMF. I am in > > > favor of keeping the term RMF. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Thursday, June 27, 2002 11:39 AM > > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > hi all, > > > > > > I think it's valuable for Zhigang to highlight the point, > > > because this is one of the major changes in this NSIS > > > framework input compared to (most?) previous ones (certainly > > > the ones I have been involved in). One of the consequences of > > > the email discussions around the time of the interim meeting > > > (e.g. > > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > > msg01378.html) was that we should look at more general > > > resources than just QOS. (IMHO, this is still not obvious > > > even in the post-interim clarified charter, BTW.) > > > > > > This has quite a big impact on what we write, at least. We > > > still need a good name for this "thing we are signalling > > > for", "resource" (and hence RMF) is a first guess. 'Service' > > > seems to me to be too general. The key point which is special > > > about NSIS is that the relevant resources are those which > > > have to be provided by entities along the data path, but I > > > can't think of a snappy term for that. > > > > > > The other impact is that we might need to broaden our > > > thinking about how such a signalling protocol might fit into > > > an overall solution to some resource management problem > > > (hence my interest in Marcus' firewall draft). Certainly, the > > > relationship between nsis and midcom/tist activities seems > > > important to understand. > > > > > > Robert H. > > > > > > > -----Original Message----- > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > Sent: 27 June 2002 10:10 > > > > To: Zhigang.Kan@nokia.com > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > Hi Kan, > > > > > > > > > Resource Management Function is introduced in this draft as > > > > > "RMF: an abstract concept, representing the management of > > > > > resources in a domain or a node". I think that this > > > > > definition is not appropriate for the aim of NSIS which is > > > > > Signaling QoS, not Signaling resource. > > > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > > is not only about QoS signaling, it is about service related > > > > signaling in general. What about calling the above system > > > > "Service Management Function"? > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > Hi all, > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > activities got together after the interim meeting to put > > > > > together a joint framework document in the form of an all-new > > > > > individual submission. It (roughly) follows the structure > > > > > that was introduced and refined at that meeting. > > > > > > > > > > ============================================================== > > > > > ============ > > > > > Abstract > > > > > > > > > > The NSIS working group is considering protocol > > developments in > > > > > signaling for resources for a traffic flow along its > > > path in the > > > > > network. The requirements for such signaling are being > > > > > developed in a > > > > > separate document; This Internet Draft proposes a > > > framework for > > > > > such signaling. This initial version provides a model for > > > > > describing > > > > > the entities that take part in the signaling and the > > > > ways in which > > > > > they can be used in different modes of operation. It also > > > > > discusses > > > > > the overall structure of such a signaling protocol. > > > Finally, it > > > > > considers the possible interactions of NSIS signaling > > > with other > > > > > protocols and functions, including security issues. > > > > > ============================================================== > > > > > ============ > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > find a copy here: > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > highlights in section 3. > > > > > > > > > > Cheers, > > > > > > > > > > Robert Hancock > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 9 19:20:07 2002 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 TAA21473 for ; Tue, 9 Jul 2002 19:20:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19933 for nsis-archive@odin.ietf.org; Tue, 9 Jul 2002 19:20:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18299; Tue, 9 Jul 2002 18:58:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18206 for ; Tue, 9 Jul 2002 18:58:40 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20965 for ; Tue, 9 Jul 2002 18:57:46 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDD85>; Tue, 9 Jul 2002 23:58:26 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203D10@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Dan Grossman , "Schneider, Marco" Cc: nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Tue, 9 Jul 2002 23:58:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Dan, Without wishing to appear negative about your proposal, I can't help pointing out a sentence in the 'clarified' charter (you can find it referred to in the interim meeting report): "It is out of scope of this working group to define what quality of service is." See also further down in this mail. In any case, we're supposed to be working on signalling for more generic things than just QoS. What would be really incredibly useful (for a framework obsessive like me) would be a definition of the attributes of these "things" which actually affect what the signalling has to be able to do. But this seems to be a hard problem. Cheers, Robert H. [Please note: I'm not saying that defining QoS is not an interesting general question. But given how hard it seems to be, maybe we should try to work out how much of a definition is actually needed to make progress in NSIS.] > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: 09 July 2002 20:35 > To: Schneider, Marco > Cc: Hancock, Robert; Zhigang.Kan@nokia.com; > Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org > Subject: Re: [NSIS] New framework draft: Resource Management Function > v.s.QoS Management Function > > > Perhaps what is missing is a definition of Quality of > Service. This has been a > long standing problem in the RFC series: I'm not aware of a > single place where > the term is defined. It is also true that the industry has > no single accepted > definition. While I'm not convinced that this is the right > place to put such > definitions, there doesn't seem to be a better one right now. > > The following may be a good start toward working definitons: > > Quality-of-Service(QoS): A set of attributes and their > values that, taken > together, characterize the performance experienced by a flow. > > End-to-end QoS: A set of attributes and their values that, > taken together, > characterize the performance experienced by an end-to-end > flow, i.e., as > observed by protocols above the IP layer > > Edge-to-edge QoS: A set of attributes and their values, > that, taken together, > characterize the performance experienced by a flow from the > point where it > enters a domain (or a concatenation of domains) to the > point(s) where it leaves > that (those) domain(s). > > Agreed QoS: A set of attributes and their values that have > been agreed between > a network (or concatentation of networks) and two (or more) > hosts. This set > characterizes the performance the network(s) agree that a > flow will experience > for a defined period. The agreement can be reached through > signalling or > administratively. > > Actual QoS: The measured values of a set of QoS attributes. > > "Schneider, Marco" wrote: > > > Hi Robert, all > > > > I find our mapping of distinctions to terms confusing. The > term QOS is of > > course short for Quality of Service. This begs the question > "what or which > > service". In our context we seem to be speaking of packet > transport: A QOS > > (quality of service) service being the ability to specify > the quality of > > said packet transport service. For me, strictly speaking, > QOS is not an > > example of a resource but rather a type of service that can > reasonably be > > thought of to require resource reservations in a network. > What resources are > > actually reserved or utilized to achieve QOS is beyond the > scope of our > > work. Put another way a service is an abstraction of network > > resources/capabilities and whether or not the service > implementation uses > > said abstractions is beyond scope. > > > > Marco > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Thursday, June 27, 2002 5:45 AM > > > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > Management Function > > > v.s. QoS Management Function > > > > > > > > > Hi Zhigang, > > > > > > 'QoS' is one example of 'resource'. > > > > > > I'm actually not sure it is possible to define 'resource' > > > precisely. The basic point is that NSIS should provide a > > > generally useful signalling capability, which you could use > > > for various types of resource; exactly what types is going to > > > be defined implicitly by whether the NSIS capabilities are > > > appropriate to the resource type needs. In that sense, > > > there's a benefit in vagueness. > > > > > > An RMF is absolutely not a BB. In our framework, "RMF" is > > > just a name for what NSIS offloads certain problems in > > > resource management to, it's a way to talk about the boundary > > > of the NSIS problem space. NSIS doesn't care how the RMF is > > > implemented; it should be possible to support both > > > centralised and distributed resource management strategies > > > with the same NSIS protocol. The one thing that is ruled out > > > (initially) is NSIS signalling directly to a centralised > > > (off-path) entity; this is a consequence of recent scope > > > guidance. Please see especially section 5.1 of the draft (the > > > hardest section to write, by the way). > > > > > > Yours, > > > > > > Robert H. > > > > > > > > > > > > > -----Original Message----- > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > Sent: 27 June 2002 11:11 > > > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > Hi all, > > > > > > > > Maybe we don't care what term/name is called. The most > > > > important is that the "resources" and "resource management" > > > > should be defined exactly, and the relationship between > > > > resource and QoS should be clarified. Is RMF similar as BB? > > > > > > > > BR/Kan Zhigang > > > > > > > > -----Original Message----- > > > > From: ext Georgios Karagiannis (ELN) > > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > > Sent: 2002å¹´6æoe^27æ-¥ 17:47 > > > > To: 'Hancock, Robert' > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource Management > > > > Function v. > > > > s. QoS Management Function > > > > > > > > > > > > Hi all > > > > > > > > I agree with the explanation given by Robert regarding > RMF. I am in > > > > favor of keeping the term RMF. > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > -----Original Message----- > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: Thursday, June 27, 2002 11:39 AM > > > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > hi all, > > > > > > > > I think it's valuable for Zhigang to highlight the point, > > > > because this is one of the major changes in this NSIS > > > > framework input compared to (most?) previous ones (certainly > > > > the ones I have been involved in). One of the consequences of > > > > the email discussions around the time of the interim meeting > > > > (e.g. > > > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > > > msg01378.html) was that we should look at more general > > > > resources than just QOS. (IMHO, this is still not obvious > > > > even in the post-interim clarified charter, BTW.) > > > > > > > > This has quite a big impact on what we write, at least. We > > > > still need a good name for this "thing we are signalling > > > > for", "resource" (and hence RMF) is a first guess. 'Service' > > > > seems to me to be too general. The key point which is special > > > > about NSIS is that the relevant resources are those which > > > > have to be provided by entities along the data path, but I > > > > can't think of a snappy term for that. > > > > > > > > The other impact is that we might need to broaden our > > > > thinking about how such a signalling protocol might fit into > > > > an overall solution to some resource management problem > > > > (hence my interest in Marcus' firewall draft). Certainly, the > > > > relationship between nsis and midcom/tist activities seems > > > > important to understand. > > > > > > > > Robert H. > > > > > > > > > -----Original Message----- > > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > > Sent: 27 June 2002 10:10 > > > > > To: Zhigang.Kan@nokia.com > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: Resource > > > > Management Function > > > > > v.s. QoS Management Function > > > > > > > > > > > > > > > Hi Kan, > > > > > > > > > > > Resource Management Function is introduced in this draft as > > > > > > "RMF: an abstract concept, representing the management of > > > > > > resources in a domain or a node". I think that this > > > > > > definition is not appropriate for the aim of NSIS which is > > > > > > Signaling QoS, not Signaling resource. > > > > > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > > > is not only about QoS signaling, it is about service related > > > > > signaling in general. What about calling the above system > > > > > "Service Management Function"? > > > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > > activities got together after the interim meeting to put > > > > > > together a joint framework document in the form of > an all-new > > > > > > individual submission. It (roughly) follows the structure > > > > > > that was introduced and refined at that meeting. > > > > > > > > > > > > > ============================================================== > > > > > > ============ > > > > > > Abstract > > > > > > > > > > > > The NSIS working group is considering protocol > > > developments in > > > > > > signaling for resources for a traffic flow along its > > > > path in the > > > > > > network. The requirements for such signaling are being > > > > > > developed in a > > > > > > separate document; This Internet Draft proposes a > > > > framework for > > > > > > such signaling. This initial version provides a model for > > > > > > describing > > > > > > the entities that take part in the signaling and the > > > > > ways in which > > > > > > they can be used in different modes of operation. It also > > > > > > discusses > > > > > > the overall structure of such a signaling protocol. > > > > Finally, it > > > > > > considers the possible interactions of NSIS signaling > > > > with other > > > > > > protocols and functions, including security issues. > > > > > > > ============================================================== > > > > > > ============ > > > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > > find a copy here: > > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > > highlights in section 3. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Robert Hancock > > > > > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 02:36:24 2002 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 CAA22609 for ; Wed, 10 Jul 2002 02:36:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00574 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 02:37:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28818; Wed, 10 Jul 2002 02:18:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26521 for ; Wed, 10 Jul 2002 02:17:28 -0400 (EDT) Received: from nero.informatik.uni-wuerzburg.de (root@wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09517; Wed, 10 Jul 2002 02:16:33 -0400 (EDT) Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139]) by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g6A6CFs20010; Wed, 10 Jul 2002 08:12:15 +0200 Message-ID: <000c01c227d8$fb85e2f0$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: Date: Wed, 10 Jul 2002 08:13:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C227E9.B5048230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NSIS] ITC Specialist Seminar 2002 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C227E9.B5048230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES =20 =20 FINAL CALL FOR PARTICIPATION: =20 Dear colleagues, =20 we'd like to announce that the registration for the upcoming=20 15th ITC Specialist Seminar: "Internet Traffic Engineering=20 and Traffic Management (IP2002)" remains open until=20 18 July 2002. =20 http://www.itcspecialistseminar.com/=20 Venue: University of Wuerzburg, Department of Distributed Systems,=20 Wuerzburg, Germany. Date: July 22-24 2002. =20 A registration form for the IP2002 workshop is available at:=20 =20 http://www.itcspecialistseminar.com/RegistrationForm.pdf =20 =20 We are looking forward to welcome you in Wuerzburg. Best Regards, Phuoc Tran-Gia James Roberts Kurt Tutschku Klaus Heck, your IP2002 Organizing Team =20 ------=_NextPart_000_0009_01C227E9.B5048230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

PLEASE ACCEPT OUR=20 APOLOGIES FOR MULTIPLE COPIES

 

 

FINAL CALL FOR=20 PARTICIPATION:

 

Dear=20 colleagues,

 

we'd like to=20 announce that the registration for the upcoming=20

15th ITC=20 Specialist Seminar: "Internet Traffic Engineering=20

and Traffic=20 Management (IP2002)" remains open until =

18 July=20 2002.

 

http://www.itcspecialistsem= inar.com/=20

 

Venue:      University of = Wuerzburg,=20 Department of Distributed Systems,

Wuerzburg, Germany.

Date:       July 22-24=20 2002.

 

A = registration=20 form for the IP2002 workshop is available at:=20

 

http://www.itcspecialistseminar.com/RegistrationForm.pdf

 

 

We are looking=20 forward to welcome you in Wuerzburg.

Best=20 Regards,

Phuoc=20 Tran-Gia

James=20 Roberts

Kurt=20 Tutschku

Klaus Heck,=20 your IP2002 Organizing Team

 

------=_NextPart_000_0009_01C227E9.B5048230-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 03:04:37 2002 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 DAA23315 for ; Wed, 10 Jul 2002 03:04:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02546 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 03:05:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00743; Wed, 10 Jul 2002 02:40:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00714 for ; Wed, 10 Jul 2002 02:40:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22678 for ; Wed, 10 Jul 2002 02:39:31 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6A6esi03598 for ; Wed, 10 Jul 2002 09:40:54 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 09:40:22 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 09:40:21 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 09:40:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB2@esebe004.NOE.Nokia.com> Thread-Topic: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Thread-Index: AcInYW0xRS3QjVdvTl+jxOBWJ8NXVwAehPVw To: , , X-OriginalArrivalTime: 10 Jul 2002 06:40:21.0893 (UTC) FILETIME=[AA0AFB50:01C227DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA00715 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > Probably you should ask the ADs or John. I think this was a requirement > from there side, that we only regard traditional routing. In view, this > means no load sharing, no trafic engineering. The latter might even not be > a problem. I think we need to still work through this in detail, but at a high level, I think the issue is more about the 'explictness' of signaling off-path or on-path. The basic assumption is that the signaling messages should follow the same path as the data flow. We may need to make some provisions for when there might be some changes in the paths which the packets flow. We should address this issue in the framework document. Please note, we may want to discuss how broadly we define a path in NSIS, for example, A needs to signal B. Due to some layer 3 issues, it is possible that packets travel over 3 different paths. We could treat these as 3 different explicit paths, or group them into 1 broadly defined path. I think we can investigate this issue further in the framework document. 1 +--------+ / 2 \ A ------+--+---------+------ B \ / +------+ 3 John > > Marcus > > --On Montag, 8. Juli 2002 13:39 -0500 "Schneider, Marco" > wrote: > > > Marcus, > > > > Actually, during the meeting I raised my concerns and was > asked to post an > > example to the mailing list which I did. > > > > In reponse to your question, I am not sure what "non-traditional L3 > > routing" is. I am not sure I see the relationship between > the two issues. > > Can you further elaborate. > > > > Thanks, > > Marco > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: Friday, June 07, 2002 10:35 AM > >> To: Schneider, Marco; 'nsis@ietf.org' > >> Subject: req proposal (was Re: [NSIS] NSIS Requirement: > >> Independence of > >> existing flow reservations and default routing > >> > >> > >> Marco, > >> > >> We discussed the issue of route pinning and traffic engineering in > >> Helsinki. The conclusion during the meeting was that we want > >> to add an > >> assuption saying: NSIS assumes normal/standard L3 routing > >> > >> Plus we add a requirement saying that NSIS protocol should > >> not be broken by > >> networks which do non-traditional L3 routing. > >> > >> Does this cover your concern? Do we really need to add that > >> NSIS must work > >> with default routing changes? > >> > >> Marcus > >> > >> NSIS should not be broken by networks which do > >> non-traditional L3 routing. > >> > >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" > >> wrote: > >> > >> > Hi All, > >> > > >> > One of the Open issues mentioned in the current > >> requirements draft is > >> > Route Pinning (item 47). In the following I discuss a very strong > >> > motivation for the ability to do route pinning if a soft > >> state solution > >> > is used for NSIS. I have tried to express this as a > >> requirement upon NSIS > >> > rather than the mechanism (route pinning being the obvious > >> one) by which > >> > this requirement may be achieved. > >> > > >> > Requirement: NSIS must directly support the ability to > >> insulate a flow > >> > reservation from changes in the default routing behaviour > >> except in those > >> > cases where said changes result from loss of resources > >> (layer 3 hops, > >> > capacity etc.) along the existing flow reservation path. > >> > > >> > For instance, utilizing traffic engineering in a layer 2 > >> network (e.g. > >> > MPLS or ATM) we may provision additional links or change > >> the resources > >> > associated with existing links. Additionally failures in > >> the network may > >> > cause changes. Such changes must not affect existing layer > >> 3 reservation > >> > paths with the exception of those cases where the existing > >> reservation > >> > path no longer exists or no longer has capacity to > support the flow > >> > reservation. > >> > > >> > As a simple example consider a network with two routers A > >> and B and assume > >> > that the shortest path from A to B is two hops. Based upon > >> NSIS signaling, > >> > as directed by default routing based upon number of hops, a > >> reservation > >> > path is setup from A to B along a path of two hops, where > >> both hops have a > >> > capacity of 10 and the reservation uses a capacity of 6. > >> Now let us assume > >> > that a direct link with capacity 5 is provisioned between A and B > >> > resulting in a new and direct default route of 1 hop. If > >> NSIS uses a soft > >> > state solution without route pinning then the existing flow > >> reservation > >> > will be redirected along the new link, which cannot support > >> it. Thus the > >> > existing flow reservation is lost due a change in the > >> network unrelated > >> > to its current path. In fact thousands of reservations > may have been > >> > routed along the original path and would now be disrupted. > >> Such protocol > >> > behaviour is not acceptable. > >> > > >> > Best Regards, > >> > Marco > >> > > >> > > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> personal home page: http://www.brubers.org/marcus > >> > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Wed Jul 10 03:43:02 2002 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 DAA23946 for ; Wed, 10 Jul 2002 03:43:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04462 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 03:43:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03102; Wed, 10 Jul 2002 03:16:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03071 for ; Wed, 10 Jul 2002 03:16:37 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23522 for ; Wed, 10 Jul 2002 03:15:45 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g6A7BtR06850; Wed, 10 Jul 2002 09:11:55 +0200 Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing To: john.loughney@nokia.com Cc: , , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 10 Jul 2002 09:15:28 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/10/2002 09:15:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, I have two remarks: 1) Your suggestion would also allow the use of e.g. backup paths to be configured with the primary paths (and be treated together as a 'broader path'). If this is the case, we might need to take this into account in the signalling 2) A broader definition of path could also be 'the AS-path followed by the flow'. Would this definition also be acceptable? Sven. john.loughney@nokia.com@ietf.org on 10/07/2002 08:40:21 Sent by: nsis-admin@ietf.org To: , , cc: Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Hi Marcus, > Probably you should ask the ADs or John. I think this was a requirement > from there side, that we only regard traditional routing. In view, this > means no load sharing, no trafic engineering. The latter might even not be > a problem. I think we need to still work through this in detail, but at a high level, I think the issue is more about the 'explictness' of signaling off-path or on-path. The basic assumption is that the signaling messages should follow the same path as the data flow. We may need to make some provisions for when there might be some changes in the paths which the packets flow. We should address this issue in the framework document. Please note, we may want to discuss how broadly we define a path in NSIS, for example, A needs to signal B. Due to some layer 3 issues, it is possible that packets travel over 3 different paths. We could treat these as 3 different explicit paths, or group them into 1 broadly defined path. I think we can investigate this issue further in the framework document. 1 +--------+ / 2 \ A ------+--+---------+------ B \ / +------+ 3 John > > Marcus > > --On Montag, 8. Juli 2002 13:39 -0500 "Schneider, Marco" > wrote: > > > Marcus, > > > > Actually, during the meeting I raised my concerns and was > asked to post an > > example to the mailing list which I did. > > > > In reponse to your question, I am not sure what "non-traditional L3 > > routing" is. I am not sure I see the relationship between > the two issues. > > Can you further elaborate. > > > > Thanks, > > Marco > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: Friday, June 07, 2002 10:35 AM > >> To: Schneider, Marco; 'nsis@ietf.org' > >> Subject: req proposal (was Re: [NSIS] NSIS Requirement: > >> Independence of > >> existing flow reservations and default routing > >> > >> > >> Marco, > >> > >> We discussed the issue of route pinning and traffic engineering in > >> Helsinki. The conclusion during the meeting was that we want > >> to add an > >> assuption saying: NSIS assumes normal/standard L3 routing > >> > >> Plus we add a requirement saying that NSIS protocol should > >> not be broken by > >> networks which do non-traditional L3 routing. > >> > >> Does this cover your concern? Do we really need to add that > >> NSIS must work > >> with default routing changes? > >> > >> Marcus > >> > >> NSIS should not be broken by networks which do > >> non-traditional L3 routing. > >> > >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" > >> wrote: > >> > >> > Hi All, > >> > > >> > One of the Open issues mentioned in the current > >> requirements draft is > >> > Route Pinning (item 47). In the following I discuss a very strong > >> > motivation for the ability to do route pinning if a soft > >> state solution > >> > is used for NSIS. I have tried to express this as a > >> requirement upon NSIS > >> > rather than the mechanism (route pinning being the obvious > >> one) by which > >> > this requirement may be achieved. > >> > > >> > Requirement: NSIS must directly support the ability to > >> insulate a flow > >> > reservation from changes in the default routing behaviour > >> except in those > >> > cases where said changes result from loss of resources > >> (layer 3 hops, > >> > capacity etc.) along the existing flow reservation path. > >> > > >> > For instance, utilizing traffic engineering in a layer 2 > >> network (e.g. > >> > MPLS or ATM) we may provision additional links or change > >> the resources > >> > associated with existing links. Additionally failures in > >> the network may > >> > cause changes. Such changes must not affect existing layer > >> 3 reservation > >> > paths with the exception of those cases where the existing > >> reservation > >> > path no longer exists or no longer has capacity to > support the flow > >> > reservation. > >> > > >> > As a simple example consider a network with two routers A > >> and B and assume > >> > that the shortest path from A to B is two hops. Based upon > >> NSIS signaling, > >> > as directed by default routing based upon number of hops, a > >> reservation > >> > path is setup from A to B along a path of two hops, where > >> both hops have a > >> > capacity of 10 and the reservation uses a capacity of 6. > >> Now let us assume > >> > that a direct link with capacity 5 is provisioned between A and B > >> > resulting in a new and direct default route of 1 hop. If > >> NSIS uses a soft > >> > state solution without route pinning then the existing flow > >> reservation > >> > will be redirected along the new link, which cannot support > >> it. Thus the > >> > existing flow reservation is lost due a change in the > >> network unrelated > >> > to its current path. In fact thousands of reservations > may have been > >> > routed along the original path and would now be disrupted. > >> Such protocol > >> > behaviour is not acceptable. > >> > > >> > Best Regards, > >> > Marco > >> > > >> > > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> personal home page: http://www.brubers.org/marcus > >> > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 04:54:12 2002 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 EAA25081 for ; Wed, 10 Jul 2002 04:54:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08268 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 04:55:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07435; Wed, 10 Jul 2002 04:38:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07390 for ; Wed, 10 Jul 2002 04:38:28 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24762 for ; Wed, 10 Jul 2002 04:37:33 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6A8Elm02534; Wed, 10 Jul 2002 10:14:47 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA11552; Wed, 10 Jul 2002 10:14:46 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B889310BAB; Wed, 10 Jul 2002 10:14:45 +0200 (CEST) Date: Wed, 10 Jul 2002 10:14:41 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Cedric Westphal Cc: john.loughney@nokia.com, robert.hancock@roke.co.uk, erafodo@ESEALNT448.al.sw.ericsson.se, nsis@ietf.org, Hemant.Chaskar@nokia.com Subject: Re: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) Message-ID: <995681.1026296081@[192.168.102.207]> In-Reply-To: <3D2A0CA8.8060507@iprg.nokia.com> References: <3D2A0CA8.8060507@iprg.nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Montag, 8. Juli 2002 15:05 -0700 Cedric Westphal wrote: > I do not understand your first statement. Could you explain it to me a > bit more? Are you saying that an optimized solution should not be > considered? Your requirement draft requires the air interface to be > 'efficient'. What is the difference between 'efficient' and 'optimized'? > If you mean to say that: in a first phase, the design should focus on > making NSIS a stand-alone protocol, and the later integrate CT, then I > totally agree with you. I just hope that this is being kept in mind while > designing this first phase. Yes, thats what I meant. Design NSIS without taking care of CT issues. Then later see whether we can optimize the NSIS behaviour using CT. > > Actually, I don't inderstand the second statement either. Technically, CT > signaling is not part of NSIS, so whether it is on or off-line does not > make much of a difference from NSIS perspective. From AR on, NSIS takes > over, and is on-line if you wish so. In your draft terms, the AR > functions as the initiator. I hope that you don't mean to say that it > won't be possible to integrate CT with NSIS in a second phase of design, > as it is off-path. Could you please clarify? Thanks, I am in favour of including off-path signaling into NSIS, because I do not see the overhead complexity etc. some people are afraid of. The question arises when the handover happens, whether you do have a phase where you need off-path signaling or not (and this heavily depenbds how exactly people define off-path. And here off-path means off the original path used at the old location. If you regard the reservation from the new location also as a new reservation this is not a problem. If you think it is an update of an old reservation you might want to preestablish reservations. Marcus > Cedric. > >> >> >> Marcus >> >> --On Donnerstag, 4. Juli 2002 11:33 +0300 john.loughney@nokia.com wrote: >> >>> Hi Robert, >>> >>>> On the 'edge signalling' case, I guess the main point is that >>>> I'm confused about the scope of seamoby CT. Specifically >>>> regarding MN-AR signalling (no issue about the AR-AR part): >>> >>> >>> From my viewpoint, CT is not required for NSIS. I view CT as >>> one tool that an NSIS solution could use. So, I definately think >>> that at some point, we will need some sort of applicability >>> statement describing how to use CT for NSIS. >>> >>> John >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 05:43:42 2002 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 FAA26079 for ; Wed, 10 Jul 2002 05:43:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA11821 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 05:44:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10066; Wed, 10 Jul 2002 05:25:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09970 for ; Wed, 10 Jul 2002 05:25:12 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25696 for ; Wed, 10 Jul 2002 05:24:17 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6A94Fm06090; Wed, 10 Jul 2002 11:04:15 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA12218; Wed, 10 Jul 2002 11:04:15 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8F4A852509; Wed, 10 Jul 2002 11:04:14 +0200 (CEST) Date: Wed, 10 Jul 2002 11:04:14 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Message-ID: <3964871.1026299054@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Georgios, --On Montag, 8. Juli 2002 15:02 +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > In my opinion, the main requirements that are affected by the > in-path and out of path discussions are: > > * Requirement 5.2.2: > "No constraint of the QoS signaling Controllers to be in the data path" > You could remove this requirement! The requierment is already very weak and just says "No constraint". Could you live with it if we even make it a SHOULD? > * Requirement 5.7.2: > "Flexibility in the placement of the QoS initiator" > In my opinion the way of how the network initiated reservations > are explained ion this section, are mainly out of path. > Please remove the sentence that describes network initiated reservations. This has nothing to do with on/off path. Removing this means no proxies, no Acess Router initated signaling (even if they are on path) I vote for leaving it. > * Requirement 5.7.3: > "Flexibility in the initiation of re-negotiation (QoS change requests)" > In my opinion the way of how the network initiated reservations > are explained ion this section, are mainly out of path. > Please remove the sentence that describes network initiated reservations. The same here as with the previous req. Marcus > Best regards, > Georgios > > > > > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Monday, July 08, 2002 12:04 PM > To: Georgios Karagiannis (ELN); john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt > > > Georgios, > > Yes, please make a list and post it to the list. We can discuss it. > Evenso, myself and John (if I understood him right) think the req are not > containing any point which are off-path specific. But corr4ect me if you > find some. > > Marcus > > --On Montag, 8. Juli 2002 11:06 +0200 "Georgios Karagiannis (ELN)" > wrote: > >> >> Hi Marcus >> Please see my remarks in line: >> >>> I think that we need to seperate off-path requirements from the main >>> document. In my opinion, these are non-requirements for the current >>> charter. I would support moving these into an appendix, >>> which discusses off-path signaling. >> >> [marcus] I still don't see what problem people have with off-path >> signaling (and I [marcus] would call tunneling off-path as well). If the >> working group agrees to [marcus] remove some of the req fine, let me >> know which ones. >> >> [georgios] well we do not have to remove them, but we have to emphasise >> that [georgios] they are very optional. John propsed to move thaem in an >> appendix. [georgios] If you want I can make a list with them. >> >>> >>>> I propose to use the terms given in draft-hancock-nsis-fw-00.txt >>>> regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder >>>> (instead of QoS Controller) and NSIS Responder. This applies also >>>> for other additional terms that are >>>> included into draft-hancock-nsis-fw-00.txt and are not >>>> included into the requirements draft. >>> >>> [john] I support this, but I think we should have some WG discussion on >>> [john] this. >> >> [marcus] Yes, sure, but I can a that point in time not rely on a personal >> [marcus] submission. And the terms showed up first in the req draft. I >> agree that [marcus] there are good reasons to change them, but we need >> consensus on that. [georgios] agree, we should have a consensus on that! >> >> >>>> Please remove or signifficantly modify bullet 2: >>>> "We see the network at the level of domains/subdomains rather >>>> than individual routers ...... Aggregation can also take >>>> place at subdomain boundaries." >>>> >>>> The reasonsof asking this are: >>>> * not each domain but any router that implements a QoS >>>> controller or QoS initiator can use NSIS signaling; >>>> * It is contradictory with bullet 4 (of the same >>>> section) that mentions: >>>> " Each router on the data path implements a QoS >>>> controller and QoS initiator." >>> >> [john]> I don't see your point. If we are signaling for some 'NSIS >> [john]> resource' - does each router on the path suply this resource, >> [john]> is it aggregated or not? We are not designing a specific >> [john]> host to router, or router to router protocol; in my opinion >> [john]> we are doing something a bit broader. However, what we do >> [john]> may be applicable to this. >>> >> [marcus]I don't understand georgios point but I think we need to modify >> section 3 [marcus] anyway (or even remove it, because most of the stuff >> is framework related. >> >> [georgios] What about the last proposal that I sent as reply to John's >> e-mail. >> >> >>>> Comment_4: Section 4.1: Assumptions and exclusions (Page 11): >>>> >>>> Bullet 6: >>>> Please change the text: >>>> "NSIS assumes to operate with networks using standard >>>> ("normal") L3 routing" >>>> >>>> INTO >>>> >>>> "NSIS assumes to operate with networks using standard >>>> ("normal") L3 routing as described in RFC 2993." >>> >> [john]> I am perplexed at this reference - 2993 is "Architectural >> Implications [john]> of NAT" - what does this have to do with NSIS? >> >> [marcus] Here I don't want to include any reference, The fuzzyness is on >> purpose. >> >> [marcus] If you start talking about NATs this might be an issue for NSIS, >> whether [marcus] NSIS must work over NATs or not or don't care. >> >> [georgios] I am very sorry, I meant RFC2992,"Analysis of an Equal-Cost >> [georgios] Multi-Path Algorithm", located at: >> http://www.ietf.org/rfc/rfc2992.txt?number=2992 >> >> Best Regards, >> Georgios >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 06:00:35 2002 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 GAA26445 for ; Wed, 10 Jul 2002 06:00:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13052 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 06:01:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11789; Wed, 10 Jul 2002 05:44:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11758 for ; Wed, 10 Jul 2002 05:43:59 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26067 for ; Wed, 10 Jul 2002 05:43:03 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6A9JMm07146; Wed, 10 Jul 2002 11:19:22 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA12401; Wed, 10 Jul 2002 11:19:20 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5E67E4936E; Wed, 10 Jul 2002 11:19:20 +0200 (CEST) Date: Wed, 10 Jul 2002 11:19:20 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: sven.van_den_bosch@alcatel.be, john.loughney@nokia.com Cc: schneider@tri.sbc.com, nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing Message-ID: <4870853.1026299960@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Mittwoch, 10. Juli 2002 09:15 +0200 sven.van_den_bosch@alcatel.be wrote: > Hi John, > > I have two remarks: > 1) Your suggestion would also allow the use of e.g. backup paths to be > configured with the primary paths (and be treated together as a 'broader > path'). If this is the case, we might need to take this into account in > the signalling I have not seen backup pathes on L3. Every thing below I assume out of scope. L3 reroutes in failure cases. > 2) A broader definition of path could also be 'the AS-path followed by the > flow'. Would this definition also be acceptable? Thats what I would go for, and that what stands in the Req draft. Marcus > Sven. > > > > > > john.loughney@nokia.com@ietf.org on 10/07/2002 08:40:21 > > Sent by: nsis-admin@ietf.org > > > To: , , > cc: > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence > of existing flow reservations and default routing > > > Hi Marcus, > >> Probably you should ask the ADs or John. I think this was a requirement >> from there side, that we only regard traditional routing. In view, this >> means no load sharing, no trafic engineering. The latter might even not > be >> a problem. > > I think we need to still work through this in detail, but at a high level, > I think the issue is more about the 'explictness' of signaling off-path > or on-path. The basic assumption is that the signaling messages should > follow the same path as the data flow. We may need to make some > provisions for when there might be some changes in the paths which the > packets flow. We should address this issue in the framework document. > > Please note, we may want to discuss how broadly we define a path in NSIS, > for example, A needs to signal B. Due to some layer 3 issues, it is > possible > that packets travel over 3 different paths. We could treat these > as 3 different explicit paths, or group them into 1 broadly defined path. > I think we can investigate this issue further in the framework document. > > > 1 > +--------+ > / 2 \ > A ------+--+---------+------ B > \ / > +------+ > 3 > John > >> >> Marcus >> >> --On Montag, 8. Juli 2002 13:39 -0500 "Schneider, Marco" >> wrote: >> >> > Marcus, >> > >> > Actually, during the meeting I raised my concerns and was >> asked to post an >> > example to the mailing list which I did. >> > >> > In reponse to your question, I am not sure what "non-traditional L3 >> > routing" is. I am not sure I see the relationship between >> the two issues. >> > Can you further elaborate. >> > >> > Thanks, >> > Marco >> > >> >> -----Original Message----- >> >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> >> Sent: Friday, June 07, 2002 10:35 AM >> >> To: Schneider, Marco; 'nsis@ietf.org' >> >> Subject: req proposal (was Re: [NSIS] NSIS Requirement: >> >> Independence of >> >> existing flow reservations and default routing >> >> >> >> >> >> Marco, >> >> >> >> We discussed the issue of route pinning and traffic engineering in >> >> Helsinki. The conclusion during the meeting was that we want >> >> to add an >> >> assuption saying: NSIS assumes normal/standard L3 routing >> >> >> >> Plus we add a requirement saying that NSIS protocol should >> >> not be broken by >> >> networks which do non-traditional L3 routing. >> >> >> >> Does this cover your concern? Do we really need to add that >> >> NSIS must work >> >> with default routing changes? >> >> >> >> Marcus >> >> >> >> NSIS should not be broken by networks which do >> >> non-traditional L3 routing. >> >> >> >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" >> >> wrote: >> >> >> >> > Hi All, >> >> > >> >> > One of the Open issues mentioned in the current >> >> requirements draft is >> >> > Route Pinning (item 47). In the following I discuss a very strong >> >> > motivation for the ability to do route pinning if a soft >> >> state solution >> >> > is used for NSIS. I have tried to express this as a >> >> requirement upon NSIS >> >> > rather than the mechanism (route pinning being the obvious >> >> one) by which >> >> > this requirement may be achieved. >> >> > >> >> > Requirement: NSIS must directly support the ability to >> >> insulate a flow >> >> > reservation from changes in the default routing behaviour >> >> except in those >> >> > cases where said changes result from loss of resources >> >> (layer 3 hops, >> >> > capacity etc.) along the existing flow reservation path. >> >> > >> >> > For instance, utilizing traffic engineering in a layer 2 >> >> network (e.g. >> >> > MPLS or ATM) we may provision additional links or change >> >> the resources >> >> > associated with existing links. Additionally failures in >> >> the network may >> >> > cause changes. Such changes must not affect existing layer >> >> 3 reservation >> >> > paths with the exception of those cases where the existing >> >> reservation >> >> > path no longer exists or no longer has capacity to >> support the flow >> >> > reservation. >> >> > >> >> > As a simple example consider a network with two routers A >> >> and B and assume >> >> > that the shortest path from A to B is two hops. Based upon >> >> NSIS signaling, >> >> > as directed by default routing based upon number of hops, a >> >> reservation >> >> > path is setup from A to B along a path of two hops, where >> >> both hops have a >> >> > capacity of 10 and the reservation uses a capacity of 6. >> >> Now let us assume >> >> > that a direct link with capacity 5 is provisioned between A and B >> >> > resulting in a new and direct default route of 1 hop. If >> >> NSIS uses a soft >> >> > state solution without route pinning then the existing flow >> >> reservation >> >> > will be redirected along the new link, which cannot support >> >> it. Thus the >> >> > existing flow reservation is lost due a change in the >> >> network unrelated >> >> > to its current path. In fact thousands of reservations >> may have been >> >> > routed along the original path and would now be disrupted. >> >> Such protocol >> >> > behaviour is not acceptable. >> >> > >> >> > Best Regards, >> >> > Marco >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> >> >> >> -------------------------------------- >> >> Dr. Marcus Brunner >> >> Network Laboratories >> >> NEC Europe Ltd. >> >> >> >> E-Mail: brunner@ccrle.nec.de >> >> WWW: http://www.ccrle.nec.de/ >> >> personal home page: http://www.brubers.org/marcus >> >> >> >> >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 06:02:20 2002 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 GAA26532 for ; Wed, 10 Jul 2002 06:02:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13134 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 06:03:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11880; Wed, 10 Jul 2002 05:45:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11849 for ; Wed, 10 Jul 2002 05:45:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26098 for ; Wed, 10 Jul 2002 05:44:44 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6A9k8i00936 for ; Wed, 10 Jul 2002 12:46:08 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 12:45:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 12:45:33 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 12:45:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656D2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Thread-Index: AcInf9l8EDvtRQZ2SVa7aMoml0CmFwAdmRfA To: Cc: X-OriginalArrivalTime: 10 Jul 2002 09:45:33.0929 (UTC) FILETIME=[89551D90:01C227F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA11850 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Dan, > Perhaps what is missing is a definition of Quality of Service. This has been a > long standing problem in the RFC series: I'm not aware of a single place where > the term is defined. It is also true that the industry has no single accepted > definition. While I'm not convinced that this is the right place to put such > definitions, there doesn't seem to be a better one right now. I think the reason that there is no definition is because QoS is in the eyes of the beholder & may be very service specific. QoS for a file download via FTP may be very different than QoS for streaming audio over RTP. This is one reason why I have been depreciating the use of the term QoS in NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 06:48:31 2002 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 GAA27385 for ; Wed, 10 Jul 2002 06:48:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15137 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 06:49:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14621; Wed, 10 Jul 2002 06:35:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14594 for ; Wed, 10 Jul 2002 06:35:05 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27094 for ; Wed, 10 Jul 2002 06:34:10 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6AAXWd29588 for ; Wed, 10 Jul 2002 13:33:32 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 13:35:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 13:35:02 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 13:35:01 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656D5@esebe004.NOE.Nokia.com> Thread-Topic: req proposal (was Re: [NSIS] NSIS Requirement: Independence ofexisting flow reservations and default routing Thread-Index: AcIn/UPiseZEmYGcSO6t2hm3U7SClQAAA1oA To: , Cc: , X-OriginalArrivalTime: 10 Jul 2002 10:35:02.0440 (UTC) FILETIME=[72B3F280:01C227FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA14595 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > > 1) Your suggestion would also allow the use of e.g. backup paths to be > > configured with the primary paths (and be treated together as a 'broader > > path'). If this is the case, we might need to take this into account in > > the signalling > > I have not seen backup pathes on L3. Every thing below I assume out of > scope. L3 reroutes in failure cases. Agreed. > > 2) A broader definition of path could also be 'the AS-path followed by the > > flow'. Would this definition also be acceptable? > > Thats what I would go for, and that what stands in the Req draft. I think that Sven's definition is a good start. Let's try to make a more formal definition & stick it into the framework document (when we have one). thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 08:03:55 2002 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 IAA28685 for ; Wed, 10 Jul 2002 08:03:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19076 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 08:04:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17977; Wed, 10 Jul 2002 07:50:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17952 for ; Wed, 10 Jul 2002 07:50:20 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28357 for ; Wed, 10 Jul 2002 07:49:26 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ABomi10707 for ; Wed, 10 Jul 2002 14:50:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 14:50:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 14:50:16 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 14:50:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656D9@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] commentson on draft-ietf-nsis-req-03.txt Thread-Index: AcIn9E5TxNNW17pxSG6GZWbFgUTvwAAE2Hcw To: , Cc: X-OriginalArrivalTime: 10 Jul 2002 11:50:16.0634 (UTC) FILETIME=[F55F49A0:01C22807] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA17953 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus & Georgios, > > In my opinion, the main requirements that are affected by the > > in-path and out of path discussions are: > > > > * Requirement 5.2.2: > > "No constraint of the QoS signaling Controllers to be in the data path" > > You could remove this requirement! > > The requierment is already very weak and just says "No > constraint". Could you live with it if we even make it a SHOULD? I think we could leave this requirement loose & then over-rule it, if needed, in the framework document. > > * Requirement 5.7.2: > > "Flexibility in the placement of the QoS initiator" > > In my opinion the way of how the network initiated reservations > > are explained ion this section, are mainly out of path. > > Please remove the sentence that describes network initiated > reservations. > > This has nothing to do with on/off path. Removing this means no proxies, no > Acess Router initated signaling (even if they are on path) > I vote for leaving it. I agree with Marcus. It is not saying on- or off-path. > > * Requirement 5.7.3: > > "Flexibility in the initiation of re-negotiation (QoS change requests)" > > In my opinion the way of how the network initiated reservations > > are explained ion this section, are mainly out of path. > > Please remove the sentence that describes network initiated > reservations. > > The same here as with the previous req. I don't see the problem with this requirement. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 08:41:29 2002 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 IAA29919 for ; Wed, 10 Jul 2002 08:41:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20782 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 08:42:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19662; Wed, 10 Jul 2002 08:24:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19630 for ; Wed, 10 Jul 2002 08:24:50 -0400 (EDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29186 for ; Wed, 10 Jul 2002 08:23:56 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g6ACK9e11473; Wed, 10 Jul 2002 14:20:09 +0200 Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing To: brunner@ccrle.nec.de Cc: john.loughney@nokia.com, schneider@tri.sbc.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 10 Jul 2002 14:23:41 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/10/2002 14:23:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus, Just a single comment inline. Sven. Marcus Brunner @ietf.org on 10/07/2002 11:19:20 Please respond to brunner@ccrle.nec.de Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, john.loughney@nokia.com cc: schneider@tri.sbc.com, nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing --On Mittwoch, 10. Juli 2002 09:15 +0200 sven.van_den_bosch@alcatel.be wrote: > Hi John, > > I have two remarks: > 1) Your suggestion would also allow the use of e.g. backup paths to be > configured with the primary paths (and be treated together as a 'broader > path'). If this is the case, we might need to take this into account in > the signalling I have not seen backup pathes on L3. Every thing below I assume out of scope. L3 reroutes in failure cases. [Sven] What if it would reshuffle the traffic over several node and link disjoint paths (as you could typically use for loadbalancing). This is the reason why I made the remark in the first place. > 2) A broader definition of path could also be 'the AS-path followed by the > flow'. Would this definition also be acceptable? Thats what I would go for, and that what stands in the Req draft. Marcus > Sven. > > > > > > john.loughney@nokia.com@ietf.org on 10/07/2002 08:40:21 > > Sent by: nsis-admin@ietf.org > > > To: , , > cc: > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence > of existing flow reservations and default routing > > > Hi Marcus, > >> Probably you should ask the ADs or John. I think this was a requirement >> from there side, that we only regard traditional routing. In view, this >> means no load sharing, no trafic engineering. The latter might even not > be >> a problem. > > I think we need to still work through this in detail, but at a high level, > I think the issue is more about the 'explictness' of signaling off-path > or on-path. The basic assumption is that the signaling messages should > follow the same path as the data flow. We may need to make some > provisions for when there might be some changes in the paths which the > packets flow. We should address this issue in the framework document. > > Please note, we may want to discuss how broadly we define a path in NSIS, > for example, A needs to signal B. Due to some layer 3 issues, it is > possible > that packets travel over 3 different paths. We could treat these > as 3 different explicit paths, or group them into 1 broadly defined path. > I think we can investigate this issue further in the framework document. > > > 1 > +--------+ > / 2 \ > A ------+--+---------+------ B > \ / > +------+ > 3 > John > >> >> Marcus >> >> --On Montag, 8. Juli 2002 13:39 -0500 "Schneider, Marco" >> wrote: >> >> > Marcus, >> > >> > Actually, during the meeting I raised my concerns and was >> asked to post an >> > example to the mailing list which I did. >> > >> > In reponse to your question, I am not sure what "non-traditional L3 >> > routing" is. I am not sure I see the relationship between >> the two issues. >> > Can you further elaborate. >> > >> > Thanks, >> > Marco >> > >> >> -----Original Message----- >> >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> >> Sent: Friday, June 07, 2002 10:35 AM >> >> To: Schneider, Marco; 'nsis@ietf.org' >> >> Subject: req proposal (was Re: [NSIS] NSIS Requirement: >> >> Independence of >> >> existing flow reservations and default routing >> >> >> >> >> >> Marco, >> >> >> >> We discussed the issue of route pinning and traffic engineering in >> >> Helsinki. The conclusion during the meeting was that we want >> >> to add an >> >> assuption saying: NSIS assumes normal/standard L3 routing >> >> >> >> Plus we add a requirement saying that NSIS protocol should >> >> not be broken by >> >> networks which do non-traditional L3 routing. >> >> >> >> Does this cover your concern? Do we really need to add that >> >> NSIS must work >> >> with default routing changes? >> >> >> >> Marcus >> >> >> >> NSIS should not be broken by networks which do >> >> non-traditional L3 routing. >> >> >> >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" >> >> wrote: >> >> >> >> > Hi All, >> >> > >> >> > One of the Open issues mentioned in the current >> >> requirements draft is >> >> > Route Pinning (item 47). In the following I discuss a very strong >> >> > motivation for the ability to do route pinning if a soft >> >> state solution >> >> > is used for NSIS. I have tried to express this as a >> >> requirement upon NSIS >> >> > rather than the mechanism (route pinning being the obvious >> >> one) by which >> >> > this requirement may be achieved. >> >> > >> >> > Requirement: NSIS must directly support the ability to >> >> insulate a flow >> >> > reservation from changes in the default routing behaviour >> >> except in those >> >> > cases where said changes result from loss of resources >> >> (layer 3 hops, >> >> > capacity etc.) along the existing flow reservation path. >> >> > >> >> > For instance, utilizing traffic engineering in a layer 2 >> >> network (e.g. >> >> > MPLS or ATM) we may provision additional links or change >> >> the resources >> >> > associated with existing links. Additionally failures in >> >> the network may >> >> > cause changes. Such changes must not affect existing layer >> >> 3 reservation >> >> > paths with the exception of those cases where the existing >> >> reservation >> >> > path no longer exists or no longer has capacity to >> support the flow >> >> > reservation. >> >> > >> >> > As a simple example consider a network with two routers A >> >> and B and assume >> >> > that the shortest path from A to B is two hops. Based upon >> >> NSIS signaling, >> >> > as directed by default routing based upon number of hops, a >> >> reservation >> >> > path is setup from A to B along a path of two hops, where >> >> both hops have a >> >> > capacity of 10 and the reservation uses a capacity of 6. >> >> Now let us assume >> >> > that a direct link with capacity 5 is provisioned between A and B >> >> > resulting in a new and direct default route of 1 hop. If >> >> NSIS uses a soft >> >> > state solution without route pinning then the existing flow >> >> reservation >> >> > will be redirected along the new link, which cannot support >> >> it. Thus the >> >> > existing flow reservation is lost due a change in the >> >> network unrelated >> >> > to its current path. In fact thousands of reservations >> may have been >> >> > routed along the original path and would now be disrupted. >> >> Such protocol >> >> > behaviour is not acceptable. >> >> > >> >> > Best Regards, >> >> > Marco >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> >> >> >> -------------------------------------- >> >> Dr. Marcus Brunner >> >> Network Laboratories >> >> NEC Europe Ltd. >> >> >> >> E-Mail: brunner@ccrle.nec.de >> >> WWW: http://www.ccrle.nec.de/ >> >> personal home page: http://www.brubers.org/marcus >> >> >> >> >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ 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 daemon@optimus.ietf.org Wed Jul 10 08:49:10 2002 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 IAA00609 for ; Wed, 10 Jul 2002 08:49:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21233 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 08:50:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20579; Wed, 10 Jul 2002 08:33:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20546 for ; Wed, 10 Jul 2002 08:33:35 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29463; Wed, 10 Jul 2002 08:32:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ACY3i06006; Wed, 10 Jul 2002 15:34:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 15:33:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 15:33:31 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 15:33:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656DF@esebe004.NOE.Nokia.com> Thread-Topic: NSIS Agenda update Thread-Index: AcIoDf/OcHV+FgmlQ4GG/gJIf0qKKA== To: Cc: X-OriginalArrivalTime: 10 Jul 2002 12:33:31.0490 (UTC) FILETIME=[0006E420:01C2280E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA20547 Subject: [NSIS] NSIS Agenda update Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Attached is the Agenda for the NSIS working group. Best regards, John NSIS IETF 54 Agenda =================== MONDAY, July 15, 2002 0900-1130 Morning Session Chair: John Loughney Agenda Bashing and Status Report 15 minutes Requirements - 30 minutes NSIS Requirements - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt NSIS Threats & Security requirements - 10 minutes http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt NSIS Resilience - 10 minutes http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt Framework - 60 minutes Next Steps in Signaling: A Framework Proposal - 15 minutes http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt 2 Level Signaling Architecture - 15 minutes http://www.isi.edu/~braden/draft-braden-2level-signaling-00.txt. Framework Structure for QoS Signaling - 10 minutes http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt A Framework for Bi-Directional QoS Signaling - 10 minutes http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-01.txt Middlebox Signaling in a NSIS framework - 10 minutes http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt Analysis - 25 minutes Analysis of Existing QoS Solutions - 5 minutes http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt On path and off path signaling for NSIS - 5 minutes http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt RSVP Security Properties - 5 minutes http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-sec-properties-00.txt Analysis on RSVP Regarding Multicast - 5 minutes http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-00.txt Next Steps - 15 minutes Other if time allows Consideration of RSVP-TE Extension for Metro Network http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt The Features of IPv6 Signaling http://opticalip.icu.ac.kr/draft-choi-ipv6-signaling-02.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 08:59:25 2002 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 IAA01164 for ; Wed, 10 Jul 2002 08:59:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21838 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 09:00:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20833; Wed, 10 Jul 2002 08:43:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20803 for ; Wed, 10 Jul 2002 08:43:22 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00036 for ; Wed, 10 Jul 2002 08:42:27 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ACjIW19214 for ; Wed, 10 Jul 2002 15:45:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 10 Jul 2002 15:43:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 15:43:18 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 15:43:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656E1@esebe004.NOE.Nokia.com> Thread-Topic: NSIS Agenda update Thread-Index: AcIoDf/OcHV+FgmlQ4GG/gJIf0qKKAAATTpg To: X-OriginalArrivalTime: 10 Jul 2002 12:43:19.0027 (UTC) FILETIME=[5E39EC30:01C2280F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA20804 Subject: [NSIS] IPv6 Flow Label Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, One tool we may want to use is the IPv6 flow label. There is some standardization of this on-going in the IPv6 WG. I wonder if folks could comment on the spec, with regards to how NSIS could use it. It can be found from: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 09:34:39 2002 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 JAA02010 for ; Wed, 10 Jul 2002 09:34:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24343 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 09:35:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22775; Wed, 10 Jul 2002 09:18:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22744 for ; Wed, 10 Jul 2002 09:18:32 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01555 for ; Wed, 10 Jul 2002 09:17:37 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6ADITrU014828; Wed, 10 Jul 2002 15:18:29 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKBZCKJ; Wed, 10 Jul 2002 15:18:29 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 15:18:15 +0200 Message-ID: X-Sybari-Trust: df761a02 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , "'nsis@ietf.org'" Date: Wed, 10 Jul 2002 15:18:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus I have an additional comment to the requirements draft (draft-ietf-nsis-req-03.txt): Due to the fact that the Multi-level signaling has become a very important issue in NSIS, I would very much appreciate if we could add the following bullet into Section 5.1.3 "Modularity": "- multi-level NSIS signaling: the NSIS protocol should be able to be separated into more than one hierarchical levels." Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 09:58:53 2002 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 JAA02872 for ; Wed, 10 Jul 2002 09:58:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26527 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 09:59:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25206; Wed, 10 Jul 2002 09:45:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25087 for ; Wed, 10 Jul 2002 09:45:52 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02356 for ; Wed, 10 Jul 2002 09:44:57 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6ADjiRb027956; Wed, 10 Jul 2002 15:45:44 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKBZN4T; Wed, 10 Jul 2002 15:45:39 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 15:45:17 +0200 Message-ID: X-Sybari-Trust: 028c3db9 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'Dan Grossman'" , "Schneider, Marco" Cc: "'Hancock, Robert'" , Zhigang.Kan@nokia.com, nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function Date: Wed, 10 Jul 2002 15:45:29 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi the draft draft-hancock-nsis-fw-00.txt provides definitions for several additional terms. These terms are described in "Section 2: Terminology" of this draft. I propose to introduce them into the requirements draft draft-ietf-nsis-req-0x.txt! Can we get an agreement on this? Best Regards, Georgios -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Tuesday, July 09, 2002 9:35 PM To: Schneider, Marco Cc: 'Hancock, Robert'; Zhigang.Kan@nokia.com; Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: Re: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Perhaps what is missing is a definition of Quality of Service. This has been a long standing problem in the RFC series: I'm not aware of a single place where the term is defined. It is also true that the industry has no single accepted definition. While I'm not convinced that this is the right place to put such definitions, there doesn't seem to be a better one right now. The following may be a good start toward working definitons: Quality-of-Service(QoS): A set of attributes and their values that, taken together, characterize the performance experienced by a flow. End-to-end QoS: A set of attributes and their values that, taken together, characterize the performance experienced by an end-to-end flow, i.e., as observed by protocols above the IP layer Edge-to-edge QoS: A set of attributes and their values, that, taken together, characterize the performance experienced by a flow from the point where it enters a domain (or a concatenation of domains) to the point(s) where it leaves that (those) domain(s). Agreed QoS: A set of attributes and their values that have been agreed between a network (or concatentation of networks) and two (or more) hosts. This set characterizes the performance the network(s) agree that a flow will experience for a defined period. The agreement can be reached through signalling or administratively. Actual QoS: The measured values of a set of QoS attributes. "Schneider, Marco" wrote: > Hi Robert, all > > I find our mapping of distinctions to terms confusing. The term QOS is of > course short for Quality of Service. This begs the question "what or which > service". In our context we seem to be speaking of packet transport: A QOS > (quality of service) service being the ability to specify the quality of > said packet transport service. For me, strictly speaking, QOS is not an > example of a resource but rather a type of service that can reasonably be > thought of to require resource reservations in a network. What resources are > actually reserved or utilized to achieve QOS is beyond the scope of our > work. Put another way a service is an abstraction of network > resources/capabilities and whether or not the service implementation uses > said abstractions is beyond scope. > > Marco > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, June 27, 2002 5:45 AM > > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource Management Function > > v.s. QoS Management Function > > > > > > Hi Zhigang, > > > > 'QoS' is one example of 'resource'. > > > > I'm actually not sure it is possible to define 'resource' > > precisely. The basic point is that NSIS should provide a > > generally useful signalling capability, which you could use > > for various types of resource; exactly what types is going to > > be defined implicitly by whether the NSIS capabilities are > > appropriate to the resource type needs. In that sense, > > there's a benefit in vagueness. > > > > An RMF is absolutely not a BB. In our framework, "RMF" is > > just a name for what NSIS offloads certain problems in > > resource management to, it's a way to talk about the boundary > > of the NSIS problem space. NSIS doesn't care how the RMF is > > implemented; it should be possible to support both > > centralised and distributed resource management strategies > > with the same NSIS protocol. The one thing that is ruled out > > (initially) is NSIS signalling directly to a centralised > > (off-path) entity; this is a consequence of recent scope > > guidance. Please see especially section 5.1 of the draft (the > > hardest section to write, by the way). > > > > Yours, > > > > Robert H. > > > > > > > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 27 June 2002 11:11 > > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > Hi all, > > > > > > Maybe we don't care what term/name is called. The most > > > important is that the "resources" and "resource management" > > > should be defined exactly, and the relationship between > > > resource and QoS should be clarified. Is RMF similar as BB? > > > > > > BR/Kan Zhigang > > > > > > -----Original Message----- > > > From: ext Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 2002å¹´6æoe^27æ-¥ 17:47 > > > To: 'Hancock, Robert' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource Management > > > Function v. > > > s. QoS Management Function > > > > > > > > > Hi all > > > > > > I agree with the explanation given by Robert regarding RMF. I am in > > > favor of keeping the term RMF. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Thursday, June 27, 2002 11:39 AM > > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > hi all, > > > > > > I think it's valuable for Zhigang to highlight the point, > > > because this is one of the major changes in this NSIS > > > framework input compared to (most?) previous ones (certainly > > > the ones I have been involved in). One of the consequences of > > > the email discussions around the time of the interim meeting > > > (e.g. > > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > > msg01378.html) was that we should look at more general > > > resources than just QOS. (IMHO, this is still not obvious > > > even in the post-interim clarified charter, BTW.) > > > > > > This has quite a big impact on what we write, at least. We > > > still need a good name for this "thing we are signalling > > > for", "resource" (and hence RMF) is a first guess. 'Service' > > > seems to me to be too general. The key point which is special > > > about NSIS is that the relevant resources are those which > > > have to be provided by entities along the data path, but I > > > can't think of a snappy term for that. > > > > > > The other impact is that we might need to broaden our > > > thinking about how such a signalling protocol might fit into > > > an overall solution to some resource management problem > > > (hence my interest in Marcus' firewall draft). Certainly, the > > > relationship between nsis and midcom/tist activities seems > > > important to understand. > > > > > > Robert H. > > > > > > > -----Original Message----- > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > Sent: 27 June 2002 10:10 > > > > To: Zhigang.Kan@nokia.com > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > Hi Kan, > > > > > > > > > Resource Management Function is introduced in this draft as > > > > > "RMF: an abstract concept, representing the management of > > > > > resources in a domain or a node". I think that this > > > > > definition is not appropriate for the aim of NSIS which is > > > > > Signaling QoS, not Signaling resource. > > > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > > is not only about QoS signaling, it is about service related > > > > signaling in general. What about calling the above system > > > > "Service Management Function"? > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > Hi all, > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > activities got together after the interim meeting to put > > > > > together a joint framework document in the form of an all-new > > > > > individual submission. It (roughly) follows the structure > > > > > that was introduced and refined at that meeting. > > > > > > > > > > ============================================================== > > > > > ============ > > > > > Abstract > > > > > > > > > > The NSIS working group is considering protocol > > developments in > > > > > signaling for resources for a traffic flow along its > > > path in the > > > > > network. The requirements for such signaling are being > > > > > developed in a > > > > > separate document; This Internet Draft proposes a > > > framework for > > > > > such signaling. This initial version provides a model for > > > > > describing > > > > > the entities that take part in the signaling and the > > > > ways in which > > > > > they can be used in different modes of operation. It also > > > > > discusses > > > > > the overall structure of such a signaling protocol. > > > Finally, it > > > > > considers the possible interactions of NSIS signaling > > > with other > > > > > protocols and functions, including security issues. > > > > > ============================================================== > > > > > ============ > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > find a copy here: > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > highlights in section 3. > > > > > > > > > > Cheers, > > > > > > > > > > Robert Hancock > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 10:07:02 2002 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 KAA03076 for ; Wed, 10 Jul 2002 10:07:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27478 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 10:07:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25783; Wed, 10 Jul 2002 09:54:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25754 for ; Wed, 10 Jul 2002 09:54:05 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02595 for ; Wed, 10 Jul 2002 09:53:10 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6ADrWU04570; Wed, 10 Jul 2002 15:53:32 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA15903; Wed, 10 Jul 2002 15:53:31 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 132284A36A; Wed, 10 Jul 2002 15:53:31 +0200 (CEST) Date: Wed, 10 Jul 2002 15:53:31 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , "'nsis@ietf.org'" Subject: Re: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Message-ID: <21323471.1026316411@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Georgios, What do you mean by hierarchical levels? If you mean using tunnels for data and signaling, then why do you need this if you have on-path signaling? (And we do not talk about the reservation on a node itself. Marcus --On Mittwoch, 10. Juli 2002 15:18 +0200 "Georgios Karagiannis (ELN)" wrote: > > Hi Marcus > > I have an additional comment to the requirements > draft (draft-ietf-nsis-req-03.txt): > Due to the fact that the Multi-level signaling has become > a very important issue in NSIS, I would very much appreciate if we could > add the following bullet into Section 5.1.3 "Modularity": > > "- multi-level NSIS signaling: the NSIS protocol should be able to > be separated into more than one hierarchical levels." > > > Best Regards, > Georgios > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 10:12:26 2002 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 KAA03399 for ; Wed, 10 Jul 2002 10:12:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28349 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 10:13:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26481; Wed, 10 Jul 2002 09:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26438 for ; Wed, 10 Jul 2002 09:59:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02839 for ; Wed, 10 Jul 2002 09:58:06 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6ADwwrU025726; Wed, 10 Jul 2002 15:58:58 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKD6RLZ; Wed, 10 Jul 2002 15:58:58 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 15:58:57 +0200 Message-ID: X-Sybari-Trust: 51b86e6a 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , "Georgios Karagiannis (ELN)" , "'nsis@ietf.org'" Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Date: Wed, 10 Jul 2002 15:58:56 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus The hierarchical levels are refering to protocol functionality levels. A similar concept is presented in draft-braden-2level-signal-arch-00.txt where two levels of protocol functionality are defined. Best Regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Wednesday, July 10, 2002 3:54 PM To: Georgios Karagiannis (ELN); 'nsis@ietf.org' Subject: Re: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Georgios, What do you mean by hierarchical levels? If you mean using tunnels for data and signaling, then why do you need this if you have on-path signaling? (And we do not talk about the reservation on a node itself. Marcus --On Mittwoch, 10. Juli 2002 15:18 +0200 "Georgios Karagiannis (ELN)" wrote: > > Hi Marcus > > I have an additional comment to the requirements > draft (draft-ietf-nsis-req-03.txt): > Due to the fact that the Multi-level signaling has become > a very important issue in NSIS, I would very much appreciate if we could > add the following bullet into Section 5.1.3 "Modularity": > > "- multi-level NSIS signaling: the NSIS protocol should be able to > be separated into more than one hierarchical levels." > > > Best Regards, > Georgios > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 10:42:09 2002 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 KAA04764 for ; Wed, 10 Jul 2002 10:42:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01947 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 10:43:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29634; Wed, 10 Jul 2002 10:22:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29604 for ; Wed, 10 Jul 2002 10:22:01 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04010 for ; Wed, 10 Jul 2002 10:21:02 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6AELOU06703; Wed, 10 Jul 2002 16:21:24 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA16267; Wed, 10 Jul 2002 16:21:24 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C383242FB9; Wed, 10 Jul 2002 16:21:23 +0200 (CEST) Date: Wed, 10 Jul 2002 16:21:23 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , "'nsis@ietf.org'" Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Message-ID: <22995856.1026318083@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Ok, I agree I will do some polishing of this for -04 Marcus --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > The hierarchical levels are refering to protocol functionality levels. > A similar concept is presented in draft-braden-2level-signal-arch-00.txt > where two levels of protocol functionality are defined. > > Best Regards, > Georgios > > > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Wednesday, July 10, 2002 3:54 PM > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: Re: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > Georgios, > > What do you mean by hierarchical levels? > > If you mean using tunnels for data and signaling, then why do you need > this if you have on-path signaling? (And we do not talk about the > reservation on a node itself. > > Marcus > > > --On Mittwoch, 10. Juli 2002 15:18 +0200 "Georgios Karagiannis (ELN)" > wrote: > >> >> Hi Marcus >> >> I have an additional comment to the requirements >> draft (draft-ietf-nsis-req-03.txt): >> Due to the fact that the Multi-level signaling has become >> a very important issue in NSIS, I would very much appreciate if we could >> add the following bullet into Section 5.1.3 "Modularity": >> >> "- multi-level NSIS signaling: the NSIS protocol should be able to >> be separated into more than one hierarchical levels." >> >> >> Best Regards, >> Georgios >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 10:47:30 2002 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 KAA05020 for ; Wed, 10 Jul 2002 10:47:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02856 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 10:48:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00240; Wed, 10 Jul 2002 10:30:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00198 for ; Wed, 10 Jul 2002 10:29:59 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04240 for ; Wed, 10 Jul 2002 10:29:02 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6AETMpj006282 for ; Wed, 10 Jul 2002 07:29:22 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEJ42314; Wed, 10 Jul 2002 07:26:29 -0700 (PDT) Message-Id: <5.1.0.14.0.20020710102358.00ab5030@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Jul 2002 10:29:28 -0400 To: nsis@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [NSIS] middlebox drafts Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I was a little surprised to see the middlebox draft show up on the agenda for the Yokohama meeting. Those interested in that topic may want to have a look at my drafts on using an RSVP-like protocol for middlebox communications, which I think, frankly, are more detailed and contain more analysis and evaluation. They are: http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-01.txt http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt The protocol draft is not offered up for standardization purposes but more as a proof-of-concept exercise. As a reminder, the TIST BOF, which focuses on using an RSVP- like protocol for middlebox communication, will be Monday evening from 19:30-2200. Thanks, Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 11:05:15 2002 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 LAA05852 for ; Wed, 10 Jul 2002 11:05:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05306 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 11:06:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02951; Wed, 10 Jul 2002 10:49:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02924 for ; Wed, 10 Jul 2002 10:49:00 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05063 for ; Wed, 10 Jul 2002 10:48:05 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6AEmvrU008112; Wed, 10 Jul 2002 16:48:57 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKB5DH6; Wed, 10 Jul 2002 16:48:57 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 16:48:56 +0200 Message-ID: X-Sybari-Trust: 56c1d20c 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Wed, 10 Jul 2002 16:48:55 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please see my remarks in line! > Hi Marcus > > In my opinion, the main requirements that are affected by the > in-path and out of path discussions are: > > * Requirement 5.2.2: > "No constraint of the QoS signaling Controllers to be in the data path" > You could remove this requirement! [marcus] The requierment is already very weak and just says "No constraint". Could you live with it if we even make it a SHOULD? [georgios] what I meant is to emphasize in a stronger sense that the QoS signaling Controllers should be in the data path, for example this requirement could become: "The NSIS Forwarders and NSIS Initiators should be located in the data path. However, there might be optional situations where this is not required." ------------------------------------------------------ > * Requirement 5.7.2: > "Flexibility in the placement of the QoS initiator" > In my opinion the way of how the network initiated reservations > are explained ion this section, are mainly out of path. > Please remove the sentence that describes network initiated reservations. [marcus] This has nothing to do with on/off path. Removing this means no proxies, no Acess Router initated signaling (even if they are on path) I vote for leaving it. [georgios] Okay, what about changing the text: "But also network-initiated reservations are required in various scenarios such as PSTN gateways, some VPNs, mobility." Into: "But also network-initiated reservations are required in various scenarios such as PSTN gateways, some VPNs, mobility. Note however, that the NSIS Initiator should be located in the data path (see Requirement 5.2.2)." ------------------------------------------------------------------------------------- > * Requirement 5.7.3: > "Flexibility in the initiation of re-negotiation (QoS change requests)" > In my opinion the way of how the network initiated reservations > are explained ion this section, are mainly out of path. > Please remove the sentence that describes network initiated reservations. [marcus] The same here as with the previous req. [georgios] Okay, what about changing the text: "But also network-initiated re-negotiations is required in cases, where the network is not able to further guarantee resources etc." Into: "But also network-initiated re-negotiations is required in cases, where the network is not able to further guarantee resources etc. Note however, that the NSIS Initiator should be located in the data path (see Requirement 5.2.2)." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 11:23:05 2002 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 LAA06618 for ; Wed, 10 Jul 2002 11:23:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06900 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 11:24:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05411; Wed, 10 Jul 2002 11:06:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05376 for ; Wed, 10 Jul 2002 11:06:42 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05878 for ; Wed, 10 Jul 2002 11:05:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6AF63U09435; Wed, 10 Jul 2002 17:06:03 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA16819; Wed, 10 Jul 2002 17:06:02 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 58B6C4D430; Wed, 10 Jul 2002 17:06:02 +0200 (CEST) Date: Wed, 10 Jul 2002 17:06:02 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Melinda Shore , nsis@ietf.org Subject: Re: [NSIS] middlebox drafts Message-ID: <25674708.1026320762@[192.168.102.207]> In-Reply-To: <5.1.0.14.0.20020710102358.00ab5030@localhost> References: <5.1.0.14.0.20020710102358.00ab5030@localhost> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Melinda, My middlebox draft was intended for NSIS, because it discusses some issues we have in requirements and framework discussion. I see using NSIS for middlebox communication as a different application, where NSIS might work, and therefore we have to look into it. That your drafts is much better from a middlebox point of view is clear. E.g., in NSIS we do not care what service we signal for, so the data we need to ship around does not belong into NSIS scope. Marcus --On Mittwoch, 10. Juli 2002 10:29 -0400 Melinda Shore wrote: > I was a little surprised to see the middlebox draft show > up on the agenda for the Yokohama meeting. Those interested > in that topic may want to have a look at my drafts on using > an RSVP-like protocol for middlebox communications, which I > think, frankly, are more detailed and contain more analysis > and evaluation. They are: > http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-01.txt > http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt > > The protocol draft is not offered up for standardization > purposes but more as a proof-of-concept exercise. > > As a reminder, the TIST BOF, which focuses on using an RSVP- > like protocol for middlebox communication, will be Monday > evening from 19:30-2200. > > Thanks, > > Melinda > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 11:29:46 2002 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 LAA07027 for ; Wed, 10 Jul 2002 11:29:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08001 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 11:30:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06171; Wed, 10 Jul 2002 11:12:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06134 for ; Wed, 10 Jul 2002 11:12:42 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06250 for ; Wed, 10 Jul 2002 11:11:46 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6AFBxGs027436; Wed, 10 Jul 2002 08:11:59 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEJ43257; Wed, 10 Jul 2002 08:09:09 -0700 (PDT) Message-Id: <5.1.0.14.0.20020710111043.00abcd60@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Jul 2002 11:12:08 -0400 To: brunner@ccrle.nec.de, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] middlebox drafts In-Reply-To: <25674708.1026320762@[192.168.102.207]> References: <5.1.0.14.0.20020710102358.00ab5030@localhost> <5.1.0.14.0.20020710102358.00ab5030@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org At 05:06 PM 7/10/02 +0200, Marcus Brunner wrote: >That your drafts is much better from a middlebox point of view is clear. E.g., in NSIS we do not care what service we signal for, so the data we need to ship around does not belong into NSIS scope. I absolutely agree with that, but there are some considerations with regard to signaling and NAT, as well as security. The "Network-Friendlier Midcom" draft provides a generalized framework rather than being a specific proposal. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 11:58:03 2002 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 LAA08387 for ; Wed, 10 Jul 2002 11:58:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11886 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 11:58:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09760; Wed, 10 Jul 2002 11:42:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09732 for ; Wed, 10 Jul 2002 11:42:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07663 for ; Wed, 10 Jul 2002 11:41:42 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6AFh2i14311 for ; Wed, 10 Jul 2002 18:43:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 18:42:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 18:42:30 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 18:42:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656EA@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Thread-Index: AcIoFsr9L13NTYmXQtq5MfVIjCRCqQAEYxlg To: , , X-OriginalArrivalTime: 10 Jul 2002 15:42:31.0089 (UTC) FILETIME=[66F46210:01C22828] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA09733 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > "- multi-level NSIS signaling: the NSIS protocol should be able to > be separated into more than one hierarchical levels." What is a 'hierarchical level'? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 12:01:39 2002 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 MAA08560 for ; Wed, 10 Jul 2002 12:01:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13673 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 12:02:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10141; Wed, 10 Jul 2002 11:45:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10101 for ; Wed, 10 Jul 2002 11:45:15 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07788 for ; Wed, 10 Jul 2002 11:44:18 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6AFjhi15283 for ; Wed, 10 Jul 2002 18:45:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 18:45:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 18:45:11 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 18:45:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656EB@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Thread-Index: AcIoHT0PjVR+RfmJStqMsiQZhbrPHwAC3Yhg To: , , X-OriginalArrivalTime: 10 Jul 2002 15:45:11.0283 (UTC) FILETIME=[C6700C30:01C22828] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10103 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > Ok, I agree I will do some polishing of this for -04 > Marcus > > --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi Marcus > > > > The hierarchical levels are refering to protocol > functionality levels. > > A similar concept is presented in > draft-braden-2level-signal-arch-00.txt > > where two levels of protocol functionality are defined. I think this is OK, however I don't like the term 'hierarchical' in this case. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 12:03:10 2002 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 MAA08630 for ; Wed, 10 Jul 2002 12:03:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14117 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 12:04:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10256; Wed, 10 Jul 2002 11:46:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10219 for ; Wed, 10 Jul 2002 11:46:29 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07812 for ; Wed, 10 Jul 2002 11:45:35 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6AFkRrU019265; Wed, 10 Jul 2002 17:46:27 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKD7VDF; Wed, 10 Jul 2002 17:46:27 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 17:46:26 +0200 Message-ID: X-Sybari-Trust: 7c2942fd 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Date: Wed, 10 Jul 2002 17:46:25 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John What about muliu level signaling? best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, July 10, 2002 5:45 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Hi Marcus, > Ok, I agree I will do some polishing of this for -04 > Marcus > > --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi Marcus > > > > The hierarchical levels are refering to protocol > functionality levels. > > A similar concept is presented in > draft-braden-2level-signal-arch-00.txt > > where two levels of protocol functionality are defined. I think this is OK, however I don't like the term 'hierarchical' in this case. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 12:06:03 2002 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 MAA08785 for ; Wed, 10 Jul 2002 12:06:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14711 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 12:06:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10749; Wed, 10 Jul 2002 11:49:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10713 for ; Wed, 10 Jul 2002 11:49:49 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07975 for ; Wed, 10 Jul 2002 11:48:55 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6AFoJi16635 for ; Wed, 10 Jul 2002 18:50:19 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 18:49:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 18:49:47 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] middlebox drafts X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 18:49:47 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656ED@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] middlebox drafts Thread-Index: AcIoHmSUtrYbgLIpQ7aFaBqtsUl4rQACmkUQ To: , X-OriginalArrivalTime: 10 Jul 2002 15:49:47.0941 (UTC) FILETIME=[6B56B550:01C22829] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10714 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Melinda, > I was a little surprised to see the middlebox draft show > up on the agenda for the Yokohama meeting. At this point, I don't think that we need to worry about solutions, but at this point the possibility that NSIS may be used for other things. > Those interested > in that topic may want to have a look at my drafts on using > an RSVP-like protocol for middlebox communications, which I > think, frankly, are more detailed and contain more analysis > and evaluation. They are: > http://search.ietf.org/internet-drafts/draft-shore-friendly-mi > dcom-01.txt > http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt > > The protocol draft is not offered up for standardization > purposes but more as a proof-of-concept exercise. > > As a reminder, the TIST BOF, which focuses on using an RSVP- > like protocol for middlebox communication, will be Monday > evening from 19:30-2200. And I recommend that everyone interested in this attend the session. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 12:17:56 2002 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 MAA09581 for ; Wed, 10 Jul 2002 12:17:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16392 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 12:18:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12156; Wed, 10 Jul 2002 12:00:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12011 for ; Wed, 10 Jul 2002 12:00:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08430 for ; Wed, 10 Jul 2002 11:59:07 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6AFxxrU021442; Wed, 10 Jul 2002 17:59:59 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKB5XBQ; Wed, 10 Jul 2002 17:59:59 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 17:59:44 +0200 Message-ID: X-Sybari-Trust: 47038199 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Date: Wed, 10 Jul 2002 17:59:56 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John Sorry, what I meant is multi-level signaling. Best Regards, Georgios -----Original Message----- From: Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: Wednesday, July 10, 2002 5:46 PM To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Hi John What about muliu level signaling? best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, July 10, 2002 5:45 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Hi Marcus, > Ok, I agree I will do some polishing of this for -04 > Marcus > > --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi Marcus > > > > The hierarchical levels are refering to protocol > functionality levels. > > A similar concept is presented in > draft-braden-2level-signal-arch-00.txt > > where two levels of protocol functionality are defined. I think this is OK, however I don't like the term 'hierarchical' in this case. 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 daemon@optimus.ietf.org Wed Jul 10 12:26:44 2002 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 MAA09868 for ; Wed, 10 Jul 2002 12:26:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16908 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 12:27:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15218; Wed, 10 Jul 2002 12:09:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15176 for ; Wed, 10 Jul 2002 12:09:38 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08923 for ; Wed, 10 Jul 2002 12:08:41 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6AG90U12868; Wed, 10 Jul 2002 18:09:00 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA17463; Wed, 10 Jul 2002 18:08:59 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 642F352B3E; Wed, 10 Jul 2002 18:08:59 +0200 (CEST) Date: Wed, 10 Jul 2002 18:08:59 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Message-ID: <29452340.1026324539@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit John is right I aslo don't like multi-level XXX difficult to understand. I regard modularity as the right word in the title, but I will go over the text such that in really includes what Georgios means. Marcus --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios Karagiannis (ELN)" wrote: > Hi John > > What about muliu level signaling? > > best regards, > Georgios > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, July 10, 2002 5:45 PM > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; > nsis@ietf.org > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > Hi Marcus, > >> Ok, I agree I will do some polishing of this for -04 >> Marcus >> >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios Karagiannis (ELN)" >> wrote: >> >> > Hi Marcus >> > >> > The hierarchical levels are refering to protocol >> functionality levels. >> > A similar concept is presented in >> draft-braden-2level-signal-arch-00.txt >> > where two levels of protocol functionality are defined. > > I think this is OK, however I don't like the term 'hierarchical' > in this case. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 13:43:26 2002 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 NAA12727 for ; Wed, 10 Jul 2002 13:43:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24399 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 13:44:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22753; Wed, 10 Jul 2002 13:26:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22724 for ; Wed, 10 Jul 2002 13:26:31 -0400 (EDT) Received: from aifhs8.alcatel.fr (na5.alcatel.fr [194.133.58.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12133 for ; Wed, 10 Jul 2002 13:25:36 -0400 (EDT) From: Alban.Couturier@alcatel.fr Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id TAA05416; Wed, 10 Jul 2002 19:25:30 +0200 (MET DST) Received: from alcatel.fr ([139.54.209.251]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002071019252979:8005 ; Wed, 10 Jul 2002 19:25:29 +0200 Message-ID: <3D2C6E50.8F9C7D35@alcatel.fr> Date: Wed, 10 Jul 2002 19:26:40 +0200 X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" Cc: "'Olov =?iso-8859-1?Q?Schel=E9n'?=" , nsis@ietf.org Subject: Re: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-opopsig-00.txt) References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/10/2002 19:25:29, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/10/2002 19:25:31 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22725 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Georgios, again, thank you for your feedback. "Georgios Karagiannis (ELN)" a écrit : > > Hi Olov > > Please my remarks/comments in line and after the word [georgios]! > > Best Regards, > Georgios > > -----Original Message----- > From: Olov Schelén [mailto:olov.schelen@operax.com] > Sent: Friday, July 05, 2002 2:32 PM > To: Georgios Karagiannis (ELN) > Cc: 'Alban.Couturier@alcatel.fr'; nsis@ietf.org > Subject: Re: [NSIS] comments on draft in-path and out of path > (draft-schelen-nsis-opopsig-00.txt) > > Georgious, > thank you for your comments. I have included my response below. > /Olov > > "Georgios Karagiannis (ELN)" wrote: > > > Dear Olov and Alban > > > > I have read your draft and I have some comments mainly on Sections 3 and 4 (see below). > > > > Best Regards, > > Georgios > > > > Comments on Section 3.2.1: > > ------------------------------------ > > > > Comment_1 on Section 3.2.1: > > ----------------- > > You mention that: > > "The on-path signaling relies on the fundamental assumption that packets are all routed the > > same way, based on the IP destination address. This will be called in this draft the > > "traditional IP routing." > > [georgios] Right but, you should not exclude other types of routing. In my opinion an > > on path solution should consider > > the possible cases described in {RFC2992] regarding: > > "Analysis of an Equal-Cost Multi-Path Algorithm". > > In general, if the signalling protocol uses the same routing protocol as the data > > path then the signaling > > messages and their associated data path packets will have to follow the same path. > > > > [Olov] In RFC2992, nothing is said on that load-balancing is REQUIRED to be based on source-destination > pairs of addresses only. The same holds for any traffic engineering methods. How this is done by > real implementations I am not sure about, but would appreciate feedback on this. My understanding is > that divergence of signalling-path and data-path can happen, at least at some points in the network. > With MPLS there may be an approach for sending real-time traffic (e.g. VoIP) on separate LSPs and > also to transfer the traffic to next domain on different interfaces. > > [georgios] What I tried to say is that what is described in RFC2992 should also be considered as > traditional L3 routing. MPLS is not L3 traditional routing. > > > > > Comment_2 on Section 3.2.1: > > ------------- > > I do not understand this comment: > > "In these cases, a signaling unaware cloud is not anymore a signaling carrier, > > as nothing assures it > > will forward the signal at the same place it will forward the dataflow." > > > > [georgios] If the signalling protocol uses the same routing protocol as the data path then the > > signaling messages and their associated data path packets will have to follow the same path. > > This will have to be ensured even if the signaling protocol is not used in a certain domain. > > A network provider may for example need to configure the network such that signalling path > > messages follow the same path as the data path messages. However, this is a reasonable > > requirement, since a network provider should be able to configure many other parameters > > in his network. > > [olov] The problem here is that there may be domains along the path (perhaps over-provisioned and not > signalling-aware) that do not follow this recomendation. In the backbone there is probably multiple > peering-points, so once the signalling has diverted it may enter following domains at different > ingresses. > > [georgios] Yes, but this then will also held for the out of path approach! Therefore, this > issue is not only an on path issue, but also an out of path issue! > Please be fair with your comparison! Georgios, I agree that every ISP that will carry IP flows signalled by NSIS (so almost all ISPs) must build/configure its network in such a way the signalling will always "follow" the data path, be it on or off-path. This *is* an issue with an on-path protocol in a network making "non traditional routing". And we don't think we can force every ISP to have traditional routing. Of course if a on-path signal is send in the bad direction, an off-path NF downstream won't fix it, we never said that. And I think we are fair when we talk about solutions in 4.2.3. We wrote a router can implement the required signalling carrier function that will redirect the signals in the right direction. This can also be done in an off-path NF. > > ------------------------------------------------------------------------------------------------- > > > > Comment on Section 3.2.2 > > --------------------------- > > In this section you are talking about centralized policy servers. > > What about distributed policy servers? Distributed on the edge nodes of a domain! > > ------------------------------------------------------------------------------------------------- > > > > [olov] Yes they can be distributed physically, but they are logically centralized in the sense that they > have a common understanding the commitments and resource availability in the domain. > > [georgios] In this situation the distributed policy servers are on path. But the way of how the > common understanding is provided is out of scope of NSIS. The way is out of scope. But it can have impacts if there is a way, a standardized way, or not. Anyway, the fact that the signaling is off the data path can facilitate the fact that the policy servers are on the signaling path. Distributed does not necessarily means inside a router for me. > > Comment on Section 3.2.3 > > ------------------- > > You mentioned: > > "One problem of RSVP and intserv is that every router in the network must implement > > intserv and RSVP in order to link the sink and the source with a chain of QoS capable > > routers that all allocate > > resources for the flow." > > > > [georgios] not all routers in a communication path have to implement Intserv. > > Actually, you mighty have domains that are overprovisioned and do not implement Intserv. > > What I try to say is that this issue applies to both types of architectures, > > i.e., on path and out of path. Therefore, it is not fair to presented here as an on > > path issue! > > [olov] Yes, there may be over-provisioned and QoS un-aware doamins in both cases, so ensuring e2e QoS is > difficult in both models. We do here however emphasise the need for having the signalling support > in routers at all. Although only in edge-routers (as we explain) there are plenty of edge routers > that need to handle this signalling. This is to compare with off-path (application-level) > signalling that does not require particular support in routers at all. > > [georgios] yes e2e is difficult in both models, but ensuring out of path QoS support > is more difficult than the in path QoS support. What I tried to emphasize here is > that we need to be fair in the comparison of these two approaches. Georgios, I think that 3.2.3 is honestly written. As you correctly point out, routers may not implement Intserv for RSVP, and this has also been written in 3.2.3. > > ------------------------------------------------------------------------------------------------- > > > > Comment on Section 4.2.1 > > ----------------------------- > > You mention that there are benefits of using independent signaling plane and forwarding plane. > > This is only a benefit only when only you will assume that the forwarding plane is > > overprovisioned or, etc., > > You can get the same situation with an on path signaling when you will assume that > > a network consists of a concatenation of domains and the only routers that are using > > the NSIS protocol are only few edge nodes. This is after assuming that all the other routers > > are overprovisioned. > > Thus I do not see this issue as a benefit of the out of path architecture! > > ------------------------------------------------------------------------------------------------- > > > > [olov] I refer to my response to your previous comment. > > [georgios] I also refer to my previous reply to your previous remark. Georgios, I don't follow you on the assumption. First, 4.2.1 discuss one benefit of off-path which is independance of signalling plane and forwarding plane. This is more about economical and migration advantage than about bandwidth consumption. To come back to the overprovisionning issue you raise here, I tend to think that off path can be better, if not the same. But it is true this has not been explicitely written. Here if we can have one off-path NF that checks for the same QoS request two links/pipes (they are counterparts of trunks in aggregated RSVP, for instance), there will be one state for these two pipes/links. On the other hand, there will be 2 verifications in two RSVP aggregators and two states, one in each RVP aggregator. > > Comment on Section 4.2.2 > > --------------- > > You mentioned that VoIP or multimedia network applications rely on servers > > such as soft switches, gatekeepers, etc.,,. > > You also mention that on-path signaling solutions require complex deployments that can be > > avoided thanks to the placement's flexibility associated to the off-path model. > > In my opinion the solutions that are needed for a centralized entity located out of path > > to efficiently configure, efficiently manage resources, and efficiently communicate with > > the routers that are on path and are not using the NSIS protocol are much more complicated than > > the solutions that you will need to use when the servers are located on path. > > [olov] Standards-wise the off-path model only needs a high-level protocol to be set (e.g. containers over > TCP and possibly also over some well known applicaton level protocol). In addition, it would be nice > to use an efficient standard for setting traffic conditioners at edges (e.g., COPS-PR plus > standardised PIBs, SNMPCONF plus standardised MIBs, etc). Standards-wise this is simpler, relatively > speaking. Note that conditioners would only be operated at microflow-level at accesses, while the > rest would be on larger aggregates (constrained on destination prefixes, etc) . Implementation-wise > I see only your opinion, so I respond only by ensuring that there are solutions that are just > running fine. > > [georgios] In my remark I wanted to emphasize that a centralized entity located out of path > needs to efficiently configure, efficiently manage resources, and efficiently communicate with > the routers that are on path and are not using the NSIS protocol. When these procedures > have to be performed on demand (and online) are more complicated > then the procedures that have to be used for an on-path approach. What are these procedures? We already identified synchronization with routing tables, and admission control in the issue chapter. > > Comment in Section 4.2.3 > > ------------------------------ > > This benefit is associated with an on path disadvantage given in Section 3.2.1. > > The comment that I gave there applies also here! > > In general, if the signalling protocol uses the same routing protocol as the data path > > then the signaling > > messages and their associated data path packets will have to follow the same path. > > [olov] Our intent here is to state exactly what you say, i.e., that the problem of keeping track of > non-traditional routing applies also in the off-path case. > > [georgios] Yes, but you present it as a benefit of the out of path approach (not as a > benefit for the on-path approach). Please be fair with your comparison! That is true we placed in in the benefits of off-path. Why? Because off-path solution require no change in the legacy routers. Maybe this point could be merged in 4.2.1, but 4.2.1 was more about a general and long term characteristic af the off-path solution, while 4.2.3 focus on a particular problem of today. > > Comment in Section 4.3 > > ---------------------------- > > > > I would like to add some more issues with the out of path signaling: > > The out of path signaling scenario, compared to the in-path > > signaling, introduces the need of a centralized architecture > > (which can in turn be distributed). Having an architecture > > with centralized decision-making capabilities means that > > certain kinds of issues must be handled: > > > > * There may be a single point of failure > > > > Failure detection and error recovery are tremendously > > important. > > > > [olov] Failure detection are tremendously important in both models. In the off-path model there is no > single point of failure when the implementation is distributed (and nodes can operate independently > ). I see that the same problem applies for on-path, so I agree that we should add this as an > importand issue in general. > > [georgios] Yes, in the situation that the implementation is distributed and out of path > there will not be a single point of failure. However, I think that there will be much less > points of failures than in an on-path approach. Thus, the failure detection and error recovery > procedures are much more important in the out of path approach, compared to the on-path > approach. > > > > > > > * Checking for availability of resources within a domain may be > > based on either static or dynamic configuration data. > > If this is done dynamically, the RTT of the signalling > > protocol itself could be increased. This is an addition to the text > > that you propose in Section 4.3.2. > > [olov] Well, thats true if you prefer to do it that way. However, instant traffic measures are often not a > good basis for predicting the future. Rather you would rely on periodic feedback and perhaps > heuristics. Anyway this information will be collected as a background process that does not affect > the RTT of the signalling itself. > > > > > > > * The centralized resource management entity might become > > congested faster due to the higher number of signaling > > requests compared to a distributed resource management > > architecture. > > [olov] It is very hard to make definite statements about performance in both models. Evaluation by real > operators is probably the best way to go. However, servers are dealing with this kind of > computational tasks quite well, while routers are good at packet forwarding (not known for handling > slow-path tasks very efficiently). Also hierarchical aggregation keeps down the overhead. > > [georgios] Well, there are a lot of studies that show that centralized entities in networks are > performance bottlenecks. It sure that a trade off must be done between centralization and distribution. But here I don't really see the difference between off-path and on-path. Maybe off path is more flexible. > > * Sophisticated mechanisms for discovery of the centralized > > entities are needed. This is an addition to your Section 4.3.1. > > > > [olov] QoS controlers can also be configured with peering relations (much like BGP-routers are configured > with peering-relations today). For end-hosts (in case it would be desirable for hosts to be > initiators), configuration could be through dhcp-like mechanism. > > [georgios] Only if the number of the out of path entities is limited! Sure. But do you think off-path NF number is illimited? Best regards -- Alban Couturier --------------------------------------------------------------------- Alcatel Research and Innovation Ets de Marcoussis R&I/ULC Route de Nozay mailto:Alban.Couturier@alcatel.fr F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 --------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 15:01:27 2002 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 PAA15593 for ; Wed, 10 Jul 2002 15:01:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00371 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 15:02:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29268; Wed, 10 Jul 2002 14:47:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29239 for ; Wed, 10 Jul 2002 14:47:38 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15182 for ; Wed, 10 Jul 2002 14:46:44 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA10129; Wed, 10 Jul 2002 11:47:34 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA21679; Wed, 10 Jul 2002 11:47:34 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA23225; Wed, 10 Jul 2002 14:47:33 -0400 (EDT) Message-ID: <3D2C8145.EFA3BAC9@dma.isg.mot.com> Date: Wed, 10 Jul 2002 14:47:33 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function References: <0C1353ABB1DEB74DB067ADFF749C4EEFC656D2@esebe004.NOE.Nokia.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Dan, > > > Perhaps what is missing is a definition of Quality of Service. This has been a > > long standing problem in the RFC series: I'm not aware of a single place where > > the term is defined. It is also true that the industry has no single accepted > > definition. While I'm not convinced that this is the right place to put such > > definitions, there doesn't seem to be a better one right now. > > I think the reason that there is no definition is because QoS is in the > eyes of the beholder & may be very service specific. QoS for a file download > via FTP may be very different than QoS for streaming audio over RTP. Thank you for proving my point ;-) It is true that the performance attributes and values required for file transfer differ from those required for audio streaming. It is not true that there are multiple different frameworks. Definitions like the ones that I suggested -- whereever they get published -- would help make this clear. > > > This is one reason why I have been depreciating the use of the term QoS in > NSIS. > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 15:12:45 2002 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 PAA16146 for ; Wed, 10 Jul 2002 15:12:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00955 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 15:13:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29705; Wed, 10 Jul 2002 14:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29650 for ; Wed, 10 Jul 2002 14:59:54 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15489; Wed, 10 Jul 2002 14:59:00 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA20680; Wed, 10 Jul 2002 11:58:20 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA22816; Wed, 10 Jul 2002 11:59:25 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 13:59:14 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Rajeev Koodli , Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Wed, 10 Jul 2002 13:58:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org James, As much as I like to see a clean interaction between CT and NSIS, I don't see any reason why CT needs to play the role of NSIS optimization, not to forget the NSIS didn't even exist back then. CT is simply a tool you need in your seamless mobility toolbox, it eventually involved into a container carrying any context you like (even non-IP context, as long as it is feasible). The profile types, that Rajeev mentioned is aligned with this line of thinking. I seriously advise against going back and change CT requirements for the sake of optimizing NSIS, which at this point we don't know what it is. A couple of months from now, we have to revise CT because of a security related protocol, later for something else..... The later we wait for CT standardization, the more home brewed versions are going to pop up, just like Behcet mentioned. My 1.5 cents (lower dollars) Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, July 08, 2002 4:37 PM To: Rajeev Koodli; Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 15:13:24 2002 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 PAA16171 for ; Wed, 10 Jul 2002 15:13:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00976 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 15:14:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29637; Wed, 10 Jul 2002 14:59:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29537 for ; Wed, 10 Jul 2002 14:59:27 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15480 for ; Wed, 10 Jul 2002 14:58:33 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA21771 for ; Wed, 10 Jul 2002 11:59:26 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA26404 for ; Wed, 10 Jul 2002 11:59:25 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA23305 for ; Wed, 10 Jul 2002 14:59:25 -0400 (EDT) Message-ID: <3D2C840B.B48F017C@dma.isg.mot.com> Date: Wed, 10 Jul 2002 14:59:23 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nsis@ietf.org Subject: [Fwd: Re: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: Re: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Date: Wed, 10 Jul 2002 14:41:22 -0400 From: Dan Grossman To: "Hancock, Robert" References: <76C92FBBFB58D411AE760090271ED41805203D10@rsys002a.roke.co.uk> "Hancock, Robert" wrote: > Hi Dan, > > Without wishing to appear negative about your proposal, I can't help pointing out a sentence in the 'clarified' charter (you can find it referred to in the interim meeting report): "It is out of scope of this working group to define what quality of service is." See also further down in this mail. This is unfortunate. It's kinda difficult to define QoS signalling protocols without knowing what a QoS signalling protocol is signalling _for_. Having been through this several times over the years (ISDN, Frame Relay, ATM), I can assure you that making signalling protocols without a well formed understanding of the semantics you're looking to carry is a recipe for futility and breakage. I can see the point in saying that a signalling protocol working group is the wrong place to be defining QoS, but it doesn't seem to be happening anywhere in the IETF, and that's a concern.. > > > In any case, we're supposed to be working on signalling for more generic things than just QoS. What would be really incredibly useful (for a framework obsessive like me) would be a definition of the attributes of these "things" which actually affect what the signalling has to be able to do. But this seems to be a hard problem. Sure, but unless it's solved, the protocol isn't going to be very useful. It's unfortunate that the IESG put the horse before the cart and chartered NSIS before addressing the hard architecture issues ( problem statement and core definitions, as well as those raised but not addressed in RFC 2990). > > > Cheers, > > Robert H. > > [Please note: I'm not saying that defining QoS is not an interesting general question. But given how hard it seems to be, maybe we should try to work out how much of a definition is actually needed to make progress in NSIS.] At a top level, the objective is a protocol that negotiates attribute-value tuples among multiple parties (hosts, networks, network elements). Some of these tuples are independent variables that describe the performance of the communication, and others are dependent values that describe the resources allocated to that communication. Unfortunately, the devil is in the details, and until you can sort out the semantics and interactions at an architectural level, you won't get anywhere. > > > > -----Original Message----- > > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > > Sent: 09 July 2002 20:35 > > To: Schneider, Marco > > Cc: Hancock, Robert; Zhigang.Kan@nokia.com; > > Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org > > Subject: Re: [NSIS] New framework draft: Resource Management Function > > v.s.QoS Management Function > > > > > > Perhaps what is missing is a definition of Quality of > > Service. This has been a > > long standing problem in the RFC series: I'm not aware of a > > single place where > > the term is defined. It is also true that the industry has > > no single accepted > > definition. While I'm not convinced that this is the right > > place to put such > > definitions, there doesn't seem to be a better one right now. > > > > The following may be a good start toward working definitons: > > > > Quality-of-Service(QoS): A set of attributes and their > > values that, taken > > together, characterize the performance experienced by a flow. > > > > End-to-end QoS: A set of attributes and their values that, > > taken together, > > characterize the performance experienced by an end-to-end > > flow, i.e., as > > observed by protocols above the IP layer > > > > Edge-to-edge QoS: A set of attributes and their values, > > that, taken together, > > characterize the performance experienced by a flow from the > > point where it > > enters a domain (or a concatenation of domains) to the > > point(s) where it leaves > > that (those) domain(s). > > > > Agreed QoS: A set of attributes and their values that have > > been agreed between > > a network (or concatentation of networks) and two (or more) > > hosts. This set > > characterizes the performance the network(s) agree that a > > flow will experience > > for a defined period. The agreement can be reached through > > signalling or > > administratively. > > > > Actual QoS: The measured values of a set of QoS attributes. > > > > "Schneider, Marco" wrote: > > > > > Hi Robert, all > > > > > > I find our mapping of distinctions to terms confusing. The > > term QOS is of > > > course short for Quality of Service. This begs the question > > "what or which > > > service". In our context we seem to be speaking of packet > > transport: A QOS > > > (quality of service) service being the ability to specify > > the quality of > > > said packet transport service. For me, strictly speaking, > > QOS is not an > > > example of a resource but rather a type of service that can > > reasonably be > > > thought of to require resource reservations in a network. > > What resources are > > > actually reserved or utilized to achieve QOS is beyond the > > scope of our > > > work. Put another way a service is an abstraction of network > > > resources/capabilities and whether or not the service > > implementation uses > > > said abstractions is beyond scope. > > > > > > Marco > > > > > > > -----Original Message----- > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: Thursday, June 27, 2002 5:45 AM > > > > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > Hi Zhigang, > > > > > > > > 'QoS' is one example of 'resource'. > > > > > > > > I'm actually not sure it is possible to define 'resource' > > > > precisely. The basic point is that NSIS should provide a > > > > generally useful signalling capability, which you could use > > > > for various types of resource; exactly what types is going to > > > > be defined implicitly by whether the NSIS capabilities are > > > > appropriate to the resource type needs. In that sense, > > > > there's a benefit in vagueness. > > > > > > > > An RMF is absolutely not a BB. In our framework, "RMF" is > > > > just a name for what NSIS offloads certain problems in > > > > resource management to, it's a way to talk about the boundary > > > > of the NSIS problem space. NSIS doesn't care how the RMF is > > > > implemented; it should be possible to support both > > > > centralised and distributed resource management strategies > > > > with the same NSIS protocol. The one thing that is ruled out > > > > (initially) is NSIS signalling directly to a centralised > > > > (off-path) entity; this is a consequence of recent scope > > > > guidance. Please see especially section 5.1 of the draft (the > > > > hardest section to write, by the way). > > > > > > > > Yours, > > > > > > > > Robert H. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > > > Sent: 27 June 2002 11:11 > > > > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: Resource > > > > Management Function > > > > > v.s. QoS Management Function > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > Maybe we don't care what term/name is called. The most > > > > > important is that the "resources" and "resource management" > > > > > should be defined exactly, and the relationship between > > > > > resource and QoS should be clarified. Is RMF similar as BB? > > > > > > > > > > BR/Kan Zhigang > > > > > > > > > > -----Original Message----- > > > > > From: ext Georgios Karagiannis (ELN) > > > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > > > Sent: 2002å¹´6æoe^27æ-¥ 17:47 > > > > > To: 'Hancock, Robert' > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: Resource Management > > > > > Function v. > > > > > s. QoS Management Function > > > > > > > > > > > > > > > Hi all > > > > > > > > > > I agree with the explanation given by Robert regarding > > RMF. I am in > > > > > favor of keeping the term RMF. > > > > > > > > > > Best Regards, > > > > > Georgios > > > > > > > > > > -----Original Message----- > > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > > Sent: Thursday, June 27, 2002 11:39 AM > > > > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] New framework draft: Resource > > > > Management Function > > > > > v.s. QoS Management Function > > > > > > > > > > > > > > > hi all, > > > > > > > > > > I think it's valuable for Zhigang to highlight the point, > > > > > because this is one of the major changes in this NSIS > > > > > framework input compared to (most?) previous ones (certainly > > > > > the ones I have been involved in). One of the consequences of > > > > > the email discussions around the time of the interim meeting > > > > > (e.g. > > > > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > > > > msg01378.html) was that we should look at more general > > > > > resources than just QOS. (IMHO, this is still not obvious > > > > > even in the post-interim clarified charter, BTW.) > > > > > > > > > > This has quite a big impact on what we write, at least. We > > > > > still need a good name for this "thing we are signalling > > > > > for", "resource" (and hence RMF) is a first guess. 'Service' > > > > > seems to me to be too general. The key point which is special > > > > > about NSIS is that the relevant resources are those which > > > > > have to be provided by entities along the data path, but I > > > > > can't think of a snappy term for that. > > > > > > > > > > The other impact is that we might need to broaden our > > > > > thinking about how such a signalling protocol might fit into > > > > > an overall solution to some resource management problem > > > > > (hence my interest in Marcus' firewall draft). Certainly, the > > > > > relationship between nsis and midcom/tist activities seems > > > > > important to understand. > > > > > > > > > > Robert H. > > > > > > > > > > > -----Original Message----- > > > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > > > Sent: 27 June 2002 10:10 > > > > > > To: Zhigang.Kan@nokia.com > > > > > > Cc: nsis@ietf.org > > > > > > Subject: RE: [NSIS] New framework draft: Resource > > > > > Management Function > > > > > > v.s. QoS Management Function > > > > > > > > > > > > > > > > > > Hi Kan, > > > > > > > > > > > > > Resource Management Function is introduced in this draft as > > > > > > > "RMF: an abstract concept, representing the management of > > > > > > > resources in a domain or a node". I think that this > > > > > > > definition is not appropriate for the aim of NSIS which is > > > > > > > Signaling QoS, not Signaling resource. > > > > > > > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > > > > is not only about QoS signaling, it is about service related > > > > > > signaling in general. What about calling the above system > > > > > > "Service Management Function"? > > > > > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > > > activities got together after the interim meeting to put > > > > > > > together a joint framework document in the form of > > an all-new > > > > > > > individual submission. It (roughly) follows the structure > > > > > > > that was introduced and refined at that meeting. > > > > > > > > > > > > > > > > ============================================================== > > > > > > > ============ > > > > > > > Abstract > > > > > > > > > > > > > > The NSIS working group is considering protocol > > > > developments in > > > > > > > signaling for resources for a traffic flow along its > > > > > path in the > > > > > > > network. The requirements for such signaling are being > > > > > > > developed in a > > > > > > > separate document; This Internet Draft proposes a > > > > > framework for > > > > > > > such signaling. This initial version provides a model for > > > > > > > describing > > > > > > > the entities that take part in the signaling and the > > > > > > ways in which > > > > > > > they can be used in different modes of operation. It also > > > > > > > discusses > > > > > > > the overall structure of such a signaling protocol. > > > > > Finally, it > > > > > > > considers the possible interactions of NSIS signaling > > > > > with other > > > > > > > protocols and functions, including security issues. > > > > > > > > > ============================================================== > > > > > > > ============ > > > > > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > > > find a copy here: > > > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > > > highlights in section 3. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Robert Hancock > > > > > > > > ======================================================================================== > Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. > > ------------------------------------------------------------------------ > Name: RMRL-Disclaimer.txt > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 18:31:52 2002 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 SAA22199 for ; Wed, 10 Jul 2002 18:31:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14461 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 18:32:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13451; Wed, 10 Jul 2002 18:16:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13380 for ; Wed, 10 Jul 2002 18:16:47 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21926; Wed, 10 Jul 2002 18:15:51 -0400 (EDT) Message-ID: <018a01c2285f$392d00d0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" , Cc: , , References: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Wed, 10 Jul 2002 15:14:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 18:53:17 2002 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 SAA22614 for ; Wed, 10 Jul 2002 18:53:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15309 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 18:54:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14700; Wed, 10 Jul 2002 18:38:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14647 for ; Wed, 10 Jul 2002 18:38:53 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22304; Wed, 10 Jul 2002 18:37:57 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA26907; Wed, 10 Jul 2002 15:37:55 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA04289; Wed, 10 Jul 2002 15:38:49 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 17:38:49 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5569@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli , Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Wed, 10 Jul 2002 17:38:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, July 10, 2002 5:15 PM To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. Madjid>> don't quite agree. A QoS framework that tightly controls resources, might need to release resources at old AR and obtain resources at new AR, so CT by itself is not always enough. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). Madjid>> Ok. Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 19:17:00 2002 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 TAA23088 for ; Wed, 10 Jul 2002 19:17:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA16476 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 19:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16008; Wed, 10 Jul 2002 19:04:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15978 for ; Wed, 10 Jul 2002 19:04:41 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22823 for ; Wed, 10 Jul 2002 19:03:45 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDFSA>; Thu, 11 Jul 2002 00:04:26 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203D37@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Thu, 11 Jul 2002 00:04:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" John, Interesting draft. I have tried to think it through from a purely NSIS perspective. 1) Nowhere does it say if routers (or even sources) should send packets from the same flow along the same path. Is that because it's (a) the wrong place to say so or (b) obvious or (c) impossible to mandate? In particular, it does say that a node not carrying out flow specific treatment MUST ignore the field on forwarding - maybe 'keeping packets together' could be regarded as flow specific treatment (and made mandatory). (If we could rely on this it would be a powerful weapon in the signalling/data path divergence issue, but see next point.) 2) The draft seems to encourage (SHOULD) a highly granular assignment of flow labels (e.g. section 4 rules 3 & 4). On the other hand, there may be good reasons to use the same label for a sequence of 'microflows' (e.g. successive files in a bulk ftp transfer; the same point has been made on the v6 list). Encouraging this granularity directly increases the signalling burden. How strong is SHOULD? 3) Fortunately, I think most of the agonies about flow label re-use don't have to worry us, they're end-system internal. However, there are two points: a) Do we need to strengthen our requirement for a TEAR message to flush flow label state? b) If a TEAR isn't possible (e.g. a route flap means some routers wouldn't see it), do we need to allow the end system to control the soft state timeout so they can be assured of when flow label state has been purged? I don't think our current requirements give this level of control to end hosts, and I'm not sure they should. 4) I don't see why the flow state establishment method (i.e. NSIS for example) needs to be able to manage flow label agreement between end systems (end of section 4). After all, it doesn't handle port number agreement. Such information would need to be end-to-end secured, which (IMHO) is a poor match to the security capabilities we are currently assuming for NSIS. 5) I'm seriously concerned about rule (6) of section 5. I don't see it has anything to do with a standard on flow label definition. If it does, then the rest of the draft has to be clarified so whenever it refers to address it is clear if it means home or care of address (e.g. on reception at the end system, does a node check the combination of flow label with HA or CoA to work out which flow something belongs to), and the security considerations section might need something on validating ownership of the home address as well. Better I think would be to point out that something like the second sentence of rule (6) applies in mobile environments, and that flow state establishment methods should handle this how best they can. (We have this requirement in NSIS anyway.) So, there might be some options for making the draft leaner and meaner. Cheers, Robert > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 10 July 2002 13:43 > To: nsis@ietf.org > Subject: [NSIS] IPv6 Flow Label > > > Hi all, > > One tool we may want to use is the IPv6 flow label. There is some > standardization of this on-going in the IPv6 WG. I wonder if folks > could comment on the spec, with regards to how NSIS could use it. > > It can be found from: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt > > John > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 19:17:30 2002 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 TAA23105 for ; Wed, 10 Jul 2002 19:17:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA16495 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 19:18:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16082; Wed, 10 Jul 2002 19:05:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16025 for ; Wed, 10 Jul 2002 19:05:00 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22830 for ; Wed, 10 Jul 2002 19:04:03 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDFSF>; Thu, 11 Jul 2002 00:04:36 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203D3A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: brunner@ccrle.nec.de, "Georgios Karagiannis (ELN)" , "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Date: Thu, 11 Jul 2002 00:04:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi, i'm slightly baffled by this. i was taking a wild guess that georgios was referring to nsis-triggering-nsis scenarios (e.g. 5.5 in draft-hancock-nsis-fw-00, also draft-westberg-nsis-edge-edge-framework-00). if that's the case, isn't it covered by 5.3.6? [actually, i'm not certain that this turns into a feature visible in the protocol, it could be just a way of using the protocol; but we'll discover that during the framework.] if georgios is referring to transport/application layering as in draft-braden-2level-signal-arch-00.txt then isn't this covered by 5.1.4 (although we should probably refer to something more general than QoS...). i certainly don't like the term 'hierarchical' for this. georgios, what is your concern? robert > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 10 July 2002 17:09 > To: Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; > nsis@ietf.org > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > John is right I aslo don't like multi-level XXX difficult to > understand. I > regard modularity as the right word in the title, but I will > go over the > text such that in really includes what Georgios means. > > Marcus > > --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi John > > > > What about muliu level signaling? > > > > best regards, > > Georgios > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Wednesday, July 10, 2002 5:45 PM > > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; > > nsis@ietf.org > > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > > > > Hi Marcus, > > > >> Ok, I agree I will do some polishing of this for -04 > >> Marcus > >> > >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios > Karagiannis (ELN)" > >> wrote: > >> > >> > Hi Marcus > >> > > >> > The hierarchical levels are refering to protocol > >> functionality levels. > >> > A similar concept is presented in > >> draft-braden-2level-signal-arch-00.txt > >> > where two levels of protocol functionality are defined. > > > > I think this is OK, however I don't like the term 'hierarchical' > > in this case. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 19:17:33 2002 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 TAA23118 for ; Wed, 10 Jul 2002 19:17:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA16506 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 19:18:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16222; Wed, 10 Jul 2002 19:05:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16122 for ; Wed, 10 Jul 2002 19:05:14 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22834 for ; Wed, 10 Jul 2002 19:04:17 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDFSD>; Thu, 11 Jul 2002 00:04:36 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203D3C@rsys002a.roke.co.uk> From: "Hancock, Robert" To: sven.van_den_bosch@alcatel.be Cc: "'Schneider, Marco'" , nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing Date: Thu, 11 Jul 2002 00:04:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi sven, a belated reply: [snip] > > In fact, whether the path is determined by normal L3 routing > or abnormal > routing or any other mechanism is rather a second order problem. The > fundamental aspect is that NSIS (I assume) has no role in > determining that > path, it takes the path as given and has to live with it. > > [Sven] Would it be possible for NSIS to record the path it > has been given > at setup time and express its requirement to stay on it? [reh] OK, this is an interesting prospect, depending on 'who' NSIS should express this requirement to. Saying that NSIS should be able to do route recording and then feed this information into resource management is a requirement I can understand. (I'm not saying if I agree with it or not. It almost certainly isn't in the requirements draft at the moment.) > > What would be helpful for me would be if someone could give > an example of > how the _flow_ (not the signalling) is going to get > restricted to the old > path. Then we could see if any special tricks would be needed > to make NSIS > work after this had been done. At the moment, I can't see > what they would > be. > > [Sven] Suppose a single route towards a destination is > announced and later > on another route towards that destination is announced with a QoS > attribute. Then the flow could remain on that route, although a new > (best-effort) route becomes available. Would that be a valid example? [reh] what does 'announced' mean really? i guess it means that routers end up with forwarding entries that enable the route to be followed hop by hop in the 'right' way. well, they're available for the signalling messages as well - there's no new requirement on NSIS in this case, so far as I can see. cf. 4.1 of our framework document: "NSIS needs to know ... how to select the outgoing interface for a signaling message, in case this needs to match the interface that will be used by the corresponding flow. This might be as simple as just allowing the IP layer to handle the message using its own routing table." [Or, it might not.] We needed that even before talking about route pinning, and I'm not sure what more could be required; doing it right is an implementation issue between NSIS and the router's forwarding engine. see you in japan, robert. > > Cheers, > > Robert H. > > PS I'm sure that a topology aware system could do some sort of traffic > engineering by setting up tunnels and so on. Whether this is > a good thing > to do I make no comment on; but I don't see what additional > requirements > would be needed to make NSIS work in such an environment. In > any case, I > get the feeling there's a danger that we're trying to use > NSIS to recreate > MPLS on the IP layer. One MPLS is enough for me... > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: 09 July 2002 08:51 > > To: Hancock, Robert > > Cc: 'Schneider, Marco'; nsis@ietf.org > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > Hi Robert, Marco, > > > > I am not sure that NSIS has nothing to do with the fix of > the problem > > described by Marco. If you have the capability to do routing of this > > displaced flow in a non-traditional way, then wouldn't you > > like NSIS not to > > tear down the existing reservations (I assume in your example > > you would > > have the reservations taken down, then start new NSIS > > signalling indicating > > the 'non-traditional' path) while you updating the > > signalling? Of course, > > if you want to support such a function you would need to be > > sure that the > > old path is still available. This requires the ability to > distinguish > > between a failure on the old path and the availability of a > new path. > > > > CU, > > Sven. > > > > > > > > > > > > "Hancock, Robert" @ietf.org on 09/07/2002 > > 09:35:34 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: "'Schneider, Marco'" , nsis@ietf.org > > cc: > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > Hi Marco, > > > > I think I understand your concerns and your example. I'm > > still not sure it > > translates into an NSIS requirement. > > > > To paraphrase (I hope correctly) your example as you describe it: > > 1. You have a flow which is taking a certain path through > the network. > > 1a. NSIS messages are following that path, and reserving > > resources for it. > > Because there are enough resources on the particular path, > > the reservation > > is successful. > > 2. Someone adds a new link to the network, which changes the path in > > question. The new path is incapable of carrying the flow. > > 3. The reservation is routed along the new path. It's > > rejected (too little > > capacity) and all reservations associated with it are dropped. > > > > Clearly, that's undesirable. However, the problem is not > with the NSIS > > signalling, so NSIS can't fix it: At point (2), if you are > in a normal > > connectionless network, the flow will also be routed along > > the new path. > > NSIS is just (correctly) reflecting the fact that routing > > hasn't found the > > real 'best' route through the network. > > > > In other words, the real solution to the problem has to > come from some > > routing trick which keeps the flow on the old path, and we > referred to > > things in this class as 'non-traditional L3 routing' . If you > > can find a > > method to do this, then we want NSIS to continue to work if > > you are using > > it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or > > impossible is another question, but that seems to be the > requirement.) > > > > Cheers, > > > > Robert H. > > > > > -----Original Message----- > > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > > Sent: 08 July 2002 20:04 > > > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > > Independence > > > ofexisting flow reservations and default routing > > > > > > > > > John, > > > > > > As per my response to Marcus: I raised my concerns during the > > > meeting and > > > was asked to post an example, which I did. > > > > > > As for the text, I guess it is not clear to me whether this > > > addresses the > > > issue. In my opinion the example I gave does not have > > > anything to do with > > > non-traditional L3 routing. > > > > > > Marco > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: Monday, June 10, 2002 8:29 AM > > > > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > > > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > > > Independence > > > > ofexisting flow reservations and default routing > > > > > > > > > > > > Hi Marco & Marcus, > > > > > We discussed the issue of route pinning and traffic > > > engineering in > > > > > Helsinki. The conclusion during the meeting was that we > > > > want to add an > > > > > assuption saying: NSIS assumes normal/standard L3 routing > > > > > > > > > > Plus we add a requirement saying that NSIS protocol should > > > > not be broken by > > > > > networks which do non-traditional L3 routing. > > > > > > > > > > Does this cover your concern? Do we really need to add that > > > > NSIS must work > > > > > with default routing changes? > > > > > > > > I agree with Marcus that this is what we are trying to say. > > > > Marco, is this > > > > text OK with you? > > > > > > > > John > > > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 19:22:10 2002 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 TAA23210 for ; Wed, 10 Jul 2002 19:22:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA16639 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 19:23:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16093; Wed, 10 Jul 2002 19:05:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16024 for ; Wed, 10 Jul 2002 19:05:00 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22829 for ; Wed, 10 Jul 2002 19:04:03 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDFS1>; Thu, 11 Jul 2002 00:04:36 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203D3B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Georgios Karagiannis (ELN)" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Thu, 11 Jul 2002 00:04:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi all, a question: how precisely does the body of the requirements text have to track the w.g. charter? if the charter were (hypothetically) to be extended at a later date to include (just as an example) off path signalling, would we want to update the requirements RFC just to reflect that? a suggestion: what about adding a section near the start explaining that any subsequent work we do is constrained by these requirements and the current charter, and then in particular explaining the initial restriction to on-path signalling and the reasoning behind it. i would have thought we could leave the rest of the document as it is. [Note: such a section could also define just what the on-path restriction actually was. I've seen at least 4 different incompatible views on that.] cheers, robert h. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 10 July 2002 15:49 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt > > > Hi Marcus > > Please see my remarks in line! > > > Hi Marcus > > > > In my opinion, the main requirements that are affected by the > > in-path and out of path discussions are: > > > > * Requirement 5.2.2: > > "No constraint of the QoS signaling Controllers to be in > the data path" > > You could remove this requirement! > > [marcus] The requierment is already very weak and just says > "No constraint". Could > you live with it if we even make it a SHOULD? > > [georgios] what I meant is to emphasize in a stronger sense that the > QoS signaling Controllers should be in the data path, for > example this > requirement could become: > > "The NSIS Forwarders and NSIS Initiators should be located in > the data path. > However, there might be optional situations where this is not > required." > > ------------------------------------------------------ > > > * Requirement 5.7.2: > > "Flexibility in the placement of the QoS initiator" > > In my opinion the way of how the network initiated reservations > > are explained ion this section, are mainly out of path. > > Please remove the sentence that describes network initiated > reservations. > > [marcus] This has nothing to do with on/off path. Removing > this means no proxies, no > Acess Router initated signaling (even if they are on path) > I vote for leaving it. > > [georgios] Okay, what about changing the text: > "But also network-initiated reservations are required in > various scenarios such as > PSTN gateways, some VPNs, mobility." > > Into: > "But also network-initiated reservations are required in > various scenarios such as > PSTN gateways, some VPNs, mobility. Note however, that the > NSIS Initiator should be located > in the data path (see Requirement 5.2.2)." > > -------------------------------------------------------------- > ----------------------- > > > > * Requirement 5.7.3: > > "Flexibility in the initiation of re-negotiation (QoS > change requests)" > > In my opinion the way of how the network initiated reservations > > are explained ion this section, are mainly out of path. > > Please remove the sentence that describes network initiated > reservations. > > [marcus] The same here as with the previous req. > > [georgios] Okay, what about changing the text: > "But also network-initiated re-negotiations is required in > cases, where the > network is not able to further guarantee resources etc." > > Into: > > "But also network-initiated re-negotiations is required in > cases, where the > network is not able to further guarantee resources etc. Note > however, that the NSIS Initiator > should be located in the data path (see Requirement 5.2.2)." > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 20:07:17 2002 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 UAA24065 for ; Wed, 10 Jul 2002 20:07:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA18992 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 20:08:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18030; Wed, 10 Jul 2002 19:54:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18001 for ; Wed, 10 Jul 2002 19:54:01 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23643 for ; Wed, 10 Jul 2002 19:53:06 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g6ANvUgc018225; Wed, 10 Jul 2002 18:57:30 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g6ANqcr23476; Wed, 10 Jul 2002 18:52:38 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <3G6CDKKA>; Wed, 10 Jul 2002 18:53:43 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB74@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'brunner@ccrle.nec.de'" , "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Date: Wed, 10 Jul 2002 18:53:38 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus, [Original Marco] 1) The introduction of new links should not affect existing connections. [Marcus] you mean the path of existing reservations should not change? Is this a general operator requirement? With RSVP style siganling it definitly affects existing pathes. [New Marco] The requirement is that existing reservations should not be lost. An obvious solution is to keep the same path. Do you know of any operators who have deployed RSVP? [Original Marco] 2) More specifically the operator should not have to be concerned with whether addition of links could affect existing connections. [Marcus] I would assume that in most cases, and done on lightly loaded networks, this would not affect existing services. However, this can definitly happen, in certain cases. Again do you feel other operators have similar concerns? [New Marco] First of all the existing reservations may require any number of criteria not including capacity. Second of all, an operator could be adding links precisely because the network was overloaded. I would think that other operators would have this concern and it would be nice to hear from someone RSVP deployment experience. Nevertheless I hope we are trying to build something robust that will work not just for the networks of today but also those of tomorrow. Best Regards, Marco > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Tuesday, July 09, 2002 11:01 AM > To: Schneider, Marco; 'nsis@ietf.org' > Cc: 'sven.van_den_bosch@alcatel.be' > Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow > reserv ations and default routing > > > Marco, > > see inline > > --On Montag, 8. Juli 2002 13:35 -0500 "Schneider, Marco" > wrote: > > > Hi Marcus, > > > > Sorry for the very delayed reply. Allow me to quote for an > earlier reply > > to Georgios: > > > > "In my mind this requirement has do with the layering > relationship between > > QOS Signaling and Routing. In a hard-state solution once > the QOS path is > > created it does not unchange. The signaling protocol uses > input from the > > routing protocol to create this path. The path created is > static. In an > > RSVP style solution without route pinning we have a > reactive distributed > > algorithm that takes the default routing path as its input. While it > > should be possible to do this style of path that is dynamically > > determined by the default destination based routing, it must also be > > possible to build the path once based upon an initial set > of inputs." > > > > The fact that one can work around the deficiencies of a > protocol layering > > design does not mean the design is sound. > > > > Regarding Item 1: take care by introducing new links into > your topology, > > something you might want to do on lightly loaded metworks anyway. > > > > 1) The introduction of new links should not affect existing > connections. > > you mean the path of existing reservations should not change? > Is this a > general operator requirement? With RSVP style siganling it definitly > affects existing pathes. > > > 2) More specifically the operator should not have to be > concerned with > > whether addition of links could affect existing connections. > > I would assume that in most cases, and done on lightly loaded > networks, > this would not affect existing services. However, this can definitly > happen, in certqain cases. Again do you feel other operators > have similar > concerns? > > > > > Regarding Item 2: > > I am not sure how constraint/qos routing goes into the mechanism of > > provisioning. In fact the two are unrelated in IMHO. I do > agree that QOS > > routing appears to be out of scope. > > In QoS routing you choose the path not based on "normal > routing", but based > on resource availabiliy, which I relate to a function of the > provisioning > process (I agree in a sloppy way). > > Marcus > > > Marco > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: Friday, June 07, 2002 10:19 AM > >> To: Schneider, Marco; 'nsis@ietf.org' > >> Cc: 'sven.van_den_bosch@alcatel.be' > >> Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow > >> reservations and default routing > >> > >> > >> Marco, > >> > >> IMHO the problem you have shown in the example can be solved > >> in 2 ways, and > >> both are IMO out of scope for NSIS. > >> 1) take care by introducing new links into your topology, > >> something you > >> might want to do on lightly loaded metworks anyway. > >> > >> 2) I think an other solution would be constraint/QoS routing, > >> which is more > >> going into the mechanis of provisioning, which is again > out of scope. > >> > >> > >> Marcus > >> > >> > >> > >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" > >> wrote: > >> > >> > Hi All, > >> > > >> > One of the Open issues mentioned in the current > >> requirements draft is > >> > Route Pinning (item 47). In the following I discuss a very strong > >> > motivation for the ability to do route pinning if a soft > >> state solution > >> > is used for NSIS. I have tried to express this as a > >> requirement upon NSIS > >> > rather than the mechanism (route pinning being the obvious > >> one) by which > >> > this requirement may be achieved. > >> > > >> > Requirement: NSIS must directly support the ability to > >> insulate a flow > >> > reservation from changes in the default routing behaviour > >> except in those > >> > cases where said changes result from loss of resources > >> (layer 3 hops, > >> > capacity etc.) along the existing flow reservation path. > >> > > >> > For instance, utilizing traffic engineering in a layer 2 > >> network (e.g. > >> > MPLS or ATM) we may provision additional links or change > >> the resources > >> > associated with existing links. Additionally failures in > >> the network may > >> > cause changes. Such changes must not affect existing layer > >> 3 reservation > >> > paths with the exception of those cases where the existing > >> reservation > >> > path no longer exists or no longer has capacity to > support the flow > >> > reservation. > >> > > >> > As a simple example consider a network with two routers A > >> and B and assume > >> > that the shortest path from A to B is two hops. Based upon > >> NSIS signaling, > >> > as directed by default routing based upon number of hops, a > >> reservation > >> > path is setup from A to B along a path of two hops, where > >> both hops have a > >> > capacity of 10 and the reservation uses a capacity of 6. > >> Now let us assume > >> > that a direct link with capacity 5 is provisioned between A and B > >> > resulting in a new and direct default route of 1 hop. If > >> NSIS uses a soft > >> > state solution without route pinning then the existing flow > >> reservation > >> > will be redirected along the new link, which cannot support > >> it. Thus the > >> > existing flow reservation is lost due a change in the > >> network unrelated > >> > to its current path. In fact thousands of reservations > may have been > >> > routed along the original path and would now be disrupted. > >> Such protocol > >> > behaviour is not acceptable. > >> > > >> > Best Regards, > >> > Marco > >> > > >> > > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> personal home page: http://www.brubers.org/marcus > >> > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 10 21:28:57 2002 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 VAA25690 for ; Wed, 10 Jul 2002 21:28:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA22887 for nsis-archive@odin.ietf.org; Wed, 10 Jul 2002 21:29:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22511; Wed, 10 Jul 2002 21:15:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22476 for ; Wed, 10 Jul 2002 21:15:42 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25513 for ; Wed, 10 Jul 2002 21:14:48 -0400 (EDT) From: Zhigang.Kan@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6B1GCi25919 for ; Thu, 11 Jul 2002 04:16:12 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 04:15:40 +0300 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 04:15:40 +0300 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:15:30 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Date: Thu, 11 Jul 2002 09:12:22 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E3DD@beebe001.NOE.Nokia.com> Thread-Topic: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Thread-Index: AcIoGZsY1faJIxRTRa6gkTZhPxoBbQAXYLKA To: , , Cc: , X-OriginalArrivalTime: 11 Jul 2002 01:15:30.0960 (UTC) FILETIME=[72F46100:01C22878] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id VAA22477 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I agree on Georgios's suggestions. Should we have the common terms in the Requirement Draft. BTW, 'Signals what' (QoS, Resource, whatever) should be identified/classified in this meeting. BR/Kan Zhigang -----Original Message----- From: ext Georgios Karagiannis (ELN) [mailto:Georgios.Karagiannis@eln.ericsson.se] Sent: 2002å¹´7月10æ—¥ 21:45 To: 'Dan Grossman'; Schneider, Marco Cc: 'Hancock, Robert'; Kan Zhigang (Nokia-RD/Beijing); nsis@ietf.org Subject: RE: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Hi the draft draft-hancock-nsis-fw-00.txt provides definitions for several additional terms. These terms are described in "Section 2: Terminology" of this draft. I propose to introduce them into the requirements draft draft-ietf-nsis-req-0x.txt! Can we get an agreement on this? Best Regards, Georgios -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Tuesday, July 09, 2002 9:35 PM To: Schneider, Marco Cc: 'Hancock, Robert'; Zhigang.Kan@nokia.com; Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: Re: [NSIS] New framework draft: Resource Management Function v.s.QoS Management Function Perhaps what is missing is a definition of Quality of Service. This has been a long standing problem in the RFC series: I'm not aware of a single place where the term is defined. It is also true that the industry has no single accepted definition. While I'm not convinced that this is the right place to put such definitions, there doesn't seem to be a better one right now. The following may be a good start toward working definitons: Quality-of-Service(QoS): A set of attributes and their values that, taken together, characterize the performance experienced by a flow. End-to-end QoS: A set of attributes and their values that, taken together, characterize the performance experienced by an end-to-end flow, i.e., as observed by protocols above the IP layer Edge-to-edge QoS: A set of attributes and their values, that, taken together, characterize the performance experienced by a flow from the point where it enters a domain (or a concatenation of domains) to the point(s) where it leaves that (those) domain(s). Agreed QoS: A set of attributes and their values that have been agreed between a network (or concatentation of networks) and two (or more) hosts. This set characterizes the performance the network(s) agree that a flow will experience for a defined period. The agreement can be reached through signalling or administratively. Actual QoS: The measured values of a set of QoS attributes. "Schneider, Marco" wrote: > Hi Robert, all > > I find our mapping of distinctions to terms confusing. The term QOS is of > course short for Quality of Service. This begs the question "what or which > service". In our context we seem to be speaking of packet transport: A QOS > (quality of service) service being the ability to specify the quality of > said packet transport service. For me, strictly speaking, QOS is not an > example of a resource but rather a type of service that can reasonably be > thought of to require resource reservations in a network. What resources are > actually reserved or utilized to achieve QOS is beyond the scope of our > work. Put another way a service is an abstraction of network > resources/capabilities and whether or not the service implementation uses > said abstractions is beyond scope. > > Marco > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, June 27, 2002 5:45 AM > > To: 'Zhigang.Kan@nokia.com'; Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] New framework draft: Resource Management Function > > v.s. QoS Management Function > > > > > > Hi Zhigang, > > > > 'QoS' is one example of 'resource'. > > > > I'm actually not sure it is possible to define 'resource' > > precisely. The basic point is that NSIS should provide a > > generally useful signalling capability, which you could use > > for various types of resource; exactly what types is going to > > be defined implicitly by whether the NSIS capabilities are > > appropriate to the resource type needs. In that sense, > > there's a benefit in vagueness. > > > > An RMF is absolutely not a BB. In our framework, "RMF" is > > just a name for what NSIS offloads certain problems in > > resource management to, it's a way to talk about the boundary > > of the NSIS problem space. NSIS doesn't care how the RMF is > > implemented; it should be possible to support both > > centralised and distributed resource management strategies > > with the same NSIS protocol. The one thing that is ruled out > > (initially) is NSIS signalling directly to a centralised > > (off-path) entity; this is a consequence of recent scope > > guidance. Please see especially section 5.1 of the draft (the > > hardest section to write, by the way). > > > > Yours, > > > > Robert H. > > > > > > > > > -----Original Message----- > > > From: Zhigang.Kan@nokia.com [mailto:Zhigang.Kan@nokia.com] > > > Sent: 27 June 2002 11:11 > > > To: Georgios.Karagiannis@eln.ericsson.se; Hancock, Robert > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > Hi all, > > > > > > Maybe we don't care what term/name is called. The most > > > important is that the "resources" and "resource management" > > > should be defined exactly, and the relationship between > > > resource and QoS should be clarified. Is RMF similar as BB? > > > > > > BR/Kan Zhigang > > > > > > -----Original Message----- > > > From: ext Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 2002å¹′6æoe^27æ-ï¿¥ 17:47 > > > To: 'Hancock, Robert' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource Management > > > Function v. > > > s. QoS Management Function > > > > > > > > > Hi all > > > > > > I agree with the explanation given by Robert regarding RMF. I am in > > > favor of keeping the term RMF. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: Thursday, June 27, 2002 11:39 AM > > > To: 'Geib, Ruediger'; Zhigang.Kan@nokia.com > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] New framework draft: Resource > > Management Function > > > v.s. QoS Management Function > > > > > > > > > hi all, > > > > > > I think it's valuable for Zhigang to highlight the point, > > > because this is one of the major changes in this NSIS > > > framework input compared to (most?) previous ones (certainly > > > the ones I have been involved in). One of the consequences of > > > the email discussions around the time of the interim meeting > > > (e.g. > > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > > > msg01378.html) was that we should look at more general > > > resources than just QOS. (IMHO, this is still not obvious > > > even in the post-interim clarified charter, BTW.) > > > > > > This has quite a big impact on what we write, at least. We > > > still need a good name for this "thing we are signalling > > > for", "resource" (and hence RMF) is a first guess. 'Service' > > > seems to me to be too general. The key point which is special > > > about NSIS is that the relevant resources are those which > > > have to be provided by entities along the data path, but I > > > can't think of a snappy term for that. > > > > > > The other impact is that we might need to broaden our > > > thinking about how such a signalling protocol might fit into > > > an overall solution to some resource management problem > > > (hence my interest in Marcus' firewall draft). Certainly, the > > > relationship between nsis and midcom/tist activities seems > > > important to understand. > > > > > > Robert H. > > > > > > > -----Original Message----- > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > Sent: 27 June 2002 10:10 > > > > To: Zhigang.Kan@nokia.com > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] New framework draft: Resource > > > Management Function > > > > v.s. QoS Management Function > > > > > > > > > > > > Hi Kan, > > > > > > > > > Resource Management Function is introduced in this draft as > > > > > "RMF: an abstract concept, representing the management of > > > > > resources in a domain or a node". I think that this > > > > > definition is not appropriate for the aim of NSIS which is > > > > > Signaling QoS, not Signaling resource. > > > > > > > > And if it is going to be perfectly in the sense of IETF, NSIS > > > > is not only about QoS signaling, it is about service related > > > > signaling in general. What about calling the above system > > > > "Service Management Function"? > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > Hi all, > > > > > > > > > > A group of us who were involved in past NSIS framework > > > > > activities got together after the interim meeting to put > > > > > together a joint framework document in the form of an all-new > > > > > individual submission. It (roughly) follows the structure > > > > > that was introduced and refined at that meeting. > > > > > > > > > > ============================================================== > > > > > ============ > > > > > Abstract > > > > > > > > > > The NSIS working group is considering protocol > > developments in > > > > > signaling for resources for a traffic flow along its > > > path in the > > > > > network. The requirements for such signaling are being > > > > > developed in a > > > > > separate document; This Internet Draft proposes a > > > framework for > > > > > such signaling. This initial version provides a model for > > > > > describing > > > > > the entities that take part in the signaling and the > > > > ways in which > > > > > they can be used in different modes of operation. It also > > > > > discusses > > > > > the overall structure of such a signaling protocol. > > > Finally, it > > > > > considers the possible interactions of NSIS signaling > > > with other > > > > > protocols and functions, including security issues. > > > > > ============================================================== > > > > > ============ > > > > > > > > > > While it works its way through the i-d editor queue, you can > > > > > find a copy here: > > > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt > > > > > > > > > > Comments are welcome. There is a list of open issue > > > > > highlights in section 3. > > > > > > > > > > Cheers, > > > > > > > > > > Robert Hancock > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 02:43:26 2002 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 CAA10889 for ; Thu, 11 Jul 2002 02:43:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14898 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 02:44:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13589; Thu, 11 Jul 2002 02:26:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13547 for ; Thu, 11 Jul 2002 02:26:21 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10571 for ; Thu, 11 Jul 2002 02:25:26 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6B6QIi00767 for ; Thu, 11 Jul 2002 09:26:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 09:25:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:25:47 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 11 Jul 2002 09:25:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB9@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] commentson on draft-ietf-nsis-req-03.txt Thread-Index: AcIoZkhed/UeExciTNqJDmDz6f468AAPPu5A To: , , Cc: X-OriginalArrivalTime: 11 Jul 2002 06:25:47.0087 (UTC) FILETIME=[CB07EDF0:01C228A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA13548 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi All, First off, I would say that the requirements MUST be restricted to on-path signaling, as this is all we are chartered to do. If we try to do more, we will hear about it during last call. Second, I think the framework draft & the analysis draft can contain issues related to off-path signaling. > how precisely does the body of the requirements text have to > track the w.g. charter? if the charter were (hypothetically) > to be extended at a later date to include (just as an > example) off path signalling, would we want to update the > requirements RFC just to reflect that? Procedurally, it should be a seperate document. I think we should restrict the requirements to on-path signaling, as this is what the WG is charted for. If we try to do more, the ADs will most likely ask us to remove the material that is out of scope during last call time. > a suggestion: > > what about adding a section near the start explaining that > any subsequent work we do is constrained by these > requirements and the current charter, and then in particular > explaining the initial restriction to on-path signalling and > the reasoning behind it. i would have thought we could leave > the rest of the document as it is. Well, this is implicit in the IETF process. However, howabout something like a note saying that off-path signaling is important, there is interest in it, but it is out of scope of the requirements document. > [Note: such a section could also define just what the on-path > restriction actually was. I've seen at least 4 different > incompatible views on that.] Want to provide a summary of the 4 views? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 04:12:24 2002 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 EAA12564 for ; Thu, 11 Jul 2002 04:12:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20630 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 04:13:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19413; Thu, 11 Jul 2002 03:59:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19373 for ; Thu, 11 Jul 2002 03:59:05 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12216 for ; Thu, 11 Jul 2002 03:58:11 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 11 Jul 2002 09:57:45 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3VR7PQA2>; Thu, 11 Jul 2002 09:58:25 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Date: Thu, 11 Jul 2002 09:58:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA19374 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Marcus, > Hi Marcus, ..... > [New Marco] The requirement is that existing reservations > should not be lost. That's valid for every provider. > [Original Marco] 2) More specifically the operator should not > have to be concerned with whether addition of links could > affect existing connections. ..... Absolutely true. The problem is, that a new link affects routing. NSIS excluded routing protocol changes from the charter (which I appreciate). All an NSIS solution could do is then to track route changes. This behaviour may be optimised to be fast and reliable. But I think what NSIS could and should do stops there. Network planning, provisioning and traffic engineering will add to that. But that's not part of the NSIS business and I wouldn't favour adding it to the charter. Regards, Rüdiger (working for Deutsche Telekom, should that matter) Rüdiger Geib Senior Expert Systems Integration T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 04:39:48 2002 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 EAA13334 for ; Thu, 11 Jul 2002 04:39:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22717 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 04:40:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21304; Thu, 11 Jul 2002 04:25:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21247 for ; Thu, 11 Jul 2002 04:24:57 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12786; Thu, 11 Jul 2002 04:24:03 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 11 Jul 2002 10:23:39 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3VR7PRVX>; Thu, 11 Jul 2002 10:24:16 +0200 Message-Id: From: "Geib, Ruediger" To: kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:24:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA21248 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James > The point I was trying to make is that given CT of QoS > context succeeds, NSIS signaling at the new access subnet is > unnecessary. Thus, it could be viewed as a kind of > optimization. If CT fails, then signaling would be needed. [RG] If this means "QoS related CT replaces MN signaling during [RG] handoff", given that the related resource reservation [RG] doesn't change. > I did not mean to imply that any changes were required in the > generic CT requirements (though perhaps there would need to be > some changes in the QoS specific context definition). [RG] QoS CT should use the NSIS resource reservation parameters [RG] as basic input for its own QoS parameters. Whether the [RG] original NSIS parameters are copied or derived [RG] technology or domain specific parameters are used for CT [RG] doesn't matter if the result is as if the original NSIS [RG] parameters were used to establish resources at the new AR. > Is this accurate, from the NSIS viewpoint? One case where I > could see it not being accurate is if there were some changes > required behind the access router in order to obtain QoS for > the mobile on the new router, but perhaps there are others. [RG] This may have to be clarified. I wouldn't expect an MN [RG] to get involved into tunnel set up and release, should [RG] this be the way an access network supports QoS and [RG] mobility. A local NSIS solution may be used within [RG] the access network to provide the required signaling. [RG] But I'd expect this to be invisible to the MN. [RG] I think NSIS and SEAMOBY must agree how both interwork. [RG] Besides the QoS parameter issue, an MN should be aware [RG] of the fact whether CT is supported and whether it is [RG] succesful (or whether it wasn't). [RG] To me this seems to be a loose cooperation. If NSIS and [RG] SEAMOBY conclude to ignore each other, I'd regard both [RG] as a waste of time with regard to wireless mobility [RG] combined with QoS. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 05:46:21 2002 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 FAA14344 for ; Thu, 11 Jul 2002 05:46:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26103 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 05:47:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25166; Thu, 11 Jul 2002 05:30:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25067 for ; Thu, 11 Jul 2002 05:29:57 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14128 for ; Thu, 11 Jul 2002 05:29:03 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6B9TOU36609; Thu, 11 Jul 2002 11:29:24 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA26031; Thu, 11 Jul 2002 11:29:23 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4A3E5526C1; Thu, 11 Jul 2002 11:29:23 +0200 (CEST) Date: Thu, 11 Jul 2002 11:29:23 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Schneider, Marco" , "'nsis@ietf.org'" Cc: "'sven.van_den_bosch@alcatel.be'" Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Message-ID: <5558472.1026386963@[192.168.102.207]> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB74@TRIMAIL2.ad.tri.sbc.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB74@TRIMAIL2.ad.tri.sbc.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Mittwoch, 10. Juli 2002 18:53 -0500 "Schneider, Marco" wrote: > Hi Marcus, > > [Original Marco] 1) The introduction of new links should not affect > existing connections. > > [Marcus] you mean the path of existing reservations should not change? Is > this a > general operator requirement? With RSVP style siganling it definitly > affects existing pathes. > > [New Marco] The requirement is that existing reservations should not be > lost. An obvious solution is to keep the same path. Do you know of any > operators who have deployed RSVP? No, otherwise I would have asked them. > > [Original Marco] 2) More specifically the operator should not have to be > concerned with > whether addition of links could affect existing connections. > > [Marcus] I would assume that in most cases, and done on lightly loaded > networks, > this would not affect existing services. However, this can definitly > happen, in certain cases. Again do you feel other operators have similar > concerns? > > [New Marco] First of all the existing reservations may require any number > of criteria not including capacity. Second of all, an operator could be > adding links precisely because the network was overloaded. I would think > that other operators would have this concern and it would be nice to hear > from someone RSVP deployment experience. Nevertheless I hope we are > trying to build something robust that will work not just for the networks > of today but also those of tomorrow. Yes, I hope so as well. The question is what the future network looks like. And I am actually not sure whether the changing of path in case of added new links is a feature or a bug. I would say it is a nice feature, specally in case where you add the link because of capacity problems. Marcus > Best Regards, > Marco >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: Tuesday, July 09, 2002 11:01 AM >> To: Schneider, Marco; 'nsis@ietf.org' >> Cc: 'sven.van_den_bosch@alcatel.be' >> Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow >> reserv ations and default routing >> >> >> Marco, >> >> see inline >> >> --On Montag, 8. Juli 2002 13:35 -0500 "Schneider, Marco" >> wrote: >> >> > Hi Marcus, >> > >> > Sorry for the very delayed reply. Allow me to quote for an >> earlier reply >> > to Georgios: >> > >> > "In my mind this requirement has do with the layering >> relationship between >> > QOS Signaling and Routing. In a hard-state solution once >> the QOS path is >> > created it does not unchange. The signaling protocol uses >> input from the >> > routing protocol to create this path. The path created is >> static. In an >> > RSVP style solution without route pinning we have a >> reactive distributed >> > algorithm that takes the default routing path as its input. While it >> > should be possible to do this style of path that is dynamically >> > determined by the default destination based routing, it must also be >> > possible to build the path once based upon an initial set >> of inputs." >> > >> > The fact that one can work around the deficiencies of a >> protocol layering >> > design does not mean the design is sound. >> > >> > Regarding Item 1: take care by introducing new links into >> your topology, >> > something you might want to do on lightly loaded metworks anyway. >> > >> > 1) The introduction of new links should not affect existing >> connections. >> >> you mean the path of existing reservations should not change? >> Is this a >> general operator requirement? With RSVP style siganling it definitly >> affects existing pathes. >> >> > 2) More specifically the operator should not have to be >> concerned with >> > whether addition of links could affect existing connections. >> >> I would assume that in most cases, and done on lightly loaded >> networks, >> this would not affect existing services. However, this can definitly >> happen, in certqain cases. Again do you feel other operators >> have similar >> concerns? >> >> > >> > Regarding Item 2: >> > I am not sure how constraint/qos routing goes into the mechanism of >> > provisioning. In fact the two are unrelated in IMHO. I do >> agree that QOS >> > routing appears to be out of scope. >> >> In QoS routing you choose the path not based on "normal >> routing", but based >> on resource availabiliy, which I relate to a function of the >> provisioning >> process (I agree in a sloppy way). >> >> Marcus >> >> > Marco >> > >> >> -----Original Message----- >> >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> >> Sent: Friday, June 07, 2002 10:19 AM >> >> To: Schneider, Marco; 'nsis@ietf.org' >> >> Cc: 'sven.van_den_bosch@alcatel.be' >> >> Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow >> >> reservations and default routing >> >> >> >> >> >> Marco, >> >> >> >> IMHO the problem you have shown in the example can be solved >> >> in 2 ways, and >> >> both are IMO out of scope for NSIS. >> >> 1) take care by introducing new links into your topology, >> >> something you >> >> might want to do on lightly loaded metworks anyway. >> >> >> >> 2) I think an other solution would be constraint/QoS routing, >> >> which is more >> >> going into the mechanis of provisioning, which is again >> out of scope. >> >> >> >> >> >> Marcus >> >> >> >> >> >> >> >> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" >> >> wrote: >> >> >> >> > Hi All, >> >> > >> >> > One of the Open issues mentioned in the current >> >> requirements draft is >> >> > Route Pinning (item 47). In the following I discuss a very strong >> >> > motivation for the ability to do route pinning if a soft >> >> state solution >> >> > is used for NSIS. I have tried to express this as a >> >> requirement upon NSIS >> >> > rather than the mechanism (route pinning being the obvious >> >> one) by which >> >> > this requirement may be achieved. >> >> > >> >> > Requirement: NSIS must directly support the ability to >> >> insulate a flow >> >> > reservation from changes in the default routing behaviour >> >> except in those >> >> > cases where said changes result from loss of resources >> >> (layer 3 hops, >> >> > capacity etc.) along the existing flow reservation path. >> >> > >> >> > For instance, utilizing traffic engineering in a layer 2 >> >> network (e.g. >> >> > MPLS or ATM) we may provision additional links or change >> >> the resources >> >> > associated with existing links. Additionally failures in >> >> the network may >> >> > cause changes. Such changes must not affect existing layer >> >> 3 reservation >> >> > paths with the exception of those cases where the existing >> >> reservation >> >> > path no longer exists or no longer has capacity to >> support the flow >> >> > reservation. >> >> > >> >> > As a simple example consider a network with two routers A >> >> and B and assume >> >> > that the shortest path from A to B is two hops. Based upon >> >> NSIS signaling, >> >> > as directed by default routing based upon number of hops, a >> >> reservation >> >> > path is setup from A to B along a path of two hops, where >> >> both hops have a >> >> > capacity of 10 and the reservation uses a capacity of 6. >> >> Now let us assume >> >> > that a direct link with capacity 5 is provisioned between A and B >> >> > resulting in a new and direct default route of 1 hop. If >> >> NSIS uses a soft >> >> > state solution without route pinning then the existing flow >> >> reservation >> >> > will be redirected along the new link, which cannot support >> >> it. Thus the >> >> > existing flow reservation is lost due a change in the >> >> network unrelated >> >> > to its current path. In fact thousands of reservations >> may have been >> >> > routed along the original path and would now be disrupted. >> >> Such protocol >> >> > behaviour is not acceptable. >> >> > >> >> > Best Regards, >> >> > Marco >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> >> >> >> -------------------------------------- >> >> Dr. Marcus Brunner >> >> Network Laboratories >> >> NEC Europe Ltd. >> >> >> >> E-Mail: brunner@ccrle.nec.de >> >> WWW: http://www.ccrle.nec.de/ >> >> personal home page: http://www.brubers.org/marcus >> >> >> >> >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 05:48:59 2002 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 FAA14390 for ; Thu, 11 Jul 2002 05:48:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26255 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 05:49:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25809; Thu, 11 Jul 2002 05:32:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25775 for ; Thu, 11 Jul 2002 05:32:50 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14162 for ; Thu, 11 Jul 2002 05:31:54 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6B9WIU36852; Thu, 11 Jul 2002 11:32:18 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA26099; Thu, 11 Jul 2002 11:32:17 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B0DCB280CE; Thu, 11 Jul 2002 11:32:16 +0200 (CEST) Date: Thu, 11 Jul 2002 11:32:17 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing Message-ID: <5732282.1026387137@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA25776 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit --On Donnerstag, 11. Juli 2002 09:58 +0200 "Geib, Ruediger" wrote: > Hello Marcus, > >> Hi Marcus, > ..... >> [New Marco] The requirement is that existing reservations >> should not be lost. > > That's valid for every provider. Yes, sure, but the question is whether we need to include that requirement into NSIS, which implies we need to cover that cases, or whther this is a problem of the operator's planing of the upgrade/add of link. Marcus > >> [Original Marco] 2) More specifically the operator should not >> have to be concerned with whether addition of links could >> affect existing connections. > ..... > > Absolutely true. The problem is, that a new link affects > routing. NSIS excluded routing protocol changes from the > charter (which I appreciate). All an NSIS solution could > do is then to track route changes. This behaviour may be > optimised to be fast and reliable. But I think what NSIS > could and should do stops there. Network planning, > provisioning and traffic engineering will add to that. > But that's not part of the NSIS business and I wouldn't > favour adding it to the charter. > Regards, Rüdiger (working for Deutsche Telekom, should that matter) > > Rüdiger Geib > Senior Expert > Systems Integration > T-Systems Nova GmbH > Technologiezentrum > Am Kavalleriesand 3, 64295 Darmstadt > Germany > Fon: +49 6151 832138 > Fax: +49 6151 838103 > mailto:Ruediger.Geib@t-systems.com > http://www.t-nova.de > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 06:00:02 2002 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 GAA14514 for ; Thu, 11 Jul 2002 06:00:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26765 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 06:00:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26029; Thu, 11 Jul 2002 05:44:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25998 for ; Thu, 11 Jul 2002 05:43:57 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14314 for ; Thu, 11 Jul 2002 05:43:03 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6B9htrU002908; Thu, 11 Jul 2002 11:43:55 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SKCBJKJ; Thu, 11 Jul 2002 11:43:54 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 11:43:53 +0200 Message-ID: X-Sybari-Trust: 8c862a3d 7216406a e4ad19be 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , brunner@ccrle.nec.de, "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Date: Thu, 11 Jul 2002 11:38:04 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert What I proposed is related to modularity and is similar to the concept described in draft-braden-2level-signal-arch-00.txt and in Section 5.5 in draft-hancock-nsis-fw-00, also draft-westberg-nsis-edge-edge-framework-00. The concept in all these drafts is the same, namely, separate the protocol functionality in more than one layers. In draft-braden-2level-signal-arch-00.txt this separation is done in two layers were the functionality is split between transport and application functionality. In Section 5.5 in draft-hancock-nsis-fw-00 and also draft-westberg-nsis-edge-edge-framework-00 the protocol functionality is split in three layers. Therefore, I think that the proposed bullet is relevant and its right place is the modularity section. Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Thursday, July 11, 2002 1:04 AM To: brunner@ccrle.nec.de; Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt hi, i'm slightly baffled by this. i was taking a wild guess that georgios was referring to nsis-triggering-nsis scenarios (e.g. 5.5 in draft-hancock-nsis-fw-00, also draft-westberg-nsis-edge-edge-framework-00). if that's the case, isn't it covered by 5.3.6? [actually, i'm not certain that this turns into a feature visible in the protocol, it could be just a way of using the protocol; but we'll discover that during the framework.] if georgios is referring to transport/application layering as in draft-braden-2level-signal-arch-00.txt then isn't this covered by 5.1.4 (although we should probably refer to something more general than QoS...). i certainly don't like the term 'hierarchical' for this. georgios, what is your concern? robert > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 10 July 2002 17:09 > To: Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; > nsis@ietf.org > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > John is right I aslo don't like multi-level XXX difficult to > understand. I > regard modularity as the right word in the title, but I will > go over the > text such that in really includes what Georgios means. > > Marcus > > --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios Karagiannis (ELN)" > wrote: > > > Hi John > > > > What about muliu level signaling? > > > > best regards, > > Georgios > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Wednesday, July 10, 2002 5:45 PM > > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; > > nsis@ietf.org > > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > > > > Hi Marcus, > > > >> Ok, I agree I will do some polishing of this for -04 > >> Marcus > >> > >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios > Karagiannis (ELN)" > >> wrote: > >> > >> > Hi Marcus > >> > > >> > The hierarchical levels are refering to protocol > >> functionality levels. > >> > A similar concept is presented in > >> draft-braden-2level-signal-arch-00.txt > >> > where two levels of protocol functionality are defined. > > > > I think this is OK, however I don't like the term 'hierarchical' > > in this case. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 06:13:20 2002 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 GAA14672 for ; Thu, 11 Jul 2002 06:13:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27280 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 06:14:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26804; Thu, 11 Jul 2002 06:00:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26775 for ; Thu, 11 Jul 2002 06:00:57 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14522 for ; Thu, 11 Jul 2002 06:00:02 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6BA0OU38898; Thu, 11 Jul 2002 12:00:24 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA26479; Thu, 11 Jul 2002 12:00:23 +0200 Received: from [192.168.102.207] (unknown [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 08FBE52DD4; Thu, 11 Jul 2002 12:00:23 +0200 (CEST) Date: Thu, 11 Jul 2002 12:00:23 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , "'Hancock, Robert'" , "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Message-ID: <7418487.1026388823@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Georgios, Do you think we need more than two layers. If you say hierarchical do you mean N layers? Marcus --On Donnerstag, 11. Juli 2002 11:38 +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Robert > > What I proposed is related to modularity and is similar to > the concept described in draft-braden-2level-signal-arch-00.txt > and in Section 5.5 in draft-hancock-nsis-fw-00, also > draft-westberg-nsis-edge-edge-framework-00. > > The concept in all these drafts is the same, namely, separate the > protocol functionality in more than one layers. > In draft-braden-2level-signal-arch-00.txt this separation is done in two > layers were the functionality is split between transport and application > functionality. In Section 5.5 in draft-hancock-nsis-fw-00 and also > draft-westberg-nsis-edge-edge-framework-00 the protocol functionality is > split in three layers. > > Therefore, I think that the proposed bullet is relevant and its right > place is the modularity section. > > Best Regards, > Georgios > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Thursday, July 11, 2002 1:04 AM > To: brunner@ccrle.nec.de; Georgios Karagiannis (ELN); > 'john.loughney@nokia.com'; nsis@ietf.org > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > hi, > > i'm slightly baffled by this. > > i was taking a wild guess that georgios was referring to > nsis-triggering-nsis scenarios (e.g. 5.5 in draft-hancock-nsis-fw-00, > also draft-westberg-nsis-edge-edge-framework-00). if that's the case, > isn't it covered by 5.3.6? [actually, i'm not certain that this turns > into a feature visible in the protocol, it could be just a way of using > the protocol; but we'll discover that during the framework.] > > if georgios is referring to transport/application layering as in > draft-braden-2level-signal-arch-00.txt then isn't this covered by 5.1.4 > (although we should probably refer to something more general than > QoS...). i certainly don't like the term 'hierarchical' for this. > > georgios, what is your concern? > > robert > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 10 July 2002 17:09 >> To: Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; >> nsis@ietf.org >> Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt >> >> >> John is right I aslo don't like multi-level XXX difficult to >> understand. I >> regard modularity as the right word in the title, but I will >> go over the >> text such that in really includes what Georgios means. >> >> Marcus >> >> --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios Karagiannis (ELN)" >> wrote: >> >> > Hi John >> > >> > What about muliu level signaling? >> > >> > best regards, >> > Georgios >> > >> > -----Original Message----- >> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> > Sent: Wednesday, July 10, 2002 5:45 PM >> > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; >> > nsis@ietf.org >> > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt >> > >> > >> > Hi Marcus, >> > >> >> Ok, I agree I will do some polishing of this for -04 >> >> Marcus >> >> >> >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios >> Karagiannis (ELN)" >> >> wrote: >> >> >> >> > Hi Marcus >> >> > >> >> > The hierarchical levels are refering to protocol >> >> functionality levels. >> >> > A similar concept is presented in >> >> draft-braden-2level-signal-arch-00.txt >> >> > where two levels of protocol functionality are defined. >> > >> > I think this is OK, however I don't like the term 'hierarchical' >> > in this case. >> > >> > John >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus > ========================================================================= > =============== Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 06:29:20 2002 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 GAA14853 for ; Thu, 11 Jul 2002 06:29:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27780 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 06:30:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27258; Thu, 11 Jul 2002 06:13:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27227 for ; Thu, 11 Jul 2002 06:13:28 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14664 for ; Thu, 11 Jul 2002 06:12:33 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BADvi27379 for ; Thu, 11 Jul 2002 13:13:57 +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, 11 Jul 2002 13:13:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 13:13:26 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 11 Jul 2002 13:13:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65705@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Thread-Index: AcIowd6lywqfqf5vR8y12IPAuEWS4wAAVj6Q To: , , , X-OriginalArrivalTime: 11 Jul 2002 10:13:26.0027 (UTC) FILETIME=[9864C5B0:01C228C3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA27228 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi All, The current text states: 5.1.3 Modularity 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 / broadband, error-prone / reliable...) - This implies low bandwidth signaling and redundant information must be supported if necessary. - Uni- and bi-directional reservations are possible - Extensible in the future with different add-ons for certain environments or scenarios If I understand Georgios' request, he would like an addtional bullet, which I would phrase: - Protocol layering, where appropriate. Is that OK? John > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 July, 2002 13:00 > To: Georgios Karagiannis (ELN); 'Hancock, Robert'; Loughney John > (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > Georgios, > > Do you think we need more than two layers. If you say > hierarchical do you > mean N layers? > > Marcus > > --On Donnerstag, 11. Juli 2002 11:38 +0200 "Georgios > Karagiannis (ELN)" > wrote: > > > Hi Robert > > > > What I proposed is related to modularity and is similar to > > the concept described in draft-braden-2level-signal-arch-00.txt > > and in Section 5.5 in draft-hancock-nsis-fw-00, also > > draft-westberg-nsis-edge-edge-framework-00. > > > > The concept in all these drafts is the same, namely, separate the > > protocol functionality in more than one layers. > > In draft-braden-2level-signal-arch-00.txt this separation > is done in two > > layers were the functionality is split between transport > and application > > functionality. In Section 5.5 in draft-hancock-nsis-fw-00 and also > > draft-westberg-nsis-edge-edge-framework-00 the protocol > functionality is > > split in three layers. > > > > Therefore, I think that the proposed bullet is relevant and > its right > > place is the modularity section. > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, July 11, 2002 1:04 AM > > To: brunner@ccrle.nec.de; Georgios Karagiannis (ELN); > > 'john.loughney@nokia.com'; nsis@ietf.org > > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > > > > hi, > > > > i'm slightly baffled by this. > > > > i was taking a wild guess that georgios was referring to > > nsis-triggering-nsis scenarios (e.g. 5.5 in > draft-hancock-nsis-fw-00, > > also draft-westberg-nsis-edge-edge-framework-00). if that's > the case, > > isn't it covered by 5.3.6? [actually, i'm not certain that > this turns > > into a feature visible in the protocol, it could be just a > way of using > > the protocol; but we'll discover that during the framework.] > > > > if georgios is referring to transport/application layering as in > > draft-braden-2level-signal-arch-00.txt then isn't this > covered by 5.1.4 > > (although we should probably refer to something more general than > > QoS...). i certainly don't like the term 'hierarchical' for this. > > > > georgios, what is your concern? > > > > robert > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: 10 July 2002 17:09 > >> To: Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; > >> nsis@ietf.org > >> Subject: RE: [NSIS] additional comment on > draft-ietf-nsis-req-03.txt > >> > >> > >> John is right I aslo don't like multi-level XXX difficult to > >> understand. I > >> regard modularity as the right word in the title, but I will > >> go over the > >> text such that in really includes what Georgios means. > >> > >> Marcus > >> > >> --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios > Karagiannis (ELN)" > >> wrote: > >> > >> > Hi John > >> > > >> > What about muliu level signaling? > >> > > >> > best regards, > >> > Georgios > >> > > >> > -----Original Message----- > >> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> > Sent: Wednesday, July 10, 2002 5:45 PM > >> > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; > >> > nsis@ietf.org > >> > Subject: RE: [NSIS] additional comment on > draft-ietf-nsis-req-03.txt > >> > > >> > > >> > Hi Marcus, > >> > > >> >> Ok, I agree I will do some polishing of this for -04 > >> >> Marcus > >> >> > >> >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios > >> Karagiannis (ELN)" > >> >> wrote: > >> >> > >> >> > Hi Marcus > >> >> > > >> >> > The hierarchical levels are refering to protocol > >> >> functionality levels. > >> >> > A similar concept is presented in > >> >> draft-braden-2level-signal-arch-00.txt > >> >> > where two levels of protocol functionality are defined. > >> > > >> > I think this is OK, however I don't like the term 'hierarchical' > >> > in this case. > >> > > >> > John > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> personal home page: http://www.brubers.org/marcus > > > ============================================================== > =========== > > =============== Permission is hereby granted to pass the > contents of this > > communication to third parties and any restrictions regarding > > confidentiality do not apply. > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 06:36:43 2002 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 GAA15095 for ; Thu, 11 Jul 2002 06:36:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28666 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 06:37:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27407; Thu, 11 Jul 2002 06:21:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27376 for ; Thu, 11 Jul 2002 06:21:09 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14783 for ; Thu, 11 Jul 2002 06:20:14 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6BAL7rU012676; Thu, 11 Jul 2002 12:21:07 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SK1DTL9; Thu, 11 Jul 2002 12:21:07 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 12:21:06 +0200 Message-ID: X-Sybari-Trust: 0b6ca3f7 7216406a 2358112d 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , "'brunner@ccrle.nec.de'" , "Georgios Karagiannis (ELN)" , "'robert.hancock@roke.co.uk'" , "'nsis@ietf.org'" Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Date: Thu, 11 Jul 2002 12:15:17 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John That is great! Yes I agree! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, July 11, 2002 12:13 PM To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Hi All, The current text states: 5.1.3 Modularity 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 / broadband, error-prone / reliable...) - This implies low bandwidth signaling and redundant information must be supported if necessary. - Uni- and bi-directional reservations are possible - Extensible in the future with different add-ons for certain environments or scenarios If I understand Georgios' request, he would like an addtional bullet, which I would phrase: - Protocol layering, where appropriate. Is that OK? John > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 July, 2002 13:00 > To: Georgios Karagiannis (ELN); 'Hancock, Robert'; Loughney John > (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > Georgios, > > Do you think we need more than two layers. If you say > hierarchical do you > mean N layers? > > Marcus > > --On Donnerstag, 11. Juli 2002 11:38 +0200 "Georgios > Karagiannis (ELN)" > wrote: > > > Hi Robert > > > > What I proposed is related to modularity and is similar to > > the concept described in draft-braden-2level-signal-arch-00.txt > > and in Section 5.5 in draft-hancock-nsis-fw-00, also > > draft-westberg-nsis-edge-edge-framework-00. > > > > The concept in all these drafts is the same, namely, separate the > > protocol functionality in more than one layers. > > In draft-braden-2level-signal-arch-00.txt this separation > is done in two > > layers were the functionality is split between transport > and application > > functionality. In Section 5.5 in draft-hancock-nsis-fw-00 and also > > draft-westberg-nsis-edge-edge-framework-00 the protocol > functionality is > > split in three layers. > > > > Therefore, I think that the proposed bullet is relevant and > its right > > place is the modularity section. > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Thursday, July 11, 2002 1:04 AM > > To: brunner@ccrle.nec.de; Georgios Karagiannis (ELN); > > 'john.loughney@nokia.com'; nsis@ietf.org > > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt > > > > > > hi, > > > > i'm slightly baffled by this. > > > > i was taking a wild guess that georgios was referring to > > nsis-triggering-nsis scenarios (e.g. 5.5 in > draft-hancock-nsis-fw-00, > > also draft-westberg-nsis-edge-edge-framework-00). if that's > the case, > > isn't it covered by 5.3.6? [actually, i'm not certain that > this turns > > into a feature visible in the protocol, it could be just a > way of using > > the protocol; but we'll discover that during the framework.] > > > > if georgios is referring to transport/application layering as in > > draft-braden-2level-signal-arch-00.txt then isn't this > covered by 5.1.4 > > (although we should probably refer to something more general than > > QoS...). i certainly don't like the term 'hierarchical' for this. > > > > georgios, what is your concern? > > > > robert > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: 10 July 2002 17:09 > >> To: Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; > >> nsis@ietf.org > >> Subject: RE: [NSIS] additional comment on > draft-ietf-nsis-req-03.txt > >> > >> > >> John is right I aslo don't like multi-level XXX difficult to > >> understand. I > >> regard modularity as the right word in the title, but I will > >> go over the > >> text such that in really includes what Georgios means. > >> > >> Marcus > >> > >> --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios > Karagiannis (ELN)" > >> wrote: > >> > >> > Hi John > >> > > >> > What about muliu level signaling? > >> > > >> > best regards, > >> > Georgios > >> > > >> > -----Original Message----- > >> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> > Sent: Wednesday, July 10, 2002 5:45 PM > >> > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; > >> > nsis@ietf.org > >> > Subject: RE: [NSIS] additional comment on > draft-ietf-nsis-req-03.txt > >> > > >> > > >> > Hi Marcus, > >> > > >> >> Ok, I agree I will do some polishing of this for -04 > >> >> Marcus > >> >> > >> >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios > >> Karagiannis (ELN)" > >> >> wrote: > >> >> > >> >> > Hi Marcus > >> >> > > >> >> > The hierarchical levels are refering to protocol > >> >> functionality levels. > >> >> > A similar concept is presented in > >> >> draft-braden-2level-signal-arch-00.txt > >> >> > where two levels of protocol functionality are defined. > >> > > >> > I think this is OK, however I don't like the term 'hierarchical' > >> > in this case. > >> > > >> > John > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> personal home page: http://www.brubers.org/marcus > > > ============================================================== > =========== > > =============== Permission is hereby granted to pass the > contents of this > > communication to third parties and any restrictions regarding > > confidentiality do not apply. > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 06:40:44 2002 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 GAA15145 for ; Thu, 11 Jul 2002 06:40:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28726 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 06:41:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27571; Thu, 11 Jul 2002 06:23:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27469 for ; Thu, 11 Jul 2002 06:23:53 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14802 for ; Thu, 11 Jul 2002 06:22:58 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6BANpRb015800 for ; Thu, 11 Jul 2002 12:23:51 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SK1D4GH; Thu, 11 Jul 2002 12:23:51 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 12:23:50 +0200 Message-ID: X-Sybari-Trust: 8eda0814 7216406a 2358112d 00000138 From: "Georgios Karagiannis (ELN)" To: "'nsis@ietf.org'" Date: Thu, 11 Jul 2002 12:18:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] FW: list with all comments sent by me on list regarding requireme nts draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Please receive the following e-mail, that includes some discussions that I have had together with Marcus on the requirements draft! Best Regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Thursday, July 11, 2002 11:57 AM To: Georgios Karagiannis (ELN) Subject: Re: list with all comments sent by me on list regarding requirements draft Georgios, I think the problem I still have is the definition of the data path/on-path etc. As Robert said I also see quite a number of different definitions. If data path is loosly defined I am able agree, if it defined very strict I am not. See also some inline comments. BTW, can you post this E-Mail? And thanks for the careful reading. Marcus --On Mittwoch, 10. Juli 2002 19:14 +0200 "Georgios Karagiannis (ELN)" wrote: > Hi Marcus > > Here is a lsit of all comments that I provided until now regarding the > requirements draft. I hope that you now agree with all of them! > > > Best Regards, > Georgios > ------------------------------------------------------------------------- > ----------------------------------- > > Comment_1: general: > There are many requirements that are affected by the fact that NSIS will > have to concentrate mainly on the in-band (in-path case). > What should we do with them? maybe list them as optional and to be done > in the future? The list is as follows: > > Change required in Requirement 5.2.2: > "No constraint of the QoS signaling Controllers to be in the data path" > Please chnage into: > "The NSIS Forwarders and NSIS Initiators should be located in the data > path. However, there might be optional situations where this is not > required." > > Change required in Requirement 5.7.2: > "Flexibility in the placement of the QoS initiator" > Change the text from: > "But also network-initiated reservations are required in various > scenarios such as PSTN gateways, some VPNs, mobility." > > Into: > "But also network-initiated reservations are required in various > scenarios such as PSTN gateways, some VPNs, mobility. Note however, that > the NSIS Initiator should be located in the data path (see Requirement > 5.2.2)." > > Change required in requirement 5.7.3: > "Flexibility in the initiation of re-negotiation (QoS change requests)" > Please change the text from: > "But also network-initiated re-negotiations is required in cases, where > the network is not able to further guarantee resources etc." > Into: > "But also network-initiated re-negotiations is required in cases, where > the network is not able to further guarantee resources etc. Note > however, that the NSIS Initiator should be located in the data path (see > Requirement 5.2.2)." > > Marcus do you agree? > ------------------------------------------------------------------------- > ----------------------- > > > > > Comment_2: Section 2: Terminology: (page 6): > > I propose to use the terms given in draft-hancock-nsis-fw-00.txt regarding > NSIS Initiator (instead of QoS Initiator), NSIS Forwarder (instead of QoS > Controller) and NSIS Responder. This applies also for other additional > terms that are included into draft-hancock-nsis-fw-00.txt and are not > included into the requirements draft. > > NO discussion in the mailing list took place up to now! I put it as a point for the IETF meeting. > ------------------------------------------------------------------------- > --------------- > > Comment_3: Section 3: Problem statement and scope (Page 9): > > Please remove or signifficantly modify bullet 2: > "We see the network at the level of domains/subdomains rather > than individual routers ...... Aggregation can also take place at > subdomain boundaries." > > The reasonsof asking this are: > * not each domain but any router that implements a QoS controller or > QoS initiator can use NSIS signaling; > * It is contradictory with bullet 4 (of the same section) that > mentions: " Each router on the data path implements a QoS > controller and QoS initiator." > > > > New proposal for modification: > > "2. We 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. Subdomains are introduced to allow the fact a given QoS > provisioning mechanism may only be used within a part of a domain, > typically for a particular subnetwork technology boundary. > Aggregation can also take place at subdomain boundaries. > However, each router on the data path may implement a QoS > controller and/or QoS initiator and therefore, any router > on the data path may use the NSIS signalling." > > Marcus do you agree? I think I can agree on that. > ------------------------------------------------------------------------- > --------------- > > Comment_4: Section 4.1: Assumptions and exclusions (Page 11): > > Bullet 6: > Please change the text: > "NSIS assumes to operate with networks using standard ("normal") L3 > routing" > > INTO > > "NSIS assumes to operate with networks using standard ("normal") L3 > routing as described in RFC 2992." > > Marcus do you agree? No, actually, I would regard RFC 2992 not "normal". But we can think about whether NSIS need to be able to work with RFC 2992 type of routing. > > ------------------------------------------------------------------------- > --------------- > > Comment_5: Section 4.2: Assumptions and exclusions (Page 11): > Issue 3: Please add a sentance after: > "Specific mechanisms for QoS provisioning withis a domain/subdomain are > not considered." > > As follows: > "Specific mechanisms for QoS provisioning withis a domain/subdomain are > not considered. However, NSIS can be used for signaling within a > domain/subdomain." > > Marcus do you agree? What do you understand with "be used for signaling within a domain"? I think we even have a requirement saying that. > ------------------------------------------------------------------------- > --------------- Comment_6: Section 5.8 General (Page 20): > > Many of the security requirements mention that the signaling protocol > must provide means to provide security. I would prefer to mention > somewhere, maybe in the introduction of section 5.8 that: > "The NSIS protcol must provide means to provide security, but it is not > mandatory that all nodes that use NSIS signalling will have to apply > these means for security." Marcus do you agree? Yes, I agree with that. Would you even regard security service-specific? > ------------------------------------------------------------------------- > --------------- > > Comment_7: Section 5.10.5: Interworking with seamless handoff protocols: > > Mention that this interworking should not duplicate functionality. > > Marcus do you agree? Wasn't it you that dropped that particulr requirement? But I can definitly mention that I can agree on that. > ------------------------------------------------------------------------- > --------------- > > Comment_8: Open Issue 2: page 44: > I prefer: > "should be optimized for sender initiated" > Marcus do you agree? I put this again on the slide for Japan. But I tend to agree. > --------------------------------------------------------------------- > > Comment_9: Regarding open Issues 53, 59, 65 and 72 I propose that Sven > and myself try to propose some text that solves all these issues: > Sven do you agree? > > Marcus do you agree? Yes, I put this onto slides for Japan. > ------------------------------------------------------------------------- > ---- > > > Comment_10: > Due to the fact that the Multi-level signaling has become > a very important issue in NSIS, I would very much appreciate if we could > add the following bullet into Section 5.1.3 "Modularity": > > "- multi-level NSIS signaling: the NSIS protocol should be able to > be separated into more than one hierarchical levels. The hierarchical > levels are refering to protocol functionality levels." > > Marcus I think you mentioned that you agree! I agree with what you try to say, but myself and also John disagreed with the wording multi-level signaling. But give me a try to change the text toward your thinking, then complain again if I have not met your expectations. > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 06:52:35 2002 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 GAA15305 for ; Thu, 11 Jul 2002 06:52:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29007 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 06:53:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28647; Thu, 11 Jul 2002 06:36:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28616 for ; Thu, 11 Jul 2002 06:36:54 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15081 for ; Thu, 11 Jul 2002 06:35:59 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6BAaJU41200; Thu, 11 Jul 2002 12:36:19 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA26891; Thu, 11 Jul 2002 12:36:18 +0200 Received: from [192.168.102.207] (unknown [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D604A10C15; Thu, 11 Jul 2002 12:36:17 +0200 (CEST) Date: Thu, 11 Jul 2002 12:36:18 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt Message-ID: <9574196.1026390978@[192.168.102.207]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65705@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65705@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Is fine with me. Marcus --On Donnerstag, 11. Juli 2002 13:13 +0300 john.loughney@nokia.com wrote: > Hi All, > > The current text states: > > 5.1.3 Modularity > > 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 / broadband, error-prone > / reliable...) - This implies low bandwidth signaling and redundant > information must be supported if necessary. > > - Uni- and bi-directional reservations are possible > > - Extensible in the future with different add-ons for certain > environments or scenarios > > If I understand Georgios' request, he would like an addtional bullet, > which I would phrase: > > - Protocol layering, where appropriate. > > Is that OK? > > John > > > >> -----Original Message----- >> From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 11 July, 2002 13:00 >> To: Georgios Karagiannis (ELN); 'Hancock, Robert'; Loughney John >> (NRC/Helsinki); nsis@ietf.org >> Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt >> >> >> Georgios, >> >> Do you think we need more than two layers. If you say >> hierarchical do you >> mean N layers? >> >> Marcus >> >> --On Donnerstag, 11. Juli 2002 11:38 +0200 "Georgios >> Karagiannis (ELN)" >> wrote: >> >> > Hi Robert >> > >> > What I proposed is related to modularity and is similar to >> > the concept described in draft-braden-2level-signal-arch-00.txt >> > and in Section 5.5 in draft-hancock-nsis-fw-00, also >> > draft-westberg-nsis-edge-edge-framework-00. >> > >> > The concept in all these drafts is the same, namely, separate the >> > protocol functionality in more than one layers. >> > In draft-braden-2level-signal-arch-00.txt this separation >> is done in two >> > layers were the functionality is split between transport >> and application >> > functionality. In Section 5.5 in draft-hancock-nsis-fw-00 and also >> > draft-westberg-nsis-edge-edge-framework-00 the protocol >> functionality is >> > split in three layers. >> > >> > Therefore, I think that the proposed bullet is relevant and >> its right >> > place is the modularity section. >> > >> > Best Regards, >> > Georgios >> > >> > >> > -----Original Message----- >> > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >> > Sent: Thursday, July 11, 2002 1:04 AM >> > To: brunner@ccrle.nec.de; Georgios Karagiannis (ELN); >> > 'john.loughney@nokia.com'; nsis@ietf.org >> > Subject: RE: [NSIS] additional comment on draft-ietf-nsis-req-03.txt >> > >> > >> > hi, >> > >> > i'm slightly baffled by this. >> > >> > i was taking a wild guess that georgios was referring to >> > nsis-triggering-nsis scenarios (e.g. 5.5 in >> draft-hancock-nsis-fw-00, >> > also draft-westberg-nsis-edge-edge-framework-00). if that's >> the case, >> > isn't it covered by 5.3.6? [actually, i'm not certain that >> this turns >> > into a feature visible in the protocol, it could be just a >> way of using >> > the protocol; but we'll discover that during the framework.] >> > >> > if georgios is referring to transport/application layering as in >> > draft-braden-2level-signal-arch-00.txt then isn't this >> covered by 5.1.4 >> > (although we should probably refer to something more general than >> > QoS...). i certainly don't like the term 'hierarchical' for this. >> > >> > georgios, what is your concern? >> > >> > robert >> > >> >> -----Original Message----- >> >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> >> Sent: 10 July 2002 17:09 >> >> To: Georgios Karagiannis (ELN); 'john.loughney@nokia.com'; >> >> nsis@ietf.org >> >> Subject: RE: [NSIS] additional comment on >> draft-ietf-nsis-req-03.txt >> >> >> >> >> >> John is right I aslo don't like multi-level XXX difficult to >> >> understand. I >> >> regard modularity as the right word in the title, but I will >> >> go over the >> >> text such that in really includes what Georgios means. >> >> >> >> Marcus >> >> >> >> --On Mittwoch, 10. Juli 2002 17:46 +0200 "Georgios >> Karagiannis (ELN)" >> >> wrote: >> >> >> >> > Hi John >> >> > >> >> > What about muliu level signaling? >> >> > >> >> > best regards, >> >> > Georgios >> >> > >> >> > -----Original Message----- >> >> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> >> > Sent: Wednesday, July 10, 2002 5:45 PM >> >> > To: brunner@ccrle.nec.de; Georgios.Karagiannis@eln.ericsson.se; >> >> > nsis@ietf.org >> >> > Subject: RE: [NSIS] additional comment on >> draft-ietf-nsis-req-03.txt >> >> > >> >> > >> >> > Hi Marcus, >> >> > >> >> >> Ok, I agree I will do some polishing of this for -04 >> >> >> Marcus >> >> >> >> >> >> --On Mittwoch, 10. Juli 2002 15:58 +0200 "Georgios >> >> Karagiannis (ELN)" >> >> >> wrote: >> >> >> >> >> >> > Hi Marcus >> >> >> > >> >> >> > The hierarchical levels are refering to protocol >> >> >> functionality levels. >> >> >> > A similar concept is presented in >> >> >> draft-braden-2level-signal-arch-00.txt >> >> >> > where two levels of protocol functionality are defined. >> >> > >> >> > I think this is OK, however I don't like the term 'hierarchical' >> >> > in this case. >> >> > >> >> > John >> >> > >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> >> >> >> -------------------------------------- >> >> Dr. Marcus Brunner >> >> Network Laboratories >> >> NEC Europe Ltd. >> >> >> >> E-Mail: brunner@ccrle.nec.de >> >> WWW: http://www.ccrle.nec.de/ >> >> personal home page: http://www.brubers.org/marcus >> > >> ============================================================== >> =========== >> > =============== Permission is hereby granted to pass the >> contents of this >> > communication to third parties and any restrictions regarding >> > confidentiality do not apply. >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 07:35:54 2002 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 HAA15899 for ; Thu, 11 Jul 2002 07:35:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01311 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 07:36:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00239; Thu, 11 Jul 2002 07:14:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00213 for ; Thu, 11 Jul 2002 07:14:38 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15636 for ; Thu, 11 Jul 2002 07:13:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6BBE3U43940; Thu, 11 Jul 2002 13:14:03 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA27234; Thu, 11 Jul 2002 13:14:03 +0200 Received: from [192.168.102.207] (unknown [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 680B32F8DB; Thu, 11 Jul 2002 13:14:02 +0200 (CEST) Date: Thu, 11 Jul 2002 13:14:03 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Message-ID: <11838592.1026393243@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED41805203D37@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41805203D37@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Donnerstag, 11. Juli 2002 00:04 +0100 "Hancock, Robert" wrote: > John, > > Interesting draft. I have tried to think it through from a purely NSIS > perspective. > > 1) Nowhere does it say if routers (or even sources) should send packets > from the same flow along the same path. Is that because it's (a) the > wrong place to say so or (b) obvious or (c) impossible to mandate? In > particular, it does say that a node not carrying out flow specific > treatment MUST ignore the field on forwarding - maybe 'keeping packets > together' could be regarded as flow specific treatment (and made > mandatory). (If we could rely on this it would be a powerful weapon in > the signalling/data path divergence issue, but see next point.) > I would assume it on purpose, because it does not make sense to include a second dimension into the forwarding decision. The primary adress is still the destination address. > 2) The draft seems to encourage (SHOULD) a highly granular assignment of > flow labels (e.g. section 4 rules 3 & 4). On the other hand, there may be > good reasons to use the same label for a sequence of 'microflows' (e.g. > successive files in a bulk ftp transfer; the same point has been made on > the v6 list). Encouraging this granularity directly increases the > signalling burden. How strong is SHOULD? > I think this is heavily application dependent. And I would not give too much weight on the SHOULD. > 3) Fortunately, I think most of the agonies about flow label re-use don't > have to worry us, they're end-system internal. However, there are two > points: a) Do we need to strengthen our requirement for a TEAR message to > flush flow label state? b) If a TEAR isn't possible (e.g. a route flap > means some routers wouldn't see it), do we need to allow the end system > to control the soft state timeout so they can be assured of when flow > label state has been purged? I don't think our current requirements give > this level of control to end hosts, and I'm not sure they should. What do you mean by flow label state. The spec says that flow state adressing must be via flow label AND source and dest address. I think a tear message must include flow labels into account. > 4) I don't see why the flow state establishment method (i.e. NSIS for > example) needs to be able to manage flow label agreement between end > systems (end of section 4). After all, it doesn't handle port number > agreement. Such information would need to be end-to-end secured, which > (IMHO) is a poor match to the security capabilities we are currently > assuming for NSIS. I don't think we need to care about this. It says "Therefore the source SHOULD honor the destination's request to mark the packets with the Flow Label value specified." So the source should honor this, not the signaling. > 5) I'm seriously concerned about rule (6) of section 5. I don't see it > has anything to do with a standard on flow label definition. If it does, > then the rest of the draft has to be clarified so whenever it refers to > address it is clear if it means home or care of address (e.g. on > reception at the end system, does a node check the combination of flow > label with HA or CoA to work out which flow something belongs to), and > the security considerations section might need something on validating > ownership of the home address as well. Better I think would be to point > out that something like the second sentence of rule (6) applies in mobile > environments, and that flow state establishment methods should handle > this how best they can. (We have this requirement in NSIS anyway.) Yes, this one puzzled me as well. Marcus > > So, there might be some options for making the draft leaner and meaner. > > Cheers, > > Robert > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: 10 July 2002 13:43 >> To: nsis@ietf.org >> Subject: [NSIS] IPv6 Flow Label >> >> >> Hi all, >> >> One tool we may want to use is the IPv6 flow label. There is some >> standardization of this on-going in the IPv6 WG. I wonder if folks >> could comment on the spec, with regards to how NSIS could use it. >> >> It can be found from: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt >> >> John >> > ========================================================================= > =============== Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 08:36:26 2002 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 IAA17086 for ; Thu, 11 Jul 2002 08:36:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05090 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 08:37:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04000; Thu, 11 Jul 2002 08:21:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03971 for ; Thu, 11 Jul 2002 08:21:21 -0400 (EDT) Received: from zeus.di.uoa.gr (zeus.di.uoa.gr [195.134.65.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16783 for ; Thu, 11 Jul 2002 08:20:26 -0400 (EDT) Received: from gallagher.di.uoa.gr (gallagher.di.uoa.gr [195.134.67.52]) by zeus.di.uoa.gr (8.12.3/8.12.3) with ESMTP id g6BBw012010691; Thu, 11 Jul 2002 14:58:00 +0300 (EEST) Received: from gallagher.di.uoa.gr (localhost [127.0.0.1]) by gallagher.di.uoa.gr (8.12.2/8.12.2) with ESMTP id g6BBwk5n028522; Thu, 11 Jul 2002 14:58:46 +0300 Received: (from sarantis@localhost) by gallagher.di.uoa.gr (8.12.2/8.12.2/Submit) id g6BBwjTG028520; Thu, 11 Jul 2002 14:58:45 +0300 Date: Thu, 11 Jul 2002 14:58:44 +0300 From: Sarantis Paskalis To: "Hancock, Robert" Cc: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] IPv6 Flow Label Message-ID: <20020711115844.GA28297@gallagher.di.uoa.gr> References: <76C92FBBFB58D411AE760090271ED41805203D37@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76C92FBBFB58D411AE760090271ED41805203D37@rsys002a.roke.co.uk> User-Agent: Mutt/1.4i X-MailScanner: Found to be clean Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, On Thu, Jul 11, 2002 at 12:04:21AM +0100, Hancock, Robert wrote: > John, > > Interesting draft. I have tried to think it through from a purely NSIS perspective. > > 1) Nowhere does it say if routers (or even sources) should send packets from the same flow along the same path. Is that because it's (a) the wrong place to say so or (b) obvious or (c) impossible to mandate? In particular, it does say that a node not carrying out flow specific treatment MUST ignore the field on forwarding - maybe 'keeping packets together' could be regarded as flow specific treatment (and made mandatory). (If we could rely on this it would be a powerful weapon in the signalling/data path divergence issue, but see next point.) The only thing relevant mentioned in the draft is a sentence in Section 2 The flow state defines what kind of treatment should be provided, and how to classify the packets to the flow. According to that definition, NSIS could define the state of the flows to always follow the same path. The second part of the sentence also applies to point 2. > 2) The draft seems to encourage (SHOULD) a highly granular assignment of flow labels (e.g. section 4 rules 3 & 4). On the other hand, there may be good reasons to use the same label for a sequence of 'microflows' (e.g. successive files in a bulk ftp transfer; the same point has been made on the v6 list). Encouraging this granularity directly increases the signalling burden. How strong is SHOULD? I think, this is partially covered in Section 5, rule 1. Depending on the method semantics, multiple such triplets MAY identify the same flow state (e.g. SCTP flows with multiple addresses at either end-points, or a diffserv classifier with an address range. This can be extended to cover the case for a "flowmask" in which the first say 15 bits identify the flow state, while the last 5 identify the "microflow". In that case the draft states that: The flow state establishment method MUST convey this classifying information to the IPv6 nodes that need to perform the classification. i.e. this should be a NSIS requirement. Cheers, Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 10:22:23 2002 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 KAA18942 for ; Thu, 11 Jul 2002 10:22:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10417 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 10:23:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09810; Thu, 11 Jul 2002 10:02:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09778 for ; Thu, 11 Jul 2002 10:02:37 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18623 for ; Thu, 11 Jul 2002 10:01:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6BE22U53884; Thu, 11 Jul 2002 16:02:02 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA28959; Thu, 11 Jul 2002 16:02:01 +0200 Received: from [192.168.102.207] (unknown [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 008B71467A; Thu, 11 Jul 2002 16:02:01 +0200 (CEST) Date: Thu, 11 Jul 2002 16:02:01 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, robert.hancock@roke.co.uk, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Message-ID: <21917455.1026403321@[192.168.102.207]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB9@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB9@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit >> [Note: such a section could also define just what the on-path >> restriction actually was. I've seen at least 4 different >> incompatible views on that.] > > Want to provide a summary of the 4 views? Ok, I give it a try 1) exclusive on path The NSIS initiator and NSIS receiver are the data receiver and sender 2) proxy on path The NSIS initiator is some where on the data path but not at the sending nor receiving side (only part of the data path is covered by signaling) 3) IP-hop-by-IP-hop The signaling message travels IP-hop-by-IP-hop. Where the hops are chosen by the destination addr 4) NSIS-hop-by-NSIS-hop The signaling message follows NSIS hops, where intermediate IP hops are not visited. The NSIS hop has to choose the next hop, here the data path migh follow a different path for a shsort segment. 5) in advance reservation in hand-over cases If a new access router has been chosen, where a mobile will newly connect to and a reservation should be done in advance, the data flows still on the old path. At the point in time data is flowing along the new path (after handoff) the reservation has already been setup. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 10:44:37 2002 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 KAA19545 for ; Thu, 11 Jul 2002 10:44:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12410 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 10:45:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11309; Thu, 11 Jul 2002 10:31:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11279 for ; Thu, 11 Jul 2002 10:31:18 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19125 for ; Thu, 11 Jul 2002 10:30:19 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDG5H>; Thu, 11 Jul 2002 15:30:51 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA465@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Thu, 11 Jul 2002 15:30:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi marcus, see inline: > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 July 2002 12:14 > To: Hancock, Robert; john.loughney@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] IPv6 Flow Label > > > > > --On Donnerstag, 11. Juli 2002 00:04 +0100 "Hancock, Robert" > wrote: > > > John, > > > > Interesting draft. I have tried to think it through from a > purely NSIS > > perspective. > > > > 1) Nowhere does it say if routers (or even sources) should > send packets > > from the same flow along the same path. Is that because it's (a) the > > wrong place to say so or (b) obvious or (c) impossible to > mandate? In > > particular, it does say that a node not carrying out flow specific > > treatment MUST ignore the field on forwarding - maybe > 'keeping packets > > together' could be regarded as flow specific treatment (and made > > mandatory). (If we could rely on this it would be a > powerful weapon in > > the signalling/data path divergence issue, but see next point.) > > > > I would assume it on purpose, because it does not make sense > to include a > second dimension into the forwarding decision. The primary > adress is still > the destination address. [reh] so are you saying that it _is_ reasonable for a router to load share packets from the same flow (i.e. same DA and flowlabel) on two links? > > > 2) The draft seems to encourage (SHOULD) a highly granular > assignment of > > flow labels (e.g. section 4 rules 3 & 4). On the other > hand, there may be > > good reasons to use the same label for a sequence of > 'microflows' (e.g. > > successive files in a bulk ftp transfer; the same point has > been made on > > the v6 list). Encouraging this granularity directly increases the > > signalling burden. How strong is SHOULD? > > > > I think this is heavily application dependent. And I would > not give too > much weight on the SHOULD. [reh] maybe it should be MAY then. > > > 3) Fortunately, I think most of the agonies about flow > label re-use don't > > have to worry us, they're end-system internal. However, > there are two > > points: a) Do we need to strengthen our requirement for a > TEAR message to > > flush flow label state? b) If a TEAR isn't possible (e.g. a > route flap > > means some routers wouldn't see it), do we need to allow > the end system > > to control the soft state timeout so they can be assured of > when flow > > label state has been purged? I don't think our current > requirements give > > this level of control to end hosts, and I'm not sure they should. > > What do you mean by flow label state. The spec says that flow state > adressing must be via flow label AND source and dest address. > I think a > tear message must include flow labels into account. [reh] ok, for the tear message i think it is clear. the problem comes when the tear won't work. example: 1. i set up a pinhole in a firewall associated with a flowlabel 2. rerouting changes which firewall is used, pinhole is set up in new firewall 3. i remove the new pinhole with a tear message 4. the old firewall still has a pinhole in it. when do i know it is safe to reuse that flowlabel? > > > > 4) I don't see why the flow state establishment method > (i.e. NSIS for > > example) needs to be able to manage flow label agreement between end > > systems (end of section 4). After all, it doesn't handle port number > > agreement. Such information would need to be end-to-end > secured, which > > (IMHO) is a poor match to the security capabilities we are currently > > assuming for NSIS. > > I don't think we need to care about this. It says > "Therefore the source SHOULD honor the destination's request to > mark the packets with the Flow Label value specified." > So the source should honor this, not the signaling. [reh] my concern is not with that statement, but with the paragraph at the end of section 4, which places a requirement on signalling (e.g. NSIS) to carry the flow label to the peer. if this is just a notification it's probably not a problem, but if it's a request that sounds like flow label negotiation which I think is not an NSIS problem. (Or, it may be that I have over-interpreted this section.) [snip] > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 10:58:15 2002 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 KAA19998 for ; Thu, 11 Jul 2002 10:58:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13465 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 10:59:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12394; Thu, 11 Jul 2002 10:45:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12363 for ; Thu, 11 Jul 2002 10:45:12 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19542 for ; Thu, 11 Jul 2002 10:44:18 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6BEidU56712; Thu, 11 Jul 2002 16:44:39 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA29403; Thu, 11 Jul 2002 16:44:39 +0200 Received: from [192.168.102.207] (unknown [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BE33852FEA; Thu, 11 Jul 2002 16:44:38 +0200 (CEST) Date: Thu, 11 Jul 2002 16:44:39 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Message-ID: <24476154.1026405879@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA465@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA465@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit >> > 1) Nowhere does it say if routers (or even sources) should >> send packets >> > from the same flow along the same path. Is that because it's (a) the >> > wrong place to say so or (b) obvious or (c) impossible to >> mandate? In >> > particular, it does say that a node not carrying out flow specific >> > treatment MUST ignore the field on forwarding - maybe >> 'keeping packets >> > together' could be regarded as flow specific treatment (and made >> > mandatory). (If we could rely on this it would be a >> powerful weapon in >> > the signalling/data path divergence issue, but see next point.) >> > >> >> I would assume it on purpose, because it does not make sense >> to include a >> second dimension into the forwarding decision. The primary >> adress is still >> the destination address. > [reh] so are you saying that it _is_ reasonable for a router to load > share packets from the same flow (i.e. same DA and flowlabel) on two > links? I would assume it depends on the load shareing mechanisms implemented. But in the routing decision you definitly don't want to take into account a flowlabel. [...] >> >> > 3) Fortunately, I think most of the agonies about flow >> label re-use don't >> > have to worry us, they're end-system internal. However, >> there are two >> > points: a) Do we need to strengthen our requirement for a >> TEAR message to >> > flush flow label state? b) If a TEAR isn't possible (e.g. a >> route flap >> > means some routers wouldn't see it), do we need to allow >> the end system >> > to control the soft state timeout so they can be assured of >> when flow >> > label state has been purged? I don't think our current >> requirements give >> > this level of control to end hosts, and I'm not sure they should. >> >> What do you mean by flow label state. The spec says that flow state >> adressing must be via flow label AND source and dest address. >> I think a >> tear message must include flow labels into account. > [reh] ok, for the tear message i think it is clear. the problem comes > when the tear won't work. example: 1. i set up a pinhole in a firewall > associated with a flowlabel > 2. rerouting changes which firewall is used, pinhole is set up in new > firewall 3. i remove the new pinhole with a tear message > 4. the old firewall still has a pinhole in it. when do i know it is safe > to reuse that flowlabel? You know it after some time (time a state is still operational). >> >> >> > 4) I don't see why the flow state establishment method >> (i.e. NSIS for >> > example) needs to be able to manage flow label agreement between end >> > systems (end of section 4). After all, it doesn't handle port number >> > agreement. Such information would need to be end-to-end >> secured, which >> > (IMHO) is a poor match to the security capabilities we are currently >> > assuming for NSIS. >> >> I don't think we need to care about this. It says >> "Therefore the source SHOULD honor the destination's request to >> mark the packets with the Flow Label value specified." >> So the source should honor this, not the signaling. > [reh] my concern is not with that statement, but with the paragraph at > the end of section 4, which places a requirement on signalling (e.g. > NSIS) to carry the flow label to the peer. if this is just a notification > it's probably not a problem, but if it's a request that sounds like flow > label negotiation which I think is not an NSIS problem. (Or, it may be > that I have over-interpreted this section.) Oh, I understood this such that NSIS must carry the flow label in signaling message, but not that NSIS is used for negotiation of the label. I think this is an issue of high layer lignaing such as SIP. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 11:02:16 2002 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 LAA20127 for ; Thu, 11 Jul 2002 11:02:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14238 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 11:03:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12737; Thu, 11 Jul 2002 10:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12575 for ; Thu, 11 Jul 2002 10:49:39 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19662; Thu, 11 Jul 2002 10:48:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BEl7M29024; Thu, 11 Jul 2002 10:47:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:47:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Geib, Ruediger'" , kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:47:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E9.D1A64AE4" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ruediger: Concerning the comment that CT use the "original NSIS parameters": - CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service = description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. - The issue is rather moot, because neither Seamoby nor NSIS are chartered to define what the signalling parameters or forwarding context are. To say that there should be some commonality is=20 of little import, as neither group can analyze the feasibility = and impact of such a statement. - For the two groups should discuss the common parameters would be = a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the = CT/NSIS=20 protocols were - at the very least, we can proceed with the definition=20 of the protocols. Regards, Gary > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: July 11, 2002 04:24 > To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com; > rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt >=20 >=20 > Hi James >=20 > > The point I was trying to make is that given CT of QoS=20 > > context succeeds, NSIS signaling at the new access subnet is > > unnecessary. Thus, it could be viewed as a kind of=20 > > optimization. If CT fails, then signaling would be needed. >=20 > [RG] If this means "QoS related CT replaces MN signaling during=20 > [RG] handoff", given that the related resource reservation > [RG] doesn't change. >=20 > > I did not mean to imply that any changes were required in the=20 > > generic CT requirements (though perhaps there would need to be > > some changes in the QoS specific context definition). >=20 > [RG] QoS CT should use the NSIS resource reservation parameters > [RG] as basic input for its own QoS parameters. Whether the=20 > [RG] original NSIS parameters are copied or derived=20 > [RG] technology or domain specific parameters are used for CT=20 > [RG] doesn't matter if the result is as if the original NSIS=20 > [RG] parameters were used to establish resources at the new AR. >=20 > > Is this accurate, from the NSIS viewpoint? One case where I=20 > > could see it not being accurate is if there were some changes > > required behind the access router in order to obtain QoS for=20 > > the mobile on the new router, but perhaps there are others. >=20 > [RG] This may have to be clarified. I wouldn't expect an MN > [RG] to get involved into tunnel set up and release, should > [RG] this be the way an access network supports QoS and=20 > [RG] mobility. A local NSIS solution may be used within=20 > [RG] the access network to provide the required signaling. > [RG] But I'd expect this to be invisible to the MN.=20 >=20 > [RG] I think NSIS and SEAMOBY must agree how both interwork. > [RG] Besides the QoS parameter issue, an MN should be aware > [RG] of the fact whether CT is supported and whether it is=20 > [RG] succesful (or whether it wasn't). > [RG] To me this seems to be a loose cooperation. If NSIS and > [RG] SEAMOBY conclude to ignore each other, I'd regard both > [RG] as a waste of time with regard to wireless mobility=20 > [RG] combined with QoS.=20 >=20 > Regards, R=FCdiger >=20 ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

Ruediger:

  Concerning the comment that CT use the "original NSIS parameters":

        - CT is not a service establishment protocol; it tranports
       forwarding context, not service description parameters. Some
       of the forwarding context *may* be the original service description
       parameters, but many *may* be derived values that allow a more
       representative description of the AR forwarding context.

     - The issue is rather moot, because neither Seamoby nor NSIS are
       chartered to define what the signalling parameters or forwarding
       context are. To say that there should be some commonality is
       of little import, as neither group can analyze the feasibility and
       impact of such a statement.

     - For the two groups should discuss the common parameters would be a
       violation of the respective charters. I think that this is an excellent
       idea, but I believe it will have to take place outside of the NSIS/Seamoby
       wgs, and I suggest that it would be best if we knew what the CT/NSIS
       protocols were - at the very least, we can proceed with the definition
       of the protocols.

Regards,
Gary

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: July 11, 2002 04:24
> To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com;
> rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> Hi James
>
> > The point I was trying to make is that given CT of QoS
> > context succeeds, NSIS signaling at the new access subnet is
> > unnecessary. Thus, it could be viewed as a kind of
> > optimization. If CT fails, then signaling would be needed.
>
> [RG] If this means "QoS related CT replaces MN signaling during
> [RG] handoff", given that the related resource reservation
> [RG] doesn't change.
>
> > I did not mean to imply that any changes were required in the
> > generic CT requirements (though perhaps there would need to be
> > some changes in the QoS specific context definition).
>
> [RG] QoS CT should use the NSIS resource reservation parameters
> [RG] as basic input for its own QoS parameters. Whether the
> [RG] original NSIS parameters are copied or derived
> [RG] technology or domain specific parameters are used for CT
> [RG] doesn't matter if the result is as if the original NSIS
> [RG] parameters were used to establish resources at the new AR.
>
> > Is this accurate, from the NSIS viewpoint? One case where I
> > could see it not being accurate is if there were some changes
> > required behind the access router in order to obtain QoS for
> > the mobile on the new router, but perhaps there are others.
>
> [RG] This may have to be clarified. I wouldn't expect an MN
> [RG] to get involved into tunnel set up and release, should
> [RG] this be the way an access network supports QoS and
> [RG] mobility. A local NSIS solution may be used within
> [RG] the access network to provide the required signaling.
> [RG] But I'd expect this to be invisible to the MN.
>
> [RG] I think NSIS and SEAMOBY must agree how both interwork.
> [RG] Besides the QoS parameter issue, an MN should be aware
> [RG] of the fact whether CT is supported and whether it is
> [RG] succesful (or whether it wasn't).
> [RG] To me this seems to be a loose cooperation. If NSIS and
> [RG] SEAMOBY conclude to ignore each other, I'd regard both
> [RG] as a waste of time with regard to wireless mobility
> [RG] combined with QoS.
>
> Regards, Rüdiger
>

------_=_NextPart_001_01C228E9.D1A64AE4-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 11:04:43 2002 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 LAA20191 for ; Thu, 11 Jul 2002 11:04:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14317 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 11:05:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12986; Thu, 11 Jul 2002 10:51:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12954 for ; Thu, 11 Jul 2002 10:51:40 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19720 for ; Thu, 11 Jul 2002 10:50:46 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDG6K>; Thu, 11 Jul 2002 15:46:31 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA466@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Sarantis Paskalis'" Cc: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Thu, 11 Jul 2002 15:46:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Sarantis, see inline: > -----Original Message----- > From: Sarantis Paskalis [mailto:sarantis@cnl.di.uoa.gr] > Sent: 11 July 2002 12:59 > To: Hancock, Robert > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] IPv6 Flow Label > > > Hi, > > On Thu, Jul 11, 2002 at 12:04:21AM +0100, Hancock, Robert wrote: > > John, > > > > Interesting draft. I have tried to think it through from a > purely NSIS perspective. > > > > 1) Nowhere does it say if routers (or even sources) should > send packets from the same flow along the same path. Is that > because it's (a) the wrong place to say so or (b) obvious or > (c) impossible to mandate? In particular, it does say that a > node not carrying out flow specific treatment MUST ignore the > field on forwarding - maybe 'keeping packets together' could > be regarded as flow specific treatment (and made mandatory). > (If we could rely on this it would be a powerful weapon in > the signalling/data path divergence issue, but see next point.) > > The only thing relevant mentioned in the draft is a sentence > in Section 2 > > The flow state defines > what kind of treatment should be provided, and how to classify the > packets to the flow. > > According to that definition, NSIS could define the state of > the flows to > always follow the same path. The second part of the sentence > also applies > to point 2. [reh] the problem is that if the packets of a flow do not follow a unique path, saying the state of the flow always follows 'the' path is not meaningful. in any case, it's not an NSIS responsibility to define how routers do load sharing (for example). (or, I don't understand your point.) > > > 2) The draft seems to encourage (SHOULD) a highly granular > assignment of flow labels (e.g. section 4 rules 3 & 4). On > the other hand, there may be good reasons to use the same > label for a sequence of 'microflows' (e.g. successive files > in a bulk ftp transfer; the same point has been made on the > v6 list). Encouraging this granularity directly increases the > signalling burden. How strong is SHOULD? > > I think, this is partially covered in Section 5, rule 1. > > Depending on the method semantics, multiple such triplets MAY > identify the same flow state (e.g. SCTP flows with multiple > addresses at either end-points, or a diffserv > classifier with an > address range. > > This can be extended to cover the case for a "flowmask" in > which the first > say 15 bits identify the flow state, while the last 5 identify the > "microflow". [reh] that's a very natural idea. on the other hand, it can't be defined on a case by case basis, since that section is about allowing multiple (including presently unknown) flow state establishment methods to co-exist. if you think co-existence is important, any such flowmask method would (I think) need to be defined in this draft (which is probably overkill). i don't think there's an easy answer to this question. > > In that case the draft states that: > > The flow state establishment method MUST > convey this classifying information to the IPv6 nodes > that need > to perform the classification. > > i.e. this should be a NSIS requirement. [reh] that is clear. > > Cheers, > > Sarantis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 11:04:43 2002 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 LAA20204 for ; Thu, 11 Jul 2002 11:04:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14328 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 11:05:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12911; Thu, 11 Jul 2002 10:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12821 for ; Thu, 11 Jul 2002 10:51:27 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19713; Thu, 11 Jul 2002 10:50:33 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BEtAj11908; Thu, 11 Jul 2002 09:55:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 09:51:25 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:51:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Thu, 11 Jul 2002 10:51:24 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcIoX3b7S89XNHCNQA+R55RD7Gv5YwAid8OQ To: , , Cc: , , X-OriginalArrivalTime: 11 Jul 2002 14:51:25.0817 (UTC) FILETIME=[6E52BE90:01C228EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA12824 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James: Please see inline: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 10. July 2002 18:15 To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Chaskar Hemant (NRC/Boston) Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. [Hemant] If you mean here that NSIS signaling *between MN and new AR* at the new access subnet is unnecessary, then I agree with you. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). [Hemant] If CT is merely a carrier protocol, it should be easy to define NSIS payload types to be carried within it. So, I agree that changes may not be required to requirements. Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. [Hemant] Yes, that is one case where NSIS will need to do signaling even after CT. There is also another case, which is when service at new AR is different than that at old AR (2.5G to WLAN handoff). Since, negotiation is out of scope of CT, CT would merely transfer old service description (say thrpt. = 100 kpbs) to new AR. But new AR can actually offer 1000 kbps to flow. NSIS has to later adapt to such changes. Of course, this function could be delegated to CARD, then transferred QoS context will say 1000 kbps in the first place. -Hemant jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 11:42:48 2002 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 LAA21721 for ; Thu, 11 Jul 2002 11:42:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17036 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 11:43:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15493; Thu, 11 Jul 2002 11:29:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15463 for ; Thu, 11 Jul 2002 11:29:46 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21144 for ; Thu, 11 Jul 2002 11:28:53 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDG0S>; Thu, 11 Jul 2002 16:29:44 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA467@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Thu, 11 Jul 2002 16:29:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi marcus: inline (just 2 left). > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 July 2002 15:45 > To: Hancock, Robert; john.loughney@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] IPv6 Flow Label > > > > >> > 1) Nowhere does it say if routers (or even sources) should > >> send packets > >> > from the same flow along the same path. Is that because > it's (a) the > >> > wrong place to say so or (b) obvious or (c) impossible to > >> mandate? In > >> > particular, it does say that a node not carrying out > flow specific > >> > treatment MUST ignore the field on forwarding - maybe > >> 'keeping packets > >> > together' could be regarded as flow specific treatment (and made > >> > mandatory). (If we could rely on this it would be a > >> powerful weapon in > >> > the signalling/data path divergence issue, but see next point.) > >> > > >> > >> I would assume it on purpose, because it does not make sense > >> to include a > >> second dimension into the forwarding decision. The primary > >> adress is still > >> the destination address. > > [reh] so are you saying that it _is_ reasonable for a router to load > > share packets from the same flow (i.e. same DA and flowlabel) on two > > links? > > I would assume it depends on the load shareing mechanisms > implemented. But > in the routing decision you definitly don't want to take into > account a > flowlabel. [reh] not routing but forwarding. see for example rfc3272 section 4.2.4. in the language of that rfc, should flowlabelled packets be allowed to be round-robin distributed, or distributed on any fields other than the flowlabel (and addresses)? > > [...] > > >> > >> > 3) Fortunately, I think most of the agonies about flow > >> label re-use don't > >> > have to worry us, they're end-system internal. However, > >> there are two > >> > points: a) Do we need to strengthen our requirement for a > >> TEAR message to > >> > flush flow label state? b) If a TEAR isn't possible (e.g. a > >> route flap > >> > means some routers wouldn't see it), do we need to allow > >> the end system > >> > to control the soft state timeout so they can be assured of > >> when flow > >> > label state has been purged? I don't think our current > >> requirements give > >> > this level of control to end hosts, and I'm not sure they should. > >> > >> What do you mean by flow label state. The spec says that flow state > >> adressing must be via flow label AND source and dest address. > >> I think a > >> tear message must include flow labels into account. > > [reh] ok, for the tear message i think it is clear. the > problem comes > > when the tear won't work. example: 1. i set up a pinhole in > a firewall > > associated with a flowlabel > > 2. rerouting changes which firewall is used, pinhole is set > up in new > > firewall 3. i remove the new pinhole with a tear message > > 4. the old firewall still has a pinhole in it. when do i > know it is safe > > to reuse that flowlabel? > > You know it after some time (time a state is still operational). > [reh] and does the end system need to be able to (a) know (or know an upper bound), or even (b) control this time? that's my concern. it could be hard. > > Marcus > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 12:42:08 2002 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 MAA24747 for ; Thu, 11 Jul 2002 12:42:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26093 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 12:43:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23937; Thu, 11 Jul 2002 12:29:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23882 for ; Thu, 11 Jul 2002 12:29:28 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24060; Thu, 11 Jul 2002 12:28:33 -0400 (EDT) Message-ID: <00c901c228f7$dd8b9220$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Geib, Ruediger'" , , , Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 09:27:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. If the service description parameters are involved in fowarding, then the two are the same, right? Will there be any difference for QoS? > For the two groups should discuss the common parameters would be a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the CT/NSIS protocols were - at the very least, we can proceed with the definition of the protocols. We have to make sure the two protocols work well together. CT is not specific to QoS, so I don't see any overlap, but when it comes time to define the QoS feature context type, perhaps that definition can be done by the NSIS group, or in conjunction with it in some way. Requirements, for example. jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 13:32:17 2002 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 NAA26876 for ; Thu, 11 Jul 2002 13:32:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01713 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 13:33:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00063; Thu, 11 Jul 2002 13:17:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00027 for ; Thu, 11 Jul 2002 13:17:32 -0400 (EDT) Received: from 13.19.04.12 ([218.17.72.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26313 for ; Thu, 11 Jul 2002 13:16:30 -0400 (EDT) Message-Id: <200207111716.NAA26313@ietf.org> From: =?gb2312?q?=B0=D7=BD=F0=CD=C5=B6=D3_?= To: nsis@ietf.org Reply-To: gp@postmaster.com Date: Fri, 12 Jul 2002 01:19:12 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="75c75bf8-780f-47c8-94ba-aea9d8a5600b" Subject: [NSIS] =?gb2312?q?=D4=B2=C4=FA=BD=F0=C8=DA=D7=D4=D3=C9=D6=AE=C3=CE=A3=AC=C8=C3=C4=FA=A1=B0=C7=AE=A1=B1=B3=CC=CB=C6=A1=B0=BD=F0=A1=B1=A3=A1?= Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format --75c75bf8-780f-47c8-94ba-aea9d8a5600b Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable =C5=F3=D3=D1

=D7=F0=BE=B4=B5=C4=CD=F8=D3=D1=A3=AC=C4=FA=BA=C3=A3=BA

    =C7=EB=D4=AD=C1=C2=CE=D2=C3=C7=B5=C4=C3=B0=C3=C1=A3=AC=C8= =E7=B9=FB=C4=FA=B6=D4=CD=F8=C2=E7=D7=AC=C7=AE=B8=D0=D0=CB=C8=A4=A3=AC=B2=A2=C1= =A2=D6=BE=BF=AA=B4=B4=D7=D4=BC=BA=B5=C4=CD=F8=C2=E7=D7=D4=D3=C9=CA=C2=D2=B5=A3= =AC=C4=C7=C3=B4=D5=E2=B7=E2=D0=C5=BD=AB=B4=F8=B8=F8=C4=FA=D2=BB=B8=F6=C4=D1=B5= =C3=B5=C4=BB=FA=BB=E1=A3=A1=B7=F1=D4=F2=C7=EB=D6=B1=BD=D3=B0=D1=B4=CB=D0=C5=C9= =BE=B3=FD=A3=AC=C8=E7=B8=F8=B8=F3=CF=C2=D4=EC=B3=C9=B2=BB=B1=E3=A3=AC=CE=D2=C3= =C7=D6=A3=D6=D8=B5=C0=C7=B8=A1=A3

=B4=F3=BC=D2=CB=F9=CA=EC=CF=A4=B5=C4=D7=AC=C7=AE=CD=F8=D5=BE=BD=F6=BD=F6=C4=DC= =C3=D6=B2=B9=C4=FA=B5=C4=C9=CF=CD=F8=B7=D1=D3=C3=A3=AC=B6=F8=CE=D2=C3=C7=BD=E9= =C9=DC=B5=C4=D5=E2=D2=BB=CD=F8=D5=BE=CA=C7=CA=B9=B2=C6=B8=BB=C6=BD=C3=F1=BB=AF= =B5=C4=D7=AC=C7=AE=CD=F8=D5=BE=A3=AC=CB=FB=B2=BB=CD=AC=D3=DA=C8=CE=BA=CE=D2=BB= =BC=D2=D7=AC=C7=AE=CD=F8=D5=BE=A1=A3=CB=FC=B5=C4=D4=AD=C0=ED=BA=DC=BC=F2=B5=A5= =A3=BA=CA=C7=B0=D1=CA=C0=BD=E7=C9=CF=CB=F9=D3=D0=CF=A3=CD=FB=CD=A8=B9=FD=BB=A5= =C1=AA=CD=F8=C2=E7=D7=AC=C7=AE=B5=C4=CD=F8=D3=D1=C1=AA=BA=CF=C6=F0=C0=B4=D4=D9= =CD=A8=B9=FD=CB=FB=C3=C7=B6=C0=CC=D8=B5=C4=D4=CB=D7=F7=B7=BD=B0=B8=A3=AC=CA=B9= =B5=C3=C3=BF=D2=BB=B8=F6=BC=D3=C8=EB=D5=DF=B6=BC=C4=DC=D7=AC=C7=AE=A3=A1= :-)

=CB=FC=B2=BB=CF=F1=C4=C7=D0=A9=B9=E3=B8=E6=D7=AC=C7=AE=CD=F8=D5=BE=BC=C6=B7=D1= =B2=BB=D7=BC=A1=A2=B8=B6=BF=EE=CE=DE=B1=A3=D5=CF=A3=BB=CB=FB=D2=B2=B2=BB=CF=F1= =C4=C7=D0=A9=CB=F9=CE=BD=BD=E9=C9=DC=BB=E1=D4=B1=BC=D3=C8=EB=B1=E3=B8=B6=B8=F8= =C4=E3=BD=B1=BD=F0=B5=C4=CD=F8=D5=BE=A3=BB=CB=FC=B2=BB=CF=F1=C4=C7=D0=A9=CD=A8= =B9=FD=B6=C1=D3=CA=BC=FE=CA=D5=D3=CA=BC=FE=C0=B4=D7=AC=C7=AE=B5=C4=CD=F8=D5=BE= =A3=BB=CB=FB=D2=B2=B2=BB=CF=F1=CD=F8=C2=E7=B4=AB=CF=FA=C4=C7=D1=F9=A3=AC=BD=E9= =C9=DC=C8=CB=D3=C0=D4=B6=B8=DF=BE=D3=D4=DA=C9=CF=A3=AC=CF=ED=CA=DC=CE=DE=CF=DE= =B5=C4=C0=FB=C8=F3=A1=A3

=CB=FC=CA=C7=D5=E6=CA=B5=B5=C4=A1=A2=BF=C9=BF=BF=B5=C4=A1=A2=B9=AB=C6=BD=B5=C4= =A1=A2=B6=C0=CC=D8=B5=C4=D7=AC=C7=AE=CD=F8=D5=BE=A1=A3=CB=FC=CA=C7=D2=BB=B8=F6= =C1=BC=BA=C3=D4=CB=D0=D0=C1=CB=C8=FD=C4=EA=B5=C4=CD=F8=D5=BE=A3=AC=CB=FC=CA=C7= =BD=AB=CD=F8=C2=E7=B5=C4=B2=C6=B8=BB=C6=BD=C3=F1=BB=AF=B5=C4=CD=F8=D5=BE=A3=AC= =CB=FC=CA=C7=D2=BB=B8=F6=C4=FA=D7=EE=D6=D5=BB=E1=D1=A1=D4=F1=B5=C4=CD=F8=D5=BE= =A1=A3=C3=BF=CE=BB=B2=CE=BC=D3=D5=E2=D2=BB=CC=D7=B7=BD=B0=B8=B5=C4=C8=CB=B6=BC= =B0=B5=D7=D4=C7=EC=D0=D2=D7=D4=BC=BA=B5=B1=B3=F5=B5=C4=D1=A1=D4=F1= =A1=A3

=D0=C5=D3=EB=B2=BB=D0=C5=D3=C9=C4=FA=D7=D4=BC=BA=C0=B4=C8=A1=C9=E1=A3=AC=CF=E0= =D0=C5=CE=D2=C3=C7=A3=BA=D5=E2=CA=C7=D2=BB=B8=F6=C7=A7=D4=D8=C4=D1=B7=EA=B5=C4= =BB=FA=BB=E1=A1=A3=D3=C9=D3=DA=CE=D2=C3=C7=D6=D0=B9=FA=C8=CB=CB=BC=CF=EB=B1=A3= =CA=D8=A3=AC=B6=D4=D3=DA=C9=CC=D2=B5=C9=CF=B5=C4=C6=DB=C6=AD=D0=D0=CE=AA=B8=FC= =CA=C7=BA=DE=D6=AE=C8=EB=B9=C7=A3=AC=D4=D9=BC=D3=C9=CF=CE=D2=C3=C7=D6=D0=B9=FA= =C8=CB=CD=E2=D3=EF=CB=AE=C6=BD=BA=CD=CD=F8=C2=E7=BC=BC=C4=DC=D3=D0=CF=DE=A3=AC= =B6=D4=D3=DA=B5=B1=BD=F1=BB=A5=C1=AA=CD=F8=C2=E7=B5=C4=C1=CB=BD=E2=D7=DC=CA=C7= =B1=C8=B7=A2=B4=EF=B9=FA=BC=D2=C2=FD=B0=EB=C5=C4=A3=AC=B4=D3=B6=F8=B5=BC=D6=C2= =CE=D2=C3=C7=B2=BB=C4=DC=B5=DA=D2=BB=CA=B1=BC=E4=D5=C6=CE=D5=BA=AC=BD=F0=C1=BF= =B8=DF=B5=C4=D0=C5=CF=A2=A1=A3=B2=BB=B9=FD=A3=AC=BD=F1=CC=EC=C4=FA=D6=BB=D2=AA= =B6=AF=CA=D6=CF=F2

gp@i-1328.com

 =B7=A2=D2=BB=B7=E2=BF=D5=B0=D7=D0=C5=A3=AC=D5=E2=D0=A9=B6=BC=BD=AB=B2=BB=D4=D9= =CA=C7=CE=CA=CC=E2=A1=A3=CE=D2=C3=C7=BB=E1=D0=AD=D6=FA=C4=FA=D7=DF=CF=F2=B3=C9= =B9=A6=B5=C4=A1=A3=B6=F8=CE=D2=C3=C7=CE=AA=C4=FA=CB=F9=D7=F7=B5=C4=D2=BB=C7=D0= =B6=BC=CA=C7=C3=E2=B7=D1=B5=C4=A3=A1=BB=F2=B5=BD=D2=D4=CF=C2=B0=D7=BD=F0=C9=E7= =C7=F8=D6=D0=B9=FA=C7=F8=D3=F2=B5=C4=CD=F8=D6=B7=E4=AF=C0=C0=A3=BA

http://www.i-1328.com

=B2=BB=D2=AA=D0=C1=D0=C1=BF=E0=BF=E0= =C8=A5=D7=AC=C4=C7=D2=BB=B8=F6=D0=A1=CA=B1=BC=B8=C3=C0=B7=D6=B9=E3=B8=E6=B7=D1= =C1=CB=A3=AC=C4=E3=B2=BB=C0=DB=C2=F0=A3=BF=A3=BF=
=C8=E7=B9=FB=C4=E3=D5=E6=CF= =EB=B4=D3=CD=F8=C2=E7=D6=D0=D7=AC=C7=AE=A3=AC=BE=CD=B0=D1=D1=DB=B9=E2=B7=C5=B5= =BD=D7=EE=B7=A2=B4=EF=B5=C4=C7=B0=D1=D8=A3=AC=BF=B4=BF=B4=CB=FB=C3=C7=CA=C7=D4=F5=C3=B4=D7=F6= =B5=C4=A1=A3
=D3=D0=CE=D2=C3=C7=B5=C4=D6= =B8=D2=FD=A3=AC=C4=E3=D2=BB=B6=A8=BB=E1=B7=A2=CF=D6=A3=AC=B7=E7=BE=B0=C4=C7=B1= =DF=B6=C0=BA=C3=A3=A1
=B5=B1=C4=E3=C3=BF=CC=EC=B6= =A2=D7=C5=B9=E3=B8=E6=CC=F5=A3=AC=C0=CB=B7=D1=B5=C4=B2=BB=BD=F6=CA=C7=C4=E3=B1= =A6=B9=F3=B5=C4=CA=B1=BC=E4......
=D0=D0=B6=AF=C6=F0=C0=B4=B0= =C9,=C4=E3=D2=BB=B6=A8=BB=E1=B3=C9=B9=A6=B5=C4!=C4=E3=B5=C4=C3=FC= =D4=CB=BD=AB=B4=D3=D5=E2=D2=BB=BF=CC=BF=AA=CA=BC=B8=C4=B1=E4=A3=A1
=B0=D7=BD=F0=C9=E7=C7=F8--21=CA=C0=BC=CD=D7=EE=C1=EE=C8=CB=BE=AA=C6=E6= =B5=C4=D2=BB=B4=CE=BB=FA=BB=E1=A3=A1
=D4=B8=CE=D2=C3=C7=D0=AF=CA=D6=B2=A2= =BC=E7=A3=AC=B9=B2=B4=B4=CD=F8=C2=E7=C3=C0=BA=C3=C3=F7=CC=EC=A3=A1

=D7=A2=A3=BA=B0=D7=BD=F0=C9=E7=C7=F88=D4=C21=C8=D5=BD=AB=C8=AB=C3= =E6=C6=F4=B6=AF=A3=AC=B5=BD=CA=B1=BA=F2=C3=E2=B7=D1=BC=D3=C8=EB=B5=C4=B0=D7=BD= =F0=BB=E1=D4=B1=BE=CD=BF=C9=D2=D4=D6=B1=BD=D3=D7=AC=C8=A1=C3=C0=BD=F0=C1=CB=A3= =AC=C7=EB=C3=DC=C7=D0=C1=F4=D2=E2=A3=A1


Best Regards
=B0=D7=BD=F0=D6=C7=C7=BF=CD=C5=B6=D3 

--75c75bf8-780f-47c8-94ba-aea9d8a5600b-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 13:58:49 2002 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 NAA28291 for ; Thu, 11 Jul 2002 13:58:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA04468 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 13:59:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02737; Thu, 11 Jul 2002 13:45:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02691 for ; Thu, 11 Jul 2002 13:45:14 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27518 for ; Thu, 11 Jul 2002 13:44:19 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDH1X>; Thu, 11 Jul 2002 18:45:04 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA46A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Thu, 11 Jul 2002 18:44:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi marcus, i've added a few refinements. we get up to 8 questions in all. some answers may be obvious to some people, but I don't think any are obvious to everyone. robert h. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 July 2002 15:02 > To: john.loughney@nokia.com; Hancock, Robert; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt > > > > >> [Note: such a section could also define just what the on-path > >> restriction actually was. I've seen at least 4 different > >> incompatible views on that.] > > > > Want to provide a summary of the 4 views? > > Ok, I give it a try > > 1) exclusive on path > The NSIS initiator and NSIS receiver are the data receiver and sender > > 2) proxy on path > The NSIS initiator is some where on the data path but not at > the sending > nor receiving side (only part of the data path is covered by > signaling) > > 3) IP-hop-by-IP-hop > The signaling message travels IP-hop-by-IP-hop. Where the > hops are chosen > by the destination addr 3a) The signaling message travels IP-hop-by-IP-hop, but the hop can be chosen on any fields in the IP header (of data packet) or flow definition (in NSIS aware router), e.g. DSCP and so on. Can be used to handle some load sharing/traffic engineering issues, but not across NSIS-unaware clouds. > > 4) NSIS-hop-by-NSIS-hop > The signaling message follows NSIS hops, where intermediate > IP hops are not > visited. The NSIS hop has to choose the next hop, here the > data path migh > follow a different path for a shsort segment. [to clarify?] the ends of the NSIS hop are on the data path, but the middle may not be. the message is explicitly addressed to the next NSIS hop. > > 5) in advance reservation in hand-over cases > If a new access router has been chosen, where a mobile will > newly connect > to and a reservation should be done in advance, the data > flows still on the > old path. At the point in time data is flowing along the new > path (after > handoff) the reservation has already been setup. 6) i've seen some claim that if a node sets up a tunnel (obviously with a known endpoint) and then signals for the tunnel, and also sends data and signalling through the tunnel, this is 'morally equivalent' to off-path, in the sense that you're no longer relying on the routing system to recover from any non-end-system failures. 7) even if some messages are sent traditionally on-path as per (3) [like RSVP PATH], are other messages allowed to go off path and not be routed NSIS-hop by NSIS-hop [e.g. acknowledgements, error notifications]? or should everything go on-path? > > Marcus > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 16:22:07 2002 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 QAA04454 for ; Thu, 11 Jul 2002 16:22:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14406 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 16:23:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12729; Thu, 11 Jul 2002 15:56:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12686 for ; Thu, 11 Jul 2002 15:56:54 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03232; Thu, 11 Jul 2002 15:56:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BJrXl26163; Thu, 11 Jul 2002 15:53:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 15:53:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C0D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Geib, Ruediger'" , Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 15:53:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22913.D99AE640" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22913.D99AE640 Content-Type: text/plain; charset="iso-8859-1" The point was not that the parameters will be the same or different. The point was that discussion of the context make up is out of scope for Seamoby, and discussion of QoS parameters is out of scope for NSIS. It is too great a leap of faith to say that the NSIS parameters will be the configuration context. Thus, while I agree that the two protocols must interwork, there is nothing we can do about matching the NSIS parameters with the Context, without a change in charter. The one step we could take (but not the one that was suggested) would be to investigate into ensuring some commonality between the formats for encapsulating the respective data chunks (i.e. context/NSIS parameters). Or at least, provide for NSIS to carry CT data chunks and visa versa. gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 12:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger'; > Madjid.Nakhjiri@motorola.com; rajeev@iprg.nokia.com; > Hemant.Chaskar@nokia.com > Cc: seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt > > > > CT is not a service establishment protocol; it tranports > forwarding context, not service description parameters. Some > of the forwarding context *may* be the original > service description > parameters, but many *may* be derived values that allow a more > representative description of the AR forwarding context. > > If the service description parameters are involved in > fowarding, then the two are the same, right? Will there be any > difference for QoS? > > > > For the two groups should discuss the common parameters would be a > violation of the respective charters. I think that this is an > excellent > idea, but I believe it will have to take place outside of the > NSIS/Seamoby > wgs, and I suggest that it would be best if we knew > what the CT/NSIS > protocols were - at the very least, we can proceed with the > definition > of the protocols. > > We have to make sure the two protocols work well together. > > CT is not specific to QoS, so I don't see any overlap, but > when it comes time to define the QoS feature context type, perhaps > that definition can be done by the NSIS group, or in > conjunction with it in some way. Requirements, for example. > > jak > > ------_=_NextPart_001_01C22913.D99AE640 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

The point was not that the parameters will be the same or different.
The point was that discussion of the context make up is out of scope
for Seamoby, and discussion of QoS parameters is out of scope for
NSIS. It is too great a leap of faith to say that the NSIS parameters
will be the configuration context. Thus, while I agree that the two
protocols must interwork, there is nothing we can do about matching
the NSIS parameters with the Context, without a change in charter.

The one step we could take (but not the one that was suggested) would
be to investigate into ensuring some commonality between the formats for
encapsulating the respective data chunks (i.e. context/NSIS parameters).
Or at least, provide for NSIS to carry CT data chunks and visa versa.

gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger';
> Madjid.Nakhjiri@motorola.com; rajeev@iprg.nokia.com;
> Hemant.Chaskar@nokia.com
> Cc: seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> > CT is not a service establishment protocol; it tranports
>        forwarding context, not service description parameters. Some
>        of the forwarding context *may* be the original
> service description
>        parameters, but many *may* be derived values that allow a more
>        representative description of the AR forwarding context.
>
> If the service description parameters are involved in
> fowarding, then the two are the same, right? Will there be any
> difference for QoS?
>
>
> > For the two groups should discuss the common parameters would be a
>        violation of the respective charters. I think that this is an
> excellent
>        idea, but I believe it will have to take place outside of the
> NSIS/Seamoby
>        wgs, and I suggest that it would be best if we knew
> what the CT/NSIS
>        protocols were - at the very least, we can proceed with the
> definition
>        of the protocols.
>
> We have to make sure the two protocols work well together.
>
> CT is not specific to QoS, so I don't see any overlap, but
> when it comes time to define the QoS feature context type, perhaps
> that definition can be done by the NSIS group, or in
> conjunction with it in some way. Requirements, for example.
>
>             jak
>
>

------_=_NextPart_001_01C22913.D99AE640-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 11 16:42:45 2002 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 QAA05328 for ; Thu, 11 Jul 2002 16:42:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15514 for nsis-archive@odin.ietf.org; Thu, 11 Jul 2002 16:43:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14213; Thu, 11 Jul 2002 16:19:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14047 for ; Thu, 11 Jul 2002 16:18:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04285; Thu, 11 Jul 2002 16:17:48 -0400 (EDT) Message-ID: <030c01c22916$5f16bc20$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Geib, Ruediger'" , , , Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA4C0D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 13:05:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > The one step we could take (but not the one that was suggested) would > be to investigate into ensuring some commonality between the formats for > encapsulating the respective data chunks (i.e. context/NSIS parameters). > Or at least, provide for NSIS to carry CT data chunks and visa versa. > Right, that is in fact the kind of thing I had in mind. If you don't want to call it QoS context, call it "NSIS context". jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 12 04:45:02 2002 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 EAA11664 for ; Fri, 12 Jul 2002 04:45:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01544 for nsis-archive@odin.ietf.org; Fri, 12 Jul 2002 04:45:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00109; Fri, 12 Jul 2002 04:29:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00073 for ; Fri, 12 Jul 2002 04:29:47 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11224 for ; Fri, 12 Jul 2002 04:28:52 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6C8TjrU000695; Fri, 12 Jul 2002 10:29:45 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SK1M6BF; Fri, 12 Jul 2002 10:29:45 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 10:29:46 +0200 Message-ID: X-Sybari-Trust: c2216c5a d4614bde 37555e98 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt Date: Fri, 12 Jul 2002 10:25:19 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert I have a remark on one of your statements (statement (7)): [Robert] (7) even if some messages are sent traditionally on-path as per (3) [like RSVP PATH], are other messages allowed to go off path and not be routed NSIS-hop by NSIS-hop [e.g. acknowledgements, error notifications]? or should everything go on-path? [georgios] this is very much related to backward routing issues. In a sender initiated approach it should be allowed that the acknowledgements and error notification messages are sent to specific NSIS Forwarders (QoS Controllers) or NSIS Initiators (QoS Initiators) directly, without using backward routing (in RSVP terms without using the PHOP option). Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Thursday, July 11, 2002 7:45 PM To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt hi marcus, i've added a few refinements. we get up to 8 questions in all. some answers may be obvious to some people, but I don't think any are obvious to everyone. robert h. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 11 July 2002 15:02 > To: john.loughney@nokia.com; Hancock, Robert; > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt > > > > >> [Note: such a section could also define just what the on-path > >> restriction actually was. I've seen at least 4 different > >> incompatible views on that.] > > > > Want to provide a summary of the 4 views? > > Ok, I give it a try > > 1) exclusive on path > The NSIS initiator and NSIS receiver are the data receiver and sender > > 2) proxy on path > The NSIS initiator is some where on the data path but not at > the sending > nor receiving side (only part of the data path is covered by > signaling) > > 3) IP-hop-by-IP-hop > The signaling message travels IP-hop-by-IP-hop. Where the > hops are chosen > by the destination addr 3a) The signaling message travels IP-hop-by-IP-hop, but the hop can be chosen on any fields in the IP header (of data packet) or flow definition (in NSIS aware router), e.g. DSCP and so on. Can be used to handle some load sharing/traffic engineering issues, but not across NSIS-unaware clouds. > > 4) NSIS-hop-by-NSIS-hop > The signaling message follows NSIS hops, where intermediate > IP hops are not > visited. The NSIS hop has to choose the next hop, here the > data path migh > follow a different path for a shsort segment. [to clarify?] the ends of the NSIS hop are on the data path, but the middle may not be. the message is explicitly addressed to the next NSIS hop. > > 5) in advance reservation in hand-over cases > If a new access router has been chosen, where a mobile will > newly connect > to and a reservation should be done in advance, the data > flows still on the > old path. At the point in time data is flowing along the new > path (after > handoff) the reservation has already been setup. 6) i've seen some claim that if a node sets up a tunnel (obviously with a known endpoint) and then signals for the tunnel, and also sends data and signalling through the tunnel, this is 'morally equivalent' to off-path, in the sense that you're no longer relying on the routing system to recover from any non-end-system failures. 7) even if some messages are sent traditionally on-path as per (3) [like RSVP PATH], are other messages allowed to go off path and not be routed NSIS-hop by NSIS-hop [e.g. acknowledgements, error notifications]? or should everything go on-path? > > Marcus > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 12 06:40:47 2002 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 GAA15878 for ; Fri, 12 Jul 2002 06:40:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09002 for nsis-archive@odin.ietf.org; Fri, 12 Jul 2002 06:41:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07825; Fri, 12 Jul 2002 06:22:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07729 for ; Fri, 12 Jul 2002 06:22:28 -0400 (EDT) Received: from zeus.di.uoa.gr (zeus.di.uoa.gr [195.134.65.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15170 for ; Fri, 12 Jul 2002 06:21:32 -0400 (EDT) Received: from gallagher.di.uoa.gr (gallagher.di.uoa.gr [195.134.67.52]) by zeus.di.uoa.gr (8.12.3/8.12.3) with ESMTP id g6CALY12000140; Fri, 12 Jul 2002 13:21:35 +0300 (EEST) Received: from gallagher.di.uoa.gr (localhost [127.0.0.1]) by gallagher.di.uoa.gr (8.12.2/8.12.2) with ESMTP id g6CALf5n004240; Fri, 12 Jul 2002 13:21:41 +0300 Received: (from sarantis@localhost) by gallagher.di.uoa.gr (8.12.2/8.12.2/Submit) id g6CALeZ1004238; Fri, 12 Jul 2002 13:21:40 +0300 Date: Fri, 12 Jul 2002 13:21:40 +0300 From: Sarantis Paskalis To: "Hancock, Robert" Cc: nsis@ietf.org Subject: Re: [NSIS] IPv6 Flow Label Message-ID: <20020712102140.GA4191@gallagher.di.uoa.gr> References: <76C92FBBFB58D411AE760090271ED4181EA466@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA466@rsys002a.roke.co.uk> User-Agent: Mutt/1.4i X-MailScanner: Found to be clean Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org On Thu, Jul 11, 2002 at 03:46:24PM +0100, Hancock, Robert wrote: > > The only thing relevant mentioned in the draft is a sentence > > in Section 2 > > > > The flow state defines > > what kind of treatment should be provided, and how to classify the > > packets to the flow. > > > > According to that definition, NSIS could define the state of > > the flows to > > always follow the same path. The second part of the sentence > > also applies > > to point 2. > [reh] the problem is that if the packets of a flow do not follow a unique path, saying the state of the flow always follows 'the' path is not meaningful. in any case, it's not an NSIS responsibility to define how routers do load sharing (for example). (or, I don't understand your point.) Yes, I was not clear. What I meant was that NSIS would define the flow specific treatment at the intermediate router to include forwarding the packets of a flow to the same interface, i.e. to follow a "path". I am not sure if this can be an NSIS requirement or not (to always direct flow specific traffic to the same interface if possible). My understanding from reading the draft is that this responsibility is left to the "flow state management", i.e. NSIS in our case. > > > 2) The draft seems to encourage (SHOULD) a highly granular > > assignment of flow labels (e.g. section 4 rules 3 & 4). On > > the other hand, there may be good reasons to use the same > > label for a sequence of 'microflows' (e.g. successive files > > in a bulk ftp transfer; the same point has been made on the > > v6 list). Encouraging this granularity directly increases the > > signalling burden. How strong is SHOULD? > > > > I think, this is partially covered in Section 5, rule 1. > > > > Depending on the method semantics, multiple such triplets MAY > > identify the same flow state (e.g. SCTP flows with multiple > > addresses at either end-points, or a diffserv > > classifier with an > > address range. > > > > This can be extended to cover the case for a "flowmask" in > > which the first > > say 15 bits identify the flow state, while the last 5 identify the > > "microflow". > [reh] that's a very natural idea. on the other hand, it can't be defined on a case by case basis, since that section is about allowing multiple (including presently unknown) flow state establishment methods to co-exist. if you think co-existence is important, any such flowmask method would (I think) need to be defined in this draft (which is probably overkill). > > i don't think there's an easy answer to this question. I think it can be defined on a case-by-case basis based on specific NSIS signaling, i.e. an NSIS message defining the grouping of several flowlabels into one logical flow. By "flow state management methods" I thought something of NSIS, RSVP, etc. In these cases, I don't see any interference between different flow state management methods, if the flow label space of one is independent from the flow label space of the other. This is natural, since the application (or any other entity) initiating a flow (possibly of multiple microflows) will choose to signal its requirements by only one signaling protocol. The flow labels will be unique for that source address, so the flow state management at intermediate routers will not have to deal with multiple flow state management methods dealing with the same flow. > > In that case the draft states that: > > > > The flow state establishment method MUST > > convey this classifying information to the IPv6 nodes > > that need > > to perform the classification. > > > > i.e. this should be a NSIS requirement. > [reh] that is clear. There is a conflict with draft-ietf-nsis-req-03.txt, section 5.5.5 (possibly only naming conflict). In the flow-label draft, several microflows with different flow labels are treated as one flow, whereas in the the nsis-req draft, the microflows are treated as independent flows (and their signaling is just grouped together for efficiency). Regards, -- Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 12 07:06:24 2002 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 HAA16783 for ; Fri, 12 Jul 2002 07:06:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09995 for nsis-archive@odin.ietf.org; Fri, 12 Jul 2002 07:07:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08907; Fri, 12 Jul 2002 06:40:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08844 for ; Fri, 12 Jul 2002 06:40:14 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15819; Fri, 12 Jul 2002 06:39:18 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CAefi22956; Fri, 12 Jul 2002 13:40:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 13:40:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 13:40:09 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Jul 2002 13:40:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65720@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Thread-Index: AcIpGEBC0Wbw2LAVTZKu9SixVavevQAXpCkg To: Cc: , X-OriginalArrivalTime: 12 Jul 2002 10:40:09.0504 (UTC) FILETIME=[7E8DB200:01C22990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA08847 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > The one step we could take (but not the one that was > suggested) would > > be to investigate into ensuring some commonality between > the formats for > > encapsulating the respective data chunks (i.e. context/NSIS > parameters). > > Or at least, provide for NSIS to carry CT data chunks and > visa versa. > > > > Right, that is in fact the kind of thing I had in mind. If > you don't want to call it QoS context, call it "NSIS context". Just as an FYI, some folks are interest in looking into using NSIS for various things, like QoS, NAT, & firewall traversal, and so forth. For these cases, what parameters NSIS signals are very much service/application specific. This is also true with regards to Context Transfer. What I suggest is that NSIS and CT progress, and since there is some overlap in the interest of both groups, we can try to ensure that whatever solutions we work on do not cause trouble for the different working groups. However, I don't support tightly coupling the solutions. A much better way would be that after CT & NSIS work is well along, someone could make an applicability document of combining both NSIS & CT into a solution for particular deployments. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Jul 12 19:01:52 2002 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 TAA18740 for ; Fri, 12 Jul 2002 19:01:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25255 for nsis-archive@odin.ietf.org; Fri, 12 Jul 2002 19:02:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24446; Fri, 12 Jul 2002 18:48:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24415 for ; Fri, 12 Jul 2002 18:48:31 -0400 (EDT) Received: from 88biz-izcr0nvnh.xmgwbn.com ([211.162.36.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18259 for ; Fri, 12 Jul 2002 18:47:33 -0400 (EDT) Date: Fri, 12 Jul 2002 18:47:33 -0400 (EDT) Message-Id: <200207122247.SAA18259@ietf.org> From: 88biz888<88biz888@163.com> To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [NSIS] ÓòÃû×¢²á Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org ×ð¾´µÄÐÂÀÏ¿Í»§£ºÄúºÃ! ÏÃÃÅÊÐӯͨԶº½µç×ӿƼ¼ÓÐÏÞ¹«Ë¾http://www.88biz.comÌṩÓòÃû×¢²á£¬ Ö÷»ú×âÓã¬Ö÷»úÍйܵȷþÎñ¡£½üÆÚÄÚ¹«Ë¾²úÆ·´ó´ÙÏúÀñ°üÒ»(200M HTML¿Õ¼ä + 1¸ö¹ú¼ÊÓòÃûÒ»ÄêÖ»Ðè150Ôª)¡£²É¹º¶à¶àÓŻݶà¶à¡£»¶Ó­´ó¼Ò¶©¹º»òÀ´µç 0592-8857840, ¸ºÔðÈË: СÔø ×Éѯ¡£ ÒÔÉÏÖ»ÊÇÁãÊÛ¼Û¸ñ¡£»¶Ó­Ñ¡¹º£¬Ò²»¶Ó­Äú³ÉΪÎÒÃǵĴúÀíÉÌ! ÎÒÃÇ»¹Óиü¶àµÄÀñ°üºÍÓŻݼ۸ñ£¬ÏêÇéÇë½ø http://www.88biz.com webmaster@88biz.com ÏÃÃÅÊÐӯͨԶº½µç×ӿƼ¼ÓÐÏÞ¹«Ë¾ --------------------------------------------------------------- ·ÐµãȺ·¢Óʼþ,À´×ÔÈí¼þ¹¤³Ìר¼ÒÍø(http://www.21cmm.com) ½øCMMÍøУ(http://www.21cmm.com)£¬³ÉÏîÄ¿¹ÜÀíר¼Ò _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sat Jul 13 00:14:50 2002 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 AAA28066 for ; Sat, 13 Jul 2002 00:14:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07454 for nsis-archive@odin.ietf.org; Sat, 13 Jul 2002 00:15:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06351; Sat, 13 Jul 2002 00:00:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06306 for ; Sat, 13 Jul 2002 00:00:49 -0400 (EDT) Received: from odin.ietf.org ([64.86.155.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27552 for ; Fri, 12 Jul 2002 23:59:48 -0400 (EDT) Message-Id: <200207130359.XAA27552@ietf.org> From: "Dr, Ibrahim Atiku" Date: Fri, 04 Jan 1980 02:48:31 To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Investment Business Deal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit FROM: Dr. Ibrahim Atiku CHIEF FINANCIAL DIRECTOR INDEPENDENT NATIONAL ELECTORAL COMMISSION (INEC) LAGOS – NIGERIA DATE: 9TH May 2002 ATTENTION THE MANAGING DIRECTOR/PRESIDENT. Sir, It is my warmest pleasure writing you this confidential business offer irrespective of the fact that we have not met before or done any thing that will re-impose absolute confidence but nevertheless, an adage says a day begins a story and it is in line of this strong perspective that I am very determined to communicate you with much conviction that you will give my proposal a second thought and consideration. As earlier stated I am Dr. Ibrahim Atiku a financial director working with Inec. My Agency is in charge of conducting all elections in my country Nigeria and by the virtue of my unique position in office as the Chief financial director. I was elevated by the commission to become the chairman of foreign contract tender board committee whose responsibility is to award and supervise foreign contract to ensure it is executed promptly. Consequently, I the chairman of the tender board committee in collaboration with two other top committee members over-invoice certain contract for the supply of electoral equipments needed for the forth-coming elections approaching around August 2002. The initial cost of the contract was pegged at US $ 50 million, but after the feasibility study was done, while submitting my report to the office of the presidency for final approval, we deliberately inflated the cost to an excess amount of US$ 30 million making the cost to be US$ 80 million. Right now, the gist of contacting you is we are constrained to claim the fund due to certain laws enacted by the government guiding civil service code of conduct Bureau which prohibits top civil servants working under Government establishment from operating offshore or foreign Account and this situation has kept us in a fix to openly come forward to claim the outstanding balance of US$ 30 million, hence after series of private meetings we decided to make contact in order to get a reliable foreign partner whom we will forward his or her credentials to claim the fund based on mutual trust and agreement. In a nutshell, we need your assistance and support to claim this fund so that at the later time convenient for us, we will come over to your country after the funds have been transferred to meet you and collect our own percentage while you will keep the rest as yours. For your support and total dedication to realize the objectives of this operation, you shall be entitled to 20% of the sum total while 80% of the fund belongs to the three officials involved in the deal. Note, you are vividly assured that you will not be subjected to any kind of risk for your support and involvement in this venture hence we have piloted a good strategy to ensure the operations goes smoothly of which we have targeted two weeks duration to accomplished our Aim. Kindly treat this matter Absolutely confidential because the officials involved are still in service and some of us intend to resign our appointment immediately after the transaction is finalized. I look forward to hearing positively from you while further details will be given as soon as I get your response. Best Regards Dr. Ibrahim Atiku _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sat Jul 13 08:21:42 2002 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 IAA21968 for ; Sat, 13 Jul 2002 08:21:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15978 for nsis-archive@odin.ietf.org; Sat, 13 Jul 2002 08:22:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15759; Sat, 13 Jul 2002 08:05:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15702 for ; Sat, 13 Jul 2002 08:05:26 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21639; Sat, 13 Jul 2002 08:04:28 -0400 (EDT) Message-ID: <001301c22a65$54f6a930$056015ac@T23KEMPF> From: "James Kempf" To: Cc: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65720@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Fri, 12 Jul 2002 11:04:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit That is more or less what I had in mind. The base CT protocol is independent of the particular applications in any event. jak ----- Original Message ----- From: To: Cc: ; Sent: Friday, July 12, 2002 3:40 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt > Hi James, > > > > The one step we could take (but not the one that was > > suggested) would > > > be to investigate into ensuring some commonality between > > the formats for > > > encapsulating the respective data chunks (i.e. context/NSIS > > parameters). > > > Or at least, provide for NSIS to carry CT data chunks and > > visa versa. > > > > > > > Right, that is in fact the kind of thing I had in mind. If > > you don't want to call it QoS context, call it "NSIS context". > > Just as an FYI, some folks are interest in looking into using > NSIS for various things, like QoS, NAT, & firewall traversal, > and so forth. For these cases, what parameters NSIS signals > are very much service/application specific. This is also > true with regards to Context Transfer. > > What I suggest is that NSIS and CT progress, and since there > is some overlap in the interest of both groups, we can > try to ensure that whatever solutions we work on do not > cause trouble for the different working groups. However, > I don't support tightly coupling the solutions. A much > better way would be that after CT & NSIS work is well > along, someone could make an applicability document of > combining both NSIS & CT into a solution for > particular deployments. > > br, > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jul 14 05:35:19 2002 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 FAA29851 for ; Sun, 14 Jul 2002 05:35:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12867 for nsis-archive@odin.ietf.org; Sun, 14 Jul 2002 05:36:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12168; Sun, 14 Jul 2002 05:22:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12136 for ; Sun, 14 Jul 2002 05:22:03 -0400 (EDT) Received: from hotmail.com (f180.pav2.hotmail.com [64.4.37.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29667 for ; Sun, 14 Jul 2002 05:21:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Jul 2002 02:21:32 -0700 Received: from 133.93.16.216 by pv2fd.pav2.hotmail.msn.com with HTTP; Sun, 14 Jul 2002 09:21:31 GMT X-Originating-IP: [133.93.16.216] From: "Sven Van den Bosch" To: Georgios.Karagiannis@eln.ericsson.se, brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Sun, 14 Jul 2002 11:21:31 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jul 2002 09:21:32.0055 (UTC) FILETIME=[D78F9A70:01C22B17] Subject: [NSIS] FW: list with all comments sent by me on list regarding requirements draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, I agree. Sven. >--------------------------------------------------------------------- > >Comment_9: Regarding open Issues 53, 59, 65 and 72 I propose that Sven >and myself try to propose some text that solves all these issues: >Sven do you agree? > >Marcus do you agree? Yes, I put this onto slides for Japan. _________________________________________________________________ Meld je aan bij de grootste e-mailservice ter wereld met MSN Hotmail: http://www.hotmail.com/nl _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Sun Jul 14 17:12:48 2002 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 RAA16871 for ; Sun, 14 Jul 2002 17:12:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06621 for nsis-archive@odin.ietf.org; Sun, 14 Jul 2002 17:13:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05196; Sun, 14 Jul 2002 16:57:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05165 for ; Sun, 14 Jul 2002 16:57:51 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16487 for ; Sun, 14 Jul 2002 16:56:49 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDJGY>; Sun, 14 Jul 2002 14:48:43 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203DAB@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Sarantis Paskalis Cc: nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Sun, 14 Jul 2002 14:48:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Sarantis, [snip] > > Yes, I was not clear. What I meant was that NSIS would > define the flow > specific treatment at the intermediate router to include > forwarding the > packets of a flow to the same interface, i.e. to follow a > "path". I am > not sure if this can be an NSIS requirement or not (to always > direct flow > specific traffic to the same interface if possible). > > My understanding from reading the draft is that this responsibility > is left to the "flow state management", i.e. NSIS in our case. [reh] I don't believe that it is in the remit of NSIS (a signalling protocol group) to define router forwarding behaviour. In particular, my main concern is about intermediate routers which are not NSIS-aware in the first place. > > > > > 2) The draft seems to encourage (SHOULD) a highly granular > > > assignment of flow labels (e.g. section 4 rules 3 & 4). On > > > the other hand, there may be good reasons to use the same > > > label for a sequence of 'microflows' (e.g. successive files > > > in a bulk ftp transfer; the same point has been made on the > > > v6 list). Encouraging this granularity directly increases the > > > signalling burden. How strong is SHOULD? > > > > > > I think, this is partially covered in Section 5, rule 1. > > > > > > Depending on the method semantics, multiple such > triplets MAY > > > identify the same flow state (e.g. SCTP flows with multiple > > > addresses at either end-points, or a diffserv > > > classifier with an > > > address range. > > > > > > This can be extended to cover the case for a "flowmask" in > > > which the first > > > say 15 bits identify the flow state, while the last 5 identify the > > > "microflow". > > [reh] that's a very natural idea. on the other hand, it > can't be defined on a case by case basis, since that section > is about allowing multiple (including presently unknown) flow > state establishment methods to co-exist. if you think > co-existence is important, any such flowmask method would (I > think) need to be defined in this draft (which is probably overkill). > > > > i don't think there's an easy answer to this question. > > I think it can be defined on a case-by-case basis based on > specific NSIS > signaling, i.e. an NSIS message defining the grouping of > several flowlabels > into one logical flow. > > By "flow state management methods" I thought something of > NSIS, RSVP, etc. > In these cases, I don't see any interference between > different flow state > management methods, if the flow label space of one is > independent from the > flow label space of the other. This is natural, since the application > (or any other entity) initiating a flow (possibly of multiple > microflows) > will choose to signal its requirements by only one signaling protocol. > The flow labels will be unique for that source address, so > the flow state > management at intermediate routers will not have to deal with > multiple flow > state management methods dealing with the same flow. [reh] the issue here is when the person managing the flow label space might not be the same person doing the signalling. The draft mentions one case (signalling initiated by flow receiver, penultimate paragraph of section 2), we are also interested in cases where the signalling could be initiated by intermediate nodes. > > > > In that case the draft states that: > > > > > > The flow state establishment method MUST > > > convey this classifying information to the IPv6 nodes > > > that need > > > to perform the classification. > > > > > > i.e. this should be a NSIS requirement. > > [reh] that is clear. > > There is a conflict with draft-ietf-nsis-req-03.txt, section > 5.5.5 (possibly > only naming conflict). In the flow-label draft, several > microflows with > different flow labels are treated as one flow, whereas in the > the nsis-req > draft, the microflows are treated as independent flows (and their > signaling is just grouped together for efficiency). [reh] There are two points here: 1) Rule (1) of section 5 seems ambiguous: does the flow state establishment method have to convey the grouping of triplets, or just the state in each triplet. In other words, does 'this classifying information' refer to just the first sentence in the rule, or the second as well. 2) If it does refer to both, I don't believe the requirement is enforceable (after all, packets for different triplets might follow different paths, and the idea of the same state for each probably isn't even meaningful - which is why the NSIS requirement is restricted the way it is). If it doesn't, there is no conflict. > > Regards, > > -- Sarantis > Robert H. ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jul 14 21:53:37 2002 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 VAA24798 for ; Sun, 14 Jul 2002 21:53:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07752 for nsis-archive@odin.ietf.org; Sun, 14 Jul 2002 21:54:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07217; Sun, 14 Jul 2002 21:38:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07183 for ; Sun, 14 Jul 2002 21:38:34 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24008 for ; Sun, 14 Jul 2002 21:37:36 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6F1axd18739 for ; Mon, 15 Jul 2002 04:36:59 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Jul 2002 04:38:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 04:38:31 +0300 content-class: urn:content-classes:message Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Jul 2002 04:38:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6573A@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] commentson on draft-ietf-nsis-req-03.txt Thread-Index: AcIpArSJYKMDSTiOSmiRLip0+0OTJACnC6ew To: , , Cc: X-OriginalArrivalTime: 15 Jul 2002 01:38:31.0695 (UTC) FILETIME=[5396D1F0:01C22BA0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA07188 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert & Marcus, Could you summize and condense the below into a reasonable proposal? I think there are some obvious views which NSIS will not be consider. thanks, John > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 11 July, 2002 20:45 > To: 'brunner@ccrle.nec.de'; Loughney John (NRC/Helsinki); > Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt > > > hi marcus, > > i've added a few refinements. we get up to 8 questions in all. > > some answers may be obvious to some people, but I don't think > any are obvious to everyone. > > robert h. > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: 11 July 2002 15:02 > > To: john.loughney@nokia.com; Hancock, Robert; > > Georgios.Karagiannis@eln.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt > > > > > > > > >> [Note: such a section could also define just what the on-path > > >> restriction actually was. I've seen at least 4 different > > >> incompatible views on that.] > > > > > > Want to provide a summary of the 4 views? > > > > Ok, I give it a try > > > > 1) exclusive on path > > The NSIS initiator and NSIS receiver are the data receiver > and sender > > > > 2) proxy on path > > The NSIS initiator is some where on the data path but not at > > the sending > > nor receiving side (only part of the data path is covered by > > signaling) > > > > 3) IP-hop-by-IP-hop > > The signaling message travels IP-hop-by-IP-hop. Where the > > hops are chosen > > by the destination addr > 3a) The signaling message travels IP-hop-by-IP-hop, but the > hop can be chosen on any fields in the IP header (of data > packet) or flow definition (in NSIS aware router), e.g. DSCP > and so on. Can be used to handle some load sharing/traffic > engineering issues, but not across NSIS-unaware clouds. > > > > > 4) NSIS-hop-by-NSIS-hop > > The signaling message follows NSIS hops, where intermediate > > IP hops are not > > visited. The NSIS hop has to choose the next hop, here the > > data path migh > > follow a different path for a shsort segment. > [to clarify?] the ends of the NSIS hop are on the data path, > but the middle may not be. the message is explicitly > addressed to the next NSIS hop. > > > > > 5) in advance reservation in hand-over cases > > If a new access router has been chosen, where a mobile will > > newly connect > > to and a reservation should be done in advance, the data > > flows still on the > > old path. At the point in time data is flowing along the new > > path (after > > handoff) the reservation has already been setup. > > 6) i've seen some claim that if a node sets up a tunnel > (obviously with a known endpoint) and then signals for the > tunnel, and also sends data and signalling through the > tunnel, this is 'morally equivalent' to off-path, in the > sense that you're no longer relying on the routing system to > recover from any non-end-system failures. > > 7) even if some messages are sent traditionally on-path as > per (3) [like RSVP PATH], are other messages allowed to go > off path and not be routed NSIS-hop by NSIS-hop [e.g. > acknowledgements, error notifications]? or should everything > go on-path? > > > > > Marcus > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 15 03:50:41 2002 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 DAA15559 for ; Mon, 15 Jul 2002 03:50:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05916 for nsis-archive@odin.ietf.org; Mon, 15 Jul 2002 03:51:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05290; Mon, 15 Jul 2002 03:35:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05227 for ; Mon, 15 Jul 2002 03:35:08 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15021; Mon, 15 Jul 2002 03:34:10 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 15 Jul 2002 09:33:51 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <38ZSFW8J>; Mon, 15 Jul 2002 09:34:26 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 15 Jul 2002 09:34:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA05228 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John, >>> The one step we could take (but not the one that was >>> suggested) would be to investigate into ensuring >>> some commonality between the formats for >>> encapsulating the respective data chunks (i.e. >>> context/NSIS parameters). Or at least, provide >>> for NSIS to carry CT data chunks and visa versa. > What I suggest is that NSIS and CT progress, and since there > is some overlap in the interest of both groups, we can > try to ensure that whatever solutions we work on do not > cause trouble for the different working groups. However, > I don't support tightly coupling the solutions. A much > better way would be that after CT & NSIS work is well > along, someone could make an applicability document of > combining both NSIS & CT into a solution for > particular deployments. Both points completely represent my expectations on a loose but useful cooperation of NSIS and SEAMOBY. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 15 10:36:21 2002 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 KAA06106 for ; Mon, 15 Jul 2002 10:36:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29636 for nsis-archive@odin.ietf.org; Mon, 15 Jul 2002 10:37:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28379; Mon, 15 Jul 2002 10:20:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28352 for ; Mon, 15 Jul 2002 10:20:25 -0400 (EDT) Received: from zeus.di.uoa.gr (zeus.di.uoa.gr [195.134.65.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05352 for ; Mon, 15 Jul 2002 10:19:29 -0400 (EDT) Received: from gallagher.di.uoa.gr (gallagher.di.uoa.gr [195.134.67.52]) by zeus.di.uoa.gr (8.12.3/8.12.3) with ESMTP id g6FEK7AV015142; Mon, 15 Jul 2002 17:20:09 +0300 (EEST) Received: from gallagher.di.uoa.gr (localhost [127.0.0.1]) by gallagher.di.uoa.gr (8.12.2/8.12.2) with ESMTP id g6FEKh5n014962; Mon, 15 Jul 2002 17:20:43 +0300 Received: (from sarantis@localhost) by gallagher.di.uoa.gr (8.12.2/8.12.2/Submit) id g6FEKWdv014951; Mon, 15 Jul 2002 17:20:32 +0300 Date: Mon, 15 Jul 2002 17:20:32 +0300 From: Sarantis Paskalis To: "Hancock, Robert" Cc: Sarantis Paskalis , nsis@ietf.org Subject: Re: [NSIS] IPv6 Flow Label Message-ID: <20020715142032.GB14853@gallagher.di.uoa.gr> References: <76C92FBBFB58D411AE760090271ED41805203DAB@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76C92FBBFB58D411AE760090271ED41805203DAB@rsys002a.roke.co.uk> User-Agent: Mutt/1.4i X-MailScanner: Found to be clean Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert, On Sun, Jul 14, 2002 at 02:48:43PM +0100, Hancock, Robert wrote: > [reh] I don't believe that it is in the remit of NSIS (a signalling protocol group) to define router forwarding behaviour. In particular, my main concern is about intermediate routers which are not NSIS-aware in the first place. I have no strong feelings about that. I also agree that forwarding behavior should be somewhat independent from the signaling protocol, ala RSVP. > [reh] the issue here is when the person managing the flow label space might not be the same person doing the signalling. The draft mentions one case (signalling initiated by flow receiver, penultimate paragraph of section 2), we are also interested in cases where the signalling could be initiated by intermediate nodes. The entity doing the signaling is responsible for the flow label(s) classification. In those cases, where the signaling is initiated by intermediate nodes, flows can either be identified by some preconfigured templates or through heuristics. In either case, the intermediate node initiating the signaling is responsible for the flow grouping and the "flow classification" information forwarding. > > There is a conflict with draft-ietf-nsis-req-03.txt, section > > 5.5.5 (possibly > > only naming conflict). In the flow-label draft, several > > microflows with > > different flow labels are treated as one flow, whereas in the > > the nsis-req > > draft, the microflows are treated as independent flows (and their > > signaling is just grouped together for efficiency). > [reh] There are two points here: > 1) Rule (1) of section 5 seems ambiguous: does the flow state establishment method have to convey the grouping of triplets, or just the state in each triplet. In other words, does 'this classifying information' refer to just the first sentence in the rule, or the second as well. > 2) If it does refer to both, I don't believe the requirement is enforceable (after all, packets for different triplets might follow different paths, and the idea of the same state for each probably isn't even meaningful - which is why the NSIS requirement is restricted the way it is). If it doesn't, there is no conflict. My understanding is that it refers to both. The argument about different path for packets with different triplets could apply to packets of the same triplet following different path (eg. due to load balancing). I think there are two orthogonal management problems. One is the flow _state_ management in each node, i.e policy, QoS enforcement, etc. The other is the flow label space management. The problem we are looking at is the latter. More specifically, I think we are looking at the possibility of propagating the logical grouping of several microflows that should be treated as one flow. Something like RSVP Wildcard filter, applied to flow labels. The argument about possible different path for packets of different triplets equally applies to packets of the same triplet. Packets with the same triplet are not guaranteed to follow the same path (as mentioned before). Actions for packets with the same flow label following a different path are also enforceple for packets with different flow labels, but in the same "flow" (as defined in draft-flow-label). > Robert H. -- Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 15 13:33:12 2002 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 NAA12269 for ; Mon, 15 Jul 2002 13:33:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29435 for nsis-archive@odin.ietf.org; Mon, 15 Jul 2002 13:34:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07441; Mon, 15 Jul 2002 13:18:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07373 for ; Mon, 15 Jul 2002 13:18:40 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11773 for ; Mon, 15 Jul 2002 13:17:43 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3QXQDKRT>; Mon, 15 Jul 2002 16:18:00 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203DED@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Sarantis Paskalis Cc: nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Mon, 15 Jul 2002 16:17:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi Sarantis, [for others still following - I think the upshot of this thread is that there is clearly another issue, about section 5 rule (1): *) it's ambiguously written *) on one interpretation, it contradicts NSIS requirements.] [snip] > > [reh] the issue here is when the person managing the flow > label space might not be the same person doing the > signalling. The draft mentions one case (signalling initiated > by flow receiver, penultimate paragraph of section 2), we are > also interested in cases where the signalling could be > initiated by intermediate nodes. > > The entity doing the signaling is responsible for the flow label(s) > classification. > > In those cases, where the signaling is initiated by > intermediate nodes, > flows can either be identified by some preconfigured > templates or through > heuristics. In either case, the intermediate node initiating > the signaling > is responsible for the flow grouping and the "flow classification" > information forwarding. [reh] right - so if those flow labels are allocated in this highly granular way and/or highly randomly, by a source which knows nothing about this signalling, these classification rules will be more complex (which was the original point). > > > [reh] There are two points here: > > 1) Rule (1) of section 5 seems ambiguous: does the flow > state establishment method have to convey the grouping of > triplets, or just the state in each triplet. In other words, > does 'this classifying information' refer to just the first > sentence in the rule, or the second as well. > > 2) If it does refer to both, I don't believe the > requirement is enforceable (after all, packets for different > triplets might follow different paths, and the idea of the > same state for each probably isn't even meaningful - which is > why the NSIS requirement is restricted the way it is). If it > doesn't, there is no conflict. > > My understanding is that it refers to both. [reh] ok this needs to be clarified. > The argument about different > path for packets with different triplets could apply to packets of the > same triplet following different path (eg. due to load balancing). [reh] true, the point of the original question (1) was whether this was trying to be ruled out at least for the single triplet case. > > I think there are two orthogonal management problems. One is the flow > _state_ management in each node, i.e policy, QoS enforcement, > etc. The > other is the flow label space management. The problem we are > looking at > is the latter. More specifically, I think we are looking at the > possibility of propagating the logical grouping of several microflows > that should be treated as one flow. Something like RSVP > Wildcard filter, > applied to flow labels. [reh] i think doing this at the triplet level where there is diverse routing (remember, they may all have different destination addresses) will be a huge source of complexity. is it really worth it? otherwise we are just talking about flow grouping as already in NSIS. > > > > Robert H. > > -- Sarantis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 15 21:03:16 2002 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 VAA22288 for ; Mon, 15 Jul 2002 21:03:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10064 for nsis-archive@odin.ietf.org; Mon, 15 Jul 2002 21:04:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08691; Mon, 15 Jul 2002 20:46:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08661 for ; Mon, 15 Jul 2002 20:46:26 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21581 for ; Mon, 15 Jul 2002 20:45:28 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g6G0kBD22371; Mon, 15 Jul 2002 17:46:11 -0700 (PDT) Received: from localhost (braden@localhost) by gra.isi.edu (8.8.7/8.8.6) with ESMTP id AAA19021; Tue, 16 Jul 2002 00:46:11 GMT X-Authentication-Warning: gra.isi.edu: braden owned process doing -bs Date: Mon, 15 Jul 2002 17:46:11 -0700 (PDT) From: Bob Braden To: john.loughney@nokia.com cc: robert.hancock@roke.co.uk, brunner@ccrle.nec.de, Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6573A@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > > > > > > 1) exclusive on path > > > The NSIS initiator and NSIS receiver are the data receiver > > and sender > > > The implication here is that signaling may follow any path as long as it ends on the data receiver node? This could be used when the signaling is strictly E2E, e.g., setting up a tunnel, with no intermediate NSIS nodes. But then it is simply a degenerate case of (4), isn't it? > > > 2) proxy on path > > > The NSIS initiator is some where on the data path but not at > > > the sending > > > nor receiving side (only part of the data path is covered by > > > signaling) I believe this is simply a case of where the signaling End points (what is being called Initiator and Terminator) are located. Whether it is an ES or a proxy should make no difference, and therefore (2) is not a distinct off path/on path case. > > > > > > 3) IP-hop-by-IP-hop > > > The signaling message travels IP-hop-by-IP-hop. Where the > > > hops are chosen > > > by the destination addr Well, by the destination address or whatever fields are being used to route the data. (I think RFC2205 was explicit about this, but it is an issue that kept coming up.) WHATEVER routing is done on the data, has to also be done on the signaling, in this case (If I understand your meaning.) > > 3a) The signaling message travels IP-hop-by-IP-hop, but the > > hop can be chosen on any fields in the IP header (of data > > packet) or flow definition (in NSIS aware router), e.g. DSCP > > and so on. Can be used to handle some load sharing/traffic > > engineering issues, but not across NSIS-unaware clouds. > > > > > > > > 4) NSIS-hop-by-NSIS-hop > > > The signaling message follows NSIS hops, where intermediate > > > IP hops are not > > > visited. The NSIS hop has to choose the next hop, here the > > > data path migh > > > follow a different path for a shsort segment. > > [to clarify?] the ends of the NSIS hop are on the data path, > > but the middle may not be. the message is explicitly > > addressed to the next NSIS hop. > > A non-NSIS hop presumably is not setting up any state in that node, so I would say that (4) is not really different from (3). They are both what I called "path-directed" signaling. > > > > > > 5) in advance reservation in hand-over cases > > > If a new access router has been chosen, where a mobile will > > > newly connect > > > to and a reservation should be done in advance, the data > > > flows still on the > > > old path. At the point in time data is flowing along the new > > > path (after > > > handoff) the reservation has already been setup. > > This is a special case that probably has to be handled for the mobile case, but it would not by itself violate the general principle of on-path signaling. > > 6) i've seen some claim that if a node sets up a tunnel > > (obviously with a known endpoint) and then signals for the > > tunnel, and also sends data and signalling through the > > tunnel, this is 'morally equivalent' to off-path, in the > > sense that you're no longer relying on the routing system to > > recover from any non-end-system failures. > > > > 7) even if some messages are sent traditionally on-path as > > per (3) [like RSVP PATH], are other messages allowed to go > > off path and not be routed NSIS-hop by NSIS-hop [e.g. > > acknowledgements, error notifications]? or should everything > > go on-path? > > Again, a detail that does not violate the principle of path-directed signaling. Bob Braden > > > > > > Marcus > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > > ============================================================== > > ========================== > > Permission is hereby granted to pass the contents of this > > communication to third parties and any restrictions regarding > > confidentiality do not apply. > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Jul 16 10:49:19 2002 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 KAA21014 for ; Tue, 16 Jul 2002 10:49:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01820 for nsis-archive@odin.ietf.org; Tue, 16 Jul 2002 10:50:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00455; Tue, 16 Jul 2002 10:29:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00422 for ; Tue, 16 Jul 2002 10:29:26 -0400 (EDT) Received: from entcl9.et.tu-dresden.de (entcl2.et.tu-dresden.de [141.30.128.192]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20407 for ; Tue, 16 Jul 2002 10:28:27 -0400 (EDT) Received: (from root@localhost) by entcl9.et.tu-dresden.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id g6GEcKv04361; Tue, 16 Jul 2002 16:38:20 +0200 Date: Tue, 16 Jul 2002 16:38:20 +0200 Message-Id: <200207161438.g6GEcKv04361@entcl9.et.tu-dresden.de> To: nsis@ietf.org From: itc18tcp@ifn.et.tu-dresden.de Subject: [NSIS] ITC 18 - Call for papers Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Our apologies for receiving multiple copies of this email.. CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS +-----------------------------------------------+ | 18th International TELETRAFFIC CONGRESS | | Haus am Köllnischen Park, Berlin, Germany | | 31 August - 5 September 2003 | | | | "Providing QoS in Heterogeneous Environments" | | http://www.ITC18.org | +-----------------------------------------------+ CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS ORGANIZATIONS AND HISTORY International Advisory Committee http://www.i-teletraffic.org/ ITG - Information Technology Society in the VDE http://www.vde.com/vde/html/e/fach/itg/itg.htm The ITC, founded in 1955, provides, through regular, now bi-annual congresses, the main international forum for teletraffic research and engineering. The purpose of the ITC is to stimulate the development and application of teletraffic theory for planning, engineering, managing and administrating telecommunication networks. The analysis and control of traffic phenomena in such networks require measurements, forecasts, as well as network management algorithms. The ITC gathers teletraffic experts from research organizations, universities, manufacturers, network operators and international technical organizations yielding a well-balanced contribution from theory and application. ITCs are organized so that researchers, engineers, and administrators from telcos and data network operators can interact and benefit from discussions and exchange of ideas. The ITC also benefits from the social environment which allows for the creation of new personal contacts between delegates. CONFERENCE CITY After 33 years, the ITC community meets again in Germany - in Berlin, the old and new capital, a four million people meeting place of the East and the West in the center of Europe. Berlin is a city in transition, one that is not always easy to understand, and which is often quite difficult to describe. However, no other city of Germany reflects the historical events of the last few years to the extent Berlin does. More information: http://www.berlin.de/english CONFERENCE VENUE Close to the river Spree in the center of Berlin, the "Haus am Köllnischen Park"is located just a few minutes walking distance from famous places such as Alexanderplatz, Humboldt University, Gendarmenmarkt, Reichstag or Brandenburger Tor. "PROVIDING QOS IN HETEROGENEOUS EINVIRONMENTS" The ITC 18 will be held in a transient phase where IP packet-switched architectures migrate from being data networks only to also substituting traditional circuit-switched networks. Papers are welcome tackling the following topics: NETWORK ARCHITECTURES AND TECHNOLOGIES - Next generation networks - Broadband transport networks - Access networks - Wireless networks and wireless LANs - Heterogeneous networks and ubiquitous communication - Web technologies - Voice over IP - Ad hoc and peer to peer networking - Communication protocols TRAFFIC CONTROL AND ENGINEERING - Traffic engineering - Quality of service provisioning - Service pricing - Overload control - Traffic management - QoS in multi-provider networks - Service-aware admission control - Traffic conditioning - Routing - Mobility management and signalling - Network planning and optimization - Network management - Reliability and Survivability METHODS AND TOOLS - Traffic characterization and modelling - Performance evaluation - Queueing theory - Scheduling - Simulation methodology - Traffic and performance measurements IMPORTANT DATES Full paper due : 31 December 2002 Notification of acceptance mailed: 16 April 2003 Camera ready paper due : 1 June 2003 SUBMISSION OF PAPERS Papers should not exceed 15 double-spaced pages (about 5000 words), have an abstract of 100-200 words, and be original material not previously published. The title page should contain the authors' names, affiliation and contact details. The corresponding author must be indicated. Only electronic submission via the ITC18 homepage will be arranged. Further information can be obtained on the ITC18 homepage via http://www.ITC18.org. CONFERENCE ORGANIZATION AND CONTACT ADDRESS ITC 18 VDE Conference Services Stresemannallee 15 D-60596 Frankfurt/Main, Germany Phone: +49 69 6308-202 Fax : +49 69 9631-5213 email: vde-conferences@vde.com COMMITTEES EXECUTIVE COMMITTEE Chair : Joachim Claus, Deutsche Telekom AG, Bonn Secretariat : Volker Schanz, ITG/VDE, Frankfurt Conference Office: Rupert Rompel, VDE, Frankfurt TECHNICAL PROGRAMME COMMITTEE Chairs: Joachim Charzinski, Siemens, Munich Ralf Lehnert, Dresden University of Technology Phuoc Tran-Gia, University of Würzburg Carmelita Görg, University of Bremen (Tutorials Chair) INTERNATIONAL TPC NATIONAL TPC Marco Ajmone Marsan, Italy Dieter Baum, University of Trier Åke Arvidsson, Sweden Matthias Baumann, Dresden University of Technology Khalid Begain, United Kingdom Gunter Bolch, University of Erlangen-Nuremberg Chris Blondia, Belgium Andreas Brandt, Humboldt University Onno Boxma, The Netherlands Joachim Charzinski, Siemens AG Herwig Bruneel, Belgium Jörg Eberspächer, Munich University of Technology Olga Casals, Spain Anja Feldmann, Saarland University Laurie Cuthbert, United Kingdom Wolfgang Fischer, Cisco GmbH Hermann de Meer, United Kingdom Carmelita Görg, University of Bremen Edmundo de Souza e Silva, Brazil Franz Hartleb, T-Systems GmbH Zbigniew Dziong, USA Boudewijn Haverkort, Aachen University of Technology Khaled Elsayed, Egypt Christoph Herrmann, Philips Research Peder Emstad, Norway Ulrich Killat, Technical University of Hamburg-Harburg David Everitt, Australia Udo Krieger, T-Systems GmbH Serge Fdida, France Paul J. Kühn, University of Stuttgart Georges Fiche, France Ralf Lehnert, Dresden University of Technology Markus Fiedler, Sweden Georg Rößler, Tenovis GmbH&Co. KG Luigi Fratta, Italy Stefan Schneeberger, Siemens AG H. Richard Gail, USA Hans-Peter Schwefel, Siemens AG Richard Harris, Australia Michael Söllner, Lucent Technologies GmbH Frank Hübner-Szabo de Bucs, USA Michael Tangemann, Alcatel AG Villy Baek Iversen, Denmark Sandra Tartarelli, NEC GmbH Konosuke Kawashima, Japan Phuoc Tran-Gia, University of Würzburg Peter Key, United Kingdom Kurt Tutschku, University of Würzburg Daniel Kofman, USA Bernhard Walke, Aachen University of Technology Yonathan Levy, USA Ulrich Wellens, Vodafone GmbH Xiong Jiang Liang, China Albert Weller, T-Mobile GmbH Karl Lindberger, Sweden Adam Wolisz, Berlin University of Technology Michel Mandjes, The Netherlands Martina Zitterbart, University of Karlsruhe Ian Marshall, United Kingdom Debasis Mitra, USA Sandor Molnár, Hungary Jorge Moreira de Souza, Brazil Arne A. Nilsson, USA Ilkka Norros, Finland Baron Peterssen, South Africa Michal Pioro, Poland Jim Roberts, France Matthew Roughan, USA Hiroshi Saito, Japan Shohei Sato, Japan Danny Tsang, Hong Kong Hans van den Berg, The Netherlands Rob van der Mei, The Netherlands Manuel Villen-Altamirano, Spain Jorma Virtamo, Finland Y.T. Wang, USA Pat Wirth, USA Jim Yan, Canada Hideaki Yoshino, Japan Moshe Zukerman, Australia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 16 11:06:02 2002 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 LAA21299 for ; Tue, 16 Jul 2002 11:06:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02712 for nsis-archive@odin.ietf.org; Tue, 16 Jul 2002 11:06:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01752; Tue, 16 Jul 2002 10:46:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01721 for ; Tue, 16 Jul 2002 10:46:48 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20968 for ; Tue, 16 Jul 2002 10:45:51 -0400 (EDT) Received: from ccrle.nec.de (PRAK.dyn.ietf54.wide.ad.jp [133.93.79.94]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6GEkju10887 for ; Tue, 16 Jul 2002 23:46:45 +0900 (JST) Message-ID: <3D3431B3.6090707@ccrle.nec.de> Date: Tue, 16 Jul 2002 23:46:11 +0900 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] requirements derived from the resilience draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Based on the resilience draft (draft-vandenboesch-nsis-resilience-00.txt) we propose to change one requirement and add two new requirements. Please comment. Change of existing requirement ------------------------------- 5.3.3 Notifications to the QoS Initiator QoS Controllers should be able to notify the QoS Initiator, if there is a state change inside the network. There are various types of network changes for instance among them: Recoverable errors: the network nodes can locally repair this type error. The network nodes do not have to notify the users of the error immediately. This is a condition when the danger of degradation (or actual short term degradation) of the provided QoS was overcome by the network (QoS controller) itself. Unrecoverable errors: the network nodes cannot handle this type of error, and have to notify the users as soon as possible. QoS degradation/severe congestion: In case the service can not provided completely but partially only. Repair indication: If an error occurred an has been fixed, this trigger the sending of a notification. Service upgrade available: If a previously requested better service becomes available. The content of the notification is very service specific, but it is must at least carry type information. Additionally, it may carry the location of the state change. The notifications may or may not be in response to a NSIS message. This means an NSIS entity has to be able to handle notifications at any time. Note however, that there are a number of security consideration need to be solved with notification, even more important if the notification is sent without prior request. The problem basically is, that every body could send notifications to any NSIS entity and the NSIS entity most likely react on the notification. E.g., if it gets a error notification it might teardown the reservation, even if everything is ok. So the notification might depend on security associations between the sender of the notification and its receiver. If a hop-by-hop security mechanism is chosen, this implies also that notifications need to be sent on the reverse path. New requirements: ------------------- 5.11.4 Graceful handling of NSIS entity problems NSIS entities might have some problems different from the communication layer. For instance, corruption of protocol engine due to buffer overflows or engine overload. NSIS peers should be able to detect the malfunctioning peer. It may notify the QoS Initiator or it may handle the problem itself e.g. switching to a backup NSIS entity. In the latter case note that synchronization of state between the primary and the backup entity is needed. 5.11.3 Robustness against unexpected situations An NSIS protocol must define behaviour of NSIS signaling units during unexpected situations. Unexpected situtions are for example unknown messages, parameters, and parameter settings, as well as receiption of unexpected messages (e.g. a "Reservation Confirmation" without prior "Reservation Request"). Kind regards, Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 16 19:35:05 2002 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 TAA02783 for ; Tue, 16 Jul 2002 19:35:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28876 for nsis-archive@odin.ietf.org; Tue, 16 Jul 2002 19:36:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27716; Tue, 16 Jul 2002 19:19:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27687 for ; Tue, 16 Jul 2002 19:19:02 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02369 for ; Tue, 16 Jul 2002 19:18:05 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g6GNMVSR008970; Tue, 16 Jul 2002 18:22:31 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g6GNHQS29801; Tue, 16 Jul 2002 18:17:32 -0500 (CDT) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id <3XD42T2Y>; Tue, 16 Jul 2002 18:18:32 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BB87@trimail2> From: "Schneider, Marco" To: "'Hancock, Robert'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing Date: Tue, 16 Jul 2002 18:18:31 -0500 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I see another alternative to route recording: In response to NSIS signaling, routers install state that causes future signaling to follow the same path. This could be made explicit by a field in the protocol. The routers would also need to install state that caused the signaled flow to continue to follow this path as well. In the case of link failure along the existing path, a release may be necessary followed by reinitiation of the reservation. If intermediate routers are not NSIS aware there may be other issues with this approach. Requirements on NSIS: possibly a bit to make this option explict and ...? Marco -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Wednesday, July 10, 2002 6:05 PM To: sven.van_den_bosch@alcatel.be Cc: Schneider, Marco; nsis@ietf.org Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing hi sven, a belated reply: [snip] > > In fact, whether the path is determined by normal L3 routing > or abnormal > routing or any other mechanism is rather a second order problem. The > fundamental aspect is that NSIS (I assume) has no role in > determining that > path, it takes the path as given and has to live with it. > > [Sven] Would it be possible for NSIS to record the path it > has been given > at setup time and express its requirement to stay on it? [reh] OK, this is an interesting prospect, depending on 'who' NSIS should express this requirement to. Saying that NSIS should be able to do route recording and then feed this information into resource management is a requirement I can understand. (I'm not saying if I agree with it or not. It almost certainly isn't in the requirements draft at the moment.) > > What would be helpful for me would be if someone could give > an example of > how the _flow_ (not the signalling) is going to get > restricted to the old > path. Then we could see if any special tricks would be needed > to make NSIS > work after this had been done. At the moment, I can't see > what they would > be. > > [Sven] Suppose a single route towards a destination is > announced and later > on another route towards that destination is announced with a QoS > attribute. Then the flow could remain on that route, although a new > (best-effort) route becomes available. Would that be a valid example? [reh] what does 'announced' mean really? i guess it means that routers end up with forwarding entries that enable the route to be followed hop by hop in the 'right' way. well, they're available for the signalling messages as well - there's no new requirement on NSIS in this case, so far as I can see. cf. 4.1 of our framework document: "NSIS needs to know ... how to select the outgoing interface for a signaling message, in case this needs to match the interface that will be used by the corresponding flow. This might be as simple as just allowing the IP layer to handle the message using its own routing table." [Or, it might not.] We needed that even before talking about route pinning, and I'm not sure what more could be required; doing it right is an implementation issue between NSIS and the router's forwarding engine. see you in japan, robert. > > Cheers, > > Robert H. > > PS I'm sure that a topology aware system could do some sort of traffic > engineering by setting up tunnels and so on. Whether this is > a good thing > to do I make no comment on; but I don't see what additional > requirements > would be needed to make NSIS work in such an environment. In > any case, I > get the feeling there's a danger that we're trying to use > NSIS to recreate > MPLS on the IP layer. One MPLS is enough for me... > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: 09 July 2002 08:51 > > To: Hancock, Robert > > Cc: 'Schneider, Marco'; nsis@ietf.org > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > Hi Robert, Marco, > > > > I am not sure that NSIS has nothing to do with the fix of > the problem > > described by Marco. If you have the capability to do routing of this > > displaced flow in a non-traditional way, then wouldn't you > > like NSIS not to > > tear down the existing reservations (I assume in your example > > you would > > have the reservations taken down, then start new NSIS > > signalling indicating > > the 'non-traditional' path) while you updating the > > signalling? Of course, > > if you want to support such a function you would need to be > > sure that the > > old path is still available. This requires the ability to > distinguish > > between a failure on the old path and the availability of a > new path. > > > > CU, > > Sven. > > > > > > > > > > > > "Hancock, Robert" @ietf.org on 09/07/2002 > > 09:35:34 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: "'Schneider, Marco'" , nsis@ietf.org > > cc: > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > Independence > > ofexisting flow reservations and default routing > > > > > > Hi Marco, > > > > I think I understand your concerns and your example. I'm > > still not sure it > > translates into an NSIS requirement. > > > > To paraphrase (I hope correctly) your example as you describe it: > > 1. You have a flow which is taking a certain path through > the network. > > 1a. NSIS messages are following that path, and reserving > > resources for it. > > Because there are enough resources on the particular path, > > the reservation > > is successful. > > 2. Someone adds a new link to the network, which changes the path in > > question. The new path is incapable of carrying the flow. > > 3. The reservation is routed along the new path. It's > > rejected (too little > > capacity) and all reservations associated with it are dropped. > > > > Clearly, that's undesirable. However, the problem is not > with the NSIS > > signalling, so NSIS can't fix it: At point (2), if you are > in a normal > > connectionless network, the flow will also be routed along > > the new path. > > NSIS is just (correctly) reflecting the fact that routing > > hasn't found the > > real 'best' route through the network. > > > > In other words, the real solution to the problem has to > come from some > > routing trick which keeps the flow on the old path, and we > referred to > > things in this class as 'non-traditional L3 routing' . If you > > can find a > > method to do this, then we want NSIS to continue to work if > > you are using > > it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or > > impossible is another question, but that seems to be the > requirement.) > > > > Cheers, > > > > Robert H. > > > > > -----Original Message----- > > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > > Sent: 08 July 2002 20:04 > > > To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de; nsis@ietf.org > > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > > Independence > > > ofexisting flow reservations and default routing > > > > > > > > > John, > > > > > > As per my response to Marcus: I raised my concerns during the > > > meeting and > > > was asked to post an example, which I did. > > > > > > As for the text, I guess it is not clear to me whether this > > > addresses the > > > issue. In my opinion the example I gave does not have > > > anything to do with > > > non-traditional L3 routing. > > > > > > Marco > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: Monday, June 10, 2002 8:29 AM > > > > To: brunner@ccrle.nec.de; Schneider, Marco; nsis@ietf.org > > > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: > > > > Independence > > > > ofexisting flow reservations and default routing > > > > > > > > > > > > Hi Marco & Marcus, > > > > > We discussed the issue of route pinning and traffic > > > engineering in > > > > > Helsinki. The conclusion during the meeting was that we > > > > want to add an > > > > > assuption saying: NSIS assumes normal/standard L3 routing > > > > > > > > > > Plus we add a requirement saying that NSIS protocol should > > > > not be broken by > > > > > networks which do non-traditional L3 routing. > > > > > > > > > > Does this cover your concern? Do we really need to add that > > > > NSIS must work > > > > > with default routing changes? > > > > > > > > I agree with Marcus that this is what we are trying to say. > > > > Marco, is this > > > > text OK with you? > > > > > > > > John > > > > ============================================================================ ============ Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 16 21:04:32 2002 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 VAA05816 for ; Tue, 16 Jul 2002 21:04:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04651 for nsis-archive@odin.ietf.org; Tue, 16 Jul 2002 21:05:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03402; Tue, 16 Jul 2002 20:51:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03373 for ; Tue, 16 Jul 2002 20:51:22 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.203.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05413 for ; Tue, 16 Jul 2002 20:50:24 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 01:51:15 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41805203E36@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Marcus Brunner , nsis@ietf.org Subject: RE: [NSIS] requirements derived from the resilience draft Date: Wed, 17 Jul 2002 01:51:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi marcus, 5.3.3 i would comment that it might be desirable to send these notifications to anyone upstream (not just to the initiator). no concerned about the rest of the text. 5.11.4 surely an NSIS entity can only determine whether the protocol is operating correctly or not. whether that's due to communications problems or internal failure is not an important distinction. is this really a requirement for NSIS to have a failover capability in the protocol? robert. > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 16 July 2002 23:46 > To: nsis@ietf.org > Subject: [NSIS] requirements derived from the resilience draft > > > Based on the resilience draft > (draft-vandenboesch-nsis-resilience-00.txt) we propose to change one > requirement and add two new requirements. Please comment. > > Change of existing requirement > ------------------------------- > > 5.3.3 Notifications to the QoS Initiator > > QoS Controllers should be able to notify the QoS Initiator, > if there is > a state change inside the network. There are various types of network > changes for instance among them: > > Recoverable errors: the network nodes can locally repair this type > error. The network nodes do not have to notify the users of the error > immediately. This is a condition when the danger of degradation (or > actual short term degradation) of the provided QoS was > overcome by the > network (QoS controller) itself. > > Unrecoverable errors: the network nodes cannot handle this type of > error, and have to notify the users as soon as possible. > > QoS degradation/severe congestion: In case the service can > not provided > completely but partially only. > > Repair indication: If an error occurred an has been fixed, > this trigger > the sending of a notification. > > Service upgrade available: If a previously requested better service > becomes available. > > The content of the notification is very service specific, but > it is must > at least carry type information. Additionally, it may carry > the location > of the state change. > > The notifications may or may not be in response to a NSIS > message. This > means an NSIS entity has to be able to handle notifications > at any time. > > Note however, that there are a number of security > consideration need to > be solved with notification, even more important if the > notification is > sent without prior request. The problem basically is, that every body > could send notifications to any NSIS entity and the NSIS entity most > likely react on the notification. E.g., if it gets a error > notification > it might teardown the reservation, even if everything is ok. So the > notification might depend on security associations between > the sender of > the notification and its receiver. If a hop-by-hop security > mechanism is > chosen, this implies also that notifications need to be sent on the > reverse path. > > New requirements: > ------------------- > > 5.11.4 Graceful handling of NSIS entity problems > > NSIS entities might have some problems different from the > communication > layer. For instance, corruption of protocol engine due to buffer > overflows or engine overload. NSIS peers should be able to detect the > malfunctioning peer. It may notify the QoS Initiator or it may handle > the problem itself e.g. switching to a backup NSIS entity. In > the latter > case note that synchronization of state between the primary and the > backup entity is needed. > > 5.11.3 Robustness against unexpected situations > > An NSIS protocol must define behaviour of NSIS signaling units during > unexpected situations. Unexpected situtions are for example unknown > messages, parameters, and parameter settings, as well as > receiption of > unexpected messages (e.g. a "Reservation Confirmation" without prior > "Reservation Request"). > > Kind regards, > > Marcus > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 16 23:09:45 2002 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 XAA10083 for ; Tue, 16 Jul 2002 23:09:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA12681 for nsis-archive@odin.ietf.org; Tue, 16 Jul 2002 23:10:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11648; Tue, 16 Jul 2002 22:56:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11618 for ; Tue, 16 Jul 2002 22:56:57 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09748 for ; Tue, 16 Jul 2002 22:55:57 -0400 (EDT) Received: from ccrle.nec.de (PRAK.dyn.ietf54.wide.ad.jp [133.93.79.94]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H2upu12988; Wed, 17 Jul 2002 11:56:51 +0900 (JST) Message-ID: <3D34DCCF.5050804@ccrle.nec.de> Date: Wed, 17 Jul 2002 11:56:15 +0900 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] requirements derived from the resilience draft References: <76C92FBBFB58D411AE760090271ED41805203E36@rsys002a.roke.co.uk> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Robert, Concerning 5.3.3: what controller do you want to send it to? Do you have an example where notofication to a controller is needed? And note that due to security considerations, notifications might travel aloang the reverse path NSIS-hop-by-NSIS-hop anyway. Concerning 5.11.4: I am not sure whether you need a failover mechanism to suport the requirement. And you can regard it sort of a motherhood req. Marcus Hancock, Robert wrote: >hi marcus, > >5.3.3 i would comment that it might be desirable to send these notifications to anyone upstream (not just to the initiator). no concerned about the rest of the text. > >5.11.4 surely an NSIS entity can only determine whether the protocol is operating correctly or not. whether that's due to communications problems or internal failure is not an important distinction. is this really a requirement for NSIS to have a failover capability in the protocol? > >robert. > >>-----Original Message----- >>From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >>Sent: 16 July 2002 23:46 >>To: nsis@ietf.org >>Subject: [NSIS] requirements derived from the resilience draft >> >> >>Based on the resilience draft >>(draft-vandenboesch-nsis-resilience-00.txt) we propose to change one >>requirement and add two new requirements. Please comment. >> >>Change of existing requirement >>------------------------------- >> >>5.3.3 Notifications to the QoS Initiator >> >>QoS Controllers should be able to notify the QoS Initiator, >>if there is >>a state change inside the network. There are various types of network >>changes for instance among them: >> >>Recoverable errors: the network nodes can locally repair this type >>error. The network nodes do not have to notify the users of the error >>immediately. This is a condition when the danger of degradation (or >>actual short term degradation) of the provided QoS was >>overcome by the >>network (QoS controller) itself. >> >>Unrecoverable errors: the network nodes cannot handle this type of >>error, and have to notify the users as soon as possible. >> >>QoS degradation/severe congestion: In case the service can >>not provided >>completely but partially only. >> >>Repair indication: If an error occurred an has been fixed, >>this trigger >>the sending of a notification. >> >>Service upgrade available: If a previously requested better service >>becomes available. >> >>The content of the notification is very service specific, but >>it is must >>at least carry type information. Additionally, it may carry >>the location >>of the state change. >> >>The notifications may or may not be in response to a NSIS >>message. This >>means an NSIS entity has to be able to handle notifications >>at any time. >> >>Note however, that there are a number of security >>consideration need to >>be solved with notification, even more important if the >>notification is >>sent without prior request. The problem basically is, that every body >>could send notifications to any NSIS entity and the NSIS entity most >>likely react on the notification. E.g., if it gets a error >>notification >>it might teardown the reservation, even if everything is ok. So the >>notification might depend on security associations between >>the sender of >>the notification and its receiver. If a hop-by-hop security >>mechanism is >>chosen, this implies also that notifications need to be sent on the >>reverse path. >> >>New requirements: >>------------------- >> >>5.11.4 Graceful handling of NSIS entity problems >> >>NSIS entities might have some problems different from the >>communication >>layer. For instance, corruption of protocol engine due to buffer >>overflows or engine overload. NSIS peers should be able to detect the >>malfunctioning peer. It may notify the QoS Initiator or it may handle >>the problem itself e.g. switching to a backup NSIS entity. In >>the latter >>case note that synchronization of state between the primary and the >>backup entity is needed. >> >>5.11.3 Robustness against unexpected situations >> >>An NSIS protocol must define behaviour of NSIS signaling units during >>unexpected situations. Unexpected situtions are for example unknown >>messages, parameters, and parameter settings, as well as >>receiption of >>unexpected messages (e.g. a "Reservation Confirmation" without prior >>"Reservation Request"). >> >>Kind regards, >> >>Marcus >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >======================================================================================== >Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. > > >------------------------------------------------------------------------ > >The information contained in this e-mail and any attachments is confidential to Roke >Manor Research Ltd and must not be passed to any third party without permission. This >communication is for information only and shall not create or change any contractual >relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 17 09:59:15 2002 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 JAA16786 for ; Wed, 17 Jul 2002 09:59:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11259 for nsis-archive@odin.ietf.org; Wed, 17 Jul 2002 10:00:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09851; Wed, 17 Jul 2002 09:41:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09821 for ; Wed, 17 Jul 2002 09:41:37 -0400 (EDT) Received: from zeus.di.uoa.gr (zeus.di.uoa.gr [195.134.65.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16240 for ; Wed, 17 Jul 2002 09:40:37 -0400 (EDT) Received: from gallagher.di.uoa.gr (gallagher.di.uoa.gr [195.134.67.52]) by zeus.di.uoa.gr (8.12.3/8.12.3) with ESMTP id g6HDfEAV021338; Wed, 17 Jul 2002 16:41:22 +0300 (EEST) Received: from gallagher.di.uoa.gr (localhost [127.0.0.1]) by gallagher.di.uoa.gr (8.12.2/8.12.2) with ESMTP id g6HDfU5n018707; Wed, 17 Jul 2002 16:41:30 +0300 Received: (from sarantis@localhost) by gallagher.di.uoa.gr (8.12.2/8.12.2/Submit) id g6HDfUei018705; Wed, 17 Jul 2002 16:41:30 +0300 Date: Wed, 17 Jul 2002 16:41:30 +0300 From: Sarantis Paskalis To: "Hancock, Robert" Cc: Sarantis Paskalis , nsis@ietf.org Subject: Re: [NSIS] IPv6 Flow Label Message-ID: <20020717134130.GA18692@gallagher.di.uoa.gr> References: <76C92FBBFB58D411AE760090271ED41805203DED@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76C92FBBFB58D411AE760090271ED41805203DED@rsys002a.roke.co.uk> User-Agent: Mutt/1.4i X-MailScanner: Found to be clean Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert, On Mon, Jul 15, 2002 at 04:17:51PM +0100, Hancock, Robert wrote: > hi Sarantis, > > [for others still following - I think the upshot of this thread is that there is clearly another issue, about section 5 rule (1): > *) it's ambiguously written > *) on one interpretation, it contradicts NSIS requirements.] Correct. > [reh] right - so if those flow labels are allocated in this highly granular way and/or highly randomly, by a source which knows nothing about this signalling, these classification rules will be more complex (which was the original point). If the signaling is initiated at some intermediate nodes, it would be indeed a very difficult task to group different triplets together to one state. Especially since the intermediate node has no information about how the flow labels should be grouped. In that case, heuristics obviously fail. Other possible scenarios would be to ignore the flow label and only take into accound source and destination address fields for grouping purposes or hardcode the necessary values to the signaling initiating node. In either case, the signaling initiating node has no information about the flow label to actual flow correspondence. Any action it performs is an effort to guess the flow initiator's intentions, and that is also valid for single triplet flows. If the signaling is initiated at the endpoints, however, there are some obvious benefits from flow label distribution and signaling interworking. > > I think there are two orthogonal management problems. One is the flow > > _state_ management in each node, i.e policy, QoS enforcement, > > etc. The > > other is the flow label space management. The problem we are > > looking at > > is the latter. More specifically, I think we are looking at the > > possibility of propagating the logical grouping of several microflows > > that should be treated as one flow. Something like RSVP > > Wildcard filter, > > applied to flow labels. > > [reh] i think doing this at the triplet level where there is diverse routing (remember, they may all have different destination addresses) will be a huge source of complexity. is it really worth it? otherwise we are just talking about flow grouping as already in NSIS. How can flow labels denoting the same flow have different destination addresses? I thought we were talking about same source and destination addresses, but different flow labels for the same flow. In case of different destination address, we have different flows by definition. If you meant diverse routing for different triplets (i.e. different flow labels), there could always be diverse routing for the same triplet. In other words, the problem space of the flows with the same triplet is the same as the one of the flows with different triplets. > Robert H. -- Sarantis -- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 17 14:44:13 2002 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 OAA26511 for ; Wed, 17 Jul 2002 14:44:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22573 for nsis-archive@odin.ietf.org; Wed, 17 Jul 2002 14:45:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19833; Wed, 17 Jul 2002 14:22:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19802 for ; Wed, 17 Jul 2002 14:22:08 -0400 (EDT) Received: from odin.ietf.org ([64.86.155.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25717 for ; Wed, 17 Jul 2002 14:21:06 -0400 (EDT) Message-Id: <200207171821.OAA25717@ietf.org> From: "MR. WILLIAM DURU" Date: Wed, 17 Jul 2002 07:48:48 To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] GOOD DAY FROM MR. WILLIAM DURU Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit CHALLENGE SECURITIES LTD. LAGOS, NIGERIA phone:234-803-3004455. ATTENTION:SIR/MADAM I am MR. WILLIAM DURU, the Director of Operations CHALLENGE SECURITIES LTD,LAGOS NIGERIA. Here in NIGERIA Our firm is a security company of high repute with years of outstanding service to the people of Africa. I have resolved to contact you through this medium based on business proposal that will be of mutual benefit to both of us. I got your particulars through a consultant company base on my research for a trustworthy and established person that understands investment ethic for entering into a life time profitable joint partnership investment and also co-operation with confidence and trust that you will keep the contents secret and divulged to any third party. To be explicit and straight to the point. Some time early 1997, a reputable client of ours deposited a consignment in our company\'s vault for safe keeping. And since then our client has failed to come forward to claim his consignment, which has accumulated a considerable amount of money in demurrage. Consequently, in our bide to contact this client to redeem the demurrage which his consignment had accumulated we discovered that our client was the former president of the Federal Republic of Zaire, who died of illness after he was de-throwed in the same year the consignment was entrusted into our care. Since the death of our client President Mobutou Seseseko, none of his benefactors has come forward to claim the consignment with us, which means that non of his relatives or aids had any knowledge of this consignment. Hence out of curiosity I decided to secretly open the two boxes that our client deposited in our vault. And to my surprise I discovered that the two boxes that were registered as treasurer by our client actually contained a considerable amount of money in United States Dollars amounting to about US$30 million Dollar. Since this development I have been nursing plans secretly. I also found out from enquiries and the foreign media that our late client siphoned a lot of money from his country while he was in office as head of state. It is my conviction that the consignment in our vault was part of the money that our client siphoned and now that he is dead there is no race to this money in our care. I am now soliciting your noble assistance to assist me in transferring this money out of nigeria to your country for immediate investment with your assistance. I have also decided that you will generously be entitled to 30% of the total amount. Upon my receipt of your reply confirming your willingness to assist me of this transaction, I will immediately arrange and transfer all the rights of ownership of this consignment to your name to facilitate your easy clearance and transfer of the complete funds to your country. you have nothing to worry about, as I will be there to assist you in anyway necessary with all proper documentation. This transaction is 100% risk free. Please maintain absolute confidentiality on this matter. Please reply to the above email address with your telephone and fax so can call you. Thanks. Yours faithfully. MR. WILLIAM DURU _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Jul 17 23:00:06 2002 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 XAA09020 for ; Wed, 17 Jul 2002 23:00:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA20497 for nsis-archive@odin.ietf.org; Wed, 17 Jul 2002 23:01:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19306; Wed, 17 Jul 2002 22:37:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19278 for ; Wed, 17 Jul 2002 22:37:50 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08237 for ; Wed, 17 Jul 2002 22:36:51 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I2cKi09626 for ; Thu, 18 Jul 2002 05:38:20 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 18 Jul 2002 05:37:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 05:37:48 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 05:37:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65793@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] IPv6 Flow Label Thread-Index: AcIsI+8EwP7y2fkySNiBiBSoExq0JAB4AOmg To: X-OriginalArrivalTime: 18 Jul 2002 02:37:48.0634 (UTC) FILETIME=[1AEDE3A0:01C22E04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA19279 Subject: [NSIS] Presentations Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Here, here is a link where you can find most of the slides from the meeting: http://www-nrc.nokia.com/sua/nsis/ietf54/nsis54.html best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Jul 18 02:37:13 2002 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 CAA23563 for ; Thu, 18 Jul 2002 02:37:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA11431 for nsis-archive@odin.ietf.org; Thu, 18 Jul 2002 02:38:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10319; Thu, 18 Jul 2002 02:19:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10288 for ; Thu, 18 Jul 2002 02:18:58 -0400 (EDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23183 for ; Thu, 18 Jul 2002 02:17:57 -0400 (EDT) Received: from Freedom.icr.a-star.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g6I6JaBL028258; Thu, 18 Jul 2002 14:19:37 +0800 (SGT) Message-Id: <5.1.0.14.2.20020718140540.02a99d38@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 18 Jul 2002 14:16:09 +0800 To: nsis@ietf.org, robert.hancock@roke.co.uk From: "Charles Q. Shen" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [NSIS] Drafts on RSVP / NSIS and mobility Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, We have made an updated version of our RSVP-Mobile IPv6 Draft. A few issues related to NSIS and mobility is also discussed in a separate draft. The abstracts for these two drafts are as follows: 1. Mobility Extensions to RSVP in an RSVP-Mobile IPv6 Framework Abstract This memo first gives a brief review of a RSVP and Mobile IPv6 interoperation framework proposed in [1] and compared its features with the Performance Requirements set forth by Requirements of a QoS Solution for Mobile IP [2]. The subsequent part of the memo presents specification details including message formats, processing rules and algorithms that form the framework. The vast majority of these specifications has been verified by a prototype implementation. It is expected that this work could serve as a useful input in dealing with NSIS protocol and mobility issue. 2. Several Framework Issues Regarding NSIS and Mobility Abstract This memo discusses several framework issues related to Next Step In Signaling (NSIS) and mobility interaction. The first issue is related to handoff impact on NSIS operation. We present several general requirements for NSIS and mobility, followed by evaluation of how specific approaches using Mobile IP or other mechanisms might fit into the picture. Other issues covered include NSIS and mobility signaling layering and soft-state management. They are available also at the following links: http://www.icr.a-star.edu.sg/~shenqi/reports/draft-shen-nsis-rsvp-mobileipv6-00.txt http://www.icr.a-star.edu.sg/~shenqi/reports/draft-shen-nsis-mobility-fw-00.txt Comments are greatly appreciated! Best regards, Charles _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 23 03:33:44 2002 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 DAA02051 for ; Tue, 23 Jul 2002 03:33:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19931 for nsis-archive@odin.ietf.org; Tue, 23 Jul 2002 03:34:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18642; Tue, 23 Jul 2002 03:11:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18613 for ; Tue, 23 Jul 2002 03:11:10 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01660 for ; Tue, 23 Jul 2002 03:10:09 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N7BBi07047 for ; Tue, 23 Jul 2002 10:11:30 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 10:10:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 10:10:38 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] requirements derived from the resilience draft Date: Tue, 23 Jul 2002 10:10:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657B7@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] requirements derived from the resilience draft Thread-Index: AcItLYR60yVnuQ4LQYqcJytlrzAZWAE6nT9A To: , , X-OriginalArrivalTime: 23 Jul 2002 07:10:38.0669 (UTC) FILETIME=[0C4BBFD0:01C23218] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA18614 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, > 5.11.4 surely an NSIS entity can only determine whether the > protocol is operating correctly or not. whether that's due to > communications problems or internal failure is not an > important distinction. is this really a requirement for NSIS > to have a failover capability in the protocol? I agree. If we want to work on this, this is much more of a stage 2 requirement, something we can't really do yet. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 23 08:34:03 2002 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 IAA08545 for ; Tue, 23 Jul 2002 08:34:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06514 for nsis-archive@odin.ietf.org; Tue, 23 Jul 2002 08:35:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04977; Tue, 23 Jul 2002 08:15:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04946 for ; Tue, 23 Jul 2002 08:15:05 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07638 for ; Tue, 23 Jul 2002 08:14:01 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6NCFai06453 for ; Tue, 23 Jul 2002 15:15:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 23 Jul 2002 15:15:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 15:15:02 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23242.9240957B" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 23 Jul 2002 15:15:02 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657C5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] IPv6 Flow Label Thread-Index: AcIo78+vifyHwyccQSa0u02N98sAYQJUorKQ To: X-OriginalArrivalTime: 23 Jul 2002 12:15:02.0967 (UTC) FILETIME=[92AA7470:01C23242] Subject: [NSIS] IETF 54 Minutes Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C23242.9240957B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI all, =20 Here are the minutes, please send comments. =20 John =20 =20 NEXT STEP IN SIGNALLING WG - IETF 54 MONDAY, July 15, 2002 0900-1130 Morning Session (thanks to Janne Rinne for the minutes) =20 Requirements =20 NSIS Requirements http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-03.txt - John = Loughney =20 Open issues are 2, 4, and 44. Following open issues are discussed in = draft-vandenbosh-nsis-resilence-00.txt draft: 28, 53, 59, 65, and 72.=20 Other open issues in the mailing list are: terminology, removal of the = requirement 5.2.2, removal of the text about network initiation from=20 requirements 5.7.2 and 5.7.3. No questions or comments were provided. =20 NSIS Threats & Security requirements http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt = - Hannes Tschofenig. =20 Security requirements were introduced in the presentation such as = eavesdropping and traffic analysis, identity spoofing, missing = non-repudiation=20 property, disclosing the network structure and modification of a = reservation. Next steps: what issues are not addressed in the doc, is = the NSIS=20 threats document useful, should it be a WG item. Authorization should be = considered in the future because of adding support for applications=20 like middleboxes. It was supported to have this kind document as a = separate doc. This would be a WG item from now on. =20 NSIS Resilience http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.= txt - Sven Van den Bosch. =20 In the interim meeting, there were discussions about error handling, = failure and recovery and also it was requested to provide individual=20 submissions on this. There is a relation to other drafts, which are the = requirement draft and framework draft (hancock-nsis-fw). Latest=20 comments provided in the mailing list are related to terminology, = pre-class state, limited number of examples, additional failure = detection=20 mechanisms and clarifications. Next steps: is this good start for an = NSIS resilience draft. If yes, version 01 and might be considered as a = WG=20 item. Chairman commented that there should have a consensus first with = the requirements draft and then continue with the broader scope and=20 this doc. =20 Conclusion of the requirements discussions: =20 Requirements document should be re-issued & then see if it is ready for = WG last call. =20 Framework =20 Next Steps in Signaling: A Framework Proposal http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt - = Robert Hancock. =20 The purpose of this document is to explain what different entities = really do, how they can be used and how they can interact with other = entities.=20 Some of the issues for the work are addressing, on and off path = signalling, sender/receive/bi-directional operation, acknowledgement = options,=20 authorization issues, re-using standard protocols and supporting = different resource types and protocol interactions. There were concerns = with=20 addressing and on or off path signalling and middleboxes. It was = questioned that why we need to specify only signalling and not QoS. =20 2 Level Signaling Architecture http://www.isi.edu/~braden/draft-braden-2level-signaling-00.txt - Bob = Braden. =20 What we can learn from RSVPv1: After having basic requirements and = protocol design, it took 3 years... =20 RSVP is adaptable (syntactically and semantically). Due to complex = problem space, mapping and partitioning this space should be the task of = this WG. It was proposed to separate the common stuff from the = application level signalling stuff (CSTP and ALSP). Functional partition = would be that CSTP is much adapted from RFC 2961 and ALSP would be much = of details and complexity, of RFC 2205. In the=20 presentation, modest proposal for NSIS was that we should define the = architectural framework, map the signalling problem space into a=20 rational set of ALSP's and also revise the charter a WG to define CSTP = and one ALSP, later WG can define additional ALSP. There were=20 questions related to security and how it would work in the presence of = VPN's.. =20 Framework Structure for QoS Signaling http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt - Kan = Zhigang. =20 Off and on path signalling is relating to this and it would useful to = have more discussions and get comments to this in the mailing list. =20 A Framework for Bi-Directional QoS Signaling http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-01.txt = - Sharif Sharier. =20 It was commented that this is a very solution driven document. Also it = was mentioned that MPLS group has been doing something on this.=20 More comments should be sent to the mailing list. =20 Middlebox Signaling in a NSIS framework http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt = - Martin Stiemerling. =20 It was commented that this is useless for the general problems of NAT = and firewalls and those should be covered also in framework. =20 Conclusion of the framework discussions: The proposed way to go with the framework issue was to use Hancock draft = as a base document for the work and include some input from=20 Bob and Melinda to the document. After it is done, we could have a WG = last call for that document. =20 Analysis =20 Analysis of Existing QoS Solutions http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt - = Hannes Tschofenig. =20 Traffic Engineering group has done traffic engineering related work and = some input may come from the group to this analysis document. =20 On path and off path signaling for NSIS http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt - = Alban Couturier =20 It was asked how the states could be installed to routers if the = signalling is off path. There are cases when it is not need to install = states for=20 flows. Also COPS is used for configuring routers in centralized resource = management cases. Middlebox case was also mentioned here. It was=20 proposed to separate the solution part to own document from the analysis = part. AD's were not at present, so the charter question whether to=20 include off-path signalling to the charter is still pending. However the = original intention of NSIS work was to concentrate only to on path=20 signalling. This work would continue as an individual effort. =20 RSVP Security Properties http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-sec-properties-= 00.txt - Hannes Tschofenig. =20 Some concerns were raised with VPN's, which is kind of network = engineering problem. =20 Analysis on RSVP Regarding Multicast http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-00.t= xt - Xiaoming Fu. =20 It was commented that there is room for improvement of multicasting. It = was commented that multicast support should not be removed, but=20 there is a gread deal of room for improvement. =20 Conclusion of the analysis discussions: =20 Several important points were addressed and those should be merged into = one document, thus the structure of the document is more or less=20 open. It was commented that good goal for this document could be an = informational RFC eventually. Some discussion needs to take place=20 about the editorship of the WG document, as no document yet meets the WG = needs. =20 Other presentations =20 Consideration of RSVP-TE Extension for Metro Network http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt =20 Shortly presented. No comments provided. =20 The Features of IPv6 Signaling http://opticalip.icu.ac.kr/draft-choi-ipv6-signalling-02.txt =20 No time to discuss about this after quick presentation. =20 =20 ------_=_NextPart_001_01C23242.9240957B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI all,
 
Here are the minutes, please send=20 comments.
 
John
 
 
NEXT STEP IN SIGNALLING WG - IETF=20 54
  MONDAY, July 15, 2002
 0900-1130 Morning=20 Session
(thanks to Janne Rinne for the minutes)
 

Requirements
 
NSIS Requirements
h= ttp://www.ietf.org/internet-drafts/draft-ietf-nsis-req-03.txt=20 - John Loughney
 
Open issues are 2, 4, and 44. Following open issues are discussed = in=20 draft-vandenbosh-nsis-resilence-00.txt draft: 28, 53, 59, 65, and 72. =
Other=20 open issues in the mailing list are: terminology, removal of the = requirement=20 5.2.2, removal of the text about network initiation from =
requirements 5.7.2=20 and 5.7.3. No questions or comments were provided.
 
NSIS Threats & Security requirements
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threat= s-01.txt=20 - Hannes Tschofenig.
 
Security requirements were introduced in the presentation such as=20 eavesdropping and traffic analysis, identity spoofing, missing = non-repudiation=20
property, disclosing the network structure and modification of a=20 reservation. Next steps: what issues are not addressed in the doc, is = the NSIS=20
threats document useful, should it be a WG item. Authorization = should be=20 considered in the future because of adding support for applications =
like=20 middleboxes. It was supported to have this kind document as a separate = doc. This=20 would be a WG item from now on.
 
NSIS Resilience
http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-r= esilience-00.txt=20 - Sven Van den Bosch.
 
In the interim meeting, there were discussions about error = handling,=20 failure and recovery and also it was requested to provide individual=20
submissions on this. There is a relation to other drafts, which are = the=20 requirement draft and framework draft (hancock-nsis-fw). Latest =
comments=20 provided in the mailing list are related to terminology, pre-class = state,=20 limited number of examples, additional failure detection
mechanisms = and=20 clarifications. Next steps: is this good start for an NSIS resilience = draft. If=20 yes, version 01 and might be considered as a WG
item. Chairman = commented=20 that there should have a consensus first with the requirements draft and = then=20 continue with the broader scope and
this doc.
 
Conclusion of the requirements discussions:
 
Requirements document should be re-issued & then see if it is = ready for=20 WG last call.
 

Framework
 
Next Steps in Signaling: A Framework Proposal
http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt=20 -  Robert Hancock.
 
The purpose of this document is to explain what different entities = really=20 do, how they can be used and how they can interact with other entities. =
Some=20 of the issues for the work are addressing, on and off path signalling,=20 sender/receive/bi-directional operation, acknowledgement options,=20
authorization issues, re-using standard protocols and supporting = different=20 resource types and protocol interactions. There were concerns with=20
addressing and on or off path signalling and middleboxes. It was = questioned=20 that why we need to specify only signalling and not QoS.
 
2 Level Signaling Architecture
= http://www.isi.edu/~braden/draft-braden-2level-signaling-00.txt=20 - Bob Braden.
 
What we can learn from RSVPv1: After having basic requirements and = protocol=20 design, it took 3 years…
 
RSVP is adaptable (syntactically and semantically). Due to complex = problem=20 space, mapping and partitioning this space should be the task of =
this WG. It=20 was proposed to separate the common stuff from the application level = signalling=20 stuff (CSTP and ALSP). Functional partition
would be that CSTP is = much=20 adapted from RFC 2961 and ALSP would be much of details and complexity, = of RFC=20 2205. In the
presentation, modest proposal for NSIS was that we = should=20 define the architectural framework, map the signalling problem space = into a=20
rational set of ALSP’s and also revise the charter a WG to = define CSTP and=20 one ALSP, later WG can define additional ALSP. There were
questions = related=20 to security and how it would work in the presence of VPN’s..
 
Framework Structure for QoS Signaling
http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt= =20 - Kan Zhigang.
 
Off and on path signalling is relating to this and it would useful = to have=20 more discussions and get comments to this in the mailing list.
 
A Framework for Bi-Directional QoS Signaling
http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framewor= k-01.txt=20 - Sharif Sharier.
 
It was commented that this is a very solution driven document. Also = it was=20 mentioned that MPLS group has been doing something on this.
More = comments=20 should be sent to the mailing list.
 
Middlebox Signaling in a NSIS framework
http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-= 00.txt=20 - Martin Stiemerling.
 
It was commented that this is useless for the general problems of = NAT and=20 firewalls and those should be covered also in framework.
 
Conclusion of the framework discussions:
The proposed way to go = with the=20 framework issue was to use Hancock draft as a base document for the work = and=20 include some input from
Bob and Melinda to the document. After it is = done,=20 we could have a WG last call for that document.
 

Analysis
 
Analysis of Existing QoS Solutions
http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.t= xt=20 - Hannes Tschofenig.
 
Traffic Engineering group has done traffic engineering related work = and=20 some input may come from the group to this analysis document.
 
On path and off path signaling for NSIS
http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.t= xt=20 - Alban Couturier
 
It was asked how the states could be installed to routers if the = signalling=20 is off path. There are cases when it is not need to install states for=20
flows. Also COPS is used for configuring routers in centralized = resource=20 management cases. Middlebox case was also mentioned here. It was =
proposed to=20 separate the solution part to own document from the analysis part. = AD’s were not=20 at present, so the charter question whether to
include off-path = signalling=20 to the charter is still pending. However the original intention of NSIS = work was=20 to concentrate only to on path
signalling. This work would continue = as an=20 individual effort.
 
RSVP Security Properties
http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp= -sec-properties-00.txt=20 - Hannes Tschofenig.
 
Some concerns were raised with VPN’s, which is kind of = network engineering=20 problem.
 
Analysis on RSVP Regarding Multicast
http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-a= nalysis-00.txt=20 - Xiaoming Fu.
 
It was commented that there is room for improvement of = multicasting. It was=20 commented that multicast support should not be removed, but
there is = a gread=20 deal of room for improvement.
 
Conclusion of the analysis discussions:
 
Several important points were addressed and those should be merged = into one=20 document, thus the structure of the document is more or less
open. = It was=20 commented that good goal for this document could be an informational RFC = eventually.  Some discussion needs to take place
about the = editorship=20 of the WG document, as no document yet meets the WG needs.
 

Other presentations
 
Consideration of RSVP-TE Extension for Metro Network
http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.t= xt
 
Shortly presented. No comments provided.
 
The Features of IPv6 Signaling
htt= p://opticalip.icu.ac.kr/draft-choi-ipv6-signalling-02.txt
 
No time to discuss about this after quick presentation.
 
 

------_=_NextPart_001_01C23242.9240957B-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 23 08:44:04 2002 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 IAA09019 for ; Tue, 23 Jul 2002 08:44:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06907 for nsis-archive@odin.ietf.org; Tue, 23 Jul 2002 08:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05542; Tue, 23 Jul 2002 08:27:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05513 for ; Tue, 23 Jul 2002 08:27:28 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08052 for ; Tue, 23 Jul 2002 08:26:24 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6NCRwi13437 for ; Tue, 23 Jul 2002 15:27:58 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 15:27:25 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 15:27:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 15:27:25 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 23 Jul 2002 15:27:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657C7@esebe004.NOE.Nokia.com> Thread-Topic: req proposal (was Re: [NSIS] NSIS Requirement: Independence o fexisting flow reservations and default routing Thread-Index: AcItH0HNaNUuXHcqRn2bZVC4bDu0XAFJJjoA To: Cc: X-OriginalArrivalTime: 23 Jul 2002 12:27:25.0059 (UTC) FILETIME=[4CFCB530:01C23244] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA05514 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marco, > I see another alternative to route recording: > > In response to NSIS signaling, routers install state that causes future > signaling to follow the same path. This could be made explicit by a field in > the protocol. The routers would also need to install state that caused the > signaled flow to continue to follow this path as well. > > In the case of link failure along the existing path, a release may be > necessary followed by reinitiation of the reservation. If intermediate > routers are not NSIS aware there may be other issues with > this approach. I understand what you want to do, but this kind of thing seems rather heavy. > Requirements on NSIS: possibly a bit to make this option > explict and ...? Making a bit would be a solution, not a requirement. A requirement would be something like: An NSIS solution MAY/SHOULD be able to maintain an explicit path for packets to travel through. In the case of link failure along the existing path, a release may be necessary followed by reinitiation of the reservation. If intermediate routers are not NSIS aware there may be other issues with this approach. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 23 11:47:11 2002 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 LAA19190 for ; Tue, 23 Jul 2002 11:47:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21001 for nsis-archive@odin.ietf.org; Tue, 23 Jul 2002 11:48:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18796; Tue, 23 Jul 2002 11:30:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18757 for ; Tue, 23 Jul 2002 11:30:01 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.203.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17661 for ; Tue, 23 Jul 2002 11:28:59 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 16:29:36 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA472@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Sarantis Paskalis Cc: nsis@ietf.org Subject: RE: [NSIS] IPv6 Flow Label Date: Tue, 23 Jul 2002 16:29:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Sarantis, one brief point, else I think we have converged: > > [reh] i think doing this at the triplet level where there > is diverse routing (remember, they may all have different > destination addresses) will be a huge source of complexity. > is it really worth it? otherwise we are just talking about > flow grouping as already in NSIS. > > How can flow labels denoting the same flow have different destination > addresses? I thought we were talking about same source and > destination > addresses, but different flow labels for the same flow. In > case of different > destination address, we have different flows by definition. > [reh] well, maybe again I am over-reading the draft, but I was going from the phrase "SCTP flows with multiple addresses at either end-points" (in the same rule (1) from section 5). this refers to SCTP's ability to have one logical flow between two multihomed (therefore multi-addressed) endpoints - at the transport layer, SCTP thinks it's one flow, the question is whether we are supposed to know this at the network layer. My view is not. Cheers, Robert ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue Jul 23 15:28:39 2002 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 PAA00682 for ; Tue, 23 Jul 2002 15:28:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11104 for nsis-archive@odin.ietf.org; Tue, 23 Jul 2002 15:29:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09956; Tue, 23 Jul 2002 15:11:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09927 for ; Tue, 23 Jul 2002 15:11:28 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29870 for ; Tue, 23 Jul 2002 15:10:26 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 15:09:44 -0400 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: [NSIS] Scoping question Date: Tue, 23 Jul 2002 15:09:44 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I presented the draft "A Framework for NSIS Signaling" at the Yokohama meeting. Someone suggested that I consider sender-receiver negotiation, before proceeding with the actual QoS Signaling protocol. My question is whether this is/should be within the current scope of signaling protocol design? Comments are appreciated. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue Jul 23 15:34:16 2002 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 PAA00943 for ; Tue, 23 Jul 2002 15:34:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11984 for nsis-archive@odin.ietf.org; Tue, 23 Jul 2002 15:35:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10248; Tue, 23 Jul 2002 15:17:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10221 for ; Tue, 23 Jul 2002 15:17:58 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00265 for ; Tue, 23 Jul 2002 15:16:52 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 15:16:15 -0400 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: [NSIS] question for clarification Date: Tue, 23 Jul 2002 15:16:15 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Following my presentation of the framework draft at Yokohama, a person had asked me whether our approach was the same as the "bi-directional GMPLS" that the MPLS WG had worked on. I am not sure what this is, and would appreciate if that person can provide us with more information. Thanks. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Jul 24 11:39:12 2002 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 LAA21623 for ; Wed, 24 Jul 2002 11:39:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04324 for nsis-archive@odin.ietf.org; Wed, 24 Jul 2002 11:40:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02910; Wed, 24 Jul 2002 11:21:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02879 for ; Wed, 24 Jul 2002 11:21:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21112 for ; Wed, 24 Jul 2002 11:20:11 -0400 (EDT) From: mshore@cisco.com Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OFKiM2003153 for ; Wed, 24 Jul 2002 08:20:44 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEO96078; Wed, 24 Jul 2002 08:16:44 -0700 (PDT) Message-Id: <200207241516.AEO96078@mira-sjc5-4.cisco.com> To: nsis@ietf.org Date: Wed, 24 Jul 2002 11:19:11 -0400 Subject: [NSIS] NSIS and NATs Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Aside from the question of creating an NSIS "application" to communicate directly with NATs, the problem of getting NSIS *through* NATs probably needs to be considered. Robert and I discussed this last week and there's clearly a problem. The problem is that pretty much by definition of what the protocol is intended to do, there *must* be payload-embedded addresses (the filter spec), and those create a problem for NATs. A NAT will translate the header and may or may not translate payload- embedded addresses, depending on how sophisticated the NAT is and several other factors. Either way, it introduces problems. NSIS will clearly not be able to traverse an NSIS-unaware NAT. In fact, even low-end NATs are somewhat stateful and if NSIS is transported in raw IP packets a NAT may examine the packet, see that it's not UDP, TCP, or ICMP, and simply drop it because it doesn't know what else to do. An NSIS-aware NAT could take several forms. It's increasingly common for NATs to do sophisticated stateful inspection and payload rewrite, which introduces some problems of its own. In particular, 1) for it to do stateful inspection the traffic must be in the clear, and 2) any stateful rewrite of payload-embedded addresses will break any integrity mechanisms that have been applied to that object. It also adds considerably to the complexity and, of course, cost of the NAT device. Rather than using stateful inspection we could use a NAT request object that allows the application to communicate explicitly with a NAT, effectively putting it into the NSIS hop-by-hop path (this is the TIST proposal). It allows NATs to recompute integrity checks on a hop-by-hop basis, it allows the use of hop-by-hop encryption (NATs would share keying material) and it would allow smarter NAT table entry allocation. It would not, however, solve the problem of NSIS-unaware NATs. Nothing would, except to do something STUN-like and I do think that would work far less well for NSIS than it would for telephony applications, as it seems to me that you're more likely to run into instances of multihomed devices. The problem of NSIS devices *behind* NATs, of course, remains. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 25 06:53:00 2002 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 GAA28341 for ; Thu, 25 Jul 2002 06:52:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17679 for nsis-archive@odin.ietf.org; Thu, 25 Jul 2002 06:54:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16952; Thu, 25 Jul 2002 06:36:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16921 for ; Thu, 25 Jul 2002 06:36:24 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28031 for ; Thu, 25 Jul 2002 06:35:19 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6PAZiU71092; Thu, 25 Jul 2002 12:35:44 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA03216; Thu, 25 Jul 2002 12:35:43 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 73FA755995; Thu, 25 Jul 2002 12:35:43 +0200 (CEST) Date: Thu, 25 Jul 2002 12:35:43 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: Re: [NSIS] question for clarification Message-ID: <5233014.1027600543@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Sharif, RSVP-TE with GMPLS extension is a signaling protocol for setting up GMPLS pathes, which might be optical or what ever. There one of the extension is that they allow for bi-directional path setup. Marcus --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." wrote: > Following my presentation of the framework draft at Yokohama, a person had > asked me whether our approach was the same as the "bi-directional GMPLS" > that the MPLS WG had worked on. > > I am not sure what this is, and would appreciate if that person can > provide us with more information. > Thanks. > > Sharif. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Jul 25 13:24:11 2002 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 NAA13435 for ; Thu, 25 Jul 2002 13:24:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13807 for nsis-archive@odin.ietf.org; Thu, 25 Jul 2002 13:25:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12821; Thu, 25 Jul 2002 13:03:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12789 for ; Thu, 25 Jul 2002 13:03:19 -0400 (EDT) Received: from hello ([61.177.16.245]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12631 for ; Thu, 25 Jul 2002 13:02:13 -0400 (EDT) Message-Id: <200207251702.NAA12631@ietf.org> From: "CNIDC" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Fri, 26 Jul 2002 01:02:30 Subject: [NSIS] ¹ú¼ÊÓòÃû60Ôª£¡50M¸ßËÙÖ÷»ú120Ôª£¡£¡¿ÉÃâ·ÑÊÔÓÃÈýÌ죡£¡ Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org ¹ú¼ÊÓòÃû+60M¸ßËÙ¿Õ¼ä+3¸öÓÊÏä+ASP/ACCESSÊý¾Ý¿âÏÖÔÚÖ»Òª245Ôª£¡£¡ ·þÎñÆ÷ÎïÀíλÖÃ: ±±¾©µç±¨¾ÖÊÀ¼Í»¥Áª»ú·¿£¬ÊÇÈ«¹ú×î´óµÄIDCÊý¾ÝÖÐÐÄ¡£ ²¿·Ö¿Í»§Ãûµ¥£º ÏÃеç×Ó http://www.amoisonic.com.cn/ ÁªÍ¨ÏÃÃÅ http://www.xm165.com/ ƽ̶ÈÈÏß http://www.350400.com/ ÔÆ´óÐÅÏ¢ http://www.netcase.com.cn/ ˼Ë÷¿Æ¼¼ http://www.sisuo.net/ ¹ºÂòÈκÎÖ÷»ú¾ùÔùËÍ3-5¸ö»ùÓÚÄãÓòÃûµÄÓÊÏ䣬Ãû×Ö¿ÉÒÔ×ÔÐÐÉ趨:) ±ÈÈçÄãµÄÓòÃûÊÇ http://www.tooming.com ÔòÓÊÏäÐÎʽΪ xxx@tooming.com ,ÆäÖС°xxx¡±¿ÉÒÔÓÉÄã×ÔÐÐÉ趨£¬±ÈÈ磺 webmaster@tooming.com,ceo@tooming.comµÈµÈ¡£ -----------------·þÎñ±¨¼Û------------------------------------ ¹ú¼ÊÓòÃû£º 75Ôª/Äê £¨Í¬Ê±¹ºÂòÖ÷»ú½öÊÕ60Ôª/Ä꣩ ÐéÄâÖ÷»ú±¨¼Û: ÌØ»ÝÐÍ£º50MÍøÒ³¿Õ¼ä+´¿HTMLÖ§³Ö+3¸öÆóÒµÓÊÏä+¾«ÃÀÁôÑÔ±¾=120Ôª/Äê ³¬Îȶ¨´¿¾²Ì¬¿Õ¼ä£¬²»Ö§³ÖÈκαà³ÌÓïÑÔºÍÊý¾Ý¿â¡£¹ºÂò´Ë¿îÖ÷»úÔùËÍÁôÑÔ±¾Ò»¸ö£¡£¡ÓÊÏäÈý¸ö:) ¸öÈ˽¨Õ¾µÄ×î»ù´¡Ñ¡Ôñ ¾­¼ÃIÐÍ£º60MÍøÒ³¿Õ¼ä+ASP/ACCESS/CGI/PHPÖ§³Ö+3¸öÓÊÏä=185Ôª/Äê ¿ÉÒÔ·ÅÖÃÁôÑÔ±¾¡¢ÂÛ̳:) ¸öÈËѧϰÐÍ ¾­¼ÃIIÐÍ£º150MÍøÒ³¿Õ¼ä+ASP/ACCESS/CGI/PHPÖ§³Ö+5¸öÓÊÏä=260Ôª/Äê ¿ÉÒÔ·ÅÖÃÁôÑÔ±¾¡¢ÂÛ̳:) ÖÐСÆóÒµ½¨Õ¾Ò²ÊǸö²»´íµÄÑ¡Ôñ ±ê×¼ÐÍ£º250MÍøÒ³¿Õ¼ä+ASP/ACCESS/CGI/PHPÖ§³Ö+5¸öÓÊÏä=380Ôª/Äê ¿ÉÒÔ·ÅÖÃÁôÑÔ±¾¡¢ÂÛ̳:) ÆóÒµ½¨Õ¾Ê×Ñ¡ VIP50ÐÍ£º500MÍøÒ³¿Õ¼ä+ASP/ACCESS/CGI/PHPÖ§³Ö+5¸öÓÊÏä=880Ôª/Äê ÊʺÏÓÐÒ»¶¨Á÷Á¿µÄÍøÕ¾ VIP20ÐÍ£º1.5GÍøÒ³¿Õ¼ä+ASP/ACCESS/CGI/PHPÖ§³Ö+5¸öÓÊÏä=1920Ôª/Äê ÊʺÏÓнϸßÁ÷Á¿µÄÍøÕ¾ VIP10ÐÍ£º5G+ASP/ACCESS/Ãâ·Ñ¹Ò½ÓMS-SQL/CGI»òPHP/Ãâ·Ñ¹Ò½ÓMySQL/CGIÖ§³ÖÁÄÌìÊÒ+5¸öÓÊÏä=5940Ôª/Äê 10¸öÓû§¹²Ïíһ̨¸ßµµ·þÎñÆ÷£¬´óÐ͵ç×ÓÉÌÎñÍøÕ¾Ê×Ñ¡£¡£¡Ãâ·Ñ¹Ò½ÓSQLÊý¾Ý¿â£¡£¡£¡ ¸ü¶àÐÅÏ¢Çë·ÃÎÊÎÒÃǵÄÍøÕ¾£º ÍøÖ·£ºhttp://www.tooming.com ÓÊÏ䣺webmaster@tooming.com ÒµÎñQQ£º261034 »¶Ó­¸÷´óÖ÷Ò³ÖÆ×÷¹¤×÷ÊÒ»ò¹ã¸æ¹«Ë¾µÈ³¤ÆÚÐèÒªÓòÃû¡¢¿Õ¼äµÄµ¥Î»Í¬ÎÒÃǽ¨Á¢ºÏ×÷¹Øϵ£¡£¡ -----------------һЩ²¹³ä˵Ã÷----------------- ÓÐЩÐÂÉÏÍøµÄÅóÓÑÒ»Ö±¶ÔÏÞÖÆÔÚÏßÈËÊý±íʾ²»ÂúÒ⣬ÀÏÊÇ˵ҪÂò²»ÏÞÔÚÏßÈËÊýµÄ¼ÛλÔÚ300ÔªµÄÖ÷»ú£¬»¹Ëµ±ðÈËÓÐÕâÑùµÄÖ÷»ú~~~~ ÆäʵÕâÔõô¿ÉÄÜÄØ??? ÈκÎһ̨·þÎñÆ÷¶¼ÊÇÓÐÔÚÏßÈËÊýÏÞÖƵģ¬ÅäÖñȽϺõÄÒ»°ãÄܹ»Ö§³Ö4000ÈËÔÚÏߣ¬ºÅ³Æ¡°²»ÏÞÔÚÏßÈËÊý¡±Ò»°ã¶¼ÊÇ¡°Æ­×Ó¡±¡£ ¢ÙÈ«ÇòÖøÃûµÄËÑË÷ÒýÇæ Google ÓµÓÐ50000̨·þÎñÆ÷£¬µ«ÊÇËüµÄÔÚÏßÈËÊýÈÔÈ»ÊÇÓÐÏÞÖƵģ»¢Ú¡°9.11ʼþ¡±·¢ÉúµÄʱºò£¬ ¹úÄÚÖøÃûÃÅ»§ÍøÕ¾ ÐÂÀË ÓµÓнü°Ų̀·þÎñÆ÷£¬µ«Êǵ±Ê±ËûµÄÊ×Ò³ºÜ¶àʱºòÎÞ·¨´ò¿ª£¬ÒòΪä¯ÀÀµÄÈËÌ«¶àÁË£º£¨ ËùÒÔ¿´µ½ÄÇЩºÅ³Æ²»ÏÞÔÚÏßÈËÊýµÄÐéÄâÖ÷»úҪСÐÄÁË:)) ±¾Õ¾µÄ¿Õ¼ä¾ù×¢Ãû×î´ówebÁ¬½ÓÊý£¡£¡Çëµ½ÎÒÃÇÍøÕ¾²é¿´:) ÍøÖ·£ºhttp://www.tooming.com ÓÊÏ䣺webmaster@tooming.com ÒµÎñQQ£º261034 »¶Ó­¸÷´óÖ÷Ò³ÖÆ×÷¹¤×÷ÊÒ»ò¹ã¸æ¹«Ë¾µÈ³¤ÆÚÐèÒªÓòÃû¡¢¿Õ¼äµÄµ¥Î»Í¬ÎÒÃǽ¨Á¢ºÏ×÷¹Øϵ£¡£¡ ÎÒÃÇÖÂÁ¦ÓÚÌṩ͸Ã÷¡¢ÓÅÖʵķþÎñ£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jul 28 22:17:07 2002 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 WAA06313 for ; Sun, 28 Jul 2002 22:17:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA28163 for nsis-archive@odin.ietf.org; Sun, 28 Jul 2002 22:18:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27301; Sun, 28 Jul 2002 21:56:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27268 for ; Sun, 28 Jul 2002 21:56:25 -0400 (EDT) Received: from dginfo444 ([218.0.34.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06106 for ; Sun, 28 Jul 2002 21:55:17 -0400 (EDT) Message-Id: <200207290155.VAA06106@ietf.org> From: wzgood@21cn.com To: nsis@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_000_0018_01C1A1B3.E2C7FE20" MIME-Version: 1.0 Date: Mon, 29 Jul 2002 09:53:59 +0800 X-Priority: 3 X-Mailer: CSM 3.31 Subject: [NSIS] =?GB2312?B?vquyyrXEyta7+sHlyfnNvMasus3U2s/f0vTA1sGssqWjrMjtvP7PwtTY?= Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format --=_NextPart_000_0018_01C1A1B3.E2C7FE20 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =D5=E2=CA=C7=D2=BB=B8=F6HTML=B8=F1=CA=BD=B5=C4=D3=CA=BC=FE/This is a htm= l format mail --=_NextPart_000_0018_01C1A1B3.E2C7FE20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Mail<body bgcolor=3D"#FFFFFF" text=3D"#000000"></bod= y> --=_NextPart_000_0018_01C1A1B3.E2C7FE20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Jul 28 22:17:07 2002 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 WAA06323 for ; Sun, 28 Jul 2002 22:17:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA28180 for nsis-archive@odin.ietf.org; Sun, 28 Jul 2002 22:18:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27227; Sun, 28 Jul 2002 21:55:36 -0400 (EDT) Received: from dginfo825 ([218.0.34.37]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27196 for ; Sun, 28 Jul 2002 21:55:32 -0400 (EDT) Message-Id: <200207290155.VAA27196@optimus.ietf.org> From: wzgood@21cn.com To: nsis@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_000_0018_01C1A1B3.E2C7FE20" MIME-Version: 1.0 Date: Mon, 29 Jul 2002 09:53:08 +0800 X-Priority: 3 X-Mailer: CSM 3.31 Subject: [NSIS] =?GB2312?B?vquyyrXEyta7+sHlyfnNvMasus3U2s/f0vTA1sGssqWjrMjtvP7PwtTY?= Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format --=_NextPart_000_0018_01C1A1B3.E2C7FE20 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =D5=E2=CA=C7=D2=BB=B8=F6HTML=B8=F1=CA=BD=B5=C4=D3=CA=BC=FE/This is a htm= l format mail --=_NextPart_000_0018_01C1A1B3.E2C7FE20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Mail<body bgcolor=3D"#FFFFFF" text=3D"#000000"></bod= y> --=_NextPart_000_0018_01C1A1B3.E2C7FE20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 29 03:16:43 2002 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 DAA19753 for ; Mon, 29 Jul 2002 03:16:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17798 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 03:17:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15997; Mon, 29 Jul 2002 02:49:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15965 for ; Mon, 29 Jul 2002 02:49:38 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19275 for ; Mon, 29 Jul 2002 02:48:29 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6T6lud04180 for ; Mon, 29 Jul 2002 09:47:56 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Jul 2002 09:49:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 09:49:34 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 29 Jul 2002 09:49:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65808@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] NSIS and NATs Thread-Index: AcIzJd2/Ax0Ixk2pSIWeZRHo1lrCGQDphrBQ To: X-OriginalArrivalTime: 29 Jul 2002 06:49:35.0162 (UTC) FILETIME=[19AA61A0:01C236CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA15966 Subject: [NSIS] Security Next Steps Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, At the Yokohama meeting, there seemed to be consensus to make the following document: NSIS Threats & Security requirements http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt A working group draft. Assuming no objections from the WG, I will ask the ADs to add this as a WG draft. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 29 03:21:16 2002 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 DAA19814 for ; Mon, 29 Jul 2002 03:21:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17909 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 03:22:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16315; Mon, 29 Jul 2002 02:53:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16285 for ; Mon, 29 Jul 2002 02:53:22 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19328 for ; Mon, 29 Jul 2002 02:52:13 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6T6ped06223 for ; Mon, 29 Jul 2002 09:51:40 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Jul 2002 09:53:17 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 09:53:16 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 29 Jul 2002 09:53:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65809@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] NSIS and NATs Thread-Index: AcIzJd2/Ax0Ixk2pSIWeZRHo1lrCGQDphrBQAAARB4A= To: X-OriginalArrivalTime: 29 Jul 2002 06:53:16.0715 (UTC) FILETIME=[9DB8AFB0:01C236CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA16286 Subject: [NSIS] Mobile IP QoS requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, The Mobile IP WG Chairs have asked that the following draft: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt be considered under the NSIS WG. This draft has already passed WG last call in the MIP WG and has recieved some IESG comments. I propose have a two week WG last call period, starting on August 2nd and ending on August 16th, before sending this to the IESG. Since the Mobile IP WG has already signed off on this document, our job is just to ensure the QoS parts of the document are technically correct. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 29 04:04:46 2002 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 DAA19754 for ; Mon, 29 Jul 2002 03:16:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17801 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 03:17:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15931; Mon, 29 Jul 2002 02:48:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15900 for ; Mon, 29 Jul 2002 02:48:35 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19269 for ; Mon, 29 Jul 2002 02:47:26 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6T70Hf04398 for ; Mon, 29 Jul 2002 10:00:17 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Jul 2002 09:48:33 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 09:48:32 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 29 Jul 2002 09:48:32 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65807@esebe004.NOE.Nokia.com> Thread-Topic: Framework Next Steps Thread-Index: AcI2y/ViE60hzU1uQNmIzFDrIT6crQ== To: X-OriginalArrivalTime: 29 Jul 2002 06:48:33.0199 (UTC) FILETIME=[F4BB93F0:01C236CB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA15901 Subject: [NSIS] Framework Next Steps Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, At the Yokohama meeting, there seemed to be consensus to make the following document: Next Steps in Signaling: A Framework Proposal http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt a WG draft - with Robert Hancock, after comments from Bob Braden & Melinda Shore. I'd also suggest that other draft authors submit specific text into the document, if they feel this is needed. This is not a promise, however, that the text will be accepted. Assuming no WG objections, I propose to ask Robert to update the draft & check with our ADs about making this a WG document. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 29 08:34:28 2002 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 IAA26827 for ; Mon, 29 Jul 2002 08:34:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02529 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 08:35:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01289; Mon, 29 Jul 2002 08:10:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01258 for ; Mon, 29 Jul 2002 08:10:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25521; Mon, 29 Jul 2002 08:08:57 -0400 (EDT) Message-Id: <200207291208.IAA25521@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: Mon, 29 Jul 2002 08:08:57 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --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 QoS Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-03.txt Pages : 59 Date : 26-Jul-02 This document defines requirements for signaling QoS across different network environments, where different network environments across administrative and technology domains. 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. We also provide an outline structure for the problem, including QoS related terminology. Taken with the scenarios, this allows us to focus more precisely on which parts of the overall QoS problem needs to be solved. We present the assumptions and the aspects not considered within scope before listing the requirements 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-03.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-03.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-03.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: <20020726114310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020726114310.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Jul 29 10:39:16 2002 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 KAA01733 for ; Mon, 29 Jul 2002 10:39:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09308 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 10:40:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07884; Mon, 29 Jul 2002 10:17:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07857 for ; Mon, 29 Jul 2002 10:17:43 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00827 for ; Mon, 29 Jul 2002 10:16:35 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 10:16:06 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Framework Next Steps Date: Mon, 29 Jul 2002 10:16:04 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, Who is the actual editor of this draft, as there as several co-authors listed. I take it as per the usual rules, we should send text to the WG list as well as to the editor, for its inclusion into the draft? Sharif. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, July 29, 2002 2:49 AM To: nsis@ietf.org Subject: [NSIS] Framework Next Steps Hi all, At the Yokohama meeting, there seemed to be consensus to make the following document: Next Steps in Signaling: A Framework Proposal http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt a WG draft - with Robert Hancock, after comments from Bob Braden & Melinda Shore. I'd also suggest that other draft authors submit specific text into the document, if they feel this is needed. This is not a promise, however, that the text will be accepted. Assuming no WG objections, I propose to ask Robert to update the draft & check with our ADs about making this a WG document. Thanks, 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 daemon@optimus.ietf.org Mon Jul 29 10:50:43 2002 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 KAA02345 for ; Mon, 29 Jul 2002 10:50:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09649 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 10:51:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09088; Mon, 29 Jul 2002 10:34:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09058 for ; Mon, 29 Jul 2002 10:34:37 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01426 for ; Mon, 29 Jul 2002 10:33:29 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6TEZ8x28423 for ; Mon, 29 Jul 2002 09:35:08 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Jul 2002 09:34:35 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 29 Jul 2002 09:33:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Mobile IP QoS requirements Date: Mon, 29 Jul 2002 10:33:10 -0400 Message-ID: Thread-Topic: [NSIS] NSIS and NATs Thread-Index: AcIzJd2/Ax0Ixk2pSIWeZRHo1lrCGQDphrBQAAARB4AAEDaOgA== To: , X-OriginalArrivalTime: 29 Jul 2002 14:33:11.0312 (UTC) FILETIME=[DD620900:01C2370C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA09059 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John: 03 version of this draft is ready and I will send it to I-D directory today. Could you wait till 03 version appears on I-D directory, so that we can have last call on the latest version. Hemant -----Original Message----- From: ext john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 29. July 2002 2:53 To: nsis@ietf.org Subject: [NSIS] Mobile IP QoS requirements Hi all, The Mobile IP WG Chairs have asked that the following draft: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt be considered under the NSIS WG. This draft has already passed WG last call in the MIP WG and has recieved some IESG comments. I propose have a two week WG last call period, starting on August 2nd and ending on August 16th, before sending this to the IESG. Since the Mobile IP WG has already signed off on this document, our job is just to ensure the QoS parts of the document are technically correct. thanks, 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 daemon@optimus.ietf.org Mon Jul 29 15:12:24 2002 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 PAA11548 for ; Mon, 29 Jul 2002 15:12:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24244 for nsis-archive@odin.ietf.org; Mon, 29 Jul 2002 15:13:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22605; Mon, 29 Jul 2002 14:53:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22574 for ; Mon, 29 Jul 2002 14:53:42 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10714 for ; Mon, 29 Jul 2002 14:52:34 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 14:49:07 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] question for clarification Date: Mon, 29 Jul 2002 14:49:03 -0400 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Marcus, Thanks for the information. Would you have the link to this draft that you can send to us? Thanks. Sharif. -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Thursday, July 25, 2002 6:36 AM To: Shahrier, Sharif M. Cc: 'nsis@ietf.org' Subject: Re: [NSIS] question for clarification Sharif, RSVP-TE with GMPLS extension is a signaling protocol for setting up GMPLS pathes, which might be optical or what ever. There one of the extension is that they allow for bi-directional path setup. Marcus --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." wrote: > Following my presentation of the framework draft at Yokohama, a person had > asked me whether our approach was the same as the "bi-directional GMPLS" > that the MPLS WG had worked on. > > I am not sure what this is, and would appreciate if that person can > provide us with more information. > Thanks. > > Sharif. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 30 04:09:03 2002 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 EAA07982 for ; Tue, 30 Jul 2002 04:09:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08857 for nsis-archive@odin.ietf.org; Tue, 30 Jul 2002 04:10:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05639; Tue, 30 Jul 2002 03:50:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05608 for ; Tue, 30 Jul 2002 03:50:28 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07307 for ; Tue, 30 Jul 2002 03:49:18 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6U7npU33749; Tue, 30 Jul 2002 09:49:51 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA28258; Tue, 30 Jul 2002 09:49:50 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5A0C653BB4; Tue, 30 Jul 2002 09:49:49 +0200 (CEST) Date: Tue, 30 Jul 2002 09:50:59 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] question for clarification Message-ID: <180970.1028022659@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Whach the ccamp WG MArcus --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." wrote: > Marcus, > > Thanks for the information. Would you have the link to this draft > that you can send to us? Thanks. > > Sharif. > > > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, July 25, 2002 6:36 AM > To: Shahrier, Sharif M. > Cc: 'nsis@ietf.org' > Subject: Re: [NSIS] question for clarification > > Sharif, > > RSVP-TE with GMPLS extension is a signaling protocol for setting up GMPLS > pathes, which might be optical or what ever. There one of the extension > is that they allow for bi-directional path setup. > > Marcus > > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." > wrote: > >> Following my presentation of the framework draft at Yokohama, a person >> had asked me whether our approach was the same as the "bi-directional >> GMPLS" that the MPLS WG had worked on. >> >> I am not sure what this is, and would appreciate if that person can >> provide us with more information. >> Thanks. >> >> Sharif. >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 30 04:12:27 2002 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 EAA08044 for ; Tue, 30 Jul 2002 04:12:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08919 for nsis-archive@odin.ietf.org; Tue, 30 Jul 2002 04:13:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07343; Tue, 30 Jul 2002 03:53:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06920 for ; Tue, 30 Jul 2002 03:53:20 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07507 for ; Tue, 30 Jul 2002 03:52:02 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6U7qdU33821 for ; Tue, 30 Jul 2002 09:52:39 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA28311 for ; Tue, 30 Jul 2002 09:52:39 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B44BA57A5A for ; Tue, 30 Jul 2002 09:52:38 +0200 (CEST) Date: Tue, 30 Jul 2002 09:53:48 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-03.txt (fwd) Message-ID: <350373.1028022828@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========00367232==========" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --==========00367232========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Now, it has finaly made it into the directory. Marcus ---------- Forwarded Message ---------- Date: Montag, 29. Juli 2002 08:08 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-03.txt > 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 QoS Signaling Protocols > Author(s) : M. Brunner > Filename : draft-ietf-nsis-req-03.txt > Pages : 59 > Date : 26-Jul-02 > > This document defines requirements for signaling QoS across > different network environments, where different network environments > across administrative and technology domains. 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. We also provide an outline structure for > the problem, including QoS related terminology. Taken with the > scenarios, this allows us to focus more precisely on which parts of > the overall QoS problem needs to be solved. We present the > assumptions and the aspects not considered within scope before > listing the requirements 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-03.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-03.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-03.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. ---------- End Forwarded Message ---------- -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus --==========00367232========== Content-Type: multipart/mixed; boundary="==========00356153==========" --==========00356153========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 QoS Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-03.txt Pages : 59 Date : 26-Jul-02 This document defines requirements for signaling QoS across different network environments, where different network environments across administrative and technology domains. 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. We also provide an outline structure for the problem, including QoS related terminology. Taken with the scenarios, this allows us to focus more precisely on which parts of the overall QoS problem needs to be solved. We present the assumptions and the aspects not considered within scope before listing the requirements 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-03.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-03.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-03.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. --==========00356153========== Content-Type: multipart/alternative; boundary="==========00360509==========" --==========00360509========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020726114310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-03.txt --==========00360509========== Content-Type: message/external-body; name="draft-ietf-nsis-req-03.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020726114310.I-D@ietf.org> --==========00360509==========-- --==========00356153==========-- --==========00367232==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Jul 30 05:04:53 2002 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 EAA08043 for ; Tue, 30 Jul 2002 04:12:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08914 for nsis-archive@odin.ietf.org; Tue, 30 Jul 2002 04:13:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07184; Tue, 30 Jul 2002 03:53:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06796 for ; Tue, 30 Jul 2002 03:53:12 -0400 (EDT) Received: from ns3.super-hosts.com ([216.12.213.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07486; Tue, 30 Jul 2002 03:51:58 -0400 (EDT) Received: (from apache@localhost) by ns3.super-hosts.com (8.11.6/8.11.6) id g6U81oi19521; Tue, 30 Jul 2002 04:01:50 -0400 Date: Tue, 30 Jul 2002 04:01:50 -0400 Message-Id: <200207300801.g6U81oi19521@ns3.super-hosts.com> To: robert.thurlow@sun.com, nfsv4-wg@sunroof.eng.sun.com, john.loughney@nokia.com, nsis@ietf.org, nsis-request@ietf.org, sdawkins@cynetanetworks.com, pilc@ietf.org, pilc-request@ietf.org, nordmark@eng.sun.com, danny@tcb.net From: mike@winners.com () Subject: [NSIS] GET OVER $500 CASH in 2 minutes!!! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Below is the result of your feedback form. It was submitted by (mike@winners.com) on Tuesday, July 30, 19102 at 04:01:49 --------------------------------------------------------------------------- message: GET OVER $500 DOLLARS CASH!!! Just Click Here!!!! - http://www.reelten.com/redirect/500/index.htm - If you have received this Email in error please contact: lon_chaney_jr@hotmail.com with subject: remove. --------------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis