From mailnull@www1.ietf.org Sat Mar 1 21:09:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22931 for ; Sat, 1 Mar 2003 21:09:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h222IWC18586 for nsis-archive@odin.ietf.org; Sat, 1 Mar 2003 21:18:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h222ITp18567; Sat, 1 Mar 2003 21:18:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h222D4p17888 for ; Sat, 1 Mar 2003 21:13:04 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22583 for ; Sat, 1 Mar 2003 21:03:15 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.6/8.12.2) id h2224RSe010090; Sat, 1 Mar 2003 21:04:27 -0500 (EST) Date: Sat, 1 Mar 2003 21:04:27 -0500 (EST) From: Scott Bradner Message-Id: <200303020204.h2224RSe010090@newdev.harvard.edu> To: ccamp@ops.ietf.org, kireeti@juniper.net, mpls@uu.net, nsis@ietf.org, rsvp@ISI.EDU, tsvwg@ietf.org Cc: Jon.peterson@neustar.com, mankin@psg.com In-Reply-To: <20030301174430.O43585@kummer.juniper.net> Subject: [NSIS] Re: [Rsvp] RSVP change document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , the tsvwg list will be the main venue I will talk with Allison to see if there is time in teh tsvwg meeting to start the dicussion Scott --- From rsvp-admin@mailman.isi.edu Sat Mar 1 21:00:42 2003 X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: ccamp@ops.ietf.org, "" , "" , "" , "" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] RSVP change document Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST) Hi All, The current venue for discussing draft-kompella-rsvp-change-00.txt (IANA Considerations and change process for RSVP) will be in the TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will correct me. For now, let's limit the discussion to the tsvwg mailing list. Kireeti. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Mar 1 23:45:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24566 for ; Sat, 1 Mar 2003 23:45:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h224sMM27300 for nsis-archive@odin.ietf.org; Sat, 1 Mar 2003 23:54:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224sJp27278; Sat, 1 Mar 2003 23:54:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224k1p27002 for ; Sat, 1 Mar 2003 23:46:01 -0500 Received: from fep01-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24410 for ; Sat, 1 Mar 2003 23:36:11 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030302043755.ZZAE4812.fep01-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Sat, 1 Mar 2003 23:37:55 -0500 Message-ID: <3E618A7F.2060405@ee.ryerson.ca> Date: Sat, 01 Mar 2003 23:37:19 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Sat, 1 Mar 2003 23:37:55 -0500 Content-Transfer-Encoding: 7bit Subject: [NSIS] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 10 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Mar 2 01:47:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25936 for ; Sun, 2 Mar 2003 01:47:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h226vDA01436 for nsis-archive@odin.ietf.org; Sun, 2 Mar 2003 01:57:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h226v8p01429; Sun, 2 Mar 2003 01:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22274p16953 for ; Sat, 1 Mar 2003 21:07:04 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22275; Sat, 1 Mar 2003 20:57:16 -0500 (EST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h221xBS13041; Sat, 1 Mar 2003 17:59:11 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h221xAY43658; Sat, 1 Mar 2003 17:59:11 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org, "" , "" , "" , "" Message-ID: <20030301174430.O43585@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [NSIS] RSVP change document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi All, The current venue for discussing draft-kompella-rsvp-change-00.txt (IANA Considerations and change process for RSVP) will be in the TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will correct me. For now, let's limit the discussion to the tsvwg mailing list. Kireeti. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 3 08:09:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23195 for ; Mon, 3 Mar 2003 08:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23DJuw15521 for nsis-archive@odin.ietf.org; Mon, 3 Mar 2003 08:19:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DJkp15513; Mon, 3 Mar 2003 08:19:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DI8p15447 for ; Mon, 3 Mar 2003 08:18:08 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22996 for ; Mon, 3 Mar 2003 08:07:37 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h23DCrZ06738 for ; Mon, 3 Mar 2003 15:12:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 3 Mar 2003 15:09:37 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 15:09:35 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 15:09:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 3 Mar 2003 15:09:35 +0200 Message-ID: Thread-Topic: [NSIS] Security threats - NTLP awareness of upstream path Thread-Index: AcLecdpeJzk6LE3sS9yQeArwlLOvhADFDE3w To: X-OriginalArrivalTime: 03 Mar 2003 13:09:36.0248 (UTC) FILETIME=[23CFBF80:01C2E186] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23DI8p15448 Subject: [NSIS] Updated Interim Meeting page Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, I've collected the interim meeting slides, notes, etc. on one page, it can be found here: http://www-nrc.nokia.com/sua/nsis/interim-2003/index.htm I still need to edit the minutes. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 3 11:58:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02940 for ; Mon, 3 Mar 2003 11:58:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23H8Z104246 for nsis-archive@odin.ietf.org; Mon, 3 Mar 2003 12:08:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H8Up04207; Mon, 3 Mar 2003 12:08:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H7Ip03841 for ; Mon, 3 Mar 2003 12:07:18 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02850 for ; Mon, 3 Mar 2003 11:56:43 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h23GwhC06493; Mon, 3 Mar 2003 17:58:43 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h23Gwh127951; Mon, 3 Mar 2003 17:58:43 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 17:58:42 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675E6E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Security threats Date: Mon, 3 Mar 2003 17:58:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23H7Ip03842 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger please see my comments inline: > > Hi Hannes, > > I'm having a less complex scenario in mind and add an > example below, clarifying what I'd like get. > Additional remarks in line. > > Regards, Rüdiger > > Here you mean NSLP, I guess. > H|a number of nsis nodes along the path support a ntlp. > | however, for firewall signaling only some of them > | need to be involved in the protocol processing > | since the remaining nodes are, for example, qos aware nodes > | (qos nslps). > | > | the question is now: > | would we like to skip the qos nodes when we do firewall > | signaling and address only those nodes which are able > | to process the firewall signaling messages? > | > | my preference: > | we should skip nodes which do not support a particular nslp > | implementation. > > If I remember right, we agreed on the Interim that NTLP > is processing all NTLP messages regardless of local NSLP > support. i cannot recall this agreement. the scenario would look like: NSLP NSLP NTLP NTLP NTLP NTLP A B C D nsis messages would address nodes A, B, C and D although they are processed only by the NSLP? > > H|this simplifies security handling, refresh message handling > | and reliability handling and provides improvements for > | message processing. the drawback is that the discovery > | procedure needs to include some capability functionality > | (i.e. the discovery message says: "i would like to discover > | the next firewall along the path."). > > I'm not sure whether that holds. A domain gateway router > may support QoS-NSLP but no firewall-NSLP. The carrier > may be interested in keeping unauthenticated signaling > messages out of his domain in general. That isn't > possible with your proposal (unless the gateway supports > all NSLPs - which I don't feel to be useful). this is an artifically created example. how likely is it that a provider installs a firewall in the middle of the network and not at the end. you can also create strange network configurations. btw, you would always drop unauthenticated signaling messages. every node which receives signaling messages from the outside should provide authentication and authorization. to support your scenario you could give the gateway router (qos-nslp) an artificial firewall nslp functionality by allowing this node to also particate in firewall-nslp signaling although firewall functionality (i.e. packet filter installation) is not provided. > > Finally, my example. Lets assume a customer network with two > sites, making a QoS reservation to be used for VoIP calls > accross a carrier network. To limit his backbone signaling > processing requirements the carrier may prefer to stay out > of per VoIP call signaling. So aggregation is applied between > his edge nodes. Let's ignore how that is done with regard to > QoS. With regard to signaling it means that the carrier > routers only maintain state for a single reservation between > the two customer sites. Per VoIP call NSIS state maintenance > is restricted to the customer domain. Still, all related NSIS > signaling messages traverse the carrier network. Path coupled, > meaning NSIS path coupled (i.e. downstream and especially > upstream). Correct? i try to summarize what you just said without voip terminology: a) aggregation in the core network - signaling for this region b) per-flow signaling messages should be hidden in the core is this right? to provide (a) a protocol would need to start and end anywhere. in this case between the ingress and the egress router. for (b) it is benefitial to provide support that intermediate nodes do not particate in the signaling exchange for the per-flow signaling message. this can be accomplished for example by addressing the correct nodes (which is not suggested) or to skip intermediate nodes during the discovery process. what do you think? > If only hop by hop security is available, the > carriers NTLP still must process all per VoIP call signaling > messages. if the discovery process does not skip the intermediate nodes (ntlp nodes) in the carrier network then they are still processed at the ntlp layer although nslp layer processing might not be required. taking your firewall example from above you would also protect the end-to-end signaling messages in the carrier network. if the ntlps in the carrier process the signaling messages then some people might argue that you need protection between the nslp nodes. this is clearly not end-to-end protection but not as simple as peer-to-peer protection since you would need to discover the two nslps which communicate over a number of ntlps which requires discovery at the nslp layer. security protection can only be provided at the application layer in this case (e.g. cms). hence my suggestion: - skip intermediate nodes. do not process end-to-end messages at intermediate nodes at all since it is not necessary. - since they are then not participating in the signaling then the security process can simply skip them. > > > > ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 3 11:58:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02954 for ; Mon, 3 Mar 2003 11:58:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23H8dR04265 for nsis-archive@odin.ietf.org; Mon, 3 Mar 2003 12:08:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H8Yp04233; Mon, 3 Mar 2003 12:08:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H7Sp04039 for ; Mon, 3 Mar 2003 12:07:28 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02857 for ; Mon, 3 Mar 2003 11:56:53 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h23GwrW10111; Mon, 3 Mar 2003 17:58:53 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h23Gwr128074; Mon, 3 Mar 2003 17:58:53 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 17:58:52 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675E6F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Security threats - NTLP awareness of upstream path Date: Mon, 3 Mar 2003 17:58:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23H7Sp04040 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger please see my comment below: > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Geib, > Ruediger > Sent: Thursday, February 27, 2003 4:06 PM > To: Hannes.Tschofenig@mchp.siemens.de > Cc: nsis@ietf.org > Subject: Re: [NSIS] Security threats - NTLP awareness of upstream path > > > Hi Hannes > > | if you want to have end-to-end signaling then you also need to provide > | end-to-end security. > > Allright. That coincides with the conclusions the last signaling > design team drew I was working with. > > I've illustrated my end to end signaling scenario with an example > in an earlier reply, but I'm happy to repeat it: > > Lets assume a customer network with two > sites, making a QoS reservation to be used for VoIP calls > accross a carrier network. To limit his backbone signaling > processing requirements the carrier may prefer to stay out > of per VoIP call signaling. So signaling aggregation is > applied between his edge nodes. Let's ignore how that > is done with regard to QoS. With regard to signaling it > means that the carrier routers only maintain state for a > single reservation between the two customer sites. Per > VoIP call NSIS state maintenance is restricted to the > customer domain. Still, all related NSIS signaling messages > traverse the carrier network. Path coupled, meaning NSIS > path coupled (i.e. downstream and especially upstream). > > The best solution to this would be one where neither the > carrier routers NSLP nor the NTLP must process the per VoIP > call NSIS signaling. i am also in favor of this approach. this requires a more functionality at the discovery layer. i do not like a varient where nodes (ntlp or nslps) participate in the signaling message exchange although they have nothing todo with the particular signaling exchange. this would confirm more to the following approach: NSLP NSLP NTLP carrier NTLP customer network customer network network the following approach which was also suggested in the past does not allow your desired functionality: NSLP(y) NSLP(x) NSLP(y) NTLP NTLP NTLP NTLP customer carrier customer network network network in this case the ntlp and possible the nslp nodes intercept the end-to-end signaling messages. ciao hannes > > Regards, Rüdiger > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Mar 4 03:26:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08937 for ; Tue, 4 Mar 2003 03:26:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h248b0X14573 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 03:37:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h248atp14566; Tue, 4 Mar 2003 03:36:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h248ZNp14509 for ; Tue, 4 Mar 2003 03:35:23 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08902 for ; Tue, 4 Mar 2003 03:24:28 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 4 Mar 2003 09:26:29 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 09:26:26 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B393@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@mchp.siemens.de Cc: nsis@ietf.org Subject: AW: [NSIS] Security threats Date: Tue, 4 Mar 2003 09:26:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h248ZNp14510 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes, again, comments in line. Regards, Rüdiger |R> If I remember right, we agreed on the Interim that NTLP | > is processing all NTLP messages regardless of local NSLP | > support. | H| i cannot recall this agreement. | | the scenario would look like: | | NSLP NSLP | NTLP NTLP NTLP NTLP | A B C D | | nsis messages would address nodes A, B, C and D although they | are processed only by the NSLP? R: That's how I understood it. | > H|this simplifies security handling, refresh message handling | > | and reliability handling and provides improvements for | > | message processing. the drawback is that the discovery | > | procedure needs to include some capability functionality | > | (i.e. the discovery message says: "i would like to discover | > | the next firewall along the path."). | > |R> I'm not sure whether that holds. A domain gateway router | > may support QoS-NSLP but no firewall-NSLP. The carrier | > may be interested in keeping unauthenticated signaling | > messages out of his domain in general. That isn't | > possible with your proposal (unless the gateway supports | > all NSLPs - which I don't feel to be useful). | | this is an artifically created example. how likely is it that | a provider installs a firewall in the middle of the network | and not at the end. you can also create strange network | configurations. I'm not talking UNI, I'm talking NNI. What you call "artificial" is called peering router in the company I'm working for. We're operating a few of them. Generally I'm not contributing to NSIS to solve philosophical problems. H|btw, you would always drop unauthenticated signaling | messages. every node which receives signaling messages | from the outside should provide authentication and | authorization. Yes. H|to support your scenario you could give the gateway router | (qos-nslp) an artificial firewall nslp functionality by | allowing this node to also particate in firewall-nslp | signaling although firewall functionality (i.e. | packet filter installation) is not provided. The peering router definitely isn't the place where to add useless features. I'm favouring a good protocol design instead of patchwork. |R> Finally, my example. Lets assume a customer network with two | > sites, making a QoS reservation to be used for VoIP calls | > accross a carrier network. To limit his backbone signaling | > processing requirements the carrier may prefer to stay out | > of per VoIP call signaling. So aggregation is applied between | > his edge nodes. Let's ignore how that is done with regard to | > QoS. With regard to signaling it means that the carrier | > routers only maintain state for a single reservation between | > the two customer sites. Per VoIP call NSIS state maintenance | > is restricted to the customer domain. Still, all related NSIS | > signaling messages traverse the carrier network. Path coupled, | > meaning NSIS path coupled (i.e. downstream and especially | > upstream). Correct? | H|i try to summarize what you just said without voip terminology: | | a) aggregation in the core network - signaling for this region | b) per-flow signaling messages should be hidden in the core | | is this right? Absolutely. H|to provide (a) a protocol would need to start and end | anywhere. in this case between the ingress and the egress | router. | for (b) it is benefitial to provide support that intermediate | nodes do not particate in the signaling exchange for | the per-flow signaling message. | | this can be accomplished for example by addressing the | correct nodes (which is not suggested) or to skip | intermediate nodes during the discovery process. | | what do you think? I'm favouring skipping. However NTLP message authentication must work. |R> If only hop by hop security is available, the | > carriers NTLP still must process all per VoIP call signaling | > messages. | H|if the discovery process does not skip the intermediate nodes | (ntlp nodes) in the carrier network then they are still | processed at the ntlp layer although nslp layer processing | might not be required. | | taking your firewall example from above you would also protect the | end-to-end signaling messages in the carrier network. if the | ntlps in the carrier process the signaling messages then some | people might argue that you need protection between the nslp | nodes. this is clearly not end-to-end protection but not as | simple as peer-to-peer protection since you would need | to discover the two nslps which communicate over a number of | ntlps which requires discovery at the nslp layer. security | protection can only be provided at the application layer in | this case (e.g. cms). | | hence my suggestion: | - skip intermediate nodes. do not process end-to-end | messages at intermediate nodes at all since it is | not necessary. | - since they are then not participating in the signaling then | the security process can simply skip them. Allright with me. To some it up, we need a discovery protocol and a security mechanism working from A to B, only knowing that A and B support the same NSLP. The latter may not be simple and I'd favour an attempt distinguishing various architectures: say A and B may be part of the same Intranet, Extranet and finally Internet. The reason for that is if A and B belong to the same Intranet, their security architecture may be the same. A security/trust relation between both of them may exist or be established easily. That can't be assumed if A and B are any two hosts connected to the Internet. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 04:45:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10629 for ; Tue, 4 Mar 2003 04:45:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h249uNx20784 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 04:56:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249uHp20762; Tue, 4 Mar 2003 04:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249tQp20727 for ; Tue, 4 Mar 2003 04:55:26 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10606 for ; Tue, 4 Mar 2003 04:44:29 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h249kV720376; Tue, 4 Mar 2003 10:46:31 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h249kVw12669; Tue, 4 Mar 2003 10:46:31 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 10:46:30 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675E8A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Security threats Date: Tue, 4 Mar 2003 10:46:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h249tQp20728 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger please see my comments inline: > Hello Hannes, > > again, comments in line. > > Regards, Rüdiger > > > |R> If I remember right, we agreed on the Interim that NTLP > | > is processing all NTLP messages regardless of local NSLP > | > support. > | > H| i cannot recall this agreement. > | > | the scenario would look like: > | > | NSLP NSLP > | NTLP NTLP NTLP NTLP > | A B C D > | > | nsis messages would address nodes A, B, C and D although they > | are processed only by the NSLP? > > R: That's how I understood it. > > > | > H|this simplifies security handling, refresh message handling > | > | and reliability handling and provides improvements for > | > | message processing. the drawback is that the discovery > | > | procedure needs to include some capability functionality > | > | (i.e. the discovery message says: "i would like to discover > | > | the next firewall along the path."). > | > > |R> I'm not sure whether that holds. A domain gateway router > | > may support QoS-NSLP but no firewall-NSLP. The carrier > | > may be interested in keeping unauthenticated signaling > | > messages out of his domain in general. That isn't > | > possible with your proposal (unless the gateway supports > | > all NSLPs - which I don't feel to be useful). > | > | this is an artifically created example. how likely is it that > | a provider installs a firewall in the middle of the network > | and not at the end. you can also create strange network > | configurations. > > I'm not talking UNI, I'm talking NNI. What you call "artificial" > is called peering router in the company I'm working for. We're > operating a few of them. > Generally I'm not > contributing to NSIS to solve philosophical problems. good to hear that. > > H|btw, you would always drop unauthenticated signaling > | messages. every node which receives signaling messages > | from the outside should provide authentication and > | authorization. > > Yes. i guess we have agreement on the security protection for messages comming from the outside. > > H|to support your scenario you could give the gateway router > | (qos-nslp) an artificial firewall nslp functionality by > | allowing this node to also particate in firewall-nslp > | signaling although firewall functionality (i.e. > | packet filter installation) is not provided. > > The peering router definitely isn't the place where to add useless > features. I'm favouring a good protocol design instead of > patchwork. i share your view. i am also in favor of an approach which skips nsis nodes which have nothing todo with the signaling processing. a good place to add such a functionality is in the discovery phase. > > |R> Finally, my example. Lets assume a customer network with two > | > sites, making a QoS reservation to be used for VoIP calls > | > accross a carrier network. To limit his backbone signaling > | > processing requirements the carrier may prefer to stay out > | > of per VoIP call signaling. So aggregation is applied between > | > his edge nodes. Let's ignore how that is done with regard to > | > QoS. With regard to signaling it means that the carrier > | > routers only maintain state for a single reservation between > | > the two customer sites. Per VoIP call NSIS state maintenance > | > is restricted to the customer domain. Still, all related NSIS > | > signaling messages traverse the carrier network. Path coupled, > | > meaning NSIS path coupled (i.e. downstream and especially > | > upstream). Correct? > | > H|i try to summarize what you just said without voip terminology: > | > | a) aggregation in the core network - signaling for this region > | b) per-flow signaling messages should be hidden in the core > | > | is this right? > > Absolutely. > > H|to provide (a) a protocol would need to start and end > | anywhere. in this case between the ingress and the egress > | router. > | for (b) it is benefitial to provide support that intermediate > | nodes do not particate in the signaling exchange for > | the per-flow signaling message. > | > | this can be accomplished for example by addressing the > | correct nodes (which is not suggested) or to skip > | intermediate nodes during the discovery process. > | > | what do you think? > > I'm favouring skipping. However NTLP message authentication > must work. i also agree with you. security at the ntlp has a number of advantages (epecially if you use channel security). > > |R> If only hop by hop security is available, the > | > carriers NTLP still must process all per VoIP call signaling > | > messages. > | > H|if the discovery process does not skip the intermediate nodes > | (ntlp nodes) in the carrier network then they are still > | processed at the ntlp layer although nslp layer processing > | might not be required. > | > | taking your firewall example from above you would also protect the > | end-to-end signaling messages in the carrier network. if the > | ntlps in the carrier process the signaling messages then some > | people might argue that you need protection between the nslp > | nodes. this is clearly not end-to-end protection but not as > | simple as peer-to-peer protection since you would need > | to discover the two nslps which communicate over a number of > | ntlps which requires discovery at the nslp layer. security > | protection can only be provided at the application layer in > | this case (e.g. cms). > | > | hence my suggestion: > | - skip intermediate nodes. do not process end-to-end > | messages at intermediate nodes at all since it is > | not necessary. > | - since they are then not participating in the signaling then > | the security process can simply skip them. > > Allright with me. To some it up, we need a discovery protocol > and a security mechanism working from A to B, only knowing > that A and B support the same NSLP. The latter may not be > simple and I'd favour an attempt distinguishing various > architectures: say A and B may be part of the same > Intranet, Extranet and finally Internet. The reason for > that is if A and B belong to the same Intranet, their > security architecture may be the same. A security/trust > relation between both of them may exist or be established > easily. That can't be assumed if A and B are any two hosts > connected to the Internet. whether a node is from your local network can be derived from the ip address/fqdn. the edge has to know that it is a edge. to differentiate at the discovery phase between Intranet, Extranet and finally Internet is difficult. this requires some scoping -> see ipv6 discussions. ciao hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 11:27:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29288 for ; Tue, 4 Mar 2003 11:27:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Gbs418664 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 11:37:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gbjp18650; Tue, 4 Mar 2003 11:37:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GaRp17847 for ; Tue, 4 Mar 2003 11:36:27 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29260 for ; Tue, 4 Mar 2003 11:25:23 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h24GRPX01066 for ; Tue, 4 Mar 2003 17:27:25 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24GRPm11719 for ; Tue, 4 Mar 2003 17:27:25 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 17:27:24 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EA9@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Tue, 4 Mar 2003 17:27:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Draft Update: "RSVP Security Properties" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, i have updated the "RSVP Security Properties" draft. Abstract As the work of the NSIS working group has begun there are also concerns about security and its implication for the design of a signaling protocol. In order to understand the security properties and available options of RSVP a number of documents have to be read. This document tries to summarize the security properties of RSVP and to view them from a different point of view. This work in NSIS is part of the overall process of analyzing other signaling protocols and to learn from their design considerations. This document should also provide a starting point for security discussions. URL: http://www.tschofenig.priv.at/drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt Changes: - Added some additional security issues (IPsec handling, discovery, etc.) - Draft will be shortened in the near future - i try hard :-) Best Regards, Hannes Tschofenig _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 11:27:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29304 for ; Tue, 4 Mar 2003 11:27:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Gbvo18691 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 11:37:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gbtp18683; Tue, 4 Mar 2003 11:37:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Galp17868 for ; Tue, 4 Mar 2003 11:36:47 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29264 for ; Tue, 4 Mar 2003 11:25:43 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h24GRjc19374 for ; Tue, 4 Mar 2003 17:27:45 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24GRjm11879 for ; Tue, 4 Mar 2003 17:27:45 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 17:27:44 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EAA@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Tue, 4 Mar 2003 17:27:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Draft Update: "NSIS AAA" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, we have updated the "NSIS Authentication, Authorization and Accounting Issues" draft: Abstract This document describes the implications of authentication, authorization and accounting for an NSIS QoS signaling protocol. We try to show that authorization and charging are very important for the internal machinery of a signaling protocol and for the security and trust model behind it. This document only addresses charging aspects for unicast data traffic. URL: http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.pdf http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.ps http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.txt Changes: - Comments incorporated - Terminology clean-up, some typos and spelling errors fixed Best Regards, Hannes Tschofenig _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 11:27:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29319 for ; Tue, 4 Mar 2003 11:27:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Gc9T18731 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 11:38:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gc6p18720; Tue, 4 Mar 2003 11:38:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gbbp18544 for ; Tue, 4 Mar 2003 11:37:37 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29271 for ; Tue, 4 Mar 2003 11:26:33 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h24GSZ402072 for ; Tue, 4 Mar 2003 17:28:35 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24GSZm12287 for ; Tue, 4 Mar 2003 17:28:35 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 17:28:34 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EAB@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Tue, 4 Mar 2003 17:28:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Draft Update: "CASP / CASP-QoS / CASP NAT+Firewall" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, we have updated the "CASP - Cross-Application Signaling Protocol", the "A Quality-of-Service Resource Allocation Client for CASP" and the "A Firewall/NAT Traversal Client for CASP" drafts: CASP - Cross-Application Signaling Protocol ------------------------------------------- Abstract CASP is a modular potocol for establishing network control state along a data path between two nodes communicating on the Internet. The signalling problem addressed by CASP is the same as the overall problem being addressed by the NSIS activities. The CASP framework is defined as a modular protocol, which includes a general purpose messaging layer (M-layer), which supports a number of client layers for particular signalling applications (e.g. QoS, MIDCOM). In addition there is distinct, special purpose client component for next-peer discovery. http://www.tschofenig.priv.at/drafts/draft-schulzrinne-nsis-casp-01.pdf http://www.tschofenig.priv.at/drafts/draft-schulzrinne-nsis-casp-01.ps http://www.tschofenig.priv.at/drafts/draft-schulzrinne-nsis-casp-01.txt Changes: - More detailed (e.g. packet formats, security section) - Draft shortened - Terminology revised - Some text added to open issues list A Quality-of-Service Resource Allocation Client for CASP -------------------------------------------------------- Abstract Signaling resource reservations is one of the possible applications of the Cross-Application Signaling Protocol (CASP). This document describes a client protocol that supports per-flow resource reservation in both sender- and receiver-directed modes operation. URL: http://www.tschofenig.priv.at/drafts/draft-schulzrinne-nsis-casp-qos-01.pdf http://www.tschofenig.priv.at/drafts/draft-schulzrinne-nsis-casp-qos-01.ps http://www.tschofenig.priv.at/drafts/draft-schulzrinne-nsis-casp-qos-01.txt Changes: - Update to the first version - More mobility issues - Some text has been moved to the open issues section A Firewall/NAT Traversal Client for CASP ---------------------------------------- Abstract This document describes a CASP client protocol that allows nodes to signal information to firewalls both in an in-path and off-path fashion. The protocol furthermore allows to establish a NAT binding and to provide the signaling initiator with the NAT information. This is information can then be used within other protocols such as SIP. URL: http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-casp-midcom-01.pdf http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-casp-midcom-01.ps http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-casp-midcom-01.txt Changes: - Additional author: Cedric Aoun - Sections revised and cleaned up - Terminology re-written - Some issues added, some replaced by references to other documents - More generic than the first version Best Regards, Hannes Tschofenig _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 12:00:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01365 for ; Tue, 4 Mar 2003 12:00:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24HBUa22555 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 12:11:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HBRp22550; Tue, 4 Mar 2003 12:11:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24H6op21149 for ; Tue, 4 Mar 2003 12:06:50 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01053 for ; Tue, 4 Mar 2003 11:55:45 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h24Gvm6N008712 for ; Tue, 4 Mar 2003 08:57:48 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEB57299; Tue, 4 Mar 2003 08:57:47 -0800 (PST) Message-Id: <200303041657.AEB57299@mira-sjc5-c.cisco.com> To: nsis@ietf.org From: Melinda Shore Date: Tue, 04 Mar 2003 11:57:47 -0500 Subject: [NSIS] Way forward? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Has it been decided how the working group is going to move forward? There are obvious concerns about our ability to resolve the transport question, but there are longer-term questions, as well, about what to do once the framework and requirements drafts are completed. I'm happy to see that some work has already commenced comparing protocols against what we've got so far on framework and requirements, but I'm not sure that I'd like to see the working group get bogged down in a lengthy comparison phase. (Edit that: I mean that I'm sure I would not like to see the working group get bogged down in a lengthy comparison phase.) The charter specifies that "The working group will use existing IETF signaling as the basis for this work, evaluating RSVP in particular as the starting point" and I do feel that after we made the decision to stick with on-path signaling we've departed from that a fair bit. My experience in other working groups has been that it's impossible to reach a decision without first knocking a stake in the ground, and I think that here it would be consistent with the charter if stake might be that existing RSVP protocol machinery is sufficient unless demonstrated otherwise. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 12:07:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01725 for ; Tue, 4 Mar 2003 12:07:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24HI5k23167 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 12:18:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HI3p23147; Tue, 4 Mar 2003 12:18:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HHOp23086 for ; Tue, 4 Mar 2003 12:17:24 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01676 for ; Tue, 4 Mar 2003 12:06:18 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24HBcF15201 for ; Tue, 4 Mar 2003 19:11:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Mar 2003 19:08:21 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 19:08:20 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 19:08:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Way forward? Date: Tue, 4 Mar 2003 19:08:18 +0200 Message-ID: Thread-Topic: [NSIS] Way forward? Thread-Index: AcLicGDvCHT0kPwOS/SYDxqFYCB2+gAABoEQ To: , X-OriginalArrivalTime: 04 Mar 2003 17:08:19.0463 (UTC) FILETIME=[A786A970:01C2E270] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24HHOp23087 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > Has it been decided how the working group is going to move > forward? There are obvious concerns about our ability to > resolve the transport question, but there are longer-term > questions, as well, about what to do once the framework and > requirements drafts are completed. I'm happy to see that > some work has already commenced comparing protocols against > what we've got so far on framework and requirements, but I'm > not sure that I'd like to see the working group get bogged > down in a lengthy comparison phase. (Edit that: I mean that > I'm sure I would not like to see the working group get > bogged down in a lengthy comparison phase.) Once transport is resolved, we will work on 2 applications - one being a general QoS protocol, along the lines of RSVPv1 and the 2nd being a NAT traversal one. Updated charter is currently with the ADs. > The charter specifies that "The working group will use > existing IETF signaling as the basis for this work, > evaluating RSVP in particular as the starting point" and I > do feel that after we made the decision to stick with > on-path signaling we've departed from that a fair bit. My > experience in other working groups has been that it's > impossible to reach a decision without first knocking a > stake in the ground, and I think that here it would be > consistent with the charter if stake might be that existing > RSVP protocol machinery is sufficient unless demonstrated > otherwise. That might be a good idea. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 4 12:29:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02657 for ; Tue, 4 Mar 2003 12:29:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24HeEp25258 for nsis-archive@odin.ietf.org; Tue, 4 Mar 2003 12:40:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HeAp25233; Tue, 4 Mar 2003 12:40:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Hdfp25173 for ; Tue, 4 Mar 2003 12:39:41 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02586 for ; Tue, 4 Mar 2003 12:28:35 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 17:30:38 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8B5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 4 Mar 2003 17:30:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] new framework Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, We have not been idle on the framework front: a new version -02 exists. Until the i-d editor gets to it, you can find a copy at: http://www.epic.roke.co.uk/epic/draft-ietf-nsis-fw-02.txt This version has been radically restructured since the -01 version; in particular, the layer split approach is introduced much earlier and the rest of the document restructured around that. Discussions about resource management are now more gathered together at the end, and the rest of the document is (should be) much more independent of signalling application independent. Some of the open issues from the previous version are closed, and others postponed (as being protocol design questions). Section by section comparison with the previous version is not possible, but on the other hand the new version is nearly 10 pages shorter (==> read it again!) Comments would be nice. The major open issues are in section 3.4. (IMHO both of then can be considered questions about how much RSVP-related functionality should be in the NTLP, depending on how many RFCs you regard as making up "RSVP" ...) There are other less major open issues as well, but they seem to be contingent on these two: transport and state management functions. Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Mar 5 04:14:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22350 for ; Wed, 5 Mar 2003 04:14:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h259OvB07314 for nsis-archive@odin.ietf.org; Wed, 5 Mar 2003 04:24:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259Om507305; Wed, 5 Mar 2003 04:24:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259Nk507253 for ; Wed, 5 Mar 2003 04:23:46 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22312 for ; Wed, 5 Mar 2003 04:12:21 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h259EIB3005305; Wed, 5 Mar 2003 10:14:19 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XHRSR8; Wed, 5 Mar 2003 10:14:18 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 10:14:07 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB959@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" , nsis@ietf.org Subject: RE: [NSIS] Way forward? Date: Wed, 5 Mar 2003 10:14:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda >> I think that here it would be >> consistent with the charter if stake might be that existing >> RSVP protocol machinery is sufficient unless demonstrated >> otherwise. I agree with the above statement related to the use of a (modified) RSVP as NTLP. Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: dinsdag 4 maart 2003 17:58 To: nsis@ietf.org Subject: [NSIS] Way forward? Has it been decided how the working group is going to move forward? There are obvious concerns about our ability to resolve the transport question, but there are longer-term questions, as well, about what to do once the framework and requirements drafts are completed. I'm happy to see that some work has already commenced comparing protocols against what we've got so far on framework and requirements, but I'm not sure that I'd like to see the working group get bogged down in a lengthy comparison phase. (Edit that: I mean that I'm sure I would not like to see the working group get bogged down in a lengthy comparison phase.) The charter specifies that "The working group will use existing IETF signaling as the basis for this work, evaluating RSVP in particular as the starting point" and I do feel that after we made the decision to stick with on-path signaling we've departed from that a fair bit. My experience in other working groups has been that it's impossible to reach a decision without first knocking a stake in the ground, and I think that here it would be consistent with the charter if stake might be that existing RSVP protocol machinery is sufficient unless demonstrated otherwise. Melinda _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 5 10:21:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04460 for ; Wed, 5 Mar 2003 10:21:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25FWYB02573 for nsis-archive@odin.ietf.org; Wed, 5 Mar 2003 10:32:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FWK502554; Wed, 5 Mar 2003 10:32:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FVm502515 for ; Wed, 5 Mar 2003 10:31:48 -0500 Received: from bt0g2p.god.bel.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04365 for ; Wed, 5 Mar 2003 10:20:16 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h25FMFH05238; Wed, 5 Mar 2003 16:22:15 +0100 To: ietf@ietf.org, nsis@ietf.org Cc: brunner@ccrle.nec.de, olov.schelen@operax.com, cedric.aoun@nortelnetworks.com, sob@harvard.edu, mankin@psg.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 5 Mar 2003 16:22:09 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/05/2003 16:22:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] path-decoupled signaling (pads) BOF Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , We have added a mailing list for this BOF and updated the agenda. Path-decoupled signaling BOF (pads) Thursday, March 20 at 1530-1730 ============================== CHAIRS: Sven Van den Bosch, sven.van_den_bosch@alcatel.be Marcus Brunner, brunner@ccrle.nec.de Mailing list: pads@psg.com To subscribe - pads-request@psg.com Archive - http://psg.com/lists/pads Description The Next Steps in Signaling (NSIS) WG is developing a next-generation general purpose signaling protocol for state installation along the data path. NSIS is currently focusing on an interpretation of 'along the data path' as 'visiting the same routers as the data flow'. This is denoted as path-coupled signaling. For a number of applications, it would be useful to have a somewhat broader interpretation of 'along the data path', e.g. 'visiting the same AS's as the data flow'. This is denoted as path-decoupled signaling. The purpose of the BOF session is to survey and discuss the path-decoupled signaling case. The first part of the discussion should bring forward arguments for path-decoupled signaling and describe use cases for path-decoupled signaling, potentially limiting the scope of the signalling, e.g. to a single AS. The second part deals with the expected impact path-decoupled signaling would have on the NSIS protocol. Proposed Agenda Introduction, Chair Use cases for path-decoupled signaling, Olov Schelen (olov.schelen@operax.com), Cedric Aoun (cedric.aoun@nortelnetworks.com) Impact on nsis, TBD Discussion and round-up Drafts related to the discussion: draft-schelen-nsis-opopsig-01 draft-geib-sig-guarandif-00.txt draft-ietf-nsis-fw-02.txt draft-declercq-vsn-arch-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Mar 7 15:55:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02012 for ; Fri, 7 Mar 2003 15:55:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L6m207853 for nsis-archive@odin.ietf.org; Fri, 7 Mar 2003 16:06:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6bO07780; Fri, 7 Mar 2003 16:06:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KmRO05888 for ; Fri, 7 Mar 2003 15:48:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29548; Fri, 7 Mar 2003 15:36:16 -0500 (EST) Message-Id: <200303072036.PAA29548@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: Fri, 07 Mar 2003 15:36:16 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Next Steps in Signaling: Framework Author(s) : R. Hancock et. al. Filename : draft-ietf-nsis-fw-02.txt Pages : 46 Date : 2003-3-7 The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing and mobility. The different routing and mobility events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-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-ietf-nsis-fw-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-ietf-nsis-fw-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7151005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-fw-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-fw-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151005.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Mar 7 16:22:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04926 for ; Fri, 7 Mar 2003 16:22:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LYA911742 for nsis-archive@odin.ietf.org; Fri, 7 Mar 2003 16:34:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LY5O11687; Fri, 7 Mar 2003 16:34:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LHaO10054 for ; Fri, 7 Mar 2003 16:17:36 -0500 Received: from fep02-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03253 for ; Fri, 7 Mar 2003 16:05:23 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030307210708.IHCW311274.fep02-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 7 Mar 2003 16:07:08 -0500 Message-ID: <3E690A05.1080400@ee.ryerson.ca> Date: Fri, 07 Mar 2003 16:07:17 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org References: <3E618A7F.2060405@ee.ryerson.ca> Content-Type: multipart/alternative; boundary="------------010101010409020404080704" X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 7 Mar 2003 16:07:08 -0500 Subject: [NSIS] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Approaching March 10 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --------------010101010409020404080704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) --------------010101010409020404080704 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Call for Papers - IP Mobility 2003
IEEE VTC Symposium on IP Mobility
October 4-9, 2003 Orlando, FL, USA

in Conjunction with IEEE VTC Fall 2003
Submission Deadline Extended: March 10, 2003

Scope
=====
Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: 
* Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance
* New approaches to wide-area and local mobility
* Quality of Service models, resource management, and provisioning
* Traffic Engineering in mobile wireless IP access networks
* Transport protocol design for mobile wireless networks
* Security including security threat models, threat analysis and their impact on routing
* Application level protocol design and performance
* Mobile and wireless applications, their service requirements and performance
* Content delivery support in IP network for mobile users
* Multicasting for mobile wireless services
* Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network)
* Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular)
* Inter-vehicular network architecture
* Mobile wireless IP access network deployment and management

Posters are also solicited on the projects related to **Support for Network Mobility**.

Submission Instructions
=======================
Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/.

Important Dates
Extended Abstract Due:  March 10, 2003
Acceptance Notification:  May 15, 2003
Camera Ready Copy of Full Paper Due:  July 15, 2003
Symposium Date:  October 4, 2003

Organization
============

Program Co-Chairs:

Muhammad Jaseemuddin (jaseem@ee.ryerson.ca)
Department of Electrical and Computer Engineering
Ryerson University
Toronto, Canada

Hongyi Li (hyli@nortelnetworks.com)
Wireless Technology Lab
Nortel Networks
Ottawa, Canada

Publicity Co-Chair:

Junaid Zubairi (junaid.zubairi@fredonia.edu)
Department of Mathematics and Computer Science
SUNY at Fredonia
Fredonia, NY, USA

Technical Program Committee
===========================
* Ahmed Helmy (U of Southern California, USA)
* Abdelsalam Helal (U of Florida, Gainesville, USA)
* Alan O'Neill (Flarion Technologies, USA)
* Behcet Sarikaya (Alcatel, USA)
* Christophe Janneteau (Motorola, France)
* Govindan Ravindran (Soma Networks, Canada)
* Haseeb Akhtar (inCode Telecom group, USA)
* Hany Elgebaly (Intel Corporation, USA)
* Hesham Soliman (Ericsson, Sweden)
* Lars Wolf (TU Braunschweig, Germany)
* Michael Wolf (Daimler-Chrysler, Germany)
* Raouf Boutaba (U of Waterloo, Canada)
* Sajal Das (The U of Texas at Arlington, USA)
* Samir R. Das (SUNY at Stony Brook, USA)
* Thiery Ernst (Wide, Keio U, Japan)
* Thomas Noel (U of Strasbourg, France)
* Yasser Rasheed (Intel Corporation, USA)
--------------010101010409020404080704-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Mar 7 16:40:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02009 for ; Fri, 7 Mar 2003 15:55:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L6m507842 for nsis-archive@odin.ietf.org; Fri, 7 Mar 2003 16:06:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6hO07805; Fri, 7 Mar 2003 16:06:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Kn2O05919 for ; Fri, 7 Mar 2003 15:49:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29604; Fri, 7 Mar 2003 15:36:51 -0500 (EST) Message-Id: <200303072036.PAA29604@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: Fri, 07 Mar 2003 15:36:50 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rsvp-sec-properties-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RSVP Security Properties Author(s) : H. Tschofenig Filename : draft-ietf-nsis-rsvp-sec-properties-01.txt Pages : 43 Date : 2003-3-7 As the work of the NSIS working group has begun there are also concerns about security and its implication for the design of a signaling protocol. In order to understand the security properties and available options of RSVP a number of documents have to be read. This document tries to summarize the security properties of RSVP and to view them from a different point of view. This work in NSIS is part of the overall process of analyzing other protocols and to learn from their design considerations. This document should also provide a starting point for security discussions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-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-ietf-nsis-rsvp-sec-properties-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-ietf-nsis-rsvp-sec-properties-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: <2003-3-7151119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rsvp-sec-properties-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151119.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Mar 7 16:40:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02014 for ; Fri, 7 Mar 2003 15:55:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L6mZ07868 for nsis-archive@odin.ietf.org; Fri, 7 Mar 2003 16:06:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L6iO07820; Fri, 7 Mar 2003 16:06:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KmYO05896 for ; Fri, 7 Mar 2003 15:48:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29569; Fri, 7 Mar 2003 15:36:23 -0500 (EST) Message-Id: <200303072036.PAA29569@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: Fri, 07 Mar 2003 15:36:23 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-07.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Requirements for Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-07.txt Pages : 34 Date : 2003-3-7 This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service such as The Resource Reservation Protocol, however in recent years several other applications of signaling have been defined such as signaling for label distribution in Multiprotocol Label Switching or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-07.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-07.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-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7151157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151157.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 10 02:43:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11757 for ; Mon, 10 Mar 2003 02:43:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A7ufl20388 for nsis-archive@odin.ietf.org; Mon, 10 Mar 2003 02:56:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A7uRO20378; Mon, 10 Mar 2003 02:56:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A7soO20300 for ; Mon, 10 Mar 2003 02:54:50 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11339 for ; Mon, 10 Mar 2003 02:41:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2A7kwF27790 for ; Mon, 10 Mar 2003 09:46:58 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Mar 2003 09:43:32 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:43:32 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:43:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Mar 2003 09:43:31 +0200 Message-ID: Thread-Topic: [NSIS] Security threats Thread-Index: AcLiKAn6chkTmceHRMiRfZvB8RoDGAEsIwOA X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 10 Mar 2003 07:43:32.0219 (UTC) FILETIME=[BFA214B0:01C2E6D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2A7soO20301 Subject: [NSIS] Last call for agenda items Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Resending my request for agenda items. If you have not formally requested a slot, now is the time to do so. Working Group agendas due date is at 12:00 ET, March 13, Thursday. John > Please send in requests for time at the NSIS meeting in IETF 56. > A link with the relevant draft is much appreciated. > > Main topics are: > NSIS Requirements doc > NSIS Framework doc > NSIS Security Threats > RSVP Security Properties > NSIS Analysis doc > discussion of NTLP properties > > I would like to avoid discussions on solutions. > > Remember, that IETF meeting time is limited, so presentations are > frowned-upon, but discussion on open and active issues is encouraged. > > thanks, > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 10 11:20:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01336 for ; Mon, 10 Mar 2003 11:20:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGXT323751 for nsis-archive@odin.ietf.org; Mon, 10 Mar 2003 11:33:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGXOO23692; Mon, 10 Mar 2003 11:33:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGPRO23220 for ; Mon, 10 Mar 2003 11:25:27 -0500 Received: from eccles.ee.ryerson.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00913 for ; Mon, 10 Mar 2003 11:11:53 -0500 (EST) Received: from ee.ryerson.ca ([172.16.30.72]) by eccles.ee.ryerson.ca (8.12.8/8.12.8) with ESMTP id h2AGE09o079291 for ; Mon, 10 Mar 2003 11:14:00 -0500 (EST) (envelope-from jaseem@ee.ryerson.ca) Message-ID: <3E6CB9C7.7030603@ee.ryerson.ca> Date: Mon, 10 Mar 2003 11:13:59 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: nsis@ietf.org References: <3E618A7F.2060405@ee.ryerson.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 24 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 24, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 24, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Mar 12 08:05:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02406 for ; Wed, 12 Mar 2003 08:05:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CDJtL10745 for nsis-archive@odin.ietf.org; Wed, 12 Mar 2003 08:19:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDJmO10737; Wed, 12 Mar 2003 08:19:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDIXO10691 for ; Wed, 12 Mar 2003 08:18:33 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02361; Wed, 12 Mar 2003 08:04:03 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CD4n101756; Wed, 12 Mar 2003 15:04:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:06:11 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:06:11 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:06:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 12 Mar 2003 15:06:10 +0200 Message-ID: Thread-Topic: [NSIS] new framework Thread-Index: AcLic+S6HICahwqsSW61JlZJXy7PMwGIytfQ To: Cc: X-OriginalArrivalTime: 12 Mar 2003 13:06:10.0910 (UTC) FILETIME=[272367E0:01C2E898] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CDIXO10692 Subject: [NSIS] NSIS Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Next Steps in Signaling (NSIS) MONDAY, March 17, 2003 0900-1130 Morning Session ========================= Agenda bashing - chair - 5 minutes Interim Meeting review - chair - 15 minutes * RSVP discussion / Problems to solve - invited speakers - 60 minutes TBA NSIS Framework document - Robert Hancock - 30 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-02.txt TUESDAY, March 18, 2003 1300-1400 Afternoon Session I ============================= Agenda bashing - chair - 5 minutes NSIS Requirements doc - Marcus Brunner - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-07.txt NSIS Analysis doc - Jukka Manner - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt RSVP Security Properties - Hannes Tschofenig - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt NSIS Security Threats - Hannes Tschofenig - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 13 09:18:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01294 for ; Thu, 13 Mar 2003 09:18:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DEWhX30868 for nsis-archive@odin.ietf.org; Thu, 13 Mar 2003 09:32:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEWbO30844; Thu, 13 Mar 2003 09:32:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DERFO30641 for ; Thu, 13 Mar 2003 09:27:15 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01080; Thu, 13 Mar 2003 09:12:15 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DECY112244; Thu, 13 Mar 2003 16:12:37 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 16:13:56 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 16:13:55 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 16:13:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Mar 2003 16:13:54 +0200 Message-ID: Thread-Topic: [NSIS] new framework Thread-Index: AcLic+S6HICahwqsSW61JlZJXy7PMwGIytfQADTnoBA= To: Cc: X-OriginalArrivalTime: 13 Mar 2003 14:13:55.0188 (UTC) FILETIME=[C80CC340:01C2E96A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DERFO30642 Subject: [NSIS] Updated NSIS Agenda, version 3 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Next Steps in Signaling (NSIS) MONDAY, March 17, 2003 0900-1130 Morning Session ========================= Agenda bashing - chair - 5 minutes Interim Meeting review - chair - 15 minutes * RSVP discussion / Problems to solve - invited speakers - 60 minutes TBA NSIS Analysis doc - Jukka Manner - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt TUESDAY, March 18, 2003 1300-1400 Afternoon Session I ============================= Agenda bashing - chair - 5 minutes NSIS Requirements doc - Marcus Brunner - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-07.txt NSIS Framework document - Robert Hancock - 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-02.txt RSVP Security Properties - Hannes Tschofenig - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt NSIS Security Threats - Hannes Tschofenig - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 13 09:18:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01307 for ; Thu, 13 Mar 2003 09:18:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DEWj930885 for nsis-archive@odin.ietf.org; Thu, 13 Mar 2003 09:32:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEWdO30859; Thu, 13 Mar 2003 09:32:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DESCO30678 for ; Thu, 13 Mar 2003 09:28:12 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01095; Thu, 13 Mar 2003 09:13:12 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DEDw112994; Thu, 13 Mar 2003 16:13:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 16:15:16 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 16:15:15 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 16:15:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Mar 2003 16:15:14 +0200 Message-ID: Thread-Topic: [NSIS] new framework Thread-Index: AcLic+S6HICahwqsSW61JlZJXy7PMwGIytfQADTnoBAAAAuKMA== To: Cc: X-OriginalArrivalTime: 13 Mar 2003 14:15:15.0704 (UTC) FILETIME=[F80A8780:01C2E96A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DESCO30679 Subject: [NSIS] Updated NSIS Agenda, version 4 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Next Steps in Signaling (NSIS) MONDAY, March 17, 2003 0900-1130 Morning Session ========================= Agenda bashing - chair - 5 minutes Interim Meeting review - chair - 15 minutes * RSVP discussion / Problems to solve - invited speakers - 60 minutes TBA NSIS Analysis doc - Jukka Manner - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt An Evaluation on RSVP Transport Mechanism - Ping Pan - 15 minutes http://www.ietf.org/internet-drafts/draft-pan-nsis-rsvp-transport-01.txt TUESDAY, March 18, 2003 1300-1400 Afternoon Session I ============================= Agenda bashing - chair - 5 minutes NSIS Requirements doc - Marcus Brunner - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-07.txt NSIS Framework document - Robert Hancock - 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-02.txt RSVP Security Properties - Hannes Tschofenig - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt NSIS Security Threats - Hannes Tschofenig - 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 13 19:00:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25979 for ; Thu, 13 Mar 2003 19:00:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E0FPT12242 for nsis-archive@odin.ietf.org; Thu, 13 Mar 2003 19:15:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0FGO12230; Thu, 13 Mar 2003 19:15:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0EBO12175 for ; Thu, 13 Mar 2003 19:14:11 -0500 Received: from mailrelay1.alcatel.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25896 for ; Thu, 13 Mar 2003 18:59:01 -0500 (EST) From: Axel.Kuttner@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA29814 for ; Fri, 14 Mar 2003 01:00:39 +0100 (MET) To: nsis@ietf.org Message-ID: Date: Fri, 14 Mar 2003 01:01:06 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/14/2003 01:01:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I will be out of the office starting 13.03.2003 and will not return until 16.03.2003. Thank you for keeping me informed. I will respond to your message when I return. In urgent cases please contact Guenther Arheit. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Mar 18 18:29:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05981 for ; Tue, 18 Mar 2003 18:29:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2INkdX30455 for nsis-archive@odin.ietf.org; Tue, 18 Mar 2003 18:46:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INkXO30448; Tue, 18 Mar 2003 18:46:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INjEO30419 for ; Tue, 18 Mar 2003 18:45:14 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05964 for ; Tue, 18 Mar 2003 18:27:37 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 23:29:50 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0A7A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 18 Mar 2003 23:29:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] state management question Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, As discussed in today's session, there may or may not be an open issue about how much the NTLP should 'know' or 'do' about providing a state management service to signalling applications, or being aware that signalling applications are using the NTLP to do state management. (Note that this is entirely not about state that the NTLP uses internally, e.g. to route messages correctly.) This is described as an open issue in section 3.4.2 of the current draft. Some of what is discussed there is certainly more than an implementation issue, since it relates to what message types the protocol supports, whether the protocol explicitly carries timing and related control information, and so on. The pure question of whether the NTLP treats a refresh message differently from a 'new' message could be considered a node-internal implementation issue - provided you only expect this treatment to take place at nodes processing that signalling application and not intermediate ones. Consider a possible example: 1. The NTLP design is such that downstream (sender-->receiver) messages will be sent in end-to-end addressed router-alerting PATH-like packets. 2. An signalling application which generates a downstream message which is basically a refresh will have that message seen at every downstream node. 3. Any node which doesn't support that signalling application (i.e. not including the message sender) will have no choice but to forward that message immediately. Network desynchronisation actions can only be taken at the signalling application aware nodes. Are we worried about this sort of thing? I'd be very happy with the 'NTLP is 100% ignorant of signalling application state management' approach. However, some people might see it as a departure from 'typical' RSVP behaviour. It's also clearly different from the original CSTP proposal (e.g. section 2.2 of Bob's 2 level draft). I'd invite people who think that the NTLP should contain standardised (i.e. non-implementation specific) functionality to do something related to state management to say what that functionality should be. Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Mar 19 14:25:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02101 for ; Wed, 19 Mar 2003 14:25:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJhNN26306 for nsis-archive@odin.ietf.org; Wed, 19 Mar 2003 14:43:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJhJO26253; Wed, 19 Mar 2003 14:43:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJdxO25899 for ; Wed, 19 Mar 2003 14:39:59 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01896 for ; Wed, 19 Mar 2003 14:21:58 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 18vjAW-0000fV-00; Wed, 19 Mar 2003 20:24:08 +0100 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 18vjAT-0001NX-00; Wed, 19 Mar 2003 20:24:05 +0100 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=tm.uka.de ident=3010) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.12) id 18vjAU-0000MK-00; Wed, 19 Mar 2003 20:24:06 +0100 Message-ID: <3E78C498.3050205@tm.uka.de> Date: Wed, 19 Mar 2003 20:27:20 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] state management question References: <76C92FBBFB58D411AE760090271ED41806AC0A7A@rsys002a.roke.co.uk> In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC0A7A@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-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, >Are we worried about this sort of thing? I'd be very happy with the 'NTLP is 100% ignorant of signalling application state management' approach. However, some people might see it as a > Yes, I share this view. Especially, in the mobility context, NTLP "connections" may change more often during a handover. In these environments, you are usually interested in keeping/refreshing state in the NSLP independently of the underlying transport. >departure from 'typical' RSVP behaviour. It's also clearly different from the original CSTP proposal (e.g. section 2.2 of Bob's 2 level draft). > >I'd invite people who think that the NTLP should contain standardised (i.e. non-implementation specific) functionality to do something related to state management to say what that functionality should be. > > Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 20 13:48:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29179 for ; Thu, 20 Mar 2003 13:48:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KJ6cg15040 for nsis-archive@odin.ietf.org; Thu, 20 Mar 2003 14:06:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJ6OO14974; Thu, 20 Mar 2003 14:06:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJ5EO14873 for ; Thu, 20 Mar 2003 14:05:14 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29050 for ; Thu, 20 Mar 2003 13:46:43 -0500 (EST) 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.5/Switch-2.2.5) with ESMTP id h2KIlWM15013 for ; Thu, 20 Mar 2003 20:47:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Mar 2003 20:48:58 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 20:48:58 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 20:48:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 20 Mar 2003 20:48:57 +0200 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcLuTaPT8K7CwlfUSVWXzZtIe5rhgAAv/XFQ To: Cc: X-OriginalArrivalTime: 20 Mar 2003 18:48:58.0465 (UTC) FILETIME=[5DA93D10:01C2EF11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2KJ5EO14874 Subject: [NSIS] NTLP Work Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, At IETF 56, after discussing with our ADs and some other folks, I suggested that Henning Schulzrinne & Melinda Shore undertake (as document editors) the initial work on the NTLP document; who will serve the WG consensus. My presentation can be found here. http://www-nrc.nokia.com/sua/nsis/ietf56/nsis-agenda.ppt Some folks have asked me about the background of this descision, so I shall try to explain. As most of you know, the WG chair has the responsiblity for making decisions on behalf of the WG - for determining consensus, selecting document, etc - in concert with the ADs. More details are found in 2418. http://www.ietf.org/rfc/rfc2418.txt I have been counseled by the AD to ensure we stay within our charter: http://www.ietf.org/html.charters/nsis-charter.html The charter says: The working group will use existing IETF signaling as the basis for this work, evaluating RSVP in particular as the starting point. and: The working group will develop signaling requirements, analysis and framework documents. The Transport area directors and chair will evaluate these against criteria including that the use of a simplified version of RSVP has been fully evaluated, and that the potential for a tool box or building block contribution has been covered by the framework. Work on the protocol document will be contingent on this evaluation. I have made the deterimination, in consultation with our ADs, that there is no consensus that an updated & modified version of RSVP cannot fulfill our requirements. We could debate this on the mailing list, but I personally feel that we need to begin work on the protocol In order to progress the work, I asked Henning and Melinda (along with Michael Thomas & Bob Braden) if they thought that they could find common ground to begin this work. Everyone felt that this would be doable. There were no behind-the-scenes machinations on anyone's part. Please not we are not bound by backward compatibility with RSVP, but as we (the IETF) have extensive design experience with RSVP as well as extensive deployment experience with RSVP, this should be an efficient way to make forward. This decision was undertaken by my own initiative; in order to progress our work. This is my proposal to the Working Group. If anyone has questions or comments on this proposal, please comment - either on-list or directly to me. So, in summary, I am asking if this proposal is acceptable to the working group. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 20 17:46:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11006 for ; Thu, 20 Mar 2003 17:46:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KN4Pr03978 for nsis-archive@odin.ietf.org; Thu, 20 Mar 2003 18:04:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KN4GO03914; Thu, 20 Mar 2003 18:04:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KMh0O02852 for ; Thu, 20 Mar 2003 17:43:00 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10310 for ; Thu, 20 Mar 2003 17:24:26 -0500 (EST) Received: from wl-143-97.wireless.ietf56.ietf.org ([130.129.143.97] helo=n-brunner.office) by sunserver1.ietf56.ietf.org with esmtp (Exim 4.12) id 18w8Ue-0004e3-00; Thu, 20 Mar 2003 17:26:36 -0500 Date: Thu, 20 Mar 2003 14:27:24 -0800 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" cc: nsis@ietf.org Subject: Re: [NSIS] state management question Message-ID: <5131398.1048170443@n-brunner.office> In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC0A7A@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41806AC0A7A@rsys002a.roke.co.uk> X-Mailer: Mulberry/3.0.2 (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 www1.ietf.org id h2KMh1O02853 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit --On Dienstag, 18. März 2003 23:29 +0000 "Hancock, Robert" wrote: > Dear all, > > As discussed in today's session, there may or may not be an open issue > about how much the NTLP should 'know' or 'do' about providing a state > management service to signalling applications, or being aware that > signalling applications are using the NTLP to do state management. (Note > that this is entirely not about state that the NTLP uses internally, e.g. > to route messages correctly.) > The actual problem is that signaling is not only about state management as some people think. It involved also the triggering of functionality on the nodes using the state as argument. If state management is not part of NTLP I do not see what NTLP is doing more than only forwarding signaling messages. > The pure question of whether the NTLP treats a refresh message > differently from a 'new' message could be considered a node-internal > implementation issue - provided you only expect this treatment to take > place at nodes processing that signalling application and not > intermediate ones. Consider a possible example: 1. The NTLP design is > such that downstream (sender-->receiver) messages will be sent in > end-to-end addressed router-alerting PATH-like packets. 2. An signalling > application which generates a downstream message which is basically a > refresh will have that message seen at every downstream node. 3. Any node > which doesn't support that signalling application (i.e. not including the > message sender) will have no choice but to forward that message > immediately. Network desynchronisation actions can only be taken at the > signalling application aware nodes. > > Are we worried about this sort of thing? I'd be very happy with the 'NTLP > is 100% ignorant of signalling application state management' approach. > However, some people might see it as a departure from 'typical' RSVP > behaviour. It's also clearly different from the original CSTP proposal > (e.g. section 2.2 of Bob's 2 level draft). > In RSVP it is just fully integrated. IMHO state management should be in the core of NTLP. I also understand the problem with the more complex interface to signaling application. But I assume this heavily depends on how you implement it. > I'd invite people who think that the NTLP should contain standardised > (i.e. non-implementation specific) functionality to do something related > to state management to say what that functionality should be. The functionality should include refreshing, removing state in case of failure (timeout). In the perspective of "context transfer" having generalized state management makes a lot of sense to have generic state transfer. What I currently cannot judge is what variety of state management is needed for the different signaling application. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 20 19:07:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15006 for ; Thu, 20 Mar 2003 19:07:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L0Q0V10635 for nsis-archive@odin.ietf.org; Thu, 20 Mar 2003 19:26:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L0PuO10620; Thu, 20 Mar 2003 19:25:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L0KPO10400 for ; Thu, 20 Mar 2003 19:20:25 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14719 for ; Thu, 20 Mar 2003 19:00:43 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Mar 2003 00:02:59 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0AE6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Fri, 21 Mar 2003 00:02:49 -0000 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 www1.ietf.org id h2L0KPO10401 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi marcus, > --On Dienstag, 18. März 2003 23:29 +0000 "Hancock, Robert" > wrote: > > > Dear all, > > > > As discussed in today's session, there may or may not be an > open issue > > about how much the NTLP should 'know' or 'do' about > providing a state > > management service to signalling applications, or being aware that > > signalling applications are using the NTLP to do state > management. (Note > > that this is entirely not about state that the NTLP uses > internally, e.g. > > to route messages correctly.) > > > > The actual problem is that signaling is not only about state > management as > some people think. It involved also the triggering of > functionality on the > nodes using the state as argument. true. however, the triggering of the functionality is certainly not part of the NTLP, and technically not part of the NSLP either - it's something that the signalling application does in an implementation-specific way. > > If state management is not part of NTLP I do not see what > NTLP is doing > more than only forwarding signaling messages. i would be quite happy to see the NTLP doing no more than forwarding signalling messages. > > > The pure question of whether the NTLP treats a refresh message > > differently from a 'new' message could be considered a node-internal > > implementation issue - provided you only expect this > treatment to take > > place at nodes processing that signalling application and not > > intermediate ones. Consider a possible example: 1. The NTLP > design is > > such that downstream (sender-->receiver) messages will be sent in > > end-to-end addressed router-alerting PATH-like packets. 2. > An signalling > > application which generates a downstream message which is > basically a > > refresh will have that message seen at every downstream > node. 3. Any node > > which doesn't support that signalling application (i.e. not > including the > > message sender) will have no choice but to forward that message > > immediately. Network desynchronisation actions can only be > taken at the > > signalling application aware nodes. > > > > Are we worried about this sort of thing? I'd be very happy > with the 'NTLP > > is 100% ignorant of signalling application state > management' approach. > > However, some people might see it as a departure from 'typical' RSVP > > behaviour. It's also clearly different from the original > CSTP proposal > > (e.g. section 2.2 of Bob's 2 level draft). > > > > In RSVP it is just fully integrated. IMHO state management > should be in the > core of NTLP. I also understand the problem with the more > complex interface > to signaling application. But I assume this heavily depends > on how you > implement it. > > > I'd invite people who think that the NTLP should contain > standardised > > (i.e. non-implementation specific) functionality to do > something related > > to state management to say what that functionality should be. > > The functionality should include refreshing, removing state > in case of > failure (timeout). OK, the big question: why? why can't the signalling application do this? it can generate refreshes (which are just messages for the NTLP to send); it can put time values in its data objects (which are opaque to the NTLP) and use them to set timeout failures. Why make this explicit in the NTLP behaviour? > In the perspective of "context transfer" having > generalized state management makes a lot of sense to have > generic state > transfer. ok, but this would be a seamoby question. i suppose you can see a CT protocol as a counterpart of the NTLP which moves context sideways rather than longitudinally. however, so far as i am aware, the current seamoby proposal just moves data blocks and doesn't do any actual 'management' (since it's essentially a single shot process, there isn't much call for it to do so). > > What I currently cannot judge is what variety of state > management is needed > for the different signaling application. exactly. and the fact that this is a hard question implies to me that building assumptions about this into the NTLP would be a bad idea. > > Marcus > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Mar 26 04:28:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19175 for ; Wed, 26 Mar 2003 04:28:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q9mnJ12549 for nsis-archive@odin.ietf.org; Wed, 26 Mar 2003 04:48:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9mdO12531; Wed, 26 Mar 2003 04:48:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9lPO12484 for ; Wed, 26 Mar 2003 04:47:25 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19095 for ; Wed, 26 Mar 2003 04:26:11 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2Q9R2U16107 for ; Wed, 26 Mar 2003 11:27:02 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Mar 2003 11:28:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 11:28:30 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 11:28:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] state management question Date: Wed, 26 Mar 2003 11:28:29 +0200 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcLtpoDQQnaZWmrxQWCtVaDzyDdY9wF0yOFQ To: , X-OriginalArrivalTime: 26 Mar 2003 09:28:29.0946 (UTC) FILETIME=[0FFAF5A0:01C2F37A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2Q9lPO12485 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Robert, > As discussed in today's session, there may or may not be an > open issue about how much the NTLP should 'know' or 'do' > about providing a state management service to signalling > applications, or being aware that signalling applications are > using the NTLP to do state management. (Note that this is > entirely not about state that the NTLP uses internally, e.g. > to route messages correctly.) So, I've been scratching my head about this question. In my opinion (not as WG chair), my thoughts have been that NTLP would transport the application state between NSIS entities. NTLP could/should be responsible for handling refreshes, expiration of the state; teardown of the NTLP sessions. However, your question to the list is a bit too abstract for me to fully 'get' at what you are asking. Could you try to rephrase it, maybe with concrete examples? Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Mar 26 05:15:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20338 for ; Wed, 26 Mar 2003 05:15:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QAaMF15815 for nsis-archive@odin.ietf.org; Wed, 26 Mar 2003 05:36:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QAaFO15807; Wed, 26 Mar 2003 05:36:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QAZDO15757 for ; Wed, 26 Mar 2003 05:35:13 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20313 for ; Wed, 26 Mar 2003 05:13:58 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QAGHHQ023925; Wed, 26 Mar 2003 11:16:17 +0100 (MET) 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.2655.55) id HMMSTHPG; Wed, 26 Mar 2003 11:16:14 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 11:16:04 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9D4@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] state management question Date: Wed, 26 Mar 2003 11:15:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John >> In my opinion >> (not as WG chair), my thoughts have been that NTLP would transport >> the application state between NSIS entities. NTLP could/should be >> responsible for handling refreshes, expiration of the state; teardown >> of the NTLP sessions. Regarding NTLP state management, I have the same opinion as you have! However, there might be situations where the NTLP will not have to install and maintain a NTLP state into a node. Please see: http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-01.txt Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 27 02:17:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17841 for ; Thu, 27 Mar 2003 02:17:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R7cXk24567 for nsis-archive@odin.ietf.org; Thu, 27 Mar 2003 02:38:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7cSO24534; Thu, 27 Mar 2003 02:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7b9O23792 for ; Thu, 27 Mar 2003 02:37:09 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17530 for ; Thu, 27 Mar 2003 02:15:28 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2R7GLU26272 for ; Thu, 27 Mar 2003 09:16:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Mar 2003 09:17:46 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Mar 2003 09:17:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Mar 2003 09:17:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 27 Mar 2003 09:17:39 +0200 Message-ID: Thread-Topic: [NSIS] state management question Thread-Index: AcLzgMCqORzzxzlJSXC6Rm+oU97OvgAr4qxw To: X-OriginalArrivalTime: 27 Mar 2003 07:17:39.0926 (UTC) FILETIME=[F36AB760:01C2F430] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2R7b9O23793 Subject: [NSIS] Note takers? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Could anyone who took notes at the NSIS wg meeting please send them to me. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 27 02:25:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18326 for ; Thu, 27 Mar 2003 02:25:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R7l9L24904 for nsis-archive@odin.ietf.org; Thu, 27 Mar 2003 02:47:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7l4O24893; Thu, 27 Mar 2003 02:47:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R7kuO24871 for ; Thu, 27 Mar 2003 02:46:56 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18312 for ; Thu, 27 Mar 2003 02:25:14 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 07:27:35 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0B9C@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] state management question Date: Thu, 27 Mar 2003 07:27:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , john, let's see what i can do. > > > As discussed in today's session, there may or may not be an > > open issue about how much the NTLP should 'know' or 'do' > > about providing a state management service to signalling > > applications, or being aware that signalling applications are > > using the NTLP to do state management. (Note that this is > > entirely not about state that the NTLP uses internally, e.g. > > to route messages correctly.) > > So, I've been scratching my head about this question. In my opinion > (not as WG chair), my thoughts have been that NTLP would transport > the application state between NSIS entities. First alert: it's clear that the NTLP would transport signalling application data between NEs. Some of that information may or may not sometimes be state related (does sending ResvConf count as 'transporting state'?); in fact, whether or not it's state related depends on what the receiving application does with it. The question is whether the NTLP contains special functions (message types, sequences) to deal with state refreshing and so on. > NTLP could/should be > responsible for handling refreshes, expiration of the state; teardown > of the NTLP sessions. So, many signalling applications may periodically send the same information (semantically but not necessarily bitwise identical). You don't need to know this in the NTLP for it to work, the signalling application just invokes it periodically. There is nothing to stop you developing an NTLP implementation which includes code to repeat messages, and to filter the repetitions it receives. It would do this as a service to local signalling applications (they get less interrupt load, simpler timer management and so on). However, it would interoperate perfectly with a simpler implementation which left all this up to the signalling application. A clever implementation could even do message jittering, and time the messages to coincide with any NTLP-internal refresh messages. In the simple case where the signalling application peers are also NTLP peers (i.e. no intermediate NTLP-only nodes) this may be all we need. In other words, all this state management stuff is just implementation stuff. I think this is the point Mike raised in SF, and Henning in New York. In that case, there's no need to contaminate the protocol discussion with it (so far as I can tell), and it probably hurts more than helps to do so. When you do have intermediate NTLP-only nodes, the question arises whether they should do something clever by knowing the state management semantics of the messages carried (e.g. jitter them, generate them at different rates). If we think they should (and this is quite unclear to me), we should define what those functions are and what information is needed at the NTLP to make them possible. To make it concrete in this case: - should the NTLP contain fields which are refresh times? always? sometimes? - should the NTLP have a bit in its header which distinguishes between state refreshing and other messages? - should the NTLP make up its own mind whether to acknowledge state creation or deletion messages? ... and so on. > > However, your question to the list is a bit too abstract for me > to fully 'get' at what you are asking. Could you try to rephrase > it, maybe with concrete examples? > > Thanks, > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Mar 27 03:52:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20277 for ; Thu, 27 Mar 2003 03:52:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R9DMR31442 for nsis-archive@odin.ietf.org; Thu, 27 Mar 2003 04:13:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R9DGO31434; Thu, 27 Mar 2003 04:13:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R9CaO31404 for ; Thu, 27 Mar 2003 04:12:36 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20270 for ; Thu, 27 Mar 2003 03:50:52 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Mar 2003 09:51:18 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 09:51:17 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B419@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Thu, 27 Mar 2003 09:51:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2R9CaO31405 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Robert, my answers on your final questions in line. I've added some text on the message sequence number mechanism, which I think is another issue raising concerns. Regards, Rüdiger | To make it concrete in this case: | - should the NTLP contain fields which are refresh times? | always? sometimes? Don't think so. Local time information should be used to maintain state only. Also a refresh reduction mechanism shouldn't require timestamps to be transmitted. If possible. | - should the NTLP have a bit in its header which | distinguishes between state refreshing and other messages? As the refresh message initiates completely new state in the case of a route change in new routers, the refreshes shouldn't be "marked". Your idea is to distinguish between a refresh of state and a modification of this state? Valid Point. It may be more useful to have "state set up & modification" messages instead of "state set up & refresh" messages. The NLTP receiving a "state set up" with an already existing session ID knows that this is a refresh and acts accordingly. | - should the NTLP make up its own mind whether to acknowledge | state creation or deletion messages? The fast answer is: no, that's an issue of NSLP. It gets tricky should NTLP maintain state also for services without local NSLP support (the NTLP relay case). I think we should clarify what these NTLP relay nodes are supposed to do with messages they have no NSLP support for. Or whether we allow such a NTLP relay function at all. My personal feeling is: - NTLP relay may be useful. - NTLP service state maintenance only if NSLP is present. In this case, each NTLP node must interpret the NSLP field of a "state set up" message first and then check the session ID. A concern I have is whether to maintain sequence numbers in NTLP or NSLP only or whether to maintain them on both layers. If refreshes are handled by NTLP only, NTLP must be aware of the sequence numbers. It must maintain the service specific sequence numbering mechanism too. In the case of an NTLP relay, there's no service specific state, hence there's no sequence number maintenance (for relayed messages). It might be advantageous to let the sequence number mechanism count messages between adjacent NTLP peers only. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 08:48:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06397 for ; Mon, 31 Mar 2003 08:48:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEBuw05227 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 09:11:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEBiO05217; Mon, 31 Mar 2003 09:11:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEAeO05180 for ; Mon, 31 Mar 2003 09:10:40 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06353 for ; Mon, 31 Mar 2003 08:46:53 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VDnIUE024719 for ; Mon, 31 Mar 2003 15:49:18 +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.2655.55) id 2AGQ63Z7; Mon, 31 Mar 2003 15:49:19 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 15:48:57 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9E7@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 15:48:48 +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 www1.ietf.org id h2VEAeO05181 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all Since the RSVPv1 (RFC2205) refresh procedure and the management of refresh timers work quite well I think that it should be reasonable to try and reuse them in NTLP. Best Regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: donderdag 27 maart 2003 9:51 To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Robert, my answers on your final questions in line. I've added some text on the message sequence number mechanism, which I think is another issue raising concerns. Regards, Rüdiger | To make it concrete in this case: | - should the NTLP contain fields which are refresh times? | always? sometimes? Don't think so. Local time information should be used to maintain state only. Also a refresh reduction mechanism shouldn't require timestamps to be transmitted. If possible. | - should the NTLP have a bit in its header which | distinguishes between state refreshing and other messages? As the refresh message initiates completely new state in the case of a route change in new routers, the refreshes shouldn't be "marked". Your idea is to distinguish between a refresh of state and a modification of this state? Valid Point. It may be more useful to have "state set up & modification" messages instead of "state set up & refresh" messages. The NLTP receiving a "state set up" with an already existing session ID knows that this is a refresh and acts accordingly. | - should the NTLP make up its own mind whether to acknowledge | state creation or deletion messages? The fast answer is: no, that's an issue of NSLP. It gets tricky should NTLP maintain state also for services without local NSLP support (the NTLP relay case). I think we should clarify what these NTLP relay nodes are supposed to do with messages they have no NSLP support for. Or whether we allow such a NTLP relay function at all. My personal feeling is: - NTLP relay may be useful. - NTLP service state maintenance only if NSLP is present. In this case, each NTLP node must interpret the NSLP field of a "state set up" message first and then check the session ID. A concern I have is whether to maintain sequence numbers in NTLP or NSLP only or whether to maintain them on both layers. If refreshes are handled by NTLP only, NTLP must be aware of the sequence numbers. It must maintain the service specific sequence numbering mechanism too. In the case of an NTLP relay, there's no service specific state, hence there's no sequence number maintenance (for relayed messages). It might be advantageous to let the sequence number mechanism count messages between adjacent NTLP peers only. _______________________________________________ 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 mailnull@www1.ietf.org Mon Mar 31 09:23:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07135 for ; Mon, 31 Mar 2003 09:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEkH607525 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 09:46:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEkBO07505; Mon, 31 Mar 2003 09:46:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEjpO07478 for ; Mon, 31 Mar 2003 09:45:51 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07094 for ; Mon, 31 Mar 2003 09:22:03 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1900D5-00074X-00; Mon, 31 Mar 2003 16:24:27 +0200 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1900D1-0001HT-00; Mon, 31 Mar 2003 16:24:23 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:1:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1900D2-000298-00; Mon, 31 Mar 2003 16:24:24 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 1900D2-0001Yg-00; Mon, 31 Mar 2003 16:24:24 +0200 Date: Mon, 31 Mar 2003 16:24:24 +0200 From: Roland Bless To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: Re: [NSIS] state management question Message-Id: <20030331162424.31412797.bless@tm.uka.de> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB9E7@enleent103.nl.eu.ericsson.se> References: <2B06CD3FC17AF64587BC7A7617B230C0CBB9E7@enleent103.nl.eu.ericsson.se> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VEjpO07479 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios, On Mon, 31 Mar 2003 15:48:48 +0200 "Georgios Karagiannis (ELN)" wrote: > Since the RSVPv1 (RFC2205) refresh procedure and the management of refresh > timers work quite well I think that it should be reasonable to try and > reuse them in NTLP. Sorry, I disagree here if you do not include RFC 2961 as well. If I remember correctly, there was a consensus to use at least both 2205+2961 as a starting point. Regards, Roland > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 27 maart 2003 9:51 > To: robert.hancock@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Robert, > > my answers on your final questions in line. I've > added some text on the message sequence number > mechanism, which I think is another issue > raising concerns. > > Regards, Rüdiger > > > | To make it concrete in this case: > | - should the NTLP contain fields which are refresh times? > | always? sometimes? > > Don't think so. Local time information should be used to > maintain state only. Also a refresh reduction mechanism > shouldn't require timestamps to be transmitted. If possible. > > | - should the NTLP have a bit in its header which > | distinguishes between state refreshing and other messages? > > As the refresh message initiates completely new state in the > case of a route change in new routers, the refreshes > shouldn't be "marked". Your idea is to distinguish between a > refresh of state and a modification of this state? > Valid Point. It may be more useful to have > "state set up & modification" messages instead of > "state set up & refresh" messages. The NLTP > receiving a "state set up" with an already existing session > ID knows that this is a refresh and acts accordingly. > > | - should the NTLP make up its own mind whether to acknowledge > | state creation or deletion messages? > > The fast answer is: no, that's an issue of NSLP. It gets > tricky should NTLP maintain state also for services without > local NSLP support (the NTLP relay case). I think we should > clarify what these NTLP relay nodes are supposed to do with > messages they have no NSLP support for. Or whether we > allow such a NTLP relay function at all. My personal > feeling is: > - NTLP relay may be useful. > - NTLP service state maintenance only if NSLP is present. > In this case, each NTLP node must interpret the NSLP field > of a "state set up" message first and then check the > session ID. > > A concern I have is whether to maintain sequence numbers in > NTLP or NSLP only or whether to maintain them on both > layers. If refreshes are handled by NTLP only, NTLP must > be aware of the sequence numbers. It must maintain the > service specific sequence numbering mechanism too. In the > case of an NTLP relay, there's no service specific state, > hence there's no sequence number maintenance (for relayed > messages). It might be advantageous to let the sequence > number mechanism count messages between adjacent NTLP > peers only. > > _______________________________________________ > 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 -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 09:26:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07304 for ; Mon, 31 Mar 2003 09:26:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEo8S07758 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 09:50:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEo2O07745; Mon, 31 Mar 2003 09:50:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEngO07714 for ; Mon, 31 Mar 2003 09:49:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07268 for ; Mon, 31 Mar 2003 09:25:54 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VESJrs010200; Mon, 31 Mar 2003 16:28:19 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A480Z6J; Mon, 31 Mar 2003 16:28:20 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:18:19 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9EC@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Roland Bless'" Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:27:49 +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 www1.ietf.org id h2VEngO07715 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Roland RFC2961 describes an optimization procedure! Best Regards, georgios -----Original Message----- From: Roland Bless [mailto:bless@tm.uka.de] Sent: maandag 31 maart 2003 16:24 To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: Re: [NSIS] state management question Hi Georgios, On Mon, 31 Mar 2003 15:48:48 +0200 "Georgios Karagiannis (ELN)" wrote: > Since the RSVPv1 (RFC2205) refresh procedure and the management of refresh > timers work quite well I think that it should be reasonable to try and > reuse them in NTLP. Sorry, I disagree here if you do not include RFC 2961 as well. If I remember correctly, there was a consensus to use at least both 2205+2961 as a starting point. Regards, Roland > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 27 maart 2003 9:51 > To: robert.hancock@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Robert, > > my answers on your final questions in line. I've > added some text on the message sequence number > mechanism, which I think is another issue > raising concerns. > > Regards, Rüdiger > > > | To make it concrete in this case: > | - should the NTLP contain fields which are refresh times? > | always? sometimes? > > Don't think so. Local time information should be used to > maintain state only. Also a refresh reduction mechanism > shouldn't require timestamps to be transmitted. If possible. > > | - should the NTLP have a bit in its header which > | distinguishes between state refreshing and other messages? > > As the refresh message initiates completely new state in the > case of a route change in new routers, the refreshes > shouldn't be "marked". Your idea is to distinguish between a > refresh of state and a modification of this state? > Valid Point. It may be more useful to have > "state set up & modification" messages instead of > "state set up & refresh" messages. The NLTP > receiving a "state set up" with an already existing session > ID knows that this is a refresh and acts accordingly. > > | - should the NTLP make up its own mind whether to acknowledge > | state creation or deletion messages? > > The fast answer is: no, that's an issue of NSLP. It gets > tricky should NTLP maintain state also for services without > local NSLP support (the NTLP relay case). I think we should > clarify what these NTLP relay nodes are supposed to do with > messages they have no NSLP support for. Or whether we > allow such a NTLP relay function at all. My personal > feeling is: > - NTLP relay may be useful. > - NTLP service state maintenance only if NSLP is present. > In this case, each NTLP node must interpret the NSLP field > of a "state set up" message first and then check the > session ID. > > A concern I have is whether to maintain sequence numbers in > NTLP or NSLP only or whether to maintain them on both > layers. If refreshes are handled by NTLP only, NTLP must > be aware of the sequence numbers. It must maintain the > service specific sequence numbering mechanism too. In the > case of an NTLP relay, there's no service specific state, > hence there's no sequence number maintenance (for relayed > messages). It might be advantageous to let the sequence > number mechanism count messages between adjacent NTLP > peers only. > > _______________________________________________ > 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 -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 09:35:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07575 for ; Mon, 31 Mar 2003 09:35:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEwLo08172 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 09:58:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEwFO08157; Mon, 31 Mar 2003 09:58:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEv9O08099 for ; Mon, 31 Mar 2003 09:57:09 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07547 for ; Mon, 31 Mar 2003 09:33:22 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VEZi4c010067; Mon, 31 Mar 2003 06:35:45 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFI82870; Mon, 31 Mar 2003 06:35:43 -0800 (PST) Message-Id: <200303311435.AFI82870@mira-sjc5-c.cisco.com> To: Roland Bless cc: "Georgios Karagiannis (ELN)" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] state management question In-Reply-To: Message from bless@tm.uka.de of "Mon, 31 Mar 2003 16:24:24 +0200." <20030331162424.31412797.bless@tm.uka.de> Date: Mon, 31 Mar 2003 09:35:43 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Sorry, I disagree here if you do not include RFC 2961 as well. > If I remember correctly, there was a consensus to use at least > both 2205+2961 as a starting point. That is correct, although that decision should probably be confirmed on the mailing list. I don't recall anybody voicing objection to it at the meeting. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 09:40:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07748 for ; Mon, 31 Mar 2003 09:40:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VF49k08415 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:04:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VF44O08391; Mon, 31 Mar 2003 10:04:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VF3cO08365 for ; Mon, 31 Mar 2003 10:03:38 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07727 for ; Mon, 31 Mar 2003 09:39:50 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 15:42:14 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8F4@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 15:42:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VF3cO08366 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi Rüdiger, i think i (personally) sympathise with more than 50% of your answers, which i summarise as: *) NTLP messages don't have visible timing information *) the NTLP doesn't make up its own mind about whether to acknowledge messages. on the 'special treatment for refresh' this seems to be the most interesting case, but where you say '... knows this is a refresh and acts accordingly' what does 'accordingly' mean? how can the NTLP know it is allowed to do something special other than treating the message with less urgency (which then implies knowing about timing information...) you are right to emphasise the difference in the cases where there is/isn't an NTLP-only relay in the picture. my interpretation of what you say is that where there is a relay, it shouldn't do state management (which is yet another reason why the NTLP itself shouldn't do state management). your comments on sequence numbering are interesting but I think closer to protocol design than [I want|I am allowed|it is sensible to get] in this discussion. cheers, robert h. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 27 March 2003 08:51 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Robert, > > my answers on your final questions in line. I've > added some text on the message sequence number > mechanism, which I think is another issue > raising concerns. > > Regards, Rüdiger > > > | To make it concrete in this case: > | - should the NTLP contain fields which are refresh times? > | always? sometimes? > > Don't think so. Local time information should be used to > maintain state only. Also a refresh reduction mechanism > shouldn't require timestamps to be transmitted. If possible. > > | - should the NTLP have a bit in its header which > | distinguishes between state refreshing and other messages? > > As the refresh message initiates completely new state in the > case of a route change in new routers, the refreshes > shouldn't be "marked". Your idea is to distinguish between a > refresh of state and a modification of this state? > Valid Point. It may be more useful to have > "state set up & modification" messages instead of > "state set up & refresh" messages. The NLTP > receiving a "state set up" with an already existing session > ID knows that this is a refresh and acts accordingly. > > | - should the NTLP make up its own mind whether to acknowledge > | state creation or deletion messages? > > The fast answer is: no, that's an issue of NSLP. It gets > tricky should NTLP maintain state also for services without > local NSLP support (the NTLP relay case). I think we should > clarify what these NTLP relay nodes are supposed to do with > messages they have no NSLP support for. Or whether we > allow such a NTLP relay function at all. My personal > feeling is: > - NTLP relay may be useful. > - NTLP service state maintenance only if NSLP is present. > In this case, each NTLP node must interpret the NSLP field > of a "state set up" message first and then check the > session ID. > > A concern I have is whether to maintain sequence numbers in > NTLP or NSLP only or whether to maintain them on both > layers. If refreshes are handled by NTLP only, NTLP must > be aware of the sequence numbers. It must maintain the > service specific sequence numbering mechanism too. In the > case of an NTLP relay, there's no service specific state, > hence there's no sequence number maintenance (for relayed > messages). It might be advantageous to let the sequence > number mechanism count messages between adjacent NTLP > peers only. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 09:40:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07762 for ; Mon, 31 Mar 2003 09:40:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VF4AG08429 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:04:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VF46O08407; Mon, 31 Mar 2003 10:04:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VF3lO08371 for ; Mon, 31 Mar 2003 10:03:47 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07731 for ; Mon, 31 Mar 2003 09:39:59 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 15:42:24 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8F5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 15:42:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VF3lO08372 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit georgios, two questions: *) regardless of whether the general idea of soft stateness is good and how well it works in RSVP, why support it explicitly in the NTLP - why isn't this a signalling application issue? if something is needed in the NTLP, why isn't it an implementation issue? *) assuming the answer is still 'it is meaningfully part of the NTLP', what kind of detectable impact on the actual protocol would you expect it to have? what i'm trying to make progress from is the generalised view 'let's put soft state in the NTLP' and turn that into a concrete statement whose impact on the framework can be evaluated. at the moment, it seems to be a matter of opinion whether the question has no meaning or very deep meaning (at least to me). robert h. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 14:49 > To: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi all > > Since the RSVPv1 (RFC2205) refresh procedure and the > management of refresh > timers work quite well I think that it should be reasonable > to try and > reuse them in NTLP. > > Best Regards, > Georgios > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 27 maart 2003 9:51 > To: robert.hancock@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Robert, > > my answers on your final questions in line. I've > added some text on the message sequence number > mechanism, which I think is another issue > raising concerns. > > Regards, Rüdiger > > > | To make it concrete in this case: > | - should the NTLP contain fields which are refresh times? > | always? sometimes? > > Don't think so. Local time information should be used to > maintain state only. Also a refresh reduction mechanism > shouldn't require timestamps to be transmitted. If possible. > > | - should the NTLP have a bit in its header which > | distinguishes between state refreshing and other messages? > > As the refresh message initiates completely new state in the > case of a route change in new routers, the refreshes > shouldn't be "marked". Your idea is to distinguish between a > refresh of state and a modification of this state? > Valid Point. It may be more useful to have > "state set up & modification" messages instead of > "state set up & refresh" messages. The NLTP > receiving a "state set up" with an already existing session > ID knows that this is a refresh and acts accordingly. > > | - should the NTLP make up its own mind whether to acknowledge > | state creation or deletion messages? > > The fast answer is: no, that's an issue of NSLP. It gets > tricky should NTLP maintain state also for services without > local NSLP support (the NTLP relay case). I think we should > clarify what these NTLP relay nodes are supposed to do with > messages they have no NSLP support for. Or whether we > allow such a NTLP relay function at all. My personal > feeling is: > - NTLP relay may be useful. > - NTLP service state maintenance only if NSLP is present. > In this case, each NTLP node must interpret the NSLP field > of a "state set up" message first and then check the > session ID. > > A concern I have is whether to maintain sequence numbers in > NTLP or NSLP only or whether to maintain them on both > layers. If refreshes are handled by NTLP only, NTLP must > be aware of the sequence numbers. It must maintain the > service specific sequence numbering mechanism too. In the > case of an NTLP relay, there's no service specific state, > hence there's no sequence number maintenance (for relayed > messages). It might be advantageous to let the sequence > number mechanism count messages between adjacent NTLP > peers only. > > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Mar 31 09:44:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07839 for ; Mon, 31 Mar 2003 09:44:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VF8C109351 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:08:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VF84O09337; Mon, 31 Mar 2003 10:08:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VF7YO09198 for ; Mon, 31 Mar 2003 10:07:34 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07813 for ; Mon, 31 Mar 2003 09:43:46 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VEk8rs015232; Mon, 31 Mar 2003 16:46:08 +0200 (MEST) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4RBPC1; Mon, 31 Mar 2003 16:46:09 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:36:08 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9EE@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:45: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-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda I am not against on combining RFC2205 and RFC2961 for providing state management, but in my opinion RFC2961 is used as an optimization solution and therefore, it should not be stated as a mandatory solution, but as an optional solution! Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: maandag 31 maart 2003 16:36 To: Roland Bless Cc: Georgios Karagiannis (ELN); nsis@ietf.org Subject: Re: [NSIS] state management question > Sorry, I disagree here if you do not include RFC 2961 as well. > If I remember correctly, there was a consensus to use at least > both 2205+2961 as a starting point. That is correct, although that decision should probably be confirmed on the mailing list. I don't recall anybody voicing objection to it at the meeting. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 09:59:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08242 for ; Mon, 31 Mar 2003 09:59:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFMQH10141 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:22:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFMLO10092; Mon, 31 Mar 2003 10:22:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFLZO10025 for ; Mon, 31 Mar 2003 10:21:35 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08193 for ; Mon, 31 Mar 2003 09:57:42 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:00:07 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8F6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:00:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , i support this consensus view. i.e. some functionality like that of 2961 should be part of our overall solution, and some parts of 2961 should be replicated in the NTLP. (whether they should be mandatory/optional to implement/use is a question we'll get on to.) my reading of 2961 is that it doesn't change the underlying concepts of soft state maintenance *within* nodes, but it provides some 'lower layer' functions which make it possible to issue refreshes more efficiently. (i believe a mandatory NACK and optional ACK; in general I think you need one and then the other is an optimisation.) one facet of the question before us is therefore: should the NTLP do the equivalent of decision making between summary and full refreshes (knowing when each is appropriate and sending the appropriate messages to make it happen); or, should it just provide transport-like functions (ACK and/or NACK) to enable a soft-state-based signalling application to reduce the refresh load it generates; or, should it do neither. (my preference at the moment is the second, certainly not the first.) cheers, robert h. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 31 March 2003 15:36 > To: Roland Bless > Cc: Georgios Karagiannis (ELN); nsis@ietf.org > Subject: Re: [NSIS] state management question > > > > Sorry, I disagree here if you do not include RFC 2961 as well. > > If I remember correctly, there was a consensus to use at least > > both 2205+2961 as a starting point. > > That is correct, although that decision should probably be > confirmed on the mailing list. I don't recall anybody > voicing objection to it at the meeting. > > Melinda > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Mar 31 10:02:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08450 for ; Mon, 31 Mar 2003 10:02:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFQGx10365 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:26:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFQ3O10336; Mon, 31 Mar 2003 10:26:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFPxO10319 for ; Mon, 31 Mar 2003 10:25:59 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08400 for ; Mon, 31 Mar 2003 10:02:10 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VF4ZUE018926; Mon, 31 Mar 2003 17:04:35 +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.2655.55) id 2A4KH6PG; Mon, 31 Mar 2003 17:04:36 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:54:35 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9F1@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 17:04:05 +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 www1.ietf.org id h2VFPxO10320 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert The NTLP states are in my opinion different than the NSLP states. The NTLP states are more associated with forwarding behavior and the NSLP application states are reservation states. One can use the NTLP state management procedure to maintain the NSLP (reservation) states, but this cannot be done the other way around! This is for example valid when not all NSIS nodes support NSLP functionality (but they support NTLP functionality). Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: maandag 31 maart 2003 16:42 To: Georgios Karagiannis (ELN); nsis@ietf.org Subject: RE: [NSIS] state management question georgios, two questions: *) regardless of whether the general idea of soft stateness is good and how well it works in RSVP, why support it explicitly in the NTLP - why isn't this a signalling application issue? if something is needed in the NTLP, why isn't it an implementation issue? *) assuming the answer is still 'it is meaningfully part of the NTLP', what kind of detectable impact on the actual protocol would you expect it to have? what i'm trying to make progress from is the generalised view 'let's put soft state in the NTLP' and turn that into a concrete statement whose impact on the framework can be evaluated. at the moment, it seems to be a matter of opinion whether the question has no meaning or very deep meaning (at least to me). robert h. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 14:49 > To: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi all > > Since the RSVPv1 (RFC2205) refresh procedure and the > management of refresh > timers work quite well I think that it should be reasonable > to try and > reuse them in NTLP. > > Best Regards, > Georgios > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 27 maart 2003 9:51 > To: robert.hancock@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Robert, > > my answers on your final questions in line. I've > added some text on the message sequence number > mechanism, which I think is another issue > raising concerns. > > Regards, Rüdiger > > > | To make it concrete in this case: > | - should the NTLP contain fields which are refresh times? > | always? sometimes? > > Don't think so. Local time information should be used to > maintain state only. Also a refresh reduction mechanism > shouldn't require timestamps to be transmitted. If possible. > > | - should the NTLP have a bit in its header which > | distinguishes between state refreshing and other messages? > > As the refresh message initiates completely new state in the > case of a route change in new routers, the refreshes > shouldn't be "marked". Your idea is to distinguish between a > refresh of state and a modification of this state? > Valid Point. It may be more useful to have > "state set up & modification" messages instead of > "state set up & refresh" messages. The NLTP > receiving a "state set up" with an already existing session > ID knows that this is a refresh and acts accordingly. > > | - should the NTLP make up its own mind whether to acknowledge > | state creation or deletion messages? > > The fast answer is: no, that's an issue of NSLP. It gets > tricky should NTLP maintain state also for services without > local NSLP support (the NTLP relay case). I think we should > clarify what these NTLP relay nodes are supposed to do with > messages they have no NSLP support for. Or whether we > allow such a NTLP relay function at all. My personal > feeling is: > - NTLP relay may be useful. > - NTLP service state maintenance only if NSLP is present. > In this case, each NTLP node must interpret the NSLP field > of a "state set up" message first and then check the > session ID. > > A concern I have is whether to maintain sequence numbers in > NTLP or NSLP only or whether to maintain them on both > layers. If refreshes are handled by NTLP only, NTLP must > be aware of the sequence numbers. It must maintain the > service specific sequence numbering mechanism too. In the > case of an NTLP relay, there's no service specific state, > hence there's no sequence number maintenance (for relayed > messages). It might be advantageous to let the sequence > number mechanism count messages between adjacent NTLP > peers only. > > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Mar 31 10:03:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08650 for ; Mon, 31 Mar 2003 10:03:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFRDx10495 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:27:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFR7O10425; Mon, 31 Mar 2003 10:27:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFQFO10360 for ; Mon, 31 Mar 2003 10:26:15 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08411 for ; Mon, 31 Mar 2003 10:02:21 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1900q5-0007Dz-00; Mon, 31 Mar 2003 17:04:45 +0200 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1900q1-0005E4-00; Mon, 31 Mar 2003 17:04:41 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:1:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1900q5-0003Ax-00; Mon, 31 Mar 2003 17:04:45 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 1900q5-0002Rp-00; Mon, 31 Mar 2003 17:04:45 +0200 Date: Mon, 31 Mar 2003 17:04:45 +0200 From: Roland Bless To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: Re: [NSIS] state management question Message-Id: <20030331170445.6eb0fa23.bless@tm.uka.de> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB9EC@enleent103.nl.eu.ericsson.se> References: <2B06CD3FC17AF64587BC7A7617B230C0CBB9EC@enleent103.nl.eu.ericsson.se> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VFQFO10361 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios > RFC2961 describes an optimization procedure! IMO it describes a number of operational problems and solutions for them due to feedback of implementers and operators. RFC 2961 won't be there if it was pure optimization. However, there may be some environments in which these extensions are not necessarily required. But I got the impression from several discussions that most people think that RFC 2205 alone is not sufficient for most cases. Regards, Roland > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: maandag 31 maart 2003 16:24 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: Re: [NSIS] state management question > > > Hi Georgios, > > On Mon, 31 Mar 2003 15:48:48 +0200 > "Georgios Karagiannis (ELN)" wrote: > > > Since the RSVPv1 (RFC2205) refresh procedure and the management of refresh > > timers work quite well I think that it should be reasonable to try and > > reuse them in NTLP. > > Sorry, I disagree here if you do not include RFC 2961 as well. > If I remember correctly, there was a consensus to use at least > both 2205+2961 as a starting point. > > Regards, > Roland > > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: donderdag 27 maart 2003 9:51 > > To: robert.hancock@roke.co.uk > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Robert, > > > > my answers on your final questions in line. I've > > added some text on the message sequence number > > mechanism, which I think is another issue > > raising concerns. > > > > Regards, Rüdiger > > > > > > | To make it concrete in this case: > > | - should the NTLP contain fields which are refresh times? > > | always? sometimes? > > > > Don't think so. Local time information should be used to > > maintain state only. Also a refresh reduction mechanism > > shouldn't require timestamps to be transmitted. If possible. > > > > | - should the NTLP have a bit in its header which > > | distinguishes between state refreshing and other messages? > > > > As the refresh message initiates completely new state in the > > case of a route change in new routers, the refreshes > > shouldn't be "marked". Your idea is to distinguish between a > > refresh of state and a modification of this state? > > Valid Point. It may be more useful to have > > "state set up & modification" messages instead of > > "state set up & refresh" messages. The NLTP > > receiving a "state set up" with an already existing session > > ID knows that this is a refresh and acts accordingly. > > > > | - should the NTLP make up its own mind whether to acknowledge > > | state creation or deletion messages? > > > > The fast answer is: no, that's an issue of NSLP. It gets > > tricky should NTLP maintain state also for services without > > local NSLP support (the NTLP relay case). I think we should > > clarify what these NTLP relay nodes are supposed to do with > > messages they have no NSLP support for. Or whether we > > allow such a NTLP relay function at all. My personal > > feeling is: > > - NTLP relay may be useful. > > - NTLP service state maintenance only if NSLP is present. > > In this case, each NTLP node must interpret the NSLP field > > of a "state set up" message first and then check the > > session ID. > > > > A concern I have is whether to maintain sequence numbers in > > NTLP or NSLP only or whether to maintain them on both > > layers. If refreshes are handled by NTLP only, NTLP must > > be aware of the sequence numbers. It must maintain the > > service specific sequence numbering mechanism too. In the > > case of an NTLP relay, there's no service specific state, > > hence there's no sequence number maintenance (for relayed > > messages). It might be advantageous to let the sequence > > number mechanism count messages between adjacent NTLP > > peers only. > > > > _______________________________________________ > > 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 > > > -- > Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless > Institute of Telematics, University of Karlsruhe, Germany -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Mar 31 10:12:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09919 for ; Mon, 31 Mar 2003 10:12:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFZLv10913 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:35:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFZDO10855; Mon, 31 Mar 2003 10:35:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFYHO10813 for ; Mon, 31 Mar 2003 10:34:17 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09596 for ; Mon, 31 Mar 2003 10:10:27 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:12:53 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8F7@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:12:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VFYHO10814 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi georgios, you are right to point out this difference. (in the email at the start of the thread: "(Note that this is entirely not about state that the NTLP uses internally, e.g. to route messages correctly.)") so, my question is about the assertion: "One can use the NTLP state management procedure to maintain the NSLP reservation) states" (can one really? is it a good idea? is it more than an implementation issue?) especially, if it is more than an implementation issue, ***what is the actual impact on the protocol?*** (in broad terms, or giving an example) cheers, r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 16:04 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi Robert > > The NTLP states are in my opinion different than the > NSLP states. > The NTLP states are more associated with forwarding behavior and > the NSLP application states are reservation states. > One can use the NTLP state management procedure to maintain the > NSLP (reservation) states, but this cannot be done the other > way around! > This is for example valid when not all NSIS nodes support > NSLP functionality > (but they support NTLP functionality). > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 31 maart 2003 16:42 > To: Georgios Karagiannis (ELN); nsis@ietf.org > Subject: RE: [NSIS] state management question > > > georgios, > > two questions: > *) regardless of whether the general idea of soft stateness > is good and how well it works in RSVP, why support it > explicitly in the NTLP - why isn't this a signalling > application issue? if something is needed in the NTLP, why > isn't it an implementation issue? > *) assuming the answer is still 'it is meaningfully part of > the NTLP', what kind of detectable impact on the actual > protocol would you expect it to have? > > what i'm trying to make progress from is the generalised view > 'let's put soft state in the NTLP' and turn that into a > concrete statement whose impact on the framework can be > evaluated. at the moment, it seems to be a matter of opinion > whether the question has no meaning or very deep meaning (at > least to me). > > robert h. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 31 March 2003 14:49 > > To: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Hi all > > > > Since the RSVPv1 (RFC2205) refresh procedure and the > > management of refresh > > timers work quite well I think that it should be reasonable > > to try and > > reuse them in NTLP. > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: donderdag 27 maart 2003 9:51 > > To: robert.hancock@roke.co.uk > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Robert, > > > > my answers on your final questions in line. I've > > added some text on the message sequence number > > mechanism, which I think is another issue > > raising concerns. > > > > Regards, Rüdiger > > > > > > | To make it concrete in this case: > > | - should the NTLP contain fields which are refresh times? > > | always? sometimes? > > > > Don't think so. Local time information should be used to > > maintain state only. Also a refresh reduction mechanism > > shouldn't require timestamps to be transmitted. If possible. > > > > | - should the NTLP have a bit in its header which > > | distinguishes between state refreshing and other messages? > > > > As the refresh message initiates completely new state in the > > case of a route change in new routers, the refreshes > > shouldn't be "marked". Your idea is to distinguish between a > > refresh of state and a modification of this state? > > Valid Point. It may be more useful to have > > "state set up & modification" messages instead of > > "state set up & refresh" messages. The NLTP > > receiving a "state set up" with an already existing session > > ID knows that this is a refresh and acts accordingly. > > > > | - should the NTLP make up its own mind whether to acknowledge > > | state creation or deletion messages? > > > > The fast answer is: no, that's an issue of NSLP. It gets > > tricky should NTLP maintain state also for services without > > local NSLP support (the NTLP relay case). I think we should > > clarify what these NTLP relay nodes are supposed to do with > > messages they have no NSLP support for. Or whether we > > allow such a NTLP relay function at all. My personal > > feeling is: > > - NTLP relay may be useful. > > - NTLP service state maintenance only if NSLP is present. > > In this case, each NTLP node must interpret the NSLP field > > of a "state set up" message first and then check the > > session ID. > > > > A concern I have is whether to maintain sequence numbers in > > NTLP or NSLP only or whether to maintain them on both > > layers. If refreshes are handled by NTLP only, NTLP must > > be aware of the sequence numbers. It must maintain the > > service specific sequence numbering mechanism too. In the > > case of an NTLP relay, there's no service specific state, > > hence there's no sequence number maintenance (for relayed > > messages). It might be advantageous to let the sequence > > number mechanism count messages between adjacent NTLP > > peers only. > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Mon Mar 31 10:15:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10614 for ; Mon, 31 Mar 2003 10:15:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFd9e11866 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:39:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFd4O11844; Mon, 31 Mar 2003 10:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFcCO11802 for ; Mon, 31 Mar 2003 10:38:12 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10416 for ; Mon, 31 Mar 2003 10:14:22 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VFGlUE021833; Mon, 31 Mar 2003 17:16:47 +0200 (MEST) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A49ALH3; Mon, 31 Mar 2003 17:16:48 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 17:16:27 +0200 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB9F2@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 17:16: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 www1.ietf.org id h2VFcCO11803 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert I do not understand your question. Are you saying that we need to have two refresh management procedures? One for NTLP states and one for NSLP states! Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: maandag 31 maart 2003 17:13 To: Georgios Karagiannis (ELN); nsis@ietf.org Subject: RE: [NSIS] state management question hi georgios, you are right to point out this difference. (in the email at the start of the thread: "(Note that this is entirely not about state that the NTLP uses internally, e.g. to route messages correctly.)") so, my question is about the assertion: "One can use the NTLP state management procedure to maintain the NSLP reservation) states" (can one really? is it a good idea? is it more than an implementation issue?) especially, if it is more than an implementation issue, ***what is the actual impact on the protocol?*** (in broad terms, or giving an example) cheers, r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 16:04 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi Robert > > The NTLP states are in my opinion different than the > NSLP states. > The NTLP states are more associated with forwarding behavior and > the NSLP application states are reservation states. > One can use the NTLP state management procedure to maintain the > NSLP (reservation) states, but this cannot be done the other > way around! > This is for example valid when not all NSIS nodes support > NSLP functionality > (but they support NTLP functionality). > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 31 maart 2003 16:42 > To: Georgios Karagiannis (ELN); nsis@ietf.org > Subject: RE: [NSIS] state management question > > > georgios, > > two questions: > *) regardless of whether the general idea of soft stateness > is good and how well it works in RSVP, why support it > explicitly in the NTLP - why isn't this a signalling > application issue? if something is needed in the NTLP, why > isn't it an implementation issue? > *) assuming the answer is still 'it is meaningfully part of > the NTLP', what kind of detectable impact on the actual > protocol would you expect it to have? > > what i'm trying to make progress from is the generalised view > 'let's put soft state in the NTLP' and turn that into a > concrete statement whose impact on the framework can be > evaluated. at the moment, it seems to be a matter of opinion > whether the question has no meaning or very deep meaning (at > least to me). > > robert h. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 31 March 2003 14:49 > > To: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Hi all > > > > Since the RSVPv1 (RFC2205) refresh procedure and the > > management of refresh > > timers work quite well I think that it should be reasonable > > to try and > > reuse them in NTLP. > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: donderdag 27 maart 2003 9:51 > > To: robert.hancock@roke.co.uk > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Robert, > > > > my answers on your final questions in line. I've > > added some text on the message sequence number > > mechanism, which I think is another issue > > raising concerns. > > > > Regards, Rüdiger > > > > > > | To make it concrete in this case: > > | - should the NTLP contain fields which are refresh times? > > | always? sometimes? > > > > Don't think so. Local time information should be used to > > maintain state only. Also a refresh reduction mechanism > > shouldn't require timestamps to be transmitted. If possible. > > > > | - should the NTLP have a bit in its header which > > | distinguishes between state refreshing and other messages? > > > > As the refresh message initiates completely new state in the > > case of a route change in new routers, the refreshes > > shouldn't be "marked". Your idea is to distinguish between a > > refresh of state and a modification of this state? > > Valid Point. It may be more useful to have > > "state set up & modification" messages instead of > > "state set up & refresh" messages. The NLTP > > receiving a "state set up" with an already existing session > > ID knows that this is a refresh and acts accordingly. > > > > | - should the NTLP make up its own mind whether to acknowledge > > | state creation or deletion messages? > > > > The fast answer is: no, that's an issue of NSLP. It gets > > tricky should NTLP maintain state also for services without > > local NSLP support (the NTLP relay case). I think we should > > clarify what these NTLP relay nodes are supposed to do with > > messages they have no NSLP support for. Or whether we > > allow such a NTLP relay function at all. My personal > > feeling is: > > - NTLP relay may be useful. > > - NTLP service state maintenance only if NSLP is present. > > In this case, each NTLP node must interpret the NSLP field > > of a "state set up" message first and then check the > > session ID. > > > > A concern I have is whether to maintain sequence numbers in > > NTLP or NSLP only or whether to maintain them on both > > layers. If refreshes are handled by NTLP only, NTLP must > > be aware of the sequence numbers. It must maintain the > > service specific sequence numbering mechanism too. In the > > case of an NTLP relay, there's no service specific state, > > hence there's no sequence number maintenance (for relayed > > messages). It might be advantageous to let the sequence > > number mechanism count messages between adjacent NTLP > > peers only. > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Mon Mar 31 10:31:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11334 for ; Mon, 31 Mar 2003 10:31:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFtGW12932 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:55:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFt9O12924; Mon, 31 Mar 2003 10:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFshO12893 for ; Mon, 31 Mar 2003 10:54:43 -0500 Received: from cbibipnt03.HC.BT.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11314 for ; Mon, 31 Mar 2003 10:30:52 -0500 (EST) From: louise.burness@bt.com Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <2A2CJL77>; Mon, 31 Mar 2003 16:32:59 +0100 Message-ID: To: robert.hancock@roke.co.uk, Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:32:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , if you do: "One can use the NTLP state management procedure to maintain the NSLP reservation) states" Then are you running the risk of losing the benefits of separating out the two protocols in the first place? Louise -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 31 March 2003 16:13 To: 'Georgios Karagiannis (ELN)'; nsis@ietf.org Subject: RE: [NSIS] state management question hi georgios, you are right to point out this difference. (in the email at the start of the thread: "(Note that this is entirely not about state that the NTLP uses internally, e.g. to route messages correctly.)") so, my question is about the assertion: "One can use the NTLP state management procedure to maintain the NSLP reservation) states" (can one really? is it a good idea? is it more than an implementation issue?) especially, if it is more than an implementation issue, ***what is the actual impact on the protocol?*** (in broad terms, or giving an example) cheers, r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 16:04 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi Robert > > The NTLP states are in my opinion different than the > NSLP states. > The NTLP states are more associated with forwarding behavior and > the NSLP application states are reservation states. > One can use the NTLP state management procedure to maintain the > NSLP (reservation) states, but this cannot be done the other > way around! > This is for example valid when not all NSIS nodes support > NSLP functionality > (but they support NTLP functionality). > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 31 maart 2003 16:42 > To: Georgios Karagiannis (ELN); nsis@ietf.org > Subject: RE: [NSIS] state management question > > > georgios, > > two questions: > *) regardless of whether the general idea of soft stateness > is good and how well it works in RSVP, why support it > explicitly in the NTLP - why isn't this a signalling > application issue? if something is needed in the NTLP, why > isn't it an implementation issue? > *) assuming the answer is still 'it is meaningfully part of > the NTLP', what kind of detectable impact on the actual > protocol would you expect it to have? > > what i'm trying to make progress from is the generalised view > 'let's put soft state in the NTLP' and turn that into a > concrete statement whose impact on the framework can be > evaluated. at the moment, it seems to be a matter of opinion > whether the question has no meaning or very deep meaning (at > least to me). > > robert h. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 31 March 2003 14:49 > > To: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Hi all > > > > Since the RSVPv1 (RFC2205) refresh procedure and the > > management of refresh > > timers work quite well I think that it should be reasonable > > to try and > > reuse them in NTLP. > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: donderdag 27 maart 2003 9:51 > > To: robert.hancock@roke.co.uk > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Robert, > > > > my answers on your final questions in line. I've > > added some text on the message sequence number > > mechanism, which I think is another issue > > raising concerns. > > > > Regards, Rüdiger > > > > > > | To make it concrete in this case: > > | - should the NTLP contain fields which are refresh times? > > | always? sometimes? > > > > Don't think so. Local time information should be used to > > maintain state only. Also a refresh reduction mechanism > > shouldn't require timestamps to be transmitted. If possible. > > > > | - should the NTLP have a bit in its header which > > | distinguishes between state refreshing and other messages? > > > > As the refresh message initiates completely new state in the > > case of a route change in new routers, the refreshes > > shouldn't be "marked". Your idea is to distinguish between a > > refresh of state and a modification of this state? > > Valid Point. It may be more useful to have > > "state set up & modification" messages instead of > > "state set up & refresh" messages. The NLTP > > receiving a "state set up" with an already existing session > > ID knows that this is a refresh and acts accordingly. > > > > | - should the NTLP make up its own mind whether to acknowledge > > | state creation or deletion messages? > > > > The fast answer is: no, that's an issue of NSLP. It gets > > tricky should NTLP maintain state also for services without > > local NSLP support (the NTLP relay case). I think we should > > clarify what these NTLP relay nodes are supposed to do with > > messages they have no NSLP support for. Or whether we > > allow such a NTLP relay function at all. My personal > > feeling is: > > - NTLP relay may be useful. > > - NTLP service state maintenance only if NSLP is present. > > In this case, each NTLP node must interpret the NSLP field > > of a "state set up" message first and then check the > > session ID. > > > > A concern I have is whether to maintain sequence numbers in > > NTLP or NSLP only or whether to maintain them on both > > layers. If refreshes are handled by NTLP only, NTLP must > > be aware of the sequence numbers. It must maintain the > > service specific sequence numbering mechanism too. In the > > case of an NTLP relay, there's no service specific state, > > hence there's no sequence number maintenance (for relayed > > messages). It might be advantageous to let the sequence > > number mechanism count messages between adjacent NTLP > > peers only. > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Mon Mar 31 10:34:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11411 for ; Mon, 31 Mar 2003 10:34:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VFwCR13078 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 10:58:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFw2O13051; Mon, 31 Mar 2003 10:58:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFv2O12990 for ; Mon, 31 Mar 2003 10:57:02 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11375 for ; Mon, 31 Mar 2003 10:33:11 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:35:37 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8F9@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:35:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Georgios, That is one aspect of the question. another way to put it: Should there be a single state management procedure which all signalling applications (and indeed all NSIS entities) have to use? OR Should we decouple the lower and upper layers and allow a clever implementor to integrate them for efficiency for particular signalling applications? (i prefer the second.) another way to put it: Should the NTLP internal design be determined by the state management service it offers externally to signalling applications ? (sounds like a bad idea to me, though i admit i am more influenced by philosophical considerations in holding that view.) cheers, robert h. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 31 March 2003 16:16 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] state management question > > > Hi Robert > > I do not understand your question. > Are you saying that we need to have two > refresh management procedures? > One for NTLP states and one for NSLP states! > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 31 maart 2003 17:13 > To: Georgios Karagiannis (ELN); nsis@ietf.org > Subject: RE: [NSIS] state management question > > > hi georgios, > > you are right to point out this difference. > (in the email at the start of the thread: "(Note that this is > entirely not about state that the NTLP uses internally, e.g. > to route messages correctly.)") > > so, my question is about the assertion: > "One can use the NTLP state management procedure to maintain > the NSLP reservation) states" > > (can one really? is it a good idea? is it more than an > implementation issue?) > > especially, if it is more than an implementation issue, > ***what is the actual impact on the protocol?*** (in broad > terms, or giving an example) > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 31 March 2003 16:04 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Hi Robert > > > > The NTLP states are in my opinion different than the > > NSLP states. > > The NTLP states are more associated with forwarding behavior and > > the NSLP application states are reservation states. > > One can use the NTLP state management procedure to maintain the > > NSLP (reservation) states, but this cannot be done the other > > way around! > > This is for example valid when not all NSIS nodes support > > NSLP functionality > > (but they support NTLP functionality). > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: maandag 31 maart 2003 16:42 > > To: Georgios Karagiannis (ELN); nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > georgios, > > > > two questions: > > *) regardless of whether the general idea of soft stateness > > is good and how well it works in RSVP, why support it > > explicitly in the NTLP - why isn't this a signalling > > application issue? if something is needed in the NTLP, why > > isn't it an implementation issue? > > *) assuming the answer is still 'it is meaningfully part of > > the NTLP', what kind of detectable impact on the actual > > protocol would you expect it to have? > > > > what i'm trying to make progress from is the generalised view > > 'let's put soft state in the NTLP' and turn that into a > > concrete statement whose impact on the framework can be > > evaluated. at the moment, it seems to be a matter of opinion > > whether the question has no meaning or very deep meaning (at > > least to me). > > > > robert h. > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 31 March 2003 14:49 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] state management question > > > > > > > > > Hi all > > > > > > Since the RSVPv1 (RFC2205) refresh procedure and the > > > management of refresh > > > timers work quite well I think that it should be reasonable > > > to try and > > > reuse them in NTLP. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > Sent: donderdag 27 maart 2003 9:51 > > > To: robert.hancock@roke.co.uk > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] state management question > > > > > > > > > Robert, > > > > > > my answers on your final questions in line. I've > > > added some text on the message sequence number > > > mechanism, which I think is another issue > > > raising concerns. > > > > > > Regards, Rüdiger > > > > > > > > > | To make it concrete in this case: > > > | - should the NTLP contain fields which are refresh times? > > > | always? sometimes? > > > > > > Don't think so. Local time information should be used to > > > maintain state only. Also a refresh reduction mechanism > > > shouldn't require timestamps to be transmitted. If possible. > > > > > > | - should the NTLP have a bit in its header which > > > | distinguishes between state refreshing and other messages? > > > > > > As the refresh message initiates completely new state in the > > > case of a route change in new routers, the refreshes > > > shouldn't be "marked". Your idea is to distinguish between a > > > refresh of state and a modification of this state? > > > Valid Point. It may be more useful to have > > > "state set up & modification" messages instead of > > > "state set up & refresh" messages. The NLTP > > > receiving a "state set up" with an already existing session > > > ID knows that this is a refresh and acts accordingly. > > > > > > | - should the NTLP make up its own mind whether to acknowledge > > > | state creation or deletion messages? > > > > > > The fast answer is: no, that's an issue of NSLP. It gets > > > tricky should NTLP maintain state also for services without > > > local NSLP support (the NTLP relay case). I think we should > > > clarify what these NTLP relay nodes are supposed to do with > > > messages they have no NSLP support for. Or whether we > > > allow such a NTLP relay function at all. My personal > > > feeling is: > > > - NTLP relay may be useful. > > > - NTLP service state maintenance only if NSLP is present. > > > In this case, each NTLP node must interpret the NSLP field > > > of a "state set up" message first and then check the > > > session ID. > > > > > > A concern I have is whether to maintain sequence numbers in > > > NTLP or NSLP only or whether to maintain them on both > > > layers. If refreshes are handled by NTLP only, NTLP must > > > be aware of the sequence numbers. It must maintain the > > > service specific sequence numbering mechanism too. In the > > > case of an NTLP relay, there's no service specific state, > > > hence there's no sequence number maintenance (for relayed > > > messages). It might be advantageous to let the sequence > > > number mechanism count messages between adjacent NTLP > > > peers only. > > > > > > _______________________________________________ > > > 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 mailnull@www1.ietf.org Mon Mar 31 10:37:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11554 for ; Mon, 31 Mar 2003 10:37:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VG1FZ13322 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 11:01:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VG16O13306; Mon, 31 Mar 2003 11:01:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VG0qO13249 for ; Mon, 31 Mar 2003 11:00:52 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11505 for ; Mon, 31 Mar 2003 10:37:01 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 16:39:27 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA8FA@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] state management question Date: Mon, 31 Mar 2003 16:39:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Louise, I agree 100% (and that doesn't happen often). Keep the split (architecturally) clean or don't do it at all. In the meantime, we should get some implementation experience (or at least thought experiments) to see how much harder it really makes our lives. Cheers, Robert H. > -----Original Message----- > From: louise.burness@bt.com [mailto:louise.burness@bt.com] > Sent: 31 March 2003 16:32 > To: Hancock, Robert; Georgios.Karagiannis@eln.ericsson.se; > nsis@ietf.org > Subject: RE: [NSIS] state management question > > > if you do: > > "One can use the NTLP state management procedure to maintain the NSLP > reservation) states" > > Then are you running the risk of losing the benefits of > separating out the > two protocols in the first place? > > Louise > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 31 March 2003 16:13 > To: 'Georgios Karagiannis (ELN)'; nsis@ietf.org > Subject: RE: [NSIS] state management question > > > hi georgios, > > you are right to point out this difference. > (in the email at the start of the thread: "(Note that this is > entirely not > about state that the NTLP uses internally, e.g. to route messages > correctly.)") > > so, my question is about the assertion: > "One can use the NTLP state management procedure to maintain the NSLP > reservation) states" > > (can one really? is it a good idea? is it more than an implementation > issue?) > > especially, if it is more than an implementation issue, ***what is the > actual impact on the protocol?*** (in broad terms, or giving > an example) > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 31 March 2003 16:04 > > To: Hancock, Robert; nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > Hi Robert > > > > The NTLP states are in my opinion different than the > > NSLP states. > > The NTLP states are more associated with forwarding behavior and > > the NSLP application states are reservation states. > > One can use the NTLP state management procedure to maintain the > > NSLP (reservation) states, but this cannot be done the other > > way around! > > This is for example valid when not all NSIS nodes support > > NSLP functionality > > (but they support NTLP functionality). > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: maandag 31 maart 2003 16:42 > > To: Georgios Karagiannis (ELN); nsis@ietf.org > > Subject: RE: [NSIS] state management question > > > > > > georgios, > > > > two questions: > > *) regardless of whether the general idea of soft stateness > > is good and how well it works in RSVP, why support it > > explicitly in the NTLP - why isn't this a signalling > > application issue? if something is needed in the NTLP, why > > isn't it an implementation issue? > > *) assuming the answer is still 'it is meaningfully part of > > the NTLP', what kind of detectable impact on the actual > > protocol would you expect it to have? > > > > what i'm trying to make progress from is the generalised view > > 'let's put soft state in the NTLP' and turn that into a > > concrete statement whose impact on the framework can be > > evaluated. at the moment, it seems to be a matter of opinion > > whether the question has no meaning or very deep meaning (at > > least to me). > > > > robert h. > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 31 March 2003 14:49 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] state management question > > > > > > > > > Hi all > > > > > > Since the RSVPv1 (RFC2205) refresh procedure and the > > > management of refresh > > > timers work quite well I think that it should be reasonable > > > to try and > > > reuse them in NTLP. > > > > > > Best Regards, > > > Georgios > > > > > > -----Original Message----- > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > Sent: donderdag 27 maart 2003 9:51 > > > To: robert.hancock@roke.co.uk > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] state management question > > > > > > > > > Robert, > > > > > > my answers on your final questions in line. I've > > > added some text on the message sequence number > > > mechanism, which I think is another issue > > > raising concerns. > > > > > > Regards, Rüdiger > > > > > > > > > | To make it concrete in this case: > > > | - should the NTLP contain fields which are refresh times? > > > | always? sometimes? > > > > > > Don't think so. Local time information should be used to > > > maintain state only. Also a refresh reduction mechanism > > > shouldn't require timestamps to be transmitted. If possible. > > > > > > | - should the NTLP have a bit in its header which > > > | distinguishes between state refreshing and other messages? > > > > > > As the refresh message initiates completely new state in the > > > case of a route change in new routers, the refreshes > > > shouldn't be "marked". Your idea is to distinguish between a > > > refresh of state and a modification of this state? > > > Valid Point. It may be more useful to have > > > "state set up & modification" messages instead of > > > "state set up & refresh" messages. The NLTP > > > receiving a "state set up" with an already existing session > > > ID knows that this is a refresh and acts accordingly. > > > > > > | - should the NTLP make up its own mind whether to acknowledge > > > | state creation or deletion messages? > > > > > > The fast answer is: no, that's an issue of NSLP. It gets > > > tricky should NTLP maintain state also for services without > > > local NSLP support (the NTLP relay case). I think we should > > > clarify what these NTLP relay nodes are supposed to do with > > > messages they have no NSLP support for. Or whether we > > > allow such a NTLP relay function at all. My personal > > > feeling is: > > > - NTLP relay may be useful. > > > - NTLP service state maintenance only if NSLP is present. > > > In this case, each NTLP node must interpret the NSLP field > > > of a "state set up" message first and then check the > > > session ID. > > > > > > A concern I have is whether to maintain sequence numbers in > > > NTLP or NSLP only or whether to maintain them on both > > > layers. If refreshes are handled by NTLP only, NTLP must > > > be aware of the sequence numbers. It must maintain the > > > service specific sequence numbering mechanism too. In the > > > case of an NTLP relay, there's no service specific state, > > > hence there's no sequence number maintenance (for relayed > > > messages). It might be advantageous to let the sequence > > > number mechanism count messages between adjacent NTLP > > > peers only. > > > > > > _______________________________________________ > > > 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 mailnull@www1.ietf.org Mon Mar 31 11:27:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13015 for ; Mon, 31 Mar 2003 11:27:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VGnKW17329 for nsis-archive@odin.ietf.org; Mon, 31 Mar 2003 11:49:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGnDO17319; Mon, 31 Mar 2003 11:49:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGm4O17275 for ; Mon, 31 Mar 2003 11:48:04 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12946 for ; Mon, 31 Mar 2003 11:24:12 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VGQY708230; Mon, 31 Mar 2003 11:26:35 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDF40NLK; Mon, 31 Mar 2003 11:26:35 -0500 Received: from nortelnetworks.com (acart1d8.ca.nortel.com [47.129.129.84]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWLFD; Mon, 31 Mar 2003 11:26:34 -0500 Message-ID: <3E886C37.4000707@nortelnetworks.com> Date: Mon, 31 Mar 2003 11:26:31 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] state management question References: <76C92FBBFB58D411AE760090271ED4181EA8F9@rsys002a.roke.co.uk> In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA8F9@rsys002a.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I've seen enough of this dialogue now to decide that this is not a totally stupid question. Could we possibly get a bit more concrete and indicate what sort of state variables we are talking about at the NTLP level? Is it next-NTLP-hop for a given NTLP session, and what else? Hancock, Robert wrote: > Georgios, > > That is one aspect of the question. > > another way to put it: > Should there be a single state management procedure which all signalling applications (and indeed all NSIS entities) have to use? > OR > Should we decouple the lower and upper layers and allow a clever implementor to integrate them for efficiency for particular signalling applications? > > (i prefer the second.) > > another way to put it: > Should the NTLP internal design be determined by the state management service it offers externally to signalling applications ? > > (sounds like a bad idea to me, though i admit i am more influenced by philosophical considerations in holding that view.) > > cheers, > > robert h. > > >>-----Original Message----- >>From: Georgios Karagiannis (ELN) >>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>Sent: 31 March 2003 16:16 >>To: Hancock, Robert; nsis@ietf.org >>Subject: RE: [NSIS] state management question >> >> >>Hi Robert >> >>I do not understand your question. >>Are you saying that we need to have two >>refresh management procedures? >>One for NTLP states and one for NSLP states! >> >>Best Regards, >>Georgios >> >>-----Original Message----- >>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>Sent: maandag 31 maart 2003 17:13 >>To: Georgios Karagiannis (ELN); nsis@ietf.org >>Subject: RE: [NSIS] state management question >> >> >>hi georgios, >> >>you are right to point out this difference. >>(in the email at the start of the thread: "(Note that this is >>entirely not about state that the NTLP uses internally, e.g. >>to route messages correctly.)") >> >>so, my question is about the assertion: >>"One can use the NTLP state management procedure to maintain >>the NSLP reservation) states" >> >>(can one really? is it a good idea? is it more than an >>implementation issue?) >> >>especially, if it is more than an implementation issue, >>***what is the actual impact on the protocol?*** (in broad >>terms, or giving an example) >> >>cheers, >> >>r. >> >> >>>-----Original Message----- >>>From: Georgios Karagiannis (ELN) >>>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>>Sent: 31 March 2003 16:04 >>>To: Hancock, Robert; nsis@ietf.org >>>Subject: RE: [NSIS] state management question >>> >>> >>>Hi Robert >>> >>>The NTLP states are in my opinion different than the >>>NSLP states. >>>The NTLP states are more associated with forwarding behavior and >>>the NSLP application states are reservation states. >>>One can use the NTLP state management procedure to maintain the >>>NSLP (reservation) states, but this cannot be done the other >>>way around! >>>This is for example valid when not all NSIS nodes support >>>NSLP functionality >>>(but they support NTLP functionality). >>> >>>Best Regards, >>>Georgios >>> >>>-----Original Message----- >>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>>Sent: maandag 31 maart 2003 16:42 >>>To: Georgios Karagiannis (ELN); nsis@ietf.org >>>Subject: RE: [NSIS] state management question >>> >>> >>>georgios, >>> >>>two questions: >>>*) regardless of whether the general idea of soft stateness >>>is good and how well it works in RSVP, why support it >>>explicitly in the NTLP - why isn't this a signalling >>>application issue? if something is needed in the NTLP, why >>>isn't it an implementation issue? >>>*) assuming the answer is still 'it is meaningfully part of >>>the NTLP', what kind of detectable impact on the actual >>>protocol would you expect it to have? >>> >>>what i'm trying to make progress from is the generalised view >>>'let's put soft state in the NTLP' and turn that into a >>>concrete statement whose impact on the framework can be >>>evaluated. at the moment, it seems to be a matter of opinion >>>whether the question has no meaning or very deep meaning (at >>>least to me). >>> >>>robert h. >>> >>> >>>>-----Original Message----- >>>>From: Georgios Karagiannis (ELN) >>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>>>Sent: 31 March 2003 14:49 >>>>To: nsis@ietf.org >>>>Subject: RE: [NSIS] state management question >>>> >>>> >>>>Hi all >>>> >>>>Since the RSVPv1 (RFC2205) refresh procedure and the >>>>management of refresh >>>>timers work quite well I think that it should be reasonable >>>>to try and >>>>reuse them in NTLP. >>>> >>>>Best Regards, >>>>Georgios >>>> >>>>-----Original Message----- >>>>From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >>>>Sent: donderdag 27 maart 2003 9:51 >>>>To: robert.hancock@roke.co.uk >>>>Cc: nsis@ietf.org >>>>Subject: RE: [NSIS] state management question >>>> >>>> >>>>Robert, >>>> >>>>my answers on your final questions in line. I've >>>>added some text on the message sequence number >>>>mechanism, which I think is another issue >>>>raising concerns. >>>> >>>>Regards, Rüdiger >>>> >>>> >>>>| To make it concrete in this case: >>>>| - should the NTLP contain fields which are refresh times? >>>>| always? sometimes? >>>> >>>>Don't think so. Local time information should be used to >>>>maintain state only. Also a refresh reduction mechanism >>>>shouldn't require timestamps to be transmitted. If possible. >>>> >>>>| - should the NTLP have a bit in its header which >>>>| distinguishes between state refreshing and other messages? >>>> >>>>As the refresh message initiates completely new state in the >>>>case of a route change in new routers, the refreshes >>>>shouldn't be "marked". Your idea is to distinguish between a >>>>refresh of state and a modification of this state? >>>>Valid Point. It may be more useful to have >>>>"state set up & modification" messages instead of >>>>"state set up & refresh" messages. The NLTP >>>>receiving a "state set up" with an already existing session >>>>ID knows that this is a refresh and acts accordingly. >>>> >>>>| - should the NTLP make up its own mind whether to acknowledge >>>>| state creation or deletion messages? >>>> >>>>The fast answer is: no, that's an issue of NSLP. It gets >>>>tricky should NTLP maintain state also for services without >>>>local NSLP support (the NTLP relay case). I think we should >>>>clarify what these NTLP relay nodes are supposed to do with >>>>messages they have no NSLP support for. Or whether we >>>>allow such a NTLP relay function at all. My personal >>>>feeling is: >>>>- NTLP relay may be useful. >>>>- NTLP service state maintenance only if NSLP is present. >>>>In this case, each NTLP node must interpret the NSLP field >>>>of a "state set up" message first and then check the >>>>session ID. >>>> >>>>A concern I have is whether to maintain sequence numbers in >>>>NTLP or NSLP only or whether to maintain them on both >>>>layers. If refreshes are handled by NTLP only, NTLP must >>>>be aware of the sequence numbers. It must maintain the >>>>service specific sequence numbering mechanism too. In the >>>>case of an NTLP relay, there's no service specific state, >>>>hence there's no sequence number maintenance (for relayed >>>>messages). It might be advantageous to let the sequence >>>>number mechanism count messages between adjacent NTLP >>>>peers only. >>>> >>>>_______________________________________________ >>>>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