From nsis-bounces@ietf.org Thu Mar 01 04:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMho8-0002rJ-69; Thu, 01 Mar 2007 04:42:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMho7-0002rD-1A for nsis@ietf.org; Thu, 01 Mar 2007 04:42:39 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMho5-00060X-EI for nsis@ietf.org; Thu, 01 Mar 2007 04:42:39 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l219gOK3012096 for ; Thu, 1 Mar 2007 09:42:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2007 09:42:23 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST authorisation Thread-Index: Acdb5enmh79SKqk4SRu+LQUywefiXw== From: "Hancock, Robert" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [NSIS] GIST authorisation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, Several review comments on GIST related to the question of how a node should decide to accept the creation of a secured messaging association (specifically, how to decide that the TLS authentication step is acceptable). A node can't just accept any authentication as acceptable, because then the MA security would provide almost no value. (It would prevent people disrupting the MA once established, but wouldn't prevent anyone establishing it in the first place.) This is referred to as GIST authorisation (note that it's got nothing to do with authorisation for allocation of resources by the signalling application). Conceptually what is required is an algorithm for the node, which takes an identity and returns an 'OK/not OK' decision. That algorithm has to use the identity along with some other dat; the simplest form of that data is a list, and the algorithm is just a lookup. (You can imagine other algorithms, such as invoking other protocols to check the identity; however, these can all be modelled as different ways of storing and accessing the list.) One needs to define criteria for when an identity should be in the list, but that's about it. Text based on the above description is in GIST -12 (currently with the i-d editor). There are two aspects: the authorisation algorithm described abstractly in terms of a list lookup, and TLS-specific details about name matching in certificates. The abstract description is attached below; it would be interesting to see if people see it as under- or over-specification. cheers, r. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D 4.4.2. GIST Peer Authorisation When two GIST nodes authenticate using a messaging association, both ends have to decide whether to accept the creation of the MA and whether to trust the information sent over it. This can be seen as an authorisation decision: o Authorised peers are trusted to install correct routing state about themselves and not, for example, to claim that they are on- path for a flow when they are not. o Authorised peers are trusted to obey transport and application level flow control rules, and not to attempt to create overload situations. o Authorised peers are trusted not to send erroneous or malicious error messages, for example asserting that routing state has been lost when it has not. This specification models the decision as verification by the authorising node of the peer's identity against a local list of peers, the authorised peer database (APD). The APD is a abstract construct, similar to the security policy database of IPsec [39]. Implementations MAY provide the associated functionality in any way they choose. This section defines only the requirements for APD administration and the consequences of successfully validating a peer's identity against it. The APD consists of a list of entries. Each entry includes an identity, the namespace from which the identity comes (e.g. DNS domains), the scope within which the entry is applicable, and whether authorisation is allowed or denied. The following are example scopes: Peer Address Ownership: The scope is the IP address at which the peer for this MRI should be; the APD entry denotes the identity as the owner of address. If the authorising node can determine this address from local information (such as its own routing tables), matching this entry shows that the peer is the correct on-path node and so should be authorised. The determination is simple if the peer is one IP hop downstream, since the IP address can be derived from the router's forwarding tables. If the peer is more than one hop away or is upstream, the determination is harder but may still be possible in some circumstances. The authorising node may be able to determine a (small) set of possible peer addresses, and accept that any of these could be the correct peer. End-System Subnet: The scope is an address range within which the MRI source or destination lie; the APD entry denotes the identity as potentially being on-path between the authorising node and that address range. There may be different source and destination scopes, to account for asymmetric routing. The same identity may appear in multiple entries, and the order of entries in the APD is significant. When a messaging association is authenticated and associated with an MRI, the authorising node scans the APD to find the first entry where the identity matches that presented by the peer, and where the scope information matches the circumstances for which the MA is being set up. The identity matching process itself depends on the messaging association protocol that carries out the authentication, and details for TLS are given in Section 5.7.3. Whenever the full set of possible peers for a specific scope is known, deny entries SHOULD be added for the wildcard identity to reject signalling associations from unknown nodes. The ability of the authorising node to reject inappropriate MAs depends directly on the granularity of the APD and the precision of the scope matching process. If authorisation is allowed, the MA can be used as normal; otherwise it MUST be torn down without further GIST exchanges, and any routing state associated with the MA MUST also be deleted. An error condition MAY be logged locally. When an APD entry is modified or deleted, the node MUST re-validate existing MAs and the routing state table against the revised contents of the APD. This may result in MAs being torn down or routing state entries being deleted. These changes SHOULD be indicated to local signalling applications via the NetworkNotification API call (Appendix B.4). This specification does not define how the APD is populated. As a minimum, an implementation MUST provide an administrative interface through which entries can be added, modified, or deleted. More sophisticated mechanisms are possible in some scenarios. For example, the fact that a node is legitimately associated with a specific IP address could be established by direct embedding of the IP address as a particular identity type in a certificate, or by a mapping that address to another identifier type via an additional database lookup (such as relating IP addresses in in-addr.arpa to domain names). An enterprise network operator could generate a list of all the identities of its border nodes as authorised to be on the signalling path to external destinations, and this could be distributed to all hosts inside the network. Regardless of the technique, it MUST be ensured that the source data justify the authorisation decisions listed at the start of this section, and that the security of the chain of operations on which the APD entry depends cannot be compromised. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 01 10:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmuT-0005uO-Ah; Thu, 01 Mar 2007 10:09:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmuR-0005o1-Vx for nsis@ietf.org; Thu, 01 Mar 2007 10:09:32 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMmuM-0000P5-SO for nsis@ietf.org; Thu, 01 Mar 2007 10:09:31 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1F513112; Thu, 1 Mar 2007 16:09:25 +0100 (NFT) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 17836-02; Thu, 1 Mar 2007 16:09:23 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C7196147; Thu, 1 Mar 2007 16:09:22 +0100 (NFT) Message-ID: <45E6ECA1.1030002@uni-tuebingen.de> Date: Thu, 01 Mar 2007 16:09:21 +0100 From: Ali Fessi User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST authorisation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, just my opinion: few comments are inline, otherwise I think it is fine. Hancock, Robert wrote: > hi all, > > Several review comments on GIST related to the question of how a node > should decide to accept the creation of a secured messaging association > (specifically, how to decide that the TLS authentication step is > acceptable). A node can't just accept any authentication as acceptable, > because then the MA security would provide almost no value. (It would > prevent people disrupting the MA once established, but wouldn't prevent > anyone establishing it in the first place.) This is referred to as GIST > authorisation (note that it's got nothing to do with authorisation for > allocation of resources by the signalling application). > > Conceptually what is required is an algorithm for the node, which takes > an identity and returns an 'OK/not OK' decision. That algorithm has to > use the identity along with some other dat; the simplest form of that > data is a list, and the algorithm is just a lookup. (You can imagine > other algorithms, such as invoking other protocols to check the > identity; however, these can all be modelled as different ways of > storing and accessing the list.) One needs to define criteria for when > an identity should be in the list, but that's about it. > > Text based on the above description is in GIST -12 (currently with the > i-d editor). There are two aspects: the authorisation algorithm > described abstractly in terms of a list lookup, and TLS-specific details > about name matching in certificates. The abstract description is > attached below; it would be interesting to see if people see it as > under- or over-specification. > > cheers, > > r. > > ======================================================================== > ======= > > 4.4.2. GIST Peer Authorisation > > When two GIST nodes authenticate using a messaging association, both > ends have to decide whether to accept the creation of the MA and > whether to trust the information sent over it. This can be seen as > an authorisation decision: > > o Authorised peers are trusted to install correct routing state > about themselves and not, for example, to claim that they are on- > path for a flow when they are not. > > o Authorised peers are trusted to obey transport and application > level flow control rules, and not to attempt to create overload > situations. > > o Authorised peers are trusted not to send erroneous or malicious > error messages, for example asserting that routing state has been > lost when it has not. > > This specification models the decision as verification by the > authorising node of the peer's identity against a local list of > peers, the authorised peer database (APD). The APD is a abstract > construct, similar to the security policy database of IPsec [39]. > Implementations MAY provide the associated functionality in any way > they choose. This section defines only the requirements for APD > administration and the consequences of successfully validating a > peer's identity against it. > > The APD consists of a list of entries. Each entry includes an > identity, the namespace from which the identity comes (e.g. DNS > domains), the scope within which the entry is applicable, and whether > authorisation is allowed or denied. The following are example > scopes: > > Peer Address Ownership: The scope is the IP address at which the > peer for this MRI should be; the APD entry denotes the identity as > the owner of address. If the authorising node can determine this > address from local information (such as its own routing tables), > matching this entry shows that the peer is the correct on-path > node and so should be authorised. The determination is simple if > the peer is one IP hop downstream, since the IP address can be > derived from the router's forwarding tables. If the peer is more > than one hop away or is upstream, the determination is harder but > may still be possible in some circumstances. The authorising node > may be able to determine a (small) set of possible peer addresses, > and accept that any of these could be the correct peer. > > End-System Subnet: The scope is an address range within which the > MRI source or destination lie; the APD entry denotes the identity > as potentially being on-path between the authorising node and that > address range. There may be different source and destination > scopes, to account for asymmetric routing. > > The same identity may appear in multiple entries, and the order of > entries in the APD is significant. When a messaging association is > authenticated and associated with an MRI, the authorising node scans > the APD to find the first entry where the identity matches that > presented by the peer, and where the scope information matches the > circumstances for which the MA is being set up. The identity > matching process itself depends on the messaging association protocol > that carries out the authentication, and details for TLS are given in > Section 5.7.3. Section 5.7.3 specifies the use of TLS with either server-only or mutual authentication. It's not clear to me, in which cases, the server-only authentication can be sufficient and in which cases, authentication of the client is additionally needed. It the "GIST peer"/"TLS client" is not authenticated in any way, then it won't be possible to take the authorization decisions for GIST listed above. I know it won't be always possible for the client to provide a certificate. But there might be a problem here. > Whenever the full set of possible peers for a > specific scope is known, deny entries SHOULD be added for the > wildcard identity to reject signalling associations from unknown > nodes. The ability of the authorising node to reject inappropriate > MAs depends directly on the granularity of the APD and the precision > of the scope matching process. > > If authorisation is allowed, the MA can be used as normal; otherwise > it MUST be torn down without further GIST exchanges, and any routing > state associated with the MA MUST also be deleted. An error > condition MAY be logged locally. When an APD entry is modified or > deleted, the node MUST re-validate existing MAs and the routing state > table against the revised contents of the APD. This may result in > MAs being torn down or routing state entries being deleted. These > changes SHOULD be indicated to local signalling applications via the > NetworkNotification API call (Appendix B.4). > > This specification does not define how the APD is populated. As a > minimum, an implementation MUST provide an administrative interface > through which entries can be added, modified, or deleted. I think up to here, it is fine. The rest is probably not needed - at least in this document. It might be too early to think of how to populate GIST APDs in the network. But maybe in few years, we may think of a "GIST APD Propagation Protocol" ;-) > More > sophisticated mechanisms are possible in some scenarios. For > example, the fact that a node is legitimately associated with a > specific IP address could be established by direct embedding of the > IP address as a particular identity type in a certificate, or by a > mapping that address to another identifier type via an additional > database lookup (such as relating IP addresses in in-addr.arpa to > domain names). An enterprise network operator could generate a list > of all the identities of its border nodes as authorised to be on the > signalling path to external destinations, and this could be > distributed to all hosts inside the network. Regardless of the > technique, it MUST be ensured that the source data justify the > authorisation decisions listed at the start of this section, and that > the security of the chain of operations on which the APD entry > depends cannot be compromised. cheers, ali > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 01 11:11:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnrp-0003PW-Jh; Thu, 01 Mar 2007 11:10:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnro-0003OD-9z for nsis@ietf.org; Thu, 01 Mar 2007 11:10:52 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMnrm-00046j-NB for nsis@ietf.org; Thu, 01 Mar 2007 11:10:52 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l21GAfOc026001; Thu, 1 Mar 2007 17:10:45 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R, ATTLABS'" , "'Martin Stiemerling'" , "'nsis'" References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Thu, 1 Mar 2007 17:10:36 +0100 Message-ID: <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDA= X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 01 Mar 2007 17:10:46 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry The need for the QOSM ID can be seen probably seen in the below e-mail: Suppose that: A QNE supports the following: * end-to-end QOS Models: QOSMI-1, QOSMI-2, QOSMI-3 * local QoS Models: QOSML-1, QOSML-2, QOSML-3 Suppose now that the operator of such a QNE wants to use the follwing combinations: * QOSMI-1 with QOSML-3. Meaning that end-to-end sessions and QOS-NSLP messages that are carrying initial QSPEC of QOSM-I1 should be bound with local sessions and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3 * QOSMI-2 with QOSML-3 Meaning that end-to-end sessions and QOS-NSLP messages that are carrying initial QSPEC of QOSMI-2 should be bound with local sessions and local QOS-NSLP messages that are carying local QSPEC of QOSML-3 * QOSMI-3 with QOSML-1 initial QSPEC of QOSMI-3 should be bound with local sessions and local QOS-NSLP messages that are carying local QSPEC of QOSML-1 * QOSMI-3 with QOSML-2 initial QSPEC of QOSMI-3 should be bound with local sessions and local QOS-NSLP messages that are carying local QSPEC of QOSML-2 -- If the QOSM ID will not be supported these combinations will not beable to be made meaning that A QNE will be able to support only one initial (end-to-end) QOSM with only one local QOSM at a time. Best Regards, Georgios > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > Sent: woensdag 28 februari 2007 14:43 > To: Georgios Karagiannis; Martin Stiemerling; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Georgios, All, > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, February 28, 2007 12:37 AM > > To: Martin Stiemerling; nsis > > Subject: [NSIS] comment on reintroduction of QOSM-ID in qspec draft > > > > Hi > > > > I was busy updating some of the QOSM drafts and I have seen that > > starting from version 13 of the QSPEC draft, the QOSM ID field is > > removed form the common header of a QSPEC object and > instead of this, > > the field QSPEC type is used. > > The QSPEC Type was introduced to support Roland's QSPEC > stacking/encapsulation method (see > http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht > ml), it does not replace QOSM ID. > > The QOSM ID was removed in the discussion around the QSPEC-13 > draft update, see the post on 1 November 2006 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > ml, where it says "A QOSM ID need not be defined or signaled > and a QNE need not support any particular QOSM". Slide 3 of > the QSPEC presentation at IETF-67 makes the same point. The > same point is made again in the announcement of the draft to > the NSIS list at > http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht > ml and the point is also made in Appendix A of the QSPEC > draft itself. There were no objections to this point. > > > I agree that QSPEC type (shows if the QSPEC object is initial or a > > local) is useful and it should be used, but by removing the QOSM ID > > field it will mean that a QNE can always support only one type of > > initial > > (end-to-end) QOSM and one type of local QOSM. > > That is not reasonable. A QNE should be able to support > many QOSMs and > > it should be able to distinguish and associate a QSPEC > object with a > > certain QOSM. > > There is no mention in any QSPEC draft as to how or why a > QOSM ID field is needed or used. A QNE can support any QOSM > it wants, it does not depend on a QOSM ID field from the QNI > to determine which one. > > At a minimum, we would need to have a bit-level example of > how/why such a field is needed to justify reintroducing the > QOSM ID field. > > > Therefore, I think that it is required that the QOSM ID > field should > > be reintroduced in the QSPEC common header. The field QSPEC type is > > also useful ant it should be kept. > > We need clear justification to reintroduce the complexity of > having the QOSM ID field and the IANA registry to maintain > the parameter. > > Jerry > > > > > Best regards, > > Georgios > > > > > > On 2/20/2007, "Martin Stiemerling" > wrote: > > > > >Dear all, > > > > > >I would like to start the working group last call for the > QSPEC draft > > >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > > > > >The WGLC is starting today and will run for two weeks > until Tuesday > > >Feb 6th. > > > > > >Please send your comments to the NSIS WG list. > > > > > > Martin > > > > > >Anfang der weitergeleiteten E-Mail: > > > > > >> Von: > > >> Datum: 16. Februar 2007 21:50:02 MEZ > > >> An: > > >> Kopie: > > >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt > > >> > > >> A New Internet-Draft is available from the on-line > Internet-Drafts > > >> directories. > > >> This draft is a work item of the Next Steps in Signaling Working > > >> Group of the IETF. > > >> > > >> Title : QoS NSLP QSPEC Template > > >> Author(s) : J. Ash, et al. > > >> Filename : draft-ietf-nsis-qspec-15.txt > > >> Pages : 54 > > >> Date : 2007-2-16 > > >> > > >> The QoS NSLP protocol is used to signal QoS reservations and is > > >> independent of a specific QoS model (QOSM) such as IntServ or > > >> DiffServ. Rather, all information specific to a QOSM is > > >> encapsulated > > >> in a separate object, the QSPEC. This document defines > > a template > > >> for the QSPEC including a number of QSPEC parameters. > The QSPEC > > >> parameters provide a common language to be re-used in > > several QOSMs > > >> and thereby aim to ensure the extensibility and > > interoperability of > > >> QoS NSLP. The node initiating the NSIS signaling adds > > an initiator > > >> QSPEC, which indicates the QSPEC parameters that must be > > >> interpreted > > >> by the downstream nodes less the reservation fails, thereby > > >> ensuring > > >> the intention of the NSIS initiator is preserved along the > > >> signaling > > >> path. > > >> > > >> A URL for this Internet-Draft is: > > >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > > >> > > >> To remove yourself from the I-D Announcement list, send a > > message to > > >> i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > >> the message. > > >> You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > >> to change your subscription settings. > > >> > > >> 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-qspec-15.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-qspec-15.txt". > > >> > > >> NOTE: The mail server at ietf.org can return the document in > > >> MIME-encoded form by using the "mpack" utility. To use this > > >> feature, insert the command "ENCODING mime" before the "FILE" > > >> command. To decode the response(s), you will need "munpack" or > > >> a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > >> exhibit different behavior, especially when dealing with > > >> "multipart" MIME messages (i.e. documents which have been split > > >> up into multiple messages), so check your local documentation on > > >> how to manipulate these messages. > > >> > > >> Below is the data which will enable a MIME compliant mail reader > > >> implementation to automatically retrieve the ASCII version of the > > >> Internet-Draft.) > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 01 15:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsEP-0000y1-1X; Thu, 01 Mar 2007 15:50:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsE0-0000bH-5C; Thu, 01 Mar 2007 15:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMsDz-0001Xv-PX; Thu, 01 Mar 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id AA9373294E; Thu, 1 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDz-0002er-Ie; Thu, 01 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-12.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST: General Internet Signalling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-12.txt Pages : 173 Date : 2007-3-1 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ntlp-12.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-ntlp-12.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: <2007-3-1130658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1130658.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Mar 01 17:49:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMu5C-0005R6-7B; Thu, 01 Mar 2007 17:49:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMu59-0005OG-OF for nsis@ietf.org; Thu, 01 Mar 2007 17:49:03 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMu58-00042T-W9 for nsis@ietf.org; Thu, 01 Mar 2007 17:49:03 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1172789341!12556299!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5048 invoked from network); 1 Mar 2007 22:49:01 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-120.messagelabs.com with SMTP; 1 Mar 2007 22:49:01 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l21MmvXF000615; Thu, 1 Mar 2007 17:48:57 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l21MmqQQ000592; Thu, 1 Mar 2007 17:48:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C75C53.C8DF95C5" Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Thu, 1 Mar 2007 16:48:52 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDAADZkzgA== References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> From: "ASH, GERALD R, ATTLABS" To: "Georgios Karagiannis" , "Martin Stiemerling" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C75C53.C8DF95C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georgios, Your examples don't illustrate how and why a QOSM ID field is needed and used. =20 Perhaps you are saying that QoS NSLP and RMF communicate with messages and that the I-QOSM ID and L-QOSM ID need to be included in those messages so that the QoS NSLP can react differently based on which L-QOSM is being used by the RMF? If so, then this interaction suffers from the problems identified in Cornelia's slide (attached) discussed on our conference call on 31 January. If not, please give a more detailed example of how and why a QOSM ID field is needed and used. Jerry=20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: Thursday, March 01, 2007 11:11 AM To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Hi Jerry The need for the QOSM ID can be seen probably seen in the below e-mail: Suppose that: A QNE supports the following: * end-to-end QOS Models:=20 QOSMI-1, QOSMI-2, QOSMI-3=20 * local QoS Models: QOSML-1, QOSML-2, QOSML-3 Suppose now that the operator of such a QNE wants to use the follwing combinations: * QOSMI-1 with QOSML-3. Meaning that end-to-end sessions and QOS-NSLP messages that are carrying initial QSPEC of QOSM-I1 should be bound with local sessions and local QOS-NSLP messages that=20 are carying local QSPEC of QOSM-L3 * QOSMI-2 with QOSML-3 Meaning that end-to-end sessions and QOS-NSLP messages that are carrying initial QSPEC of QOSMI-2 should be bound with local sessions and local QOS-NSLP messages that=20 are carying local QSPEC of QOSML-3 * QOSMI-3 with QOSML-1 initial QSPEC of QOSMI-3 should be bound with local sessions and local QOS-NSLP messages that=20 are carying local QSPEC of QOSML-1 * QOSMI-3 with QOSML-2 initial QSPEC of QOSMI-3 should be bound with local sessions and local QOS-NSLP messages that=20 are carying local QSPEC of QOSML-2 -- If the QOSM ID will not be supported these combinations will not beable to be made meaning that=20 A QNE will be able to support only one initial (end-to-end) QOSM with only one local QOSM at a time. Best Regards, Georgios > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Sent: woensdag 28 februari 2007 14:43 > To: Georgios Karagiannis; Martin Stiemerling; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 > qspec draft >=20 > Georgios, All, >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, February 28, 2007 12:37 AM > > To: Martin Stiemerling; nsis > > Subject: [NSIS] comment on reintroduction of QOSM-ID in qspec draft > >=20 > > Hi > >=20 > > I was busy updating some of the QOSM drafts and I have seen that=20 > > starting from version 13 of the QSPEC draft, the QOSM ID field is=20 > > removed form the common header of a QSPEC object and=20 > instead of this,=20 > > the field QSPEC type is used. >=20 > The QSPEC Type was introduced to support Roland's QSPEC=20 > stacking/encapsulation method (see=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht > ml), it does not replace QOSM ID. >=20 > The QOSM ID was removed in the discussion around the QSPEC-13=20 > draft update, see the post on 1 November 2006=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > ml, where it says "A QOSM ID need not be defined or signaled=20 > and a QNE need not support any particular QOSM". Slide 3 of=20 > the QSPEC presentation at IETF-67 makes the same point. The=20 > same point is made again in the announcement of the draft to=20 > the NSIS list at=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht > ml and the point is also made in Appendix A of the QSPEC=20 > draft itself. There were no objections to this point. >=20 > > I agree that QSPEC type (shows if the QSPEC object is initial or a=20 > > local) is useful and it should be used, but by removing the QOSM ID=20 > > field it will mean that a QNE can always support only one type of=20 > > initial > > (end-to-end) QOSM and one type of local QOSM. > > That is not reasonable. A QNE should be able to support=20 > many QOSMs and=20 > > it should be able to distinguish and associate a QSPEC=20 > object with a=20 > > certain QOSM. >=20 > There is no mention in any QSPEC draft as to how or why a=20 > QOSM ID field is needed or used. A QNE can support any QOSM=20 > it wants, it does not depend on a QOSM ID field from the QNI=20 > to determine which one. >=20 > At a minimum, we would need to have a bit-level example of=20 > how/why such a field is needed to justify reintroducing the=20 > QOSM ID field. >=20 > > Therefore, I think that it is required that the QOSM ID=20 > field should=20 > > be reintroduced in the QSPEC common header. The field QSPEC type is=20 > > also useful ant it should be kept. >=20 > We need clear justification to reintroduce the complexity of=20 > having the QOSM ID field and the IANA registry to maintain=20 > the parameter. >=20 > Jerry > =20 > >=20 > > Best regards, > > Georgios > >=20 > >=20 > > On 2/20/2007, "Martin Stiemerling"=20 > wrote: > >=20 > > >Dear all, > > > > > >I would like to start the working group last call for the=20 > QSPEC draft=20 > > >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > > > > >The WGLC is starting today and will run for two weeks=20 > until Tuesday=20 > > >Feb 6th. > > > > > >Please send your comments to the NSIS WG list. > > > > > > Martin > > > > > >Anfang der weitergeleiteten E-Mail: > > > > > >> Von: > > >> Datum: 16. Februar 2007 21:50:02 MEZ > > >> An: > > >> Kopie: > > >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt > > >> > > >> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > >> directories. > > >> This draft is a work item of the Next Steps in Signaling Working=20 > > >> Group of the IETF. > > >> > > >> Title : QoS NSLP QSPEC Template > > >> Author(s) : J. Ash, et al. > > >> Filename : draft-ietf-nsis-qspec-15.txt > > >> Pages : 54 > > >> Date : 2007-2-16 > > >> > > >> The QoS NSLP protocol is used to signal QoS reservations and is > > >> independent of a specific QoS model (QOSM) such as IntServ or > > >> DiffServ. Rather, all information specific to a QOSM is=20 > > >> encapsulated > > >> in a separate object, the QSPEC. This document defines > > a template > > >> for the QSPEC including a number of QSPEC parameters.=20 > The QSPEC > > >> parameters provide a common language to be re-used in > > several QOSMs > > >> and thereby aim to ensure the extensibility and > > interoperability of > > >> QoS NSLP. The node initiating the NSIS signaling adds > > an initiator > > >> QSPEC, which indicates the QSPEC parameters that must be=20 > > >> interpreted > > >> by the downstream nodes less the reservation fails, thereby=20 > > >> ensuring > > >> the intention of the NSIS initiator is preserved along the=20 > > >> signaling > > >> path. > > >> > > >> A URL for this Internet-Draft is: > > >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > > >> > > >> To remove yourself from the I-D Announcement list, send a > > message to > > >> i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > >> the message. > > >> You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > >> to change your subscription settings. > > >> > > >> Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > > >> username "anonymous" and a password of your e-mail=20 > address. After=20 > > >> logging in, type "cd internet-drafts" and then "get=20 > > >> draft-ietf-nsis-qspec-15.txt". > > >> > > >> A list of Internet-Drafts directories can be found in=20 > > >> http://www.ietf.org/shadow.html or=20 > > >> 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-qspec-15.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=20 > > >> implementation to automatically retrieve the ASCII version of the > > >> Internet-Draft.) >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C75C53.C8DF95C5 Content-Type: application/octet-stream; name="vgs.QSPEC.open.issues.CK.pdf" Content-Transfer-Encoding: base64 Content-Description: vgs.QSPEC.open.issues.CK.pdf Content-Disposition: attachment; filename="vgs.QSPEC.open.issues.CK.pdf" JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nL1Z227bRhBF+6iv4CNZhCx3ueSSLzVa1G0T5GZbSB+CPiiSLKewLMeS0+Q7 2uZ7O3ufXY4UOUWbAMZy7zN7ZubM6F1WV4xntfrvGvP15Ntzma22E92dnf9sG3erybtJXzXqn+7A 7fk6+2EKC4dsqIYum17CIpaVDIZaMVRd1vVDJWFgPclZMf19cjqdnKmNq2aQgxhgsjkofB91HmMZ l+mJrK4rIbK+rrgcWnXm6/yXoq4GWddM5Jui5JVsRM3yPwpWMdkxmWdFCRO6QbY83xYlqwZR101+ ZeY2snXLVPMelrVt3/H8Gi1bmF5m95I1l11+VpRNxRhM3bjhC2jIrhEymvhcX5A1vIEJcFLL+0bm T92il+Qif+SyKLuKN6xp87m+fTO0+ds9M+0w3sjpRA75jZ4p63hC6F1a7bRt/sHs1Ysu36mm7ATo AS9bg1Rt3/fSX5ELpd/QcnvNQnOFz7IzT4qOsd+mTzxwHgxN1mSsj3EiZCV5JuCBBoOT/CuFTZjb 2rlcwrzpAgA0LcoB1MSrruuEFpLDnaPP68J39U1+p9QAl+jaASRyvUvf0kvC54eiU61OKlWqgVKA 0tUoaNX06RVn6s/GL7so1CG8bpgZfg53MH364KdmYs0BQL5TT1z4kaU/Zf62UANw8tKPbrGktRFy Ey5nNmjbTr0NUvKQlZwp7YLy8q9TrQK8O6fYP62eOEDnsRcz6HGN9JgM3cTKVLcPXSvyJYLCNQqN xo2MYenGi5ZqSbX05B16hjq+s/s8h+s8K0qZ/wj94HmMyeE9w3osZNgGDFioZoO1XXkdBW3p29z7 KTdEaxm9oFpl76Qtdxh6Cc4uHGy7QDPqYQX3z+WHwtbzoMmRRBqZVg454FXmfQauPZrd89xtfhpg 7RAOVoZ6/cxXoe80soUedm/Bhc4IZSzQS3HZK00oMUslZ8lkxToj7Mob+NK3AkyWGGES4XIXm3aC 2gRs2tIhELVwd9G6m3fDMDYz3QKE/FUk1lYai/ofTC74IOVpzovR2iDYwvsVPYWwwhrbzHwXwzkx Lt13RcA5NX21FW1YpDmtxkZ7GlzlhYI2tGuGe9WkV+Ezxp3F5Rv1eB8L1uhQhAZWsX/F76tNrevd M90hEwp6CvaamKIypUgaOzoj+j5jaC+N2ALe7oVf89ytuRibHKwZg7LlnUYlBFgDyv3R1YYsBcgQ Y9cIpsH+du6917Rbx1ESNG12FkI2hwIkLHyZRFLKdYZW8CAojjgoWs8adrj1rXv8jhZzl6l50PA9 wgxsyPFLfnKsaRSZu897iV9VjDC6uSJ8XhJ88cXGPGdPCNa+z8G8B+/3PnGibwvsCG5iaS/joKvm qti2fUSSpdq9OzDr7oFkaUvZqyZKKT2yz7DfuhqGkXacdUWOZeaN/do4jEFWvfcZVDTfEOjTXugK XztyKq3AxCAdNcSgHBGBDQb3aC11NYzfKBAboVQs5r2RDAUdyfn+AHgEspG3CYgNnPret65DxFjE gB5bGhgLtJn1Ard++syHQWwEHt2acwf/EPl5IswREWxE50vL5LcHrSdhF+qdFAUBxmTJSEM/1C4Q FGr4jvRYGwJpMwTGcQsHPxsZBa8G7t5wRavMsb5woUcYim7YitjqDF/E0jn3fUC6xCQDsik5Sfbr DYkI51SsXx5UYGI8RlHYeN748GlSPAdO9aXJa3DK89Txal8PSgqu2WUQiVtX7jDixH7sfQLrg8CM HyOfn8RiKhGBVQkRrP11/gkOF0JlWujWUa7H+3oco0oupbrjXnMeemcsCAGwlV5ERpcA/C9OxTWF Ram4vyXFi1GmvotDkWag18XIc1+FDSlqGDBHJ5SRufjt8SN5KwvRzWtNXUu9YAtvVwtnzFTguPLp zsmYWQ6NWn0Ms0SQEMjLNd7LNYhbJrlMVELANpKwG4srbyNxxebBzIhIiw4YTMgW3dGXh/nPv0Lo hsBqVD5JaQAqfdiHxXA3fh1clycwt2g0ClCLFKutEPt0cpBxePSf+eEAVMS+niFff0KUuAB9g7r4 l2TdupoYMKGjtU9ktwkMA4oCdug6I1UB8wl4wkptfptksfvzW4cGh7f9dRV/4kOTldjnJgTo2tF7 PWgTI83lqdhIPT0VV/EKA8YWgfEqBiORPxsBeC9lB65mtOmcAiiyCswnNkhUgngTJOLyIO/YzuIS xDZlCVpSXO7C8cV5w1FV1KVmepQqbO8pkKX1zVAnK8WhEplRPquV9Mprc3v0Grlk5YS2mE+GIKXL ZTb4iLxE9/jO5rc1H583blFBehED2pZ8omoAArl+ZAIj1CvSPBOnCaZW1FZcUOWiHQWc2SGAxXzb a/V9RZiKRz9BBJaIKsbVEepnglL0kOgd7UIfu7S/N55SAahXDkkaYOicBqdvmkNF9Cmifyq+2Evt o5Q6hL5Qf5CvfJYmOdptG5K5z2B6db1BqbjryYTvnW/dH8H7vjy0g7aUwEbSp5PpN7Gs6W9Ln9vT l87CxE/HE+vvw1K0SyhKO8XKJlDuF4VLgoknEQADbOXbW8JwNbu+9Cl40da1Usl/oIq0UHlrSDm+ DFHHHIWLtC6ACgFUhLFQnKHymsvREPnZj+tjlTjyYL7L67TpsFH9De6grbX6qHBChY45SuOQj9eM 3JT8vCo+BqDEPwgkVEKvDXqjhMO/6OhcKjg6f5x3aPo36bPJP7JF8IplbmRzdHJlYW0KZW5kb2Jq CjYgMCBvYmoKMjAyNQplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDE2IDAgUgovRm9udCAxNyAwIFIKPj4KL0NvbnRlbnRzIDUgMCBS Cj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjQgMCBSCl0gL0NvdW50 IDEKL1JvdGF0ZSA5MD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMg MCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlCi9PUE0gMT4+ZW5kb2JqCjE2 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE3IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEz IDAgUi9SMTUKMTUgMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjE4IDAgb2JqCjw8L1N1YnR5cGUvVHlw ZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTkgMCBSPj5zdHJlYW0KeJxVVWtQFFcWvs3M 9LQIKIytIjrTiIyCTHw/QCwVYUBAIfGBSkAJDC9nGFYGBGIMqIml1yciWGKcUcEHZBEXH6Mggq8p ISCkrGgiq+um1mBqjci6nmYv2drbUGaTHzN1+9zbp7/zne87l0FyJ8QwzIgIgzHPYMlITtKFmI0p UihA9GLE8U7iBBkmWf3f9G9VTEDRx3tcsYsMu8jPjOcOecBddygdAYUjkYxh8veULzVnF2zOSEu3 CFNWfxTnN3VqwP8jMwIDA4VPCt7vCKGGnIy0LEFLF3kGoznbZMiyLBCW0tNGY0aykGYsyE7PEZJS Ugwp0mtrkoyGTYI+w5iRnW3OE6Ys9RNmTp8+Q0f/Zq7IMH2SmyOsTMrKEaIFCf8fIgihsdFZyeaU FYbYtA9z0i0ZKyNytxiT8k3CIoR0KAaFolgUhqYhPZqBItBMtAotQ6tRJJqN/NAatBYtRyFoHVqB GCQgT8oXkqOJyICuMojZwOxhXjvNdLog08r+IkfyQPkG+UOFQhGu2KYoZ3VsMnuPva/0h2o3ETC4 i91W5gn4y6Cw38QT/19N4i5wJ29Yadcm6mB4ltWjFQTYAMIYlb1VrOMH6ujjY6XqcZv98gPH+cwo NXlOI/9VwvBlD4gyZH12TLJaZf9e6SY2W0ABv4CC+TMIMvEEvOCLYeysH4gX5sgcnTeJJvoeH5gN Y150A39UQ8axBWHm7NWYC93Y9rbpSMPxGk3F+eqKenwHn8muCOUoqPcZa+knS2hWaBGv8SRQSxgS RvS9BEEQzO8DBpZA1JR3ZKFmL1Hwj2/ovbVxYYsXre3q62vqeqQZTDRMZxOnwTCYbfU4R7MVSRVu Ff1Gg9BvIgIpZ9NbPq6MoFB5PzKSzAs5ueRCnEbVGFfXntHu1YGvV9Y2c8RZdOW/va6f5BcfHhYW 3/nL64auLo1bfyq29YdamQfgD9cou+Lh0eBPs/oP7GTJZXGngnzwqwn8xb2sRNI7mNgDI94xog3y +L3l+CAuwS07bmy7mPZq9j3CUATTAoicLCNLXnqDDlxfdf67WkPUbOHGlM1rcTLedHzL+W3WL0/v buL29fClf629dB/X4ppCq/nolkN5+1M5t/5p2AY7wB3M4M48oqCOSC3Pg6M8xLAw7vnPMAW085+Q AA35TgLGirycnhWUT+rSFy9JTV8gMUay/vGW0vUChlFN0I7CNvAco+oWA6go5itV/2xLSji73IuM mkrcyQIS/CORg2frxRP3bmpClJHrE8PWpJ+8VKQmvuzepIqsC6Yr6Y7Cp5iDeS8fgkpD89yiOcgh gviumyGT/dZGhCxL6Hj15tq3DyifJywwSjwIo5grlDUtBd+v6+MbHdWv8Sv8ztAX1Rn9IPBrH+yD AzOjw6P0hkmY8kaYi5Pa9K3hTzP78Hf49rG7tdzzoEfdCvIVHOAXBT0OsXyeuXMT9iQuC3opr7on veAKbj9MJtNiilbnbtAMCtgJ3oKTRwMtNxK8iLskkl5xn+jE7wZ2Vifxpd2ZMFdPZGllxhN5mhP5 x7ffLIQFcWNVPbVF5UW54zJTtkSmZZWUF6i3ln1R9sU5epw9QJz/vhzmU1B3Kupr6mtO38DNuCvd HmojYU1jU8qLD+OT3Pkaa6Na1duBv87Zu577zY9UrkwHRbOGir+Depa2S7LjffvV1vOni3Ir1OUF Bz7D6Rx5OmhK3FHQkFptrEo8loj1eJ05JZYDq9INnosRPczTIQNV8QvBlyreV/9BJ/kbO9ee9FN1 5f7DlepXys9279hTjLnU7WUNGrhOPQ3VFMYuaxvVUYf0djJtPhGkmcD2m+Q0CWWIpXqzgAuVswtj Bx9oAR+Z+C/xAI87tl5Nq1/fEnRuIqVtqTaQTCSKO6tgilnzZsvr/DozjvVcsTJ1uu9HV77/Uk20 bCmZ/m4urKAqiQXZj1Skyg8dxKtKQ9iTgs1ow82etxprH//cnLzkoHrQdNBKRX5oyHiXJeMdgGc8 eTZovqmkilyCKmnI0d1nysEhMHyqVI7H3fcjLl+8OFqso3W8UKrsUYlJ4TGmmm/U8JrW6KIkw9vD Qfmw8YyjXq3Kj1JSXQ6ywYj9o0En1imouAMH3IJENwURpNUcaeXLQsBAnQImsc9F9+4Bd8UgidJ4 GGJQGryC1EZ2aGLOsImzQOFxlkKKgQkSJNtxfvOpncfwWQ6aleC0+DbREu2i5cR9uxq82JLbp77q xFzLmYK0gu2fbt2hyS/GWF+0snisUBC3CvvjhKOGymxOZd9UfT2/wcuBb1U1NnGqfGzeX3z0Uw4C WLIQTLzKHpScEPpxVmX95ZPWu+XqhtK6kkP7Kg57UlRDVQJAJQ+hYFOQYHY2mTcL5kkrCCU2EkEq FRDM/gTBL0iwtHL7j+tvF4iDlrJ46DdG1ej43SXS3X6h3nH9XPZGNRkYjPzhWfRQvo26T1B4fM7K JPWfmlafi8DLcXJewipO1dghiXHwEtOKFnBm2mC8HUZeA2+ZqIAEHreXlDku97SfuYqfcTDe9yWZ PCfCFLtRnblhW/yeQBrax+7qbrjfjjmHfV1k4uf5sfGa4HBL4v65HAir6F1I6Jxh3SynxDorLLTG n2LB2Rm8h4NzqYsLeB9xcUXof/knMTMKZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iagoxOTczCmVu ZG9iagoyMCAwIG9iago8PC9MZW5ndGgxIDU2NTIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAy MSAwIFI+PnN0cmVhbQp4nO1Yf3xU1ZU/59777nuTmWQmIUkDw483vBAxk5iAAQPhx0AygZBtDRB0 JoEy+YVJIxhgikAqjRYrTlBHi1QaUasWZd2yLyFCEF2jZouf0n6q3bhbfmitla5+LGvWXdwfQLLn vQks2ba2f+w/++OefN+995xz7z333HPfnBdAAEiGDuBQdfPKgplgl3GX6HFLw/q6tkQ/7XEAXNCw JarfnLL0FDHOAijRdW23rX/ouY/vB5BVAMK47fZt6xL6yUUA/MfNTXWNPbW73gPIIH2Y3UyMlAVq NUBSlPrZzeujWxP66cTD5tvvaKhL9FMJ+Pj6uq1tPFdNJv3HiKFvqFvfNGqfNd+Utjs2RxP9jJct edumprYNu34YJv0+ALZdeZisfI3ghRrlMAiAkQ8tbcwY/sSqLZlVLK7yLHxhGfkD5YtH/edIuznz DyrNhEfZPiiHJahAAO6EUpgOi8APv4E5sAsK4DropRO6HvJhOy4BgXugXumHv4ABto8dgVVQQ6On w2KIwT74Pp1nLiyBDdCm9MJsmE/tJTCM9+Oz+BFbxjaAAm7IJp1c2A2PgQmn4BOcg/NxEz6Mj+HT OERzT6GRJfbI5bAdXoXX4RxbABqkQCZRDvE3wmEa+Vu8DXfhm/gx2TEb5pHVX6ERt0AN2f0o7Ice GvsGnIA34e9Qxeuxkmgj2fIIy2Rhohq2mR1VhmjO8WDQDi2rZtA8C2mW5bSzWojCFthGEfpdeAZe gx9T7A2hA69DP9GNWI2tRA/jC/gj/BXLZrlsEbuDbWWH5JcojK4jH86guVZBHdRDM7TAHbAZvkl0 N+yEb8MjNOv3yMoniV6AQ/AK/Ax+Du/CP8JnmIzTaP5iXI3N+A2y+HHcj8/gEXwLzxBdYg5Wyh7h B8TzSoayV06VR+XPaUWdznKeTZbfV5EnbiVf1MJqoo20dhS+Tvv5Bu3nHngAnoBu8pBFR2GA6G3y 6Fla/1P4DC7A54jIUZLfnOjBTNrzDWRRCS7Dr+ByXIW1uAYbsYX8uQnjRHtwH1l4gOg57MbDRMfw OPnlBJ3PafyMTWBT2Cx2E5vPKthKogZ2J/sW+zZ7mO216SfsLfY2G2R/zy5xB5/OZ/MS3sij/Bl+ Utwk5oinxDvitDhr08diWJmsFCsh5W5lr/IL5V05TjbKp+UR+bfyl/Ij+e/qfRSH2RTJFJ0Ui5vg LorOTniIPH4ADsIRImvPP4O/gdNwBs4RfQL/QDvNwImoY7lNFRjGGlxP+/s6bsEddM6P0DlY+zuI r+Eb+Nf4Hv4Sf4Wf4T/hv+FlvMyAZVBkjae9TqbdTmUFrIhoPltKkVbD1rBGtoGi426iXSzODrDn 2QvsVfYGG2An2Vn2PhtiF7mTu3kO9/MiPouv5pt4J3+AP8Gf4s/yH/If8beJTvGLAkSV2C4eFKcU UJBiYLayVrlHeVo5pvxG+VQ6ZYacICfJGbJCLpOrZKvcIb8r35Sfq1zNVPPUCvU+9QR5Yz9Fwdiy Cb4Mz8Fq7KIb7QeEqXBM1EITn8zuxTC8zi/Z6MLpsANewTRxE1TCQfTDDlyLj8EyuJVu735spDt3 muJsPvTgqzCZ5+Bc+AUweoOcgkdxIrzKVHZIeRAPwv0Uq/9KsToLNvBX+Dv8OAtBK92xQ/QuugkH +WrcgCd4Eqsn35ymXjGd/KfWuxOzYB47z3rgRdDZd9hXxV38hsCsohtnzigsuCE/z597/fTrcqZl G1N9+pTJkyZ6J4zP+lJmRvq4tFSPOyXZ5UxyaKpUBGcIeUGjPKKbORFT5BhLl+ZbfaOOGHXXMCKm TqzysTqmHrHV9LGaAdJc9180AwnNwFVN9Oh0UfPz9KChmz8tM/Q+rFkeovYDZUZYN8/b7S/bbZFj d5Kp4/PRCD2Y1VymmxjRg2b5luZYMFJG83U7k0qN0qak/DzoTnJS00kts9xo68byBWg3WHlwbjcD LZmsMpcZZUGzwiizTDD5tGBdo1m1PBQs8/p84fw8E0sbjHoTjMWm22+rQKm9jClLTdVeRm+xtgOd endef2x3nwfqI35Xo9FYtzpk8rqwtUaq31xilJlLtn+YlZ/XhweqQ6ajtA+hOnQMlo10dFd0lJWF STPGg7HYfWPV8/MqV4R8ZI8R3K1bBq4I2baROmYV0PIWz9pAYitNRtDiRL6mmw5jsdEc+1qEjmFC zIQV23w9E5YFjo28D8uCeqw6ZPjMhV4jXFc2sTsdYiu2Ha4I6BVjJfl53Z7UhA+7U9yjDVfytY2m qzK7ZatbLbL6ihPRssiooMM39QadLAkZJptWbD2aiiHWUExqVMJIvmohz0RinrmWi5VpHkOPXQA6 YuP8b8dy6kY5cprnAlhNKxCuBhPJr7RNv9/MzbViQC2lQyPLFtj9Wfl5W8xKo82jm5XkMqgK0aDw 3AJyuc9nnV9nXwDqqWN2LA8l+jrUe3sgUOAPmyxiSfqvSDJWWZKOK5KrwyMGBWovWAlehqnlXP1z ezLHBZvnmpj5BeKmhJwuRlDvFsq0WFUopy7W6c2JxHaH6WjK6ZLFYuWGXh6LxOr6RjrqDd1jxLor K2NtwciVLfWN9Hd6zcDucDOSU80bbW+AtaZsGaZcTvNZmZE6aFtxbamxOT/FFeCx+4zqcVBMQ4dp hARclEXvnH1QSAgQqggCdPwBFBIChCpCG0GBDrYZTLY5kMygvJzmSkvVAkvpqvPAzUtn6u8RzhJO E04RDhG+T3iS8BDhW4QdhGZCIyFCWEv4KmENoZYQJqwi9OHrPXb1WqIKJKoFiWp+ohKJigUepfpd whmrT3ia8BQhTniQcC9hJ+Eewl2ErYQ7CS2EJkI9IbR0Zqoj1RH/nhrfq8a/o8bvU+PtanyLGt+k xlvV+Do1XqPGb1Xjt6jZ2lRN1yZrE7UJWpaWqaVraZpHS9FcWpKmaVITGtMov8NKs78BKut18/OV Rh8mLa8xFWMxmmmVUFm9+Big2n/vA5n+3y1Z13awsmrbMZiCbx9RpwyoU9pU4lWuJFbcYsUH1LjN ysKeKphZWdcZmQS/Z8rEVL+XGWxZuZgWCXVrsDhcujpRH2bOpLTSUMTrCy/O9LQtMKlzrMSXtcP7 kgB8Hpx0RVz0Nk0mWKL8RfmLLBF9GViiFOtFOyrK2lHi876Ez4+KPMROJTds3rzZikYrOOlXnz5y QIXcF0Uc1Dj2saIeSBJ/RT+0JKUnZwUABcPnPOdgofWcUehL9aVOowfSkpd03n8poMBF0EW/FeGk rHygHKVpHXDzYVSF1ofrAilcfVmRPImDQ3tZOPrwtsAkdjcIj9BFoQiINtEhTDEkHG+J96niomDN xsvnPZdT58yBhQvPe87PSZ0zoxAVWjRVoaXFTzDz4tbhd8T+i73iz5Sjly4G0SOeW37xz+kTDipG PlIuK132vpzgZvsCupd1MZZOmXUJ5U5RtpPJWtbK2lkvJUxnmGR92BLwoZd3cZbOs0czxp1c1vJW 3s57+Ul+hktOWofX0qXuYwcDUxWRru3RmFfza0Vaq9audWqyWmvUotpxbUAbpGC0JjWUJJku9gjm FX5RJFpFu+gUslo0iqg4LgbEoJDC0tO9skuydJktSygDjcqdUtZSutUue+VJeUZKSUpHHKpzLWVp 9vIpyemuPS7mdfldRa5WV7ur0yWrXY2uqOu4a8A16JIue9p09x4387r97iJ3q7vd3emW1e5Gd9R9 3D3gHnRLt6WUk5KUjG6eTqk389L3SBF9i7RjJ8pqSsyjlHwP4CAl8Akz/7iLAj7mdXY5Wboz21ni bHRGnTudstbZ6mx39jpPOs84pdPWSvJqXRpL17K1EtttOzVZazuyVzupnRn1n8+RruxRmFfxK0VK q9KudCqyWmlUospxZUAZVKRia/0pPn5R1dc60GF5z+ECxlLWutBl9cZ71Ij6qcoL1CpqdKhx1VT7 1fdVTaUwHP/Pa+bN88zzfLhmgufymo2b5p2nxzUt62E3SAmyFo63JOcsqccaaOucS4gvjHLtsRZv RqGDqw6pOhg3cPLwB8MfPJGoxN4xXaWLnr/GSU8M/3r4A5yMkxL1k4kq8VuT+z+Ebr9CeO7/Btm/ +4nMIJ3eSFRwAkFSozr8x//x8r+5CPqytp7C8s8Qs7KoIbT/y2T9tJB/IOEghDTyIaOWpK9xqK4O zpw9q7h0UXG0sNDOwzBu/Yz9iUUb2x2CobH//xrN4ig9+3/8dyINCn4H5VCRuBNfUDCBbvMvX1rr nncBvIkD/EHDiUN2/S931o+MDDepg7KFus4rw/4DFmvcyQplbmRzdHJlYW0KZW5kb2JqCjIxIDAg b2JqCjMyMTIKZW5kb2JqCjIyIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMjMgMCBSPj5zdHJlYW0KeJxlVgtYE1cWnhgyM0UIldkBEU0iUEXLS4SKomh5 a3koIK0PtAgIKAHkjQVr1dWVq9VabVm0BPGF1Ac+qFRRUbRVF3m0SJNqeAVs3Lq7drE9k73h270T u9t198tM5s59nLnn/8/5z5VQVmMoiURiHZmWVZRWkJmSLL55CM4SYeIYYZJ0O87+h7+pVDaJijr0 2BbZSJGNVe1E25/tBfk4+NwOSl6lpBJJye6qkJzc0rzM9IwClfvSuLenvf66x289M2bPnq1aU/rv EVVoWn5merZqCmkUpWXl5KrTsgsCVSFkdlZWZooqPas0NyNflZyampYqLktMzkpbrwrPzMrMzc0p UrmHTFP5+vjM8CR/vjGZ6jWF+ar45Ox8VZQqLi29MCs576VOiqJmRL1Zmp0SnZMak5sWG7ph7eKw vPQl4fkZcQWZ8YUJC4uKs5ITS9Rr3lZ5eHrt/+TAx0HzKcqTcqGWU7FUKOVFLabCKG9qCRVO+VCv UXFUBDWDmkLFU5GULzWVSqAWUjOppdQiyo9KpPyp6dTb1DtUNBVMzaKWUTFUCBVASShbSk7ZUcVU DlVAZVJKSkX5EuApK0pBDBykHkqmSlZKDo+hxrw+ZvuYYekC6SbpAys7qwSrMqurslhZk+wRHUHv oH9hvJlY5iHrwPqxi1g1W8N+8UrsK3mv1FlLrZdbf2z9ifVl6zZr/Vi3sW+MjR27f+wFGw7q5UIL 0psYjeShUQpvmtS816haWKbHZlpu8kY1sFwn+GgkQjbk8D04RzZC4/0mtQzb0LhyVC37K62FHBl8 rONxGQ020C+TC3/A2XrT78ia8UINj18ze+AJgofMl4Ywc+36gE1rS8ozkNP7qHx36R52AXNoy6Ed h9FxVLf/8MFj1VWHDzZCuUk+XtxWjbCkO0Nj36UN6oMPex25i13EIHfKXNMHjQzX/Utr18D9xpQo Bf5nr6BiBhe1Tpm3TB2cpOAuGhiyjQKt4KGV1A9KhfXwjN9xbfOp4rr05qi6YMTiyd7YCgfjecMq cIFx3/fA7w4oZ9Hls95NDkWsd0IPvAqON3SPuy6tCT6glJseoBpTqEbSYxD2GaRChgMkCyAzg8Gk xjyDM0btcJbJTob5UbVBABpSzEBwaHmxgbOD0DIohaPCWR5P9XXBoTjU4ALTYOrwc1gAC/1G8OvK XUH8k9Yg7IDtlszz9orTAgf2t3RGpWhEl1AjROkgSGN/bBCuExjKhK2EpgB8hM5oiT8RRryZ6Isl OFDJNeOwQSyByd9ePd7WpODKwh8weKOQzA/fCsTjxGHbJYEzvWMegRzkdx49VshNa1849p1BUBik pgnE7kyzkTaPE4yyKaIzBlqwNRtkz2nLToTpOsLHDZGPa4OO3KkbOJvvg2P0paXN+R2IBechkADZ RzeE+sMYrAyNWx+dSuj4Pojh2mBjFP/D13PwODw2Zo7PzCUPwQ7sbj80WJzUQmQH+GklFwekwgHY xKOHv79Sdj5zIPD6NOLfFE/C1gK84PFkmAo2vR1A1xC2CsJXpkeiRLTqSM6l4pPbTlZcZ3d38Pue fnWvD7H6exH+O9HOip2EveoCvfBULzlnFKqMUsHJVMrjNOyCvXAJLgHyhLWG749f/Ur5fftlkCEY y8L7WAmeeJ1ithX4/oRtcBQOdSEPL+ztSoI8EiJHyMNLKeKnF+7qJUNGYaJROuQAp2mIAhkooBiK sBUocLQSn6aNo868cBcWMOD23XQcg6PmT8Nuyv+C9FdmtcJWgijXZNr4ZhjDaW+mLj4Z7owVM7CM xGrQgAsouq8eu3VeiesZPMUUyA8RXu2xzX9Itb2j/0Eph3qSOREd4NwtMfRK4ROSNH56+ozms3P7 PkQV1YpOpmTP5l0bERuUtHqB0jcsosu8sldYOci8SPiLetivlzw2wtBTKXHmLg+l9C3UdOj8mUsX qi+jdhYmzdFiNwW+Mao20oKzFeyHRGaoZUVgYOIKX6VoRA8f6qFcLxkmkvIW9PPCZL15MpQLPnrz bqIuGr05mJbDANlmsIF430kCypFr6BSzu07M7qMM6qluvlDHcp3Hqo9+dHsX28+U7962azNaitas XzGP5Rr+TDK8BWd3wTgxyYiRukG4SKw8EnyImfkM9/Ru8jt1kc7YaQZmcZB/bdgXy5TnV7duuInu oy9PXL7P5jIodMu7RdmFWe+WvoPSUOaBgs9Kqrb+cXs9+wa93127GOyQDrUfPd144UrVfQR2LDG+ iBjGJdH8cMt87IjHLZ0/0yfBkq2tuqH/jTTThgreU9v53eknCBgnEg8u4IXXkt9Lofft1wfPfKV4 7ifDyXCIT4p/EP1u8bqtq5ET9nb7Lda8wXuEBGCEZ17w0hgSOUCI+tNLGMMzPX5GMFbpzeUiMf8R wMuDsIVo4CJBzlf8PeI2tiUJJZ8bNX12Yyq8qlbqSm6X1xahNKfly9cFr0qrPFyk2FT1+6rtDexM eg+27VgCk0hmj+9re6Zb/YXrUWVgdcTB7MOowenKF/Ud7WezE3YrftXqb2G+RtLVS6Ra2kWEZFTd S2RaFOnjx7eUaRRHNh7IQ2vZF2JtiLr52purCt5aroCTjEWG4Es97NHbG42Ah+c8deSeQwy087CN 7m1ImaHkhIpFaNXHqyvVTiCrpTOObDu282kF2JScnXua5Z7rL5y61jsB7Od2YlcFHrIEpsoK9kAh cx2d3FpbfLSoch1azfqvTnVXkAQp6Bamd0j6SXbsI9HiD24B2C004huzik48q27TaHbvPaHoYjb/ YVPFe4hN/+BAgxLwACOHPOJnsQaiNZJ2snY6WRtgrumlTWqrWS59YsEk/D/T2V8xLDTCXwwRRjGl jcKnfAW4TuvFcwnyfu6z8Xjfy/E/5ilh4QoZN/RDfuPauAkotSglqzC7OGnzYjQXLa3OaMz9/P0z u5oICbsiK1fXpVyN6EsHKRpE32gun20+X9+G7qHh+Pvux/FbzeM57cwj60+0TnjQ1vwXYNsSPXaJ nBR0LxN3a9/WC3uIuJQIRQ5CTQC+ynBNqvgwv4XJF+4pBCbA7M74tcX/pG0+3tms4EqCGUt0mWi9 BP5IYusXkzMPW/XmztmwbdSZxJUoL2LN+NsTKSQSnj1H1U/EaLNAI4FzDpAk1Mg8aexunodVwjzS hChzjczCsjhFuOYAXpYprmYPN3I0eI2eavZQkYY3DR5k5hP6meD9s9lbZgFc/FZHnxQ8yLdmjar7 LKWoK6xb8NHaNw5CpcW1z5uJbO7csgNtd85+r+qYEu4wxoirmJ8fVZiaocjP/UC98222j973p3N1 OsT2NOYsUxYyKKOobOFWbF1WumP9ppi8rJUoguVKPO7H/ny/pfbGV4qPEo/l30CHUOXu4/tIEYII HuVs3ZhXkJm15r3liF2UVt9ys+HEUKXS8Olne05Ushb9FLcrTHSAj8gpyZ3Gq8yjeJ0wKptKQxU5 L/2GUxMc4SEUPhKRssdx2B7iZB40hOADOBprZH+mwQmSwBEnyZ7SlgPIr4ehPsgVL0euWTwNiWqp Z7hH392803H3TFqkAo+KHeLrnbOpC8VXYRLzZOn1aWHJRYuXK7Jak49EoDCUtGFVFMs1P2BePmHc 6IXrpLCX3bDkb087wzXHXGjJ7nYGxTApa8EQ5P8cK0LeyV2cqoQ6BqbgGt74oqZHv1zT/xH6AgpT mQNEEyhcaTzBPITnCEMECvwGaU4iTVcaYgkqP9EwS/gR5pp/JJTXkwtPPTekkQw+lw6O8K5flzIo fFPxyp1sGtN1pmlACTYkFQdg27cSaIA2Hm8JgS2WuByRDI5IIZ6scR0RC4wpTGPfbFx1qYPcjlx/ s2kZ78pw/VfoXUvKczO2E3tf7z31JXrIPmO4ynYH1yvM/w8QgMQvCbfJl8z3QoR7xPDfIURYx4fH x4eHt8Z3dtxqbf8moTWMVN6BK02rjG3kduRaYLKwgR9huJYVdMWtqhOn97LnmNjt61aiuewUhvOB PQ4jK5j/H5ELj4SzoOHN5ZAim8sIChxgVmB/sSn2WLTW5KCTaPt1w0PDUuiFFfxlBl365FDHvZ6O o03oPguvBPSQs6TbgkDspein0Zd7T3x6pLrhQk0LYrXXkiKSClMTVyoXJyK0saAoZ1sBSmcTmGEP fobrMC0vqBVqRIWLqqV11r1jdXttbPr329hS1L8A8Df4BQplbmRzdHJlYW0KZW5kb2JqCjIzIDAg b2JqCjMxNDIKZW5kb2JqCjI0IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMjUgMCBSPj5zdHJlYW0KeJxjZGBhYmBkZOQJycxNLdYNys9NzAPxtX5IM/6Q Yfohy9zd/UPupxmrLIPPXGbebh7mbh6WBT8EhL4fFPy+j//7bgEGZkbGjafvOucXVBZlpmeUKGiE BoVramvrIEQMLS0tFZIqYTIKLqnFmel5CmpARllqTn5BbmpeibWCM1B1Tk5mskJ6TmVBRrFCYkpK agpIW1hiTmq2gltmTmZBQX6ZgoazpoKRgYGhLpAwslbwK81NLcrXUcjMS8vMyyypVEjMS1Hwz01N T1TITUxJBRngkptZUlSpYGKQmQfX7ZeZm1RarAD2sIJfvqWCj0JQanppTmIRpgwDAwOjIQODEAMT IyOL1/c+vh8d3bMYv2c+ZP6+/aeF6G8PA9Za9ukTpvX3986dNKd/ajfHgik12fJ/Itm7s5pLqptq mmo7Ers4ar6vmMVu01M9tXs3x4837Hzl83+Ezf8eMp9tJdcD7pWTeXgezOXhZWAAAJhai4gKZW5k c3RyZWFtCmVuZG9iagoyNSAwIG9iagozNjgKZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L1pZ S1JaWitIZWx2ZXRpY2EtQm9sZC9Gb250RGVzY3JpcHRvciAxMCAwIFIvVHlwZS9Gb250Ci9GaXJz dENoYXIgMzIvTGFzdENoYXIgMTIwL1dpZHRoc1sKMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYxMQowIDAgMCAwIDAgMCAwIDAg NzIyIDAgMCAwIDYxMSAwIDcyMiAwCjY2NyA3NzggMCA2NjcgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAKMCA1NTYgMCA1NTYgNjExIDU1NiAwIDYxMSA2MTEgMjc4IDAgMCAyNzggODg5IDYxMSA2MTEK MCAwIDAgNTU2IDMzMyA2MTEgMCA3NzggNTU2XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1 YnR5cGUvVHlwZTE+PgplbmRvYmoKMTMgMCBvYmoKPDwvQmFzZUZvbnQvTVVIT1NZK1RURTI2NThD QTh0MDAvRm9udERlc2NyaXB0b3IgMTIgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENo YXIgMi9XaWR0aHNbIDc1OSA3ODRdCi9FbmNvZGluZyAyNiAwIFIvU3VidHlwZS9UcnVlVHlwZT4+ CmVuZG9iagoyNiAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvRGlmZmVyZW5jZXNbCjEvYTc1L2E3OV0+PgplbmRvYmoKMTUgMCBvYmoKPDwvQmFzZUZv bnQvUFBKWkFFK0hlbHZldGljYS9Gb250RGVzY3JpcHRvciAxNCAwIFIvVHlwZS9Gb250Ci9GaXJz dENoYXIgMzIvTGFzdENoYXIgMTUwL1dpZHRoc1sKMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAy NzggMzMzIDI3OCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1ODQgNTU2CjAgNjY3IDAg MCA3MjIgNjY3IDYxMSAwIDAgMjc4IDAgMCA1NTYgODMzIDcyMiA3NzgKNjY3IDc3OCA3MjIgNjY3 IDYxMSAwIDY2NyA5NDQgMCAwIDAgMCAwIDAgMCAwCjAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzgg NTU2IDU1NiAyMjIgMCAwIDIyMiA4MzMgNTU2IDU1Ngo1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1 MDAgNzIyIDUwMCA1MDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDAgMCAzMzMgMzMzIDM1MCA1NTZdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlw ZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8L0Jhc2VGb250L1NKWkdMWitUaW1lcy1Sb21hbi9G b250RGVzY3JpcHRvciA4IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciA0OS9MYXN0Q2hhciA0OS9X aWR0aHNbIDUwMF0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5k b2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvWllLUlpaK0hlbHZl dGljYS1Cb2xkL0ZvbnRCQm94WzAgLTIxOCA4MjQgNzQ0XS9GbGFncyA0Ci9Bc2NlbnQgNzQ0Ci9D YXBIZWlnaHQgNzQ0Ci9EZXNjZW50IC0yMTgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEyMwovTWlz c2luZ1dpZHRoIDI3OAovQ2hhclNldCgvTC9uL2Mvby9kL04vZS9QL2cvUS9zL2gvdC9pL1MvSC91 L3cvbC9hL3gvbS9xdWVzdGlvbi9zcGFjZSkvRm9udEZpbGUzIDE4IDAgUj4+CmVuZG9iagoxMiAw IG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL01VSE9TWStUVEUyNjU4Q0E4dDAw L0ZvbnRCQm94WzIyIC0xMSA3NDkgNzE0XS9GbGFncyA0Ci9Bc2NlbnQgNzE0Ci9DYXBIZWlnaHQg NzE0Ci9EZXNjZW50IC0xMQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTEyCi9NaXNzaW5nV2lkdGgg NzUwCi9Gb250RmlsZTIgMjAgMCBSPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udE5hbWUvUFBKWkFFK0hlbHZldGljYS9Gb250QkJveFstNSAtMjE4IDkyOSA3NDFd L0ZsYWdzIDQKL0FzY2VudCA3NDEKL0NhcEhlaWdodCA3NDEKL0Rlc2NlbnQgLTIxOAovSXRhbGlj QW5nbGUgMAovU3RlbVYgMTM5Ci9NaXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC9ML0EveS9uL2Mv TS9xdW90ZWRibHJpZ2h0L28vZC9OL3AvZS9PL0QvcS9mL1AvRS9lbmRhc2gvci9nL1EvRi9zL2gv Ui90L2kvUy91L1QvSS92L2J1bGxldC93L3F1b3RlZGJsbGVmdC9sL2EvZ3JlYXRlci9WL3gvbS9i L3F1ZXN0aW9uL1cvc3BhY2UvY29tbWEvaHlwaGVuL3BlcmlvZCkvRm9udEZpbGUzIDIyIDAgUj4+ CmVuZG9iago4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvU0paR0xaK1Rp bWVzLVJvbWFuL0ZvbnRCQm94WzAgMCAzOTQgNjc0XS9GbGFncyA0Ci9Bc2NlbnQgNjc0Ci9DYXBI ZWlnaHQgNjc0Ci9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDU5Ci9NaXNzaW5nV2lk dGggMjUwCi9DaGFyU2V0KC9vbmUpL0ZvbnRGaWxlMyAyNCAwIFI+PgplbmRvYmoKMiAwIG9iago8 PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC4xNSkKL0NyZWF0aW9uRGF0ZShEOjIwMDcwMzAx MTc0MzUyKQovTW9kRGF0ZShEOjIwMDcwMzAxMTc0MzUyKQovVGl0bGUoTWljcm9zb2Z0IFBvd2Vy UG9pbnQgLSB2Z3MuUVNQRUMub3Blbi5pc3N1ZXMuQ0suMDEzMTA3KQovQ3JlYXRvcihQU2NyaXB0 NS5kbGwgVmVyc2lvbiA1LjIpCi9BdXRob3IoZ2FzaCk+PmVuZG9iagp4cmVmCjAgMjcKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDAyMzYwIDAwMDAwIG4gCjAwMDAwMTQwMTMgMDAwMDAgbiAKMDAw MDAwMjI5MSAwMDAwMCBuIAowMDAwMDAyMTMwIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAK MDAwMDAwMjExMCAwMDAwMCBuIAowMDAwMDAyNDA4IDAwMDAwIG4gCjAwMDAwMTM4MDIgMDAwMDAg biAKMDAwMDAxMjc4NSAwMDAwMCBuIAowMDAwMDEyOTQzIDAwMDAwIG4gCjAwMDAwMTE2NjIgMDAw MDAgbiAKMDAwMDAxMzIyMCAwMDAwMCBuIAowMDAwMDEyMDQ4IDAwMDAwIG4gCjAwMDAwMTM0MjYg MDAwMDAgbiAKMDAwMDAxMjI5NCAwMDAwMCBuIAowMDAwMDAyNDQ5IDAwMDAwIG4gCjAwMDAwMDI0 NzkgMDAwMDAgbiAKMDAwMDAwMjU0MiAwMDAwMCBuIAowMDAwMDA0NjAxIDAwMDAwIG4gCjAwMDAw MDQ2MjIgMDAwMDAgbiAKMDAwMDAwNzkxOCAwMDAwMCBuIAowMDAwMDA3OTM5IDAwMDAwIG4gCjAw MDAwMTExNjcgMDAwMDAgbiAKMDAwMDAxMTE4OCAwMDAwMCBuIAowMDAwMDExNjQyIDAwMDAwIG4g CjAwMDAwMTIyMDYgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAyNyAvUm9vdCAxIDAgUiAvSW5m byAyIDAgUgovSUQgWyiVQbCI61ZzFWEyt5JRi20lKSiVQbCI61ZzFWEyt5JRi20lKV0KPj4Kc3Rh cnR4cmVmCjE0MjM0CiUlRU9GCg== ------_=_NextPart_001_01C75C53.C8DF95C5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C75C53.C8DF95C5-- From nsis-bounces@ietf.org Fri Mar 02 05:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN53S-000251-Fp; Fri, 02 Mar 2007 05:32:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN53R-000224-LM for nsis@ietf.org; Fri, 02 Mar 2007 05:32:01 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN4s7-00016g-N0 for nsis@ietf.org; Fri, 02 Mar 2007 05:20:21 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l22AK1pj028812; Fri, 2 Mar 2007 11:20:11 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R, ATTLABS'" , "'Martin Stiemerling'" , "'nsis'" References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Fri, 2 Mar 2007 11:19:55 +0100 Message-ID: <000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDAADZkzgAAYmD6w In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com> X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Mar 2007 11:20:12 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry The main goal of using the QOS-NSLP messages is to carry a QSPEC object and deliver it to the right QOSM/RMF. If a QNE will support simultaneously more than one QOS models, say QOSM-I1, QOSM-I2, and a QoS-NSLP message, which carries a QSPEC that is say associated with QOSM-I1, arrives at a QNE, then the QNE must be able to deliver the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. How the QNE will know to which RMF it should deliver the received QSPEC? Best regards, Georgios > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > Sent: donderdag 1 maart 2007 23:49 > To: Georgios Karagiannis; Martin Stiemerling; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Georgios, > > Your examples don't illustrate how and why a QOSM ID field is > needed and used. > > Perhaps you are saying that QoS NSLP and RMF communicate with > messages and that the I-QOSM ID and L-QOSM ID need to be > included in those messages so that the QoS NSLP can react > differently based on which L-QOSM is being used by the RMF? > > If so, then this interaction suffers from the problems > identified in Cornelia's slide (attached) discussed on our > conference call on 31 January. > > If not, please give a more detailed example of how and why a > QOSM ID field is needed and used. > > Jerry > > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Thursday, March 01, 2007 11:11 AM > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Hi Jerry > > The need for the QOSM ID can be seen probably seen in the > below e-mail: > > Suppose that: > > A QNE supports the following: > > * end-to-end QOS Models: > QOSMI-1, QOSMI-2, QOSMI-3 > > * local QoS Models: > QOSML-1, QOSML-2, QOSML-3 > > Suppose now that the operator of such a QNE wants to use the follwing > combinations: > > * QOSMI-1 with QOSML-3. > > Meaning that end-to-end sessions and QOS-NSLP messages that > are carrying > > initial QSPEC of QOSM-I1 should be bound with local sessions > and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3 > > * QOSMI-2 with QOSML-3 > > Meaning that end-to-end sessions and QOS-NSLP messages that > are carrying > > initial QSPEC of QOSMI-2 should be bound with local sessions > and local QOS-NSLP messages that are carying local QSPEC of QOSML-3 > > * QOSMI-3 with QOSML-1 > > initial QSPEC of QOSMI-3 should be bound with local sessions > and local QOS-NSLP messages that are carying local QSPEC of QOSML-1 > > * QOSMI-3 with QOSML-2 > > initial QSPEC of QOSMI-3 should be bound with local sessions > and local QOS-NSLP messages that are carying local QSPEC of QOSML-2 > -- > > > If the QOSM ID will not be supported these combinations will > not beable > to > be made meaning that > A QNE will be able to support only one initial (end-to-end) QOSM with > only > one local QOSM at a time. > > Best Regards, > Georgios > > > > > > > -----Original Message----- > > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > > Sent: woensdag 28 februari 2007 14:43 > > To: Georgios Karagiannis; Martin Stiemerling; nsis > > Cc: ASH, GERALD R, ATTLABS > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > > qspec draft > > > > Georgios, All, > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Wednesday, February 28, 2007 12:37 AM > > > To: Martin Stiemerling; nsis > > > Subject: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > > > > > Hi > > > > > > I was busy updating some of the QOSM drafts and I have seen that > > > starting from version 13 of the QSPEC draft, the QOSM ID > field is > > > removed form the common header of a QSPEC object and > > instead of this, > > > the field QSPEC type is used. > > > > The QSPEC Type was introduced to support Roland's QSPEC > > stacking/encapsulation method (see > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht > > ml), it does not replace QOSM ID. > > > > The QOSM ID was removed in the discussion around the QSPEC-13 > > draft update, see the post on 1 November 2006 > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > > ml, where it says "A QOSM ID need not be defined or signaled > > and a QNE need not support any particular QOSM". Slide 3 of > > the QSPEC presentation at IETF-67 makes the same point. The > > same point is made again in the announcement of the draft to > > the NSIS list at > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht > > ml and the point is also made in Appendix A of the QSPEC > > draft itself. There were no objections to this point. > > > > > I agree that QSPEC type (shows if the QSPEC object is > initial or a > > > local) is useful and it should be used, but by removing > the QOSM ID > > > field it will mean that a QNE can always support only one type of > > > initial > > > (end-to-end) QOSM and one type of local QOSM. > > > That is not reasonable. A QNE should be able to support > > many QOSMs and > > > it should be able to distinguish and associate a QSPEC > > object with a > > > certain QOSM. > > > > There is no mention in any QSPEC draft as to how or why a > > QOSM ID field is needed or used. A QNE can support any QOSM > > it wants, it does not depend on a QOSM ID field from the QNI > > to determine which one. > > > > At a minimum, we would need to have a bit-level example of > > how/why such a field is needed to justify reintroducing the > > QOSM ID field. > > > > > Therefore, I think that it is required that the QOSM ID > > field should > > > be reintroduced in the QSPEC common header. The field > QSPEC type is > > > also useful ant it should be kept. > > > > We need clear justification to reintroduce the complexity of > > having the QOSM ID field and the IANA registry to maintain > > the parameter. > > > > Jerry > > > > > > > > Best regards, > > > Georgios > > > > > > > > > On 2/20/2007, "Martin Stiemerling" > > wrote: > > > > > > >Dear all, > > > > > > > >I would like to start the working group last call for the > > QSPEC draft > > > > >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > > > > > > >The WGLC is starting today and will run for two weeks > > until Tuesday > > > >Feb 6th. > > > > > > > >Please send your comments to the NSIS WG list. > > > > > > > > Martin > > > > > > > >Anfang der weitergeleiteten E-Mail: > > > > > > > >> Von: > > > >> Datum: 16. Februar 2007 21:50:02 MEZ > > > >> An: > > > >> Kopie: > > > >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt > > > >> > > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > >> directories. > > > >> This draft is a work item of the Next Steps in > Signaling Working > > > >> Group of the IETF. > > > >> > > > >> Title : QoS NSLP QSPEC Template > > > >> Author(s) : J. Ash, et al. > > > >> Filename : draft-ietf-nsis-qspec-15.txt > > > >> Pages : 54 > > > >> Date : 2007-2-16 > > > >> > > > >> The QoS NSLP protocol is used to signal QoS reservations and is > > > >> independent of a specific QoS model (QOSM) such as > IntServ or > > > >> DiffServ. Rather, all information specific to a QOSM is > > > >> encapsulated > > > >> in a separate object, the QSPEC. This document defines > > > a template > > > >> for the QSPEC including a number of QSPEC parameters. > > The QSPEC > > > >> parameters provide a common language to be re-used in > > > several QOSMs > > > >> and thereby aim to ensure the extensibility and > > > interoperability of > > > >> QoS NSLP. The node initiating the NSIS signaling adds > > > an initiator > > > >> QSPEC, which indicates the QSPEC parameters that must be > > > >> interpreted > > > >> by the downstream nodes less the reservation fails, thereby > > > >> ensuring > > > >> the intention of the NSIS initiator is preserved along the > > > >> signaling > > > >> path. > > > >> > > > >> A URL for this Internet-Draft is: > > > >> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > > > >> > > > >> To remove yourself from the I-D Announcement list, send a > > > message to > > > >> i-d-announce-request@ietf.org with the word unsubscribe in > > > the body of > > > >> the message. > > > >> You can also visit > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > >> to change your subscription settings. > > > >> > > > >> 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-qspec-15.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-qspec-15.txt". > > > >> > > > >> NOTE: The mail server at ietf.org can return the document in > > > >> MIME-encoded form by using the "mpack" utility. > To use this > > > >> feature, insert the command "ENCODING mime" > before the "FILE" > > > >> command. To decode the response(s), you will > need "munpack" or > > > >> a MIME-compliant mail reader. Different MIME-compliant > > > mail readers > > > >> exhibit different behavior, especially when dealing with > > > >> "multipart" MIME messages (i.e. documents which > have been split > > > >> up into multiple messages), so check your local > documentation on > > > >> how to manipulate these messages. > > > >> > > > >> Below is the data which will enable a MIME compliant > mail reader > > > >> implementation to automatically retrieve the ASCII > version of the > > > >> Internet-Draft.) > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 03 10:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNVxU-0005hJ-8B; Sat, 03 Mar 2007 10:15:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNVxT-0005hC-3W for nsis@ietf.org; Sat, 03 Mar 2007 10:15:39 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNVxQ-0003vM-QW for nsis@ietf.org; Sat, 03 Mar 2007 10:15:39 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 03 Mar 2007 17:15:31 +0200 id 0005FEB2.45E99113.000049D7 Date: Sat, 3 Mar 2007 17:15:31 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] GIST and dead peer X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, While doing the work on the mobility applicability, we have raised an issue on how dead peer detection happens. The main problem is the following: - MN makes a handover - Before the handover is complited with a new AR, and e.g. QoS NSLP state repaired with a local repair, the old AR notices that the MN disappeared, and executes state tear down. - The problem now is that the states will be torn down e2e before a local repair is established. Thus, the local repair becomes a full e2e state setup. A potential solution is that GIST could have a configurable "dead peer delay", i.e., in mobile networks, GIST could be configured to be a bit more conservative in indicationg peer failure to the NSLP layer. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 03 22:44:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNhdY-0004Nn-Of; Sat, 03 Mar 2007 22:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNhdX-0004JB-7F for nsis@ietf.org; Sat, 03 Mar 2007 22:43:51 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNhdV-00070l-U8 for nsis@ietf.org; Sat, 03 Mar 2007 22:43:51 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l243hibo006602; Sat, 3 Mar 2007 22:43:45 -0500 (EST) Received: from ann (EASTGATE-THREE-FORTY-ONE.MIT.EDU [18.97.6.86]) (authenticated bits=0) (User authenticated as starsu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l243hi6B011622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Mar 2007 22:43:44 -0500 (EST) Message-ID: <002501c75e0f$4f195890$56066112@ann> From: "Sung-Hyuck Lee" To: "Jukka MJ Manner" , References: Subject: Re: [NSIS] GIST and dead peer Date: Sat, 3 Mar 2007 22:43:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I wonder why you are trying to draw on your resources to make a new approach even though the existing method, Mobility ID, resovles very well the problems below. Regards, Sung-Hyuck ----- Original Message ----- From: "Jukka MJ Manner" To: Sent: Saturday, March 03, 2007 10:15 AM Subject: [NSIS] GIST and dead peer > > Hi, > > While doing the work on the mobility applicability, we have raised an > issue on how dead peer detection happens. The main problem is the > following: > > - MN makes a handover > > - Before the handover is complited with a new AR, and e.g. QoS NSLP state > repaired with a local repair, the old AR notices that the MN > disappeared, and executes state tear down. > > - The problem now is that the states will be torn down e2e before a local > repair is established. Thus, the local repair becomes a full e2e state > setup. > > > A potential solution is that GIST could have a configurable "dead peer > delay", i.e., in mobile networks, GIST could be configured to be a bit > more conservative in indicationg peer failure to the NSLP layer. > > > Jukka > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 04 16:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxtx-0000u8-HI; Sun, 04 Mar 2007 16:05:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxtv-0000t7-UR for nsis@ietf.org; Sun, 04 Mar 2007 16:05:51 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNxtu-0006p8-LS for nsis@ietf.org; Sun, 04 Mar 2007 16:05:51 -0500 Received: from [192.168.178.25] (mnhm-590c2ee5.pool.einsundeins.de [89.12.46.229]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A9AA713CF81 for ; Sun, 4 Mar 2007 22:08:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <228D6060-6C3F-4492-87B1-C590845FAB9C@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Sun, 4 Mar 2007 22:05:40 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] NSIS Agenda for IETF 68 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, If you are interested in having a slot at the NSIS meeting at the IETF, please send the following information: Draft name Presenter's name Time slot needed. As we are behind with all our milestones, time slots will be granted for WG items only. Any non-WG item will only be presented if time permits, i.e., after the WG items have been presented. Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 04 16:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxv0-0001J1-14; Sun, 04 Mar 2007 16:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNxuy-0001Iv-Ey for nsis@ietf.org; Sun, 04 Mar 2007 16:06:56 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNxuw-00071S-IY for nsis@ietf.org; Sun, 04 Mar 2007 16:06:56 -0500 Received: from [192.168.178.25] (mnhm-590c2ee5.pool.einsundeins.de [89.12.46.229]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B31F713CF81 for ; Sun, 4 Mar 2007 22:09:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-1--685798436 References: From: Martin Stiemerling Date: Sun, 4 Mar 2007 22:06:53 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: [NSIS] Reminder for WGLC for draft-ietf-nsis-qspec-15.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --Apple-Mail-1--685798436 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, This is just a friendly reminder for the QSPEC WGLC which runs until March 6th. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 20. Februar 2007 15:54:44 MEZ > An: nsis > Betreff: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt > > Dear all, > > I would like to start the working group last call for the QSPEC draft > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > The WGLC is starting today and will run for two weeks until Tuesday > Feb 6th. > > Please send your comments to the NSIS WG list. > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: >> Datum: 16. Februar 2007 21:50:02 MEZ >> An: >> Kopie: >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Next Steps in Signaling Working >> Group of the IETF. >> >> Title : QoS NSLP QSPEC Template >> Author(s) : J. Ash, et al. >> Filename : draft-ietf-nsis-qspec-15.txt >> Pages : 54 >> Date : 2007-2-16 >> >> The QoS NSLP protocol is used to signal QoS reservations and is >> independent of a specific QoS model (QOSM) such as IntServ or >> DiffServ. Rather, all information specific to a QOSM is >> encapsulated >> in a separate object, the QSPEC. This document defines a template >> for the QSPEC including a number of QSPEC parameters. The QSPEC >> parameters provide a common language to be re-used in several >> QOSMs >> and thereby aim to ensure the extensibility and >> interoperability of >> QoS NSLP. The node initiating the NSIS signaling adds an >> initiator >> QSPEC, which indicates the QSPEC parameters that must be >> interpreted >> by the downstream nodes less the reservation fails, thereby >> ensuring >> the intention of the NSIS initiator is preserved along the >> signaling >> path. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> 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-qspec-15.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-qspec-15.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. --Apple-Mail-1--685798436 Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0666; name=ATT61320.TXT Content-Disposition: attachment; filename=ATT61320.TXT Content-Type:=20Message/External-body;=20access-type=3D"mail-server";=0D=0A= =09server=3D"mailserv@ietf.org"=0D=0A=0D=0AContent-Type:=20text/plain=0D=0A= Content-ID:=20<2007-2-16110157.I-D@ietf.org>=0D=0A=0D=0AENCODING=20mime=0D= =0AFILE=20/internet-drafts/draft-ietf-nsis-qspec-15.txt=0D=0A= --Apple-Mail-1--685798436 Content-Transfer-Encoding: quoted-printable Content-Type: application/defanged-0; x-unix-mode=0666; name=draft-ietf-nsis-qspec-15_URL.DEFANGED-0 Content-Disposition: attachment; filename=draft-ietf-nsis-qspec-15_URL.DEFANGED-0 [InternetShortcut]=0D=0A= URL=3Dftp://ftp.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt=0D=0A= --Apple-Mail-1--685798436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0666; name=ATT61321.txt Content-Disposition: attachment; filename=ATT61321.txt _______________________________________________=0D nsis mailing list=0D nsis@ietf.org=0D https://www1.ietf.org/mailman/listinfo/nsis=0D --Apple-Mail-1--685798436 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-1--685798436 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-1--685798436-- From nsis-bounces@ietf.org Sun Mar 04 21:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO37L-00024J-CB; Sun, 04 Mar 2007 21:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO37K-00024D-BR for nsis@ietf.org; Sun, 04 Mar 2007 21:40:02 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO37J-0001It-N4 for nsis@ietf.org; Sun, 04 Mar 2007 21:40:02 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Sun, 4 Mar 2007 21:39:43 -0500 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007030421394324535 ; Sun, 04 Mar 2007 21:39:43 -0500 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 21:39:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Reminder for WGLC for draft-ietf-nsis-qspec-15.txt Date: Sun, 4 Mar 2007 21:39:43 -0500 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D009@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Reminder for WGLC for draft-ietf-nsis-qspec-15.txt Thread-Index: AcdeoUHLywGhqNjFQXKRkdbFKQAp3QAKjFaF References: From: "Roy, Radhika R." To: "Martin Stiemerling" , "nsis" X-OriginalArrivalTime: 05 Mar 2007 02:39:43.0901 (UTC) FILETIME=[88297CD0:01C75ECF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1544472335==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1544472335== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75ECF.87DD7F40" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75ECF.87DD7F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin: =20 In addition to Georgio's comments, the following comments are provided: 1.=09 Extensions of QSPEC for implementation-specific value-based DSTE and = Y.xxxx QOS-SLAs MUST be deleted. 2.=09 It had been explained in many emails (if needed, I can include those = from the NSIS archives) that value-based QOS-SLAs do NOT need any NSIS = QOS signaling messages as those SLAs have been created not to send any = signaling messages in the first place because there is nothing to = negotiate as those have followed a different models - know as service = level agreements (SLAs). For example, OSP (Open Settlement Protocol) is = used among the service providers for SLAs - a kind of QOS and other = service provisioning aspects of SLAs are taken care of by using = fixed-value based agreements. 3.=09 QOS model (QOSM) drafts like DiffServ and others are being written how = QOS model-specific part will be used/extended by the QSPEC, and nothing = has been done in this QSPEC draft to take care of the DIffServ and/or = IntServ QOS models. This provides another basic reference why = QOS-model-specific extensions must NOT be taken into account in this = draft. Some side comments: 1. Is this the norm of the IETF that the names of the contributors MUST = be written upfront of the RFC? If not, why is this being followed = specific for this draft? 2. Will anyone of this NSIS WG provide any testimony or proof that the = persons whose names have been included as contributors in this draft? If = not, how are those names being printed there? Instead, why have the = members like Georgios, and others who contributed all along in this = mailing list not included as contributors in this draft? Or, could you = please see the NSIS email archives to find the proof who are the actual = contributors? Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Martin Stiemerling Sent: Sun 3/4/2007 4:06 PM To: nsis Subject: [NSIS] Reminder for WGLC for draft-ietf-nsis-qspec-15.txt=20 Dear all, This is just a friendly reminder for the QSPEC WGLC which runs until=20 March 6th. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 20. Februar 2007 15:54:44 MEZ > An: nsis > Betreff: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt > > Dear all, > > I would like to start the working group last call for the QSPEC draft > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > The WGLC is starting today and will run for two weeks until Tuesday=20 > Feb 6th. > > Please send your comments to the NSIS WG list. > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: >> Datum: 16. Februar 2007 21:50:02 MEZ >> An: >> Kopie: >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Next Steps in Signaling Working=20 >> Group of the IETF. >> >> Title : QoS NSLP QSPEC Template >> Author(s) : J. Ash, et al. >> Filename : draft-ietf-nsis-qspec-15.txt >> Pages : 54 >> Date : 2007-2-16 >> =20 >> The QoS NSLP protocol is used to signal QoS reservations and is >> independent of a specific QoS model (QOSM) such as IntServ or >> DiffServ. Rather, all information specific to a QOSM is=20 >> encapsulated >> in a separate object, the QSPEC. This document defines a template >> for the QSPEC including a number of QSPEC parameters. The QSPEC >> parameters provide a common language to be re-used in several=20 >> QOSMs >> and thereby aim to ensure the extensibility and=20 >> interoperability of >> QoS NSLP. The node initiating the NSIS signaling adds an=20 >> initiator >> QSPEC, which indicates the QSPEC parameters that must be=20 >> interpreted >> by the downstream nodes less the reservation fails, thereby=20 >> ensuring >> the intention of the NSIS initiator is preserved along the=20 >> signaling >> path. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the=20 >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> 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-qspec-15.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-qspec-15.txt". >> =20 >> 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.=20 ------_=_NextPart_001_01C75ECF.87DD7F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [NSIS] Reminder for WGLC for = draft-ietf-nsis-qspec-15.txt=0A= =0A= =0A= =0A=
Martin:
=0A=
 
=0A=
In addition to Georgio's = comments, the following comments are provided:
=0A=
=0A=
    =0A=
  1. =0A=
    Extensions of QSPEC for = implementation-specific value-based DSTE and Y.xxxx QOS-SLAs MUST be = deleted.
    2. =0A=
  2. =0A=
    It had been explained in many emails = (if needed, I can include those from the NSIS archives) that value-based = QOS-SLAs do NOT need any NSIS QOS signaling messages as those SLAs have = been created not to send any signaling messages in the first = place because there is nothing to negotiate as those have followed = a different models - know as service level agreements (SLAs). For = example, OSP (Open Settlement Protocol) is used among the service = providers for SLAs - a kind of QOS and other service provisioning = aspects of SLAs are taken care of by using fixed-value based = agreements.
    3. =0A=
  3. =0A=
    QOS model (QOSM) drafts like DiffServ = and others are being written how QOS model-specific part will = be used/extended by the QSPEC, and nothing has been done in this = QSPEC draft to take care of the DIffServ and/or IntServ QOS models. This = provides another basic reference why QOS-model-specific extensions = must NOT be taken into account in this = draft.
=0A=

Some side comments:

=0A=
    =0A=
  1. Is this the norm of the IETF that the = names of the contributors MUST be written upfront of the RFC? If not, = why is this being followed specific for this draft?
    2. =0A=
  2. Will anyone of this NSIS WG provide any = testimony or proof that the persons whose names have been included = as contributors in this draft? If not, how are those names being = printed there? Instead, why have the members like Georgios, and others = who contributed all along in this mailing list not included as = contributors in this draft? Or, could you please see the NSIS email = archives to find the proof who are the actual = contributors?
=0A=

Best regards,

=0A=

Radhika

=0A=

=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on behalf of Martin Stiemerling
Sent: = Sun 3/4/2007 4:06 PM
To: nsis
Subject: [NSIS] = Reminder for WGLC for draft-ietf-nsis-qspec-15.txt

=0A=
=0A=

Dear all,

This is just a friendly reminder for = the QSPEC WGLC which runs until 
March = 6th.

Thanks,

   Martin

Anfang der = weitergeleiteten E-Mail:

> Von: Martin Stiemerling = <stiemerling@netlab.nec.de>
> Datum: 20. Februar 2007 = 15:54:44 MEZ
> An: nsis <nsis@ietf.org>
> Betreff: = [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt
>
> Dear = all,
>
> I would like to start the working group last call = for the QSPEC draft
> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt).>
> The WGLC is starting today and will run for two weeks = until Tuesday 
> Feb 6th.
>
> Please send your = comments to the NSIS WG list.
>
>   = Martin
>
> Anfang der weitergeleiteten = E-Mail:
>
>> Von: = <Internet-Drafts@ietf.org>
>> Datum: 16. Februar 2007 = 21:50:02 MEZ
>> An: <i-d-announce@ietf.org>
>> = Kopie: <nsis@ietf.org>
>> Betreff: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-15.txt
>>
>> A New = Internet-Draft is available from the on-line Internet-Drafts
>> = directories.
>> This draft is a work item of the Next Steps in = Signaling Working 
>> Group of the = IETF.
>>
>>      Title   =         : QoS NSLP QSPEC = Template
>>      = Author(s)       : J. Ash, et = al.
>>      = Filename        : = draft-ietf-nsis-qspec-15.txt
>>      = Pages           : = 54
>>      Date    =         : 2007-2-16
>> =     
>> The QoS NSLP protocol is used to = signal QoS reservations and is
>>    independent = of a specific QoS model (QOSM) such as IntServ = or
>>    DiffServ.  Rather, all information = specific to a QOSM is 
>> = encapsulated
>>    in a separate object, the = QSPEC.  This document defines a = template
>>    for the QSPEC including a number = of QSPEC parameters.  The QSPEC
>>    = parameters provide a common language to be re-used in = several 
>> QOSMs
>>    and = thereby aim to ensure the extensibility and 
>> = interoperability of
>>    QoS NSLP.  The = node initiating the NSIS signaling adds an 
>> = initiator
>>    QSPEC, which indicates the QSPEC = parameters that must be 
>> = interpreted
>>    by the downstream nodes less = the reservation fails, thereby 
>> = ensuring
>>    the intention of the NSIS = initiator is preserved along the 
>> = signaling
>>    path.
>>
>> A = URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt
= >>
>> To remove yourself from the I-D Announcement list, = send a message to
>> i-d-announce-request@ietf.org with the = word unsubscribe in the 
>> body of
>> the = message.
>> You can also visit https://www1.ietf.or= g/mailman/listinfo/I-D-
>> announce
>> to change = your subscription settings.
>>
>> 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-qspec-15.txt".
>>
>> A list of = Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html<= /A>
>> or ftp://ftp.ietf.org/iet= f/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-qspec-15.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_001_01C75ECF.87DD7F40-- --===============1544472335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1544472335==-- From nsis-bounces@ietf.org Sun Mar 04 22:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3am-0007J3-Bf; Sun, 04 Mar 2007 22:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3ak-0007Eq-NO for nsis@ietf.org; Sun, 04 Mar 2007 22:10:26 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO3aj-00088g-1Y for nsis@ietf.org; Sun, 04 Mar 2007 22:10:26 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l253ANgR013336 for ; Mon, 5 Mar 2007 12:10:23 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l253AOg20712 for ; Mon, 5 Mar 2007 12:10:24 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id l253ANv07654 for ; Mon, 5 Mar 2007 12:10:23 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 11:10:03 +0800 Message-ID: <45EB8A0A.8050009@sg.panasonic.com> Date: Mon, 05 Mar 2007 11:10:02 +0800 From: Hong Cheng User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2007 03:10:03.0134 (UTC) FILETIME=[C48269E0:01C75ED3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Toyoki Ue , Takako Sanda Subject: [NSIS] FW: I-D ACTION:draft-cheng-nsis-multihoming-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, We have submitted an individual draft regarding the multihoming issues. Please take a look and provide comments. The relevant information is in the forwarded announcement below. cheers Cheng Hong ================================================================ * To: i-d-announce at ietf.org * Subject: I-D ACTION:draft-cheng-nsis-multihoming-00.txt * From: Internet-Drafts at ietf.org * Date: Tue, 27 Feb 2007 15:50:02 -0500 * Cc: * List-archive: * List-help: * List-id: i-d-announce.ietf.org * List-post: * List-subscribe: , * List-unsubscribe: , * Reply-to: internet-drafts at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS Multihoming Support Issues Author(s) : H. Cheng, et al. Filename : draft-cheng-nsis-multihoming-00.txt Pages : 25 Date : 2007-2-27 The NSIS operation will be greatly affected by the multihoming development in IETF such as Monami6, Shim6, etc. Solutions from these groups introduce different architecture elements and assumptions to the network layer, and thus render the current NSIS protocols ineffective or irrelevant. This draft provides an analysis of the multhoming scenarios that have impacts on the NSIS operation. Requirements for NSIS multihoming support are derived from the discussions of the NSIS applicability in these scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-nsis-multihoming-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-cheng-nsis-multihoming-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-cheng-nsis-multihoming-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 04 22:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3vg-0000OD-1G; Sun, 04 Mar 2007 22:32:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO3ve-0000Nm-5G for nsis@ietf.org; Sun, 04 Mar 2007 22:32:02 -0500 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO3vc-0002yb-Gm for nsis@ietf.org; Sun, 04 Mar 2007 22:32:02 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l253VrHm027296; Mon, 5 Mar 2007 12:31:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l253Vtt12284; Mon, 5 Mar 2007 12:31:55 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id l253Vss07308; Mon, 5 Mar 2007 12:31:54 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] GIST and dead peer Date: Mon, 5 Mar 2007 11:31:50 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0195E7AD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST and dead peer Thread-Index: Acddpzbg/fmdgt25QA+t+yA+Oyaj4QBLfrdQ From: "Cheng Hong" To: "Jukka MJ Manner" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, > A potential solution is that GIST could have a configurable=20 > "dead peer delay", i.e., in mobile networks, GIST could be=20 > configured to be a bit more conservative in indicationg peer=20 > failure to the NSLP layer. This might work. However, it requires a quite smart administrator of the network that "diligently" configure for each of the session the correct delay (as not all nodes are mobile). Another issue of introducing a general "delay" to solve the problem is that the local resources are wasted during the "delay" time for a genuine dead peer case.=20 So, I think the proposed "delay" method is a possible workaround, but it does not really solve the fundamental issues here: differentiate a mobility event and a real dead peer case.=20 Cheers Cheng Hong =20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Saturday, March 03, 2007 11:16 PM > To: nsis@ietf.org > Subject: [NSIS] GIST and dead peer >=20 >=20 > Hi, >=20 > While doing the work on the mobility applicability, we have=20 > raised an issue on how dead peer detection happens. The main=20 > problem is the > following: >=20 > - MN makes a handover >=20 > - Before the handover is complited with a new AR, and e.g.=20 > QoS NSLP state > repaired with a local repair, the old AR notices that the MN > disappeared, and executes state tear down. >=20 > - The problem now is that the states will be torn down e2e=20 > before a local > repair is established. Thus, the local repair becomes a=20 > full e2e state > setup. >=20 >=20 > A potential solution is that GIST could have a configurable=20 > "dead peer delay", i.e., in mobile networks, GIST could be=20 > configured to be a bit more conservative in indicationg peer=20 > failure to the NSLP layer. >=20 >=20 > Jukka >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 04 23:43:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO51k-0006gd-7p; Sun, 04 Mar 2007 23:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO51i-0006gY-Uy for nsis@ietf.org; Sun, 04 Mar 2007 23:42:22 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HO51f-0003Bp-DZ for nsis@ietf.org; Sun, 04 Mar 2007 23:42:22 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1173069734!4837269!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19509 invoked from network); 5 Mar 2007 04:42:14 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-7.tower-146.messagelabs.com with SMTP; 5 Mar 2007 04:42:14 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l254gAV4014656; Sun, 4 Mar 2007 23:42:10 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l254g0eI014639; Sun, 4 Mar 2007 23:42:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Sun, 4 Mar 2007 22:41:59 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8286@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDAADZkzgAAYmD6wAIpkMMA= References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com> <000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> From: "ASH, GERALD R, ATTLABS" To: "Georgios Karagiannis" , "Martin Stiemerling" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, All,=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Friday, March 02, 2007 5:20 AM > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 > qspec draft >=20 > Hi Jerry >=20 > The main goal of using the QOS-NSLP messages is to=20 > carry a QSPEC object and deliver it to the right QOSM/RMF. >=20 > If a QNE will support simultaneously more than one QOS=20 > models, say QOSM-I1, > QOSM-I2,=20 > and a QoS-NSLP message, which carries a QSPEC that is say=20 > associated with > QOSM-I1, > arrives at a QNE, then the QNE must be able to deliver=20 > the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. >=20 > How the QNE will know to which RMF it should deliver the=20 > received QSPEC? First, the notion of multiple RMF/QOSMs that a QNE might decide to deliver a QSPEC to makes no sense to me. Even so, if a QSPEC carries an I-QOSM ID, how does a QNE decide which of the multiple RMF/L-QOSMs to send it to based only on the I-QOSM ID? Presumable it would have to decide based on other content of the QSPEC in addition to the QOSM-ID. We still haven't gotten a concrete bit-level example of how the QOSM ID might be used. Without such clear justification I don't think reintroducing the QOSM ID field can be supported. It would be good for others to comment on this. Thanks, Jerry >=20 > Best regards, > Georgios >=20 > > -----Original Message----- > > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > > Sent: donderdag 1 maart 2007 23:49 > > To: Georgios Karagiannis; Martin Stiemerling; nsis > > Cc: ASH, GERALD R, ATTLABS > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 > > qspec draft > >=20 > > Georgios, > >=20 > > Your examples don't illustrate how and why a QOSM ID field is=20 > > needed and used. =20 > >=20 > > Perhaps you are saying that QoS NSLP and RMF communicate with=20 > > messages and that the I-QOSM ID and L-QOSM ID need to be=20 > > included in those messages so that the QoS NSLP can react=20 > > differently based on which L-QOSM is being used by the RMF? > >=20 > > If so, then this interaction suffers from the problems=20 > > identified in Cornelia's slide (attached) discussed on our=20 > > conference call on 31 January. > >=20 > > If not, please give a more detailed example of how and why a=20 > > QOSM ID field is needed and used. > >=20 > > Jerry=20 > >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Thursday, March 01, 2007 11:11 AM > > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 > > qspec draft > >=20 > > Hi Jerry > >=20 > > The need for the QOSM ID can be seen probably seen in the=20 > > below e-mail: > >=20 > > Suppose that: > >=20 > > A QNE supports the following: > >=20 > > * end-to-end QOS Models:=20 > > QOSMI-1, QOSMI-2, QOSMI-3=20 > >=20 > > * local QoS Models: > > QOSML-1, QOSML-2, QOSML-3 > >=20 > > Suppose now that the operator of such a QNE wants to use=20 > the following > > combinations: > >=20 > > * QOSMI-1 with QOSML-3. > >=20 > > Meaning that end-to-end sessions and QOS-NSLP messages that=20 > > are carrying > >=20 > > initial QSPEC of QOSM-I1 should be bound with local sessions=20 > > and local QOS-NSLP messages that are carrying local QSPEC of QOSM-L3 > >=20 > > * QOSMI-2 with QOSML-3 > >=20 > > Meaning that end-to-end sessions and QOS-NSLP messages that=20 > > are carrying > >=20 > > initial QSPEC of QOSMI-2 should be bound with local sessions=20 > > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-3 > >=20 > > * QOSMI-3 with QOSML-1 > >=20 > > initial QSPEC of QOSMI-3 should be bound with local sessions=20 > > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-1 > >=20 > > * QOSMI-3 with QOSML-2 > >=20 > > initial QSPEC of QOSMI-3 should be bound with local sessions=20 > > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-2 > > -- > >=20 > >=20 > > If the QOSM ID will not be supported these combinations will=20 > > not beable > > to > > be made meaning that=20 > > A QNE will be able to support only one initial (end-to-end)=20 > > QOSM with > > only > > one local QOSM at a time. > >=20 > > Best Regards, > > Georgios > >=20 > > > -----Original Message----- > > > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > > > Sent: woensdag 28 februari 2007 14:43 > > > To: Georgios Karagiannis; Martin Stiemerling; nsis > > > Cc: ASH, GERALD R, ATTLABS > > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 > > > qspec draft > > >=20 > > > Georgios, All, > > >=20 > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: Wednesday, February 28, 2007 12:37 AM > > > > To: Martin Stiemerling; nsis > > > > Subject: [NSIS] comment on reintroduction of QOSM-ID in=20 > > > > qspec draft > > > >=20 > > > > Hi > > > >=20 > > > > I was busy updating some of the QOSM drafts and I have=20 > > > > seen that=20 > > > > starting from version 13 of the QSPEC draft, the QOSM ID=20 > > > > field is=20 > > > > removed form the common header of a QSPEC object and=20 > > > > instead of this,=20 > > > > the field QSPEC type is used. > > >=20 > > > > The QSPEC Type was introduced to support Roland's QSPEC=20 > > > > stacking/encapsulation method (see=20 > > > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht > > > > ml), it does not replace QOSM ID. > > > > > > > > The QOSM ID was removed in the discussion around the QSPEC-13=20 > > > > draft update, see the post on 1 November 2006=20 > > > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > > > > ml, where it says "A QOSM ID need not be defined or signaled=20 > > > > and a QNE need not support any particular QOSM". Slide 3 of=20 > > > > the QSPEC presentation at IETF-67 makes the same point. The=20 > > > > same point is made again in the announcement of the draft to=20 > > > the NSIS list at=20 > > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht > > > ml and the point is also made in Appendix A of the QSPEC=20 > > > draft itself. There were no objections to this point. > > >=20 > > > > I agree that QSPEC type (shows if the QSPEC object is=20 > > initial or a=20 > > > > local) is useful and it should be used, but by removing=20 > > the QOSM ID=20 > > > > field it will mean that a QNE can always support only=20 > one type of=20 > > > > initial > > > > (end-to-end) QOSM and one type of local QOSM. > > > > That is not reasonable. A QNE should be able to support=20 > > > many QOSMs and=20 > > > > it should be able to distinguish and associate a QSPEC=20 > > > object with a=20 > > > > certain QOSM. > > >=20 > > > There is no mention in any QSPEC draft as to how or why a=20 > > > QOSM ID field is needed or used. A QNE can support any QOSM=20 > > > it wants, it does not depend on a QOSM ID field from the QNI=20 > > > to determine which one. > > >=20 > > > At a minimum, we would need to have a bit-level example of=20 > > > how/why such a field is needed to justify reintroducing the=20 > > > QOSM ID field. > > >=20 > > > > Therefore, I think that it is required that the QOSM ID=20 > > > field should=20 > > > > be reintroduced in the QSPEC common header. The field=20 > > QSPEC type is=20 > > > > also useful ant it should be kept. > > >=20 > > > We need clear justification to reintroduce the complexity of=20 > > > having the QOSM ID field and the IANA registry to maintain=20 > > > the parameter. > > >=20 > > > Jerry > > > =20 > > > >=20 > > > > Best regards, > > > > Georgios > > > >=20 > > > >=20 > > > > On 2/20/2007, "Martin Stiemerling"=20 > > > wrote: > > > >=20 > > > > >Dear all, > > > > > > > > > >I would like to start the working group last call for the=20 > > > QSPEC draft=20 > > > >=20 > > >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > > > > > > > > >The WGLC is starting today and will run for two weeks=20 > > > until Tuesday=20 > > > > >Feb 6th. > > > > > > > > > >Please send your comments to the NSIS WG list. > > > > > > > > > > Martin > > > > > > > > > >Anfang der weitergeleiteten E-Mail: > > > > > > > > > >> Von: > > > > >> Datum: 16. Februar 2007 21:50:02 MEZ > > > > >> An: > > > > >> Kopie: > > > > >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt > > > > >> > > > > >> A New Internet-Draft is available from the on-line=20 > > > Internet-Drafts=20 > > > > >> directories. > > > > >> This draft is a work item of the Next Steps in=20 > > Signaling Working=20 > > > > >> Group of the IETF. > > > > >> > > > > >> Title : QoS NSLP QSPEC Template > > > > >> Author(s) : J. Ash, et al. > > > > >> Filename : draft-ietf-nsis-qspec-15.txt > > > > >> Pages : 54 > > > > >> Date : 2007-2-16 > > > > >> > > > > >> The QoS NSLP protocol is used to signal QoS=20 > reservations and is > > > > >> independent of a specific QoS model (QOSM) such as=20 > > IntServ or > > > > >> DiffServ. Rather, all information specific to a QOSM is=20 > > > > >> encapsulated > > > > >> in a separate object, the QSPEC. This document defines > > > > a template > > > > >> for the QSPEC including a number of QSPEC parameters.=20 > > > The QSPEC > > > > >> parameters provide a common language to be re-used in > > > > several QOSMs > > > > >> and thereby aim to ensure the extensibility and > > > > interoperability of > > > > >> QoS NSLP. The node initiating the NSIS signaling adds > > > > an initiator > > > > >> QSPEC, which indicates the QSPEC parameters that must be=20 > > > > >> interpreted > > > > >> by the downstream nodes less the reservation=20 > fails, thereby=20 > > > > >> ensuring > > > > >> the intention of the NSIS initiator is preserved=20 > along the=20 > > > > >> signaling > > > > >> path. > > > > >> > > > > >> A URL for this Internet-Draft is: > > > > >>=20 > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 02:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO7i9-0003vg-Kg; Mon, 05 Mar 2007 02:34:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO7i7-0003r8-Ou for nsis@ietf.org; Mon, 05 Mar 2007 02:34:19 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO7i5-0005Eg-23 for nsis@ietf.org; Mon, 05 Mar 2007 02:34:19 -0500 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l257YA3e015416; Mon, 5 Mar 2007 08:34:10 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 05 Mar 2007 07:34:10 +0000 To: "ASH, GERALD R, ATTLABS" , "Martin Stiemerling" , "nsis" Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 05 Mar 2007 07:34:09 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8286@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 08:34:14 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry You have not answered my question: How the QNE (that supports simultaneously multiple RMF/QOSM) will know to which RMF it should deliver the received QSPEC? If your answer is yes the QNE should be able to do that then we will have to include the QOSM ID, otherwise is there no other way to make this distinction. Please note that we need both the QSPEC Type and QOSM ID fields. Regarding your new question please see in line: On 3/5/2007, "ASH, GERALD R, ATTLABS" wrote: >Georgios, All,=20 > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >> Sent: Friday, March 02, 2007 5:20 AM >> To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 >> qspec draft >>=20 >> Hi Jerry >>=20 >> The main goal of using the QOS-NSLP messages is to=20 >> carry a QSPEC object and deliver it to the right QOSM/RMF. >>=20 >> If a QNE will support simultaneously more than one QOS=20 >> models, say QOSM-I1, >> QOSM-I2,=20 >> and a QoS-NSLP message, which carries a QSPEC that is say=20 >> associated with >> QOSM-I1, >> arrives at a QNE, then the QNE must be able to deliver=20 >> the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. >>=20 >> How the QNE will know to which RMF it should deliver the=20 >> received QSPEC? > >First, the notion of multiple RMF/QOSMs that a QNE might decide to >deliver a QSPEC to makes no sense to me. =20 Georgios: What do you mean? Suppose that a QNE needs to simultaneously support the Intserv like controlled load, the intserv like guaranteed service and the Y.1541. These QOSMs will use a different QSPEC. When a QNE receives a message how the QNE will know by which RMF/QOSM this QSPEC should be used. If we use a QOSM ID, then the QNI (when QSPEC is initial) or QNI at Ingress or Egress (when QSPEC is local) will include the QOSM ID into the QSPEC. Any QNE downstream that receives the QSPEC will be able to relate the QSPEC object to the right RMF/QOSM by looking to the QOSM ID. > Even so, if a QSPEC carries an >I-QOSM ID, how does a QNE decide which of the multiple RMF/L-QOSMs to >send it to based only on the I-QOSM ID? Presumable it would have to >decide based on other content of the QSPEC in addition to the QOSM-ID. > Georgios: As i mentioned above, the QNI (when QSPEC in initial) or the QNI at the Ingress or Egress (when the QSPEC is Local) will include the QOSm ID into the QSPEC. Any QNE downstream can decide, based only on the QOSM ID, to which RMF/QOSM should be delivered. >We still haven't gotten a concrete bit-level example of how the QOSM ID >might be used. Without such clear justification I don't think >reintroducing the QOSM ID field can be supported. Georgios: What about the one mentioned above! Best regards, Georgios > >It would be good for others to comment on this. > >Thanks, >Jerry > >>=20 >> Best regards, >> Georgios >>=20 >> > -----Original Message----- >> > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 >> > Sent: donderdag 1 maart 2007 23:49 >> > To: Georgios Karagiannis; Martin Stiemerling; nsis >> > Cc: ASH, GERALD R, ATTLABS >> > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 >> > qspec draft >> >=20 >> > Georgios, >> >=20 >> > Your examples don't illustrate how and why a QOSM ID field is=20 >> > needed and used. =20 >> >=20 >> > Perhaps you are saying that QoS NSLP and RMF communicate with=20 >> > messages and that the I-QOSM ID and L-QOSM ID need to be=20 >> > included in those messages so that the QoS NSLP can react=20 >> > differently based on which L-QOSM is being used by the RMF? >> >=20 >> > If so, then this interaction suffers from the problems=20 >> > identified in Cornelia's slide (attached) discussed on our=20 >> > conference call on 31 January. >> >=20 >> > If not, please give a more detailed example of how and why a=20 >> > QOSM ID field is needed and used. >> >=20 >> > Jerry=20 >> >=20 >> > -----Original Message----- >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> > Sent: Thursday, March 01, 2007 11:11 AM >> > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' >> > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 >> > qspec draft >> >=20 >> > Hi Jerry >> >=20 >> > The need for the QOSM ID can be seen probably seen in the=20 >> > below e-mail: >> >=20 >> > Suppose that: >> >=20 >> > A QNE supports the following: >> >=20 >> > * end-to-end QOS Models:=20 >> > QOSMI-1, QOSMI-2, QOSMI-3=20 >> >=20 >> > * local QoS Models: >> > QOSML-1, QOSML-2, QOSML-3 >> >=20 >> > Suppose now that the operator of such a QNE wants to use=20 >> the following >> > combinations: >> >=20 >> > * QOSMI-1 with QOSML-3. >> >=20 >> > Meaning that end-to-end sessions and QOS-NSLP messages that=20 >> > are carrying >> >=20 >> > initial QSPEC of QOSM-I1 should be bound with local sessions=20 >> > and local QOS-NSLP messages that are carrying local QSPEC of QOSM-L3 >> >=20 >> > * QOSMI-2 with QOSML-3 >> >=20 >> > Meaning that end-to-end sessions and QOS-NSLP messages that=20 >> > are carrying >> >=20 >> > initial QSPEC of QOSMI-2 should be bound with local sessions=20 >> > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-3 >> >=20 >> > * QOSMI-3 with QOSML-1 >> >=20 >> > initial QSPEC of QOSMI-3 should be bound with local sessions=20 >> > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-1 >> >=20 >> > * QOSMI-3 with QOSML-2 >> >=20 >> > initial QSPEC of QOSMI-3 should be bound with local sessions=20 >> > and local QOS-NSLP messages that are carrying local QSPEC of QOSML-2 >> > -- >> >=20 >> >=20 >> > If the QOSM ID will not be supported these combinations will=20 >> > not beable >> > to >> > be made meaning that=20 >> > A QNE will be able to support only one initial (end-to-end)=20 >> > QOSM with >> > only >> > one local QOSM at a time. >> >=20 >> > Best Regards, >> > Georgios >> >=20 >> > > -----Original Message----- >> > > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 >> > > Sent: woensdag 28 februari 2007 14:43 >> > > To: Georgios Karagiannis; Martin Stiemerling; nsis >> > > Cc: ASH, GERALD R, ATTLABS >> > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 >> > > qspec draft >> > >=20 >> > > Georgios, All, >> > >=20 >> > > > -----Original Message----- >> > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> > > > Sent: Wednesday, February 28, 2007 12:37 AM >> > > > To: Martin Stiemerling; nsis >> > > > Subject: [NSIS] comment on reintroduction of QOSM-ID in=20 >> > > > qspec draft >> > > >=20 >> > > > Hi >> > > >=20 >> > > > I was busy updating some of the QOSM drafts and I have=20 >> > > > seen that=20 >> > > > starting from version 13 of the QSPEC draft, the QOSM ID=20 >> > > > field is=20 >> > > > removed form the common header of a QSPEC object and=20 >> > > > instead of this,=20 >> > > > the field QSPEC type is used. >> > >=20 >> > > > The QSPEC Type was introduced to support Roland's QSPEC=20 >> > > > stacking/encapsulation method (see=20 >> > > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht >> > > > ml), it does not replace QOSM ID. >> > > > >> > > > The QOSM ID was removed in the discussion around the QSPEC-13=20 >> > > > draft update, see the post on 1 November 2006=20 >> > > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht >> > > > ml, where it says "A QOSM ID need not be defined or signaled=20 >> > > > and a QNE need not support any particular QOSM". Slide 3 of=20 >> > > > the QSPEC presentation at IETF-67 makes the same point. The=20 >> > > > same point is made again in the announcement of the draft to=20 >> > > the NSIS list at=20 >> > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht >> > > ml and the point is also made in Appendix A of the QSPEC=20 >> > > draft itself. There were no objections to this point. >> > >=20 >> > > > I agree that QSPEC type (shows if the QSPEC object is=20 >> > initial or a=20 >> > > > local) is useful and it should be used, but by removing=20 >> > the QOSM ID=20 >> > > > field it will mean that a QNE can always support only=20 >> one type of=20 >> > > > initial >> > > > (end-to-end) QOSM and one type of local QOSM. >> > > > That is not reasonable. A QNE should be able to support=20 >> > > many QOSMs and=20 >> > > > it should be able to distinguish and associate a QSPEC=20 >> > > object with a=20 >> > > > certain QOSM. >> > >=20 >> > > There is no mention in any QSPEC draft as to how or why a=20 >> > > QOSM ID field is needed or used. A QNE can support any QOSM=20 >> > > it wants, it does not depend on a QOSM ID field from the QNI=20 >> > > to determine which one. >> > >=20 >> > > At a minimum, we would need to have a bit-level example of=20 >> > > how/why such a field is needed to justify reintroducing the=20 >> > > QOSM ID field. >> > >=20 >> > > > Therefore, I think that it is required that the QOSM ID=20 >> > > field should=20 >> > > > be reintroduced in the QSPEC common header. The field=20 >> > QSPEC type is=20 >> > > > also useful ant it should be kept. >> > >=20 >> > > We need clear justification to reintroduce the complexity of=20 >> > > having the QOSM ID field and the IANA registry to maintain=20 >> > > the parameter. >> > >=20 >> > > Jerry >> > > =20 >> > > >=20 >> > > > Best regards, >> > > > Georgios >> > > >=20 >> > > >=20 >> > > > On 2/20/2007, "Martin Stiemerling"=20 >> > > wrote: >> > > >=20 >> > > > >Dear all, >> > > > > >> > > > >I would like to start the working group last call for the=20 >> > > QSPEC draft=20 >> > > >=20 >> > >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). >> > > > > >> > > > >The WGLC is starting today and will run for two weeks=20 >> > > until Tuesday=20 >> > > > >Feb 6th. >> > > > > >> > > > >Please send your comments to the NSIS WG list. >> > > > > >> > > > > Martin >> > > > > >> > > > >Anfang der weitergeleiteten E-Mail: >> > > > > >> > > > >> Von: >> > > > >> Datum: 16. Februar 2007 21:50:02 MEZ >> > > > >> An: >> > > > >> Kopie: >> > > > >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >> > > > >> >> > > > >> A New Internet-Draft is available from the on-line=20 >> > > Internet-Drafts=20 >> > > > >> directories. >> > > > >> This draft is a work item of the Next Steps in=20 >> > Signaling Working=20 >> > > > >> Group of the IETF. >> > > > >> >> > > > >> =09Title=09=09: QoS NSLP QSPEC Template >> > > > >> =09Author(s)=09: J. Ash, et al. >> > > > >> =09Filename=09: draft-ietf-nsis-qspec-15.txt >> > > > >> =09Pages=09=09: 54 >> > > > >> =09Date=09=09: 2007-2-16 >> > > > >> >> > > > >> The QoS NSLP protocol is used to signal QoS=20 >> reservations and is >> > > > >> independent of a specific QoS model (QOSM) such as=20 >> > IntServ or >> > > > >> DiffServ. Rather, all information specific to a QOSM is=20 >> > > > >> encapsulated >> > > > >> in a separate object, the QSPEC. This document defines >> > > > a template >> > > > >> for the QSPEC including a number of QSPEC parameters.=20 >> > > The QSPEC >> > > > >> parameters provide a common language to be re-used in >> > > > several QOSMs >> > > > >> and thereby aim to ensure the extensibility and >> > > > interoperability of >> > > > >> QoS NSLP. The node initiating the NSIS signaling adds >> > > > an initiator >> > > > >> QSPEC, which indicates the QSPEC parameters that must be=20 >> > > > >> interpreted >> > > > >> by the downstream nodes less the reservation=20 >> fails, thereby=20 >> > > > >> ensuring >> > > > >> the intention of the NSIS initiator is preserved=20 >> along the=20 >> > > > >> signaling >> > > > >> path. >> > > > >> >> > > > >> A URL for this Internet-Draft is: >> > > > >>=20 >> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 04:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO9dP-0004Aa-3H; Mon, 05 Mar 2007 04:37:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO9dN-0004AV-4H for nsis@ietf.org; Mon, 05 Mar 2007 04:37:33 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO9dJ-0000Zr-Lc for nsis@ietf.org; Mon, 05 Mar 2007 04:37:33 -0500 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HO9dC-0003OP-FV; Mon, 05 Mar 2007 10:37:24 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id EA4872FC244; Mon, 5 Mar 2007 10:37:21 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HO9d8-0004bW-T4; Mon, 05 Mar 2007 10:37:19 +0100 Message-ID: <45EBE4CE.10503@tm.uka.de> Date: Mon, 05 Mar 2007 10:37:18 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Martin Stiemerling , Georgios Karagiannis , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, > The QSPEC Type was introduced to support Roland's QSPEC > stacking/encapsulation method (see > http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.html), it > does not replace QOSM ID. My intention was to have an ID for a specific QSPEC type, because the same QSPEC may be understood by several different QoS-Models. In that sense it would be a replacement for the QoSM ID. If a QOSM needs specific (local) parameters it can define its own QSPEC type. This particular QSPEC definition, however, may be (re-)used/applicable by other QoSMs, too. That's why I thought it may be better to signal a QSPEC type instead of a QOSM ID. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 05:06:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOA4r-0006mM-Do; Mon, 05 Mar 2007 05:05:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO9z9-00030o-AH for nsis@ietf.org; Mon, 05 Mar 2007 05:00:03 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO9xJ-0006vX-Aa for nsis@ietf.org; Mon, 05 Mar 2007 04:58:10 -0500 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l259w0ta025557; Mon, 5 Mar 2007 10:58:00 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 05 Mar 2007 09:58:00 +0000 To: "Roland Bless" , "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 05 Mar 2007 09:58:00 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <45EBE4CE.10503@tm.uka.de> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 10:58:03 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Martin Stiemerling , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland By using only the QSPEC type, will work only when a QNE simultaneously supports only one end-to-end QOSM and one local QOSM. When a QNE supports say more than one end-to-end QOSMs and it receives a QSPEC it will not know how to associate this QSPEC or the (specific to one QOSM) parameters contained in the QSPEC with the right QOSM. Actually we need both, the QSPEC type and the QOSM ID. Note that a QNE, such as an Ingress backbone router needs to support more than one end-to-end QOSMs and local QOSMs. Best regards, Georgios On 3/5/2007, "Roland Bless" wrote: >Hi Jerry, > >> The QSPEC Type was introduced to support Roland's QSPEC >> stacking/encapsulation method (see >> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.html), it >> does not replace QOSM ID. > >My intention was to have an ID for a specific QSPEC type, because >the same QSPEC may be understood by several different QoS-Models. >In that sense it would be a replacement for the QoSM ID. If a QOSM >needs specific (local) parameters it can define its own QSPEC type. >This particular QSPEC definition, however, may be (re-)used/applicable >by other QoSMs, too. That's why I thought it may be better to signal >a QSPEC type instead of a QOSM ID. > >Regards, > Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 07:22:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCCG-0004W9-NF; Mon, 05 Mar 2007 07:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCCF-0004VG-RZ for nsis@ietf.org; Mon, 05 Mar 2007 07:21:43 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOCCC-0008GH-AC for nsis@ietf.org; Mon, 05 Mar 2007 07:21:43 -0500 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HOCC2-0007rU-LB; Mon, 05 Mar 2007 13:21:37 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2A1E72FC210; Mon, 5 Mar 2007 13:21:30 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HOCBz-0004xr-0L; Mon, 05 Mar 2007 13:21:27 +0100 Message-ID: <45EC0B46.6020708@tm.uka.de> Date: Mon, 05 Mar 2007 13:21:26 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "ASH, GERALD R, ATTLABS" , nsis , Martin Stiemerling X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: > By using only the QSPEC type, will work only when a QNE simultaneously > supports only one end-to-end QOSM and one local QOSM. I don't know how you come to this conclusion, but I would say that: 1) your domain is likely to use only one QOSM (using the definition from the QSPEC terminology draft), i.e. one specific set of mechanisms to support QoS, e.g. DiffServ with a specific number of different service classes. 2) your domain may understand different QSPECs, usually one end-to-end QSPEC and one or more local QSPECs as long as there your QOSM defines a mapping from these QSPEC parameters to your QOSM internal parameters for admission control. > When a QNE supports say more than one end-to-end QOSMs and it receives a > QSPEC it will not know how to associate this QSPEC or the (specific to > one QOSM) parameters contained in the QSPEC with the right QOSM. Why not? I thought it is no problem to have a local table in the RMF containing the set of supported QSPEC types. The QOSM must know how to interpret the parameters and must assure that the requested constraints are actually met (in case of admission). From an interface perspective I don't care about the particular type of QOSM that you are running as long as you can correctly decide about the admission of my QoS request (i.e. QSPEC). > Actually we need both, the QSPEC type and the QOSM ID. I don't see a reason to signal the QOSM. It's clear that some QSPEC types may be specific to particular QOSMs. For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC B locally. QOSM C may be a variant of QOSM A but uses the same QSPEC A. It might be the case that QOSM B understands QSPEC A _and_ QSPEC B (usually as well as the global E2E QSPEC), so I don't see a good reason to signal the QOSM. > Note that a QNE, such as an Ingress backbone router needs to support more > than one end-to-end QOSMs and local QOSMs. Probably, but I don't see any problem in doing so with only the QSPEC type. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 07:44:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCXs-0002Oe-Lv; Mon, 05 Mar 2007 07:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCXq-0002NE-LE for nsis@ietf.org; Mon, 05 Mar 2007 07:44:02 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOCXp-0004g5-6B for nsis@ietf.org; Mon, 05 Mar 2007 07:44:02 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25Chmo4010699; Mon, 5 Mar 2007 13:43:58 +0100 (MET) From: "Georgios Karagiannis" To: "'Roland Bless'" References: <45EC0B46.6020708@tm.uka.de> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 13:43:43 +0100 Message-ID: <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45EC0B46.6020708@tm.uka.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdfINiMUvxCu0N/RmSX+FyikdVXegAAGFug X-Spam-Score: 0.236 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 13:43:59 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland Please see in line! > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: maandag 5 maart 2007 13:21 > To: Georgios Karagiannis > Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Hi Georgios, > > Georgios Karagiannis wrote: > > By using only the QSPEC type, will work only when a QNE > > simultaneously supports only one end-to-end QOSM and one local QOSM. > > I don't know how you come to this conclusion, but I would say that: > 1) your domain is likely to use only one QOSM > (using the definition from the QSPEC terminology draft), > i.e. one specific set of mechanisms to support QoS, e.g. > DiffServ with a specific number of different service classes. > 2) your domain may understand different QSPECs, usually > one end-to-end QSPEC and one or more local QSPECs as > long as there your QOSM defines a mapping from these > QSPEC parameters to your QOSM internal parameters for > admission control. Georgios: Why only one end-to-end QSPEC? A QNE might support more than one end-to-end QOSMs and more than one local (intra-domain) QOSMs. Therefore, it will be very complex for the QNE, when it receives a QSPEC to know to which RMF/QOSM to send the received QSPEC. In particular, for the situations that all QOSMs use the same types of QSPEC (private) parameters. By including the QSPEC Type and QOSM ID a QNE will know exactly how and where (to which RMF/QOSM) to send the received QSPEC. > > > When a QNE supports say more than one end-to-end QOSMs and > it receives > > a QSPEC it will not know how to associate this QSPEC or the > (specific > > to one QOSM) parameters contained in the QSPEC with the right QOSM. > > Why not? I thought it is no problem to have a local table in > the RMF containing the set of supported QSPEC types. The QOSM > must know how to interpret the parameters and must assure > that the requested constraints are actually met (in case of > admission). From an interface perspective I don't care about > the particular type of QOSM that you are running as long as > you can correctly decide about the admission of my QoS > request (i.e. QSPEC). > > > Actually we need both, the QSPEC type and the QOSM ID. > > I don't see a reason to signal the QOSM. It's clear that some > QSPEC types may be specific to particular QOSMs. > For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC > B locally. QOSM C may be a variant of QOSM A but uses the > same QSPEC A. It might be the case that QOSM B understands > QSPEC A _and_ QSPEC B (usually as well as the global E2E > QSPEC), so I don't see a good reason to signal the QOSM. > > > Note that a QNE, such as an Ingress backbone router needs > to support > > more than one end-to-end QOSMs and local QOSMs. > > Probably, but I don't see any problem in doing so with only > the QSPEC type. Georgios: Please see above! > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:01:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCnX-0004iH-Ry; Mon, 05 Mar 2007 08:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCnS-0004No-JP for nsis@ietf.org; Mon, 05 Mar 2007 08:00:10 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOCiT-0006eD-QI for nsis@ietf.org; Mon, 05 Mar 2007 07:55:03 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25CsoPT011625; Mon, 5 Mar 2007 13:54:59 +0100 (MET) From: "Georgios Karagiannis" To: "'Roland Bless'" References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 13:54:45 +0100 Message-ID: <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdfINiMUvxCu0N/RmSX+FyikdVXegAAGFugAADY/VA= X-Spam-Score: 0.236 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 13:54:59 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland Sorry, I meant: Why only one end-to-end QSPEC? A QNE might support more than one end-to-end QOSMs and more than one local (intra-domain) QOSMs. Therefore, it will be complex for the QNE, when it receives a QSPEC to know to which RMF/QOSM to send the received QSPEC. In particular, for the situations that all QOSMs use the same types of QSPEC (private) parameters, but use different semantics and values for these QSPEC private parameters. In the solution that you proposed it will mean that each QOSM will have to check all QSPEC parameters to find out if the sematics of some of them can be understood etc... And I am not sure if all situations can be covered. Are you? By including the QSPEC Type and QOSM ID a QNE will know exactly how and where (to which RMF/QOSM) to send the received QSPEC. Thius is a very clean solution that does not introduce any additional complexity, just some bits in the common header of the QSPEC object. Best regards, Georgios > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: maandag 5 maart 2007 13:44 > To: 'Roland Bless' > Cc: 'ASH, GERALD R, ATTLABS'; 'nsis'; 'Martin Stiemerling' > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Hi Roland > > Please see in line! > > > -----Original Message----- > > From: Roland Bless [mailto:bless@tm.uka.de] > > Sent: maandag 5 maart 2007 13:21 > > To: Georgios Karagiannis > > Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis > > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec > > draft > > > > Hi Georgios, > > > > Georgios Karagiannis wrote: > > > By using only the QSPEC type, will work only when a QNE > > > simultaneously supports only one end-to-end QOSM and one > local QOSM. > > > > I don't know how you come to this conclusion, but I would say that: > > 1) your domain is likely to use only one QOSM > > (using the definition from the QSPEC terminology draft), > > i.e. one specific set of mechanisms to support QoS, e.g. > > DiffServ with a specific number of different service classes. > > 2) your domain may understand different QSPECs, usually > > one end-to-end QSPEC and one or more local QSPECs as > > long as there your QOSM defines a mapping from these > > QSPEC parameters to your QOSM internal parameters for > > admission control. > > Georgios: Why only one end-to-end QSPEC? > A QNE might support more than one end-to-end QOSMs and more > than one local (intra-domain) QOSMs. > > Therefore, it will be very complex for the QNE, when it > receives a QSPEC to know to which RMF/QOSM to send the > received QSPEC. In particular, for the situations that all > QOSMs use the same types of QSPEC (private) parameters. > > By including the QSPEC Type and QOSM ID a QNE will know > exactly how and where (to which RMF/QOSM) to send the received QSPEC. > > > > > > > When a QNE supports say more than one end-to-end QOSMs and > > it receives > > > a QSPEC it will not know how to associate this QSPEC or the > > (specific > > > to one QOSM) parameters contained in the QSPEC with the > right QOSM. > > > > Why not? I thought it is no problem to have a local table in > > the RMF containing the set of supported QSPEC types. The QOSM > > must know how to interpret the parameters and must assure > > that the requested constraints are actually met (in case of > > admission). From an interface perspective I don't care about > > the particular type of QOSM that you are running as long as > > you can correctly decide about the admission of my QoS > > request (i.e. QSPEC). > > > > > Actually we need both, the QSPEC type and the QOSM ID. > > > > I don't see a reason to signal the QOSM. It's clear that some > > QSPEC types may be specific to particular QOSMs. > > For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC > > B locally. QOSM C may be a variant of QOSM A but uses the > > same QSPEC A. It might be the case that QOSM B understands > > QSPEC A _and_ QSPEC B (usually as well as the global E2E > > QSPEC), so I don't see a good reason to signal the QOSM. > > > > > Note that a QNE, such as an Ingress backbone router needs > > to support > > > more than one end-to-end QOSMs and local QOSMs. > > > > Probably, but I don't see any problem in doing so with only > > the QSPEC type. > > Georgios: Please see above! > > > > > Regards, > > Roland > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODBu-00046x-W6; Mon, 05 Mar 2007 08:25:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODBp-0003o8-JK for nsis@ietf.org; Mon, 05 Mar 2007 08:25:21 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOD89-00060N-LQ for nsis@ietf.org; Mon, 05 Mar 2007 08:21:35 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l25DLLgp017713; Mon, 5 Mar 2007 13:21:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 13:21:21 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDAADZkzgAAYmD6wAIpkMMAAEpxOAA== References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com><000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com><000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8286@KCCLUST06EVS1.ugd.att.com> From: "Hancock, Robert" To: "ASH, GERALD R, ATTLABS" , "Georgios Karagiannis" , "Martin Stiemerling" , "nsis" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi,=20 > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Sent: 05 March 2007 04:42 > To: Georgios Karagiannis; Martin Stiemerling; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in=20 > qspec draft >=20 > Georgios, All,=20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Friday, March 02, 2007 5:20 AM > > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec=20 > > draft > >=20 > > Hi Jerry > >=20 > > The main goal of using the QOS-NSLP messages is to carry a QSPEC=20 > > object and deliver it to the right QOSM/RMF. > >=20 > > If a QNE will support simultaneously more than one QOS models, say=20 > > QOSM-I1, QOSM-I2, and a QoS-NSLP message, which carries a=20 > QSPEC that=20 > > is say associated with QOSM-I1, arrives at a QNE, then the=20 > QNE must be=20 > > able to deliver the received QSPEC to the right RMF/QOSM, i.e.,=20 > > QOSM-I1. > >=20 > > How the QNE will know to which RMF it should deliver the received=20 > > QSPEC? >=20 > First, the notion of multiple RMF/QOSMs that a QNE might=20 > decide to deliver a QSPEC to makes no sense to me. Even so,=20 > if a QSPEC carries an I-QOSM ID, how does a QNE decide which=20 > of the multiple RMF/L-QOSMs to send it to based only on the=20 > I-QOSM ID? Presumable it would have to decide based on other=20 > content of the QSPEC in addition to the QOSM-ID. i'm also confused by the concept of multiple RMFs at a node; at least, not multiplexed on model identity. sure the role of an RMF is to coordinate the management of the resources at a node. if you have multiple RMFs all allocating from a common resource then something at a higher level would have to coordinate=20 contending requests for them (which seems to be leading towards=20 infinite regress...). to put it another way, i would expect the RMF to be identified=20 based on what resources a request was going to draw on. so that might be an outgoing interface, or a queue on an interface (where the queue parameters are semi-statically configured). robert h. >=20 > We still haven't gotten a concrete bit-level example of how=20 > the QOSM ID > might be used. Without such clear justification I don't think > reintroducing the QOSM ID field can be supported. >=20 > It would be good for others to comment on this. >=20 > Thanks, > Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:26:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODCh-0005bK-Mo; Mon, 05 Mar 2007 08:26:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODCg-0005bF-Jr for nsis@ietf.org; Mon, 05 Mar 2007 08:26:14 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODCf-00087u-6T for nsis@ietf.org; Mon, 05 Mar 2007 08:26:14 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25DQ2q4014015; Mon, 5 Mar 2007 14:26:10 +0100 (MET) From: "Georgios Karagiannis" To: "'Hancock, Robert'" , "'ASH, GERALD R, ATTLABS'" , "'Martin Stiemerling'" , "'nsis'" References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com><000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com><000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8286@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 14:25:57 +0100 Message-ID: <003b01c75f29$d47231e0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDAADZkzgAAYmD6wAIpkMMAAEpxOAAAAmPsA X-Spam-Score: 0.236 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 14:26:10 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert I agree that the (input/outgoing) interface is important, butb this is An implementation issue. The problem that I have is explained in detail in the e-mail sent to Roland: > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 5 maart 2007 14:21 > To: ASH, GERALD R, ATTLABS; Georgios Karagiannis; Martin > Stiemerling; nsis > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > hi, > > > -----Original Message----- > > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > > Sent: 05 March 2007 04:42 > > To: Georgios Karagiannis; Martin Stiemerling; nsis > > Cc: ASH, GERALD R, ATTLABS > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec > > draft > > > > Georgios, All, > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Friday, March 02, 2007 5:20 AM > > > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec > > > draft > > > > > > Hi Jerry > > > > > > The main goal of using the QOS-NSLP messages is to carry a QSPEC > > > object and deliver it to the right QOSM/RMF. > > > > > > If a QNE will support simultaneously more than one QOS > models, say > > > QOSM-I1, QOSM-I2, and a QoS-NSLP message, which carries a > > QSPEC that > > > is say associated with QOSM-I1, arrives at a QNE, then the > > QNE must be > > > able to deliver the received QSPEC to the right RMF/QOSM, i.e., > > > QOSM-I1. > > > > > > How the QNE will know to which RMF it should deliver the received > > > QSPEC? > > > > First, the notion of multiple RMF/QOSMs that a QNE might decide to > > deliver a QSPEC to makes no sense to me. Even so, if a > QSPEC carries > > an I-QOSM ID, how does a QNE decide which of the multiple > RMF/L-QOSMs > > to send it to based only on the I-QOSM ID? Presumable it > would have > > to decide based on other content of the QSPEC in addition to the > > QOSM-ID. > > i'm also confused by the concept of multiple RMFs at a node; > at least, not multiplexed on model identity. sure the role of > an RMF is to coordinate the management of the resources at a node. > if you have multiple RMFs all allocating from a common > resource then something at a higher level would have to > coordinate contending requests for them (which seems to be > leading towards infinite regress...). > > to put it another way, i would expect the RMF to be > identified based on what resources a request was going to > draw on. so that might be an outgoing interface, or a queue > on an interface (where the queue parameters are > semi-statically configured). > > robert h. > > > > > We still haven't gotten a concrete bit-level example of how > the QOSM > > ID > > might be used. Without such clear justification I don't think > > reintroducing the QOSM ID field can be supported. > > > > It would be good for others to comment on this. > > > > Thanks, > > Jerry > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODF5-0000E6-Pp; Mon, 05 Mar 2007 08:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODF4-00009s-6J for nsis@ietf.org; Mon, 05 Mar 2007 08:28:42 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODF2-0000Fm-Nh for nsis@ietf.org; Mon, 05 Mar 2007 08:28:42 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25DSY8e014244; Mon, 5 Mar 2007 14:28:38 +0100 (MET) From: "Georgios Karagiannis" To: "'Hancock, Robert'" , "'ASH, GERALD R, ATTLABS'" , "'Martin Stiemerling'" , "'nsis'" References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com><000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com><000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8286@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 14:28:29 +0100 Message-ID: <003c01c75f2a$2c9fbe00$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acda+yOIXx5P2Sb4TGeDSr53EazCvwAO9TAwADjcoDAADZkzgAAYmD6wAIpkMMAAEpxOAAAArZEw X-Spam-Score: 0.236 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 14:28:39 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert Sorry, but the previous e-mail went out too fast! :-) I agree that the (input/outgoing) interface is important, but this is an implementation issue. The problem that I have is explained in detail in the e-mail sent to Roland: "A QNE might support more than one end-to-end QOSMs and more than one local (intra-domain) QOSMs. Therefore, it will be complex for the QNE, when it receives a QSPEC to know to which RMF/QOSM to send the received QSPEC. In particular, for the situations that all QOSMs use the same types of QSPEC (private) parameters, but use different semantics and values for these QSPEC private parameters. In the solution that you proposed it will mean that each QOSM will have to check all QSPEC parameters to find out if the sematics of some of them can be understood etc... And I am not sure if all situations can be covered. Are you? By including the QSPEC Type and QOSM ID a QNE will know exactly how and where (to which RMF/QOSM) to send the received QSPEC. Thius is a very clean solution that does not introduce any additional complexity, just some bits in the common header of the QSPEC object." Best regards, Georgios > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 5 maart 2007 14:21 > To: ASH, GERALD R, ATTLABS; Georgios Karagiannis; Martin > Stiemerling; nsis > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > hi, > > > -----Original Message----- > > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > > Sent: 05 March 2007 04:42 > > To: Georgios Karagiannis; Martin Stiemerling; nsis > > Cc: ASH, GERALD R, ATTLABS > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec > > draft > > > > Georgios, All, > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Friday, March 02, 2007 5:20 AM > > > To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > > > Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec > > > draft > > > > > > Hi Jerry > > > > > > The main goal of using the QOS-NSLP messages is to carry a QSPEC > > > object and deliver it to the right QOSM/RMF. > > > > > > If a QNE will support simultaneously more than one QOS > models, say > > > QOSM-I1, QOSM-I2, and a QoS-NSLP message, which carries a > > QSPEC that > > > is say associated with QOSM-I1, arrives at a QNE, then the > > QNE must be > > > able to deliver the received QSPEC to the right RMF/QOSM, i.e., > > > QOSM-I1. > > > > > > How the QNE will know to which RMF it should deliver the received > > > QSPEC? > > > > First, the notion of multiple RMF/QOSMs that a QNE might decide to > > deliver a QSPEC to makes no sense to me. Even so, if a > QSPEC carries > > an I-QOSM ID, how does a QNE decide which of the multiple > RMF/L-QOSMs > > to send it to based only on the I-QOSM ID? Presumable it > would have > > to decide based on other content of the QSPEC in addition to the > > QOSM-ID. > > i'm also confused by the concept of multiple RMFs at a node; > at least, not multiplexed on model identity. sure the role of > an RMF is to coordinate the management of the resources at a node. > if you have multiple RMFs all allocating from a common > resource then something at a higher level would have to > coordinate contending requests for them (which seems to be > leading towards infinite regress...). > > to put it another way, i would expect the RMF to be > identified based on what resources a request was going to > draw on. so that might be an outgoing interface, or a queue > on an interface (where the queue parameters are > semi-statically configured). > > robert h. > > > > > We still haven't gotten a concrete bit-level example of how > the QOSM > > ID > > might be used. Without such clear justification I don't think > > reintroducing the QOSM ID field can be supported. > > > > It would be good for others to comment on this. > > > > Thanks, > > Jerry > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODO5-0007vP-1D; Mon, 05 Mar 2007 08:38:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODO3-0007vH-Uh for nsis@ietf.org; Mon, 05 Mar 2007 08:37:59 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODO2-0001d6-IK for nsis@ietf.org; Mon, 05 Mar 2007 08:37:59 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2007 05:37:57 -0800 X-IronPort-AV: i="4.14,249,1170662400"; d="scan'208"; a="45222847:sNHT521956206" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l25DbuMV022207; Mon, 5 Mar 2007 05:37:56 -0800 Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l25Dbta3010490; Mon, 5 Mar 2007 13:37:55 GMT In-Reply-To: <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <360938CB-DE8E-4ADC-A961-A65AF700E65B@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 08:37:44 -0500 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3432; t=1173101876; x=1173965876; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20comment=20on=20reintroduction=20of=20QOSM-ID =20in=20qspec=20draft |Sender:=20; bh=1aVB5RA0MiOInZ1WkIwCRBRmCSHl4Mz3WpapykyrmUM=; b=Tp0oVOmuWovILBIE+A6RuzknKqfudUoQHYiTfi8RZrrTrtqOmLUezk5CKWVX0EfLCcZoJURN yuqrd9J+Y9gxPPZj6yh1qmyKUTgraiM1v12QTcuot7haqEn5OOc+Nny1; Authentication-Results: sj-dkim-7; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "'ASH, GERALD R, ATTLABS'" , 'Roland Bless' , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Mar 5, 2007, at 7:43 AM, Georgios Karagiannis wrote: > Hi Roland > > Please see in line! > >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: maandag 5 maart 2007 13:21 >> To: Georgios Karagiannis >> Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis >> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> Hi Georgios, >> >> Georgios Karagiannis wrote: >>> By using only the QSPEC type, will work only when a QNE >>> simultaneously supports only one end-to-end QOSM and one local QOSM. >> >> I don't know how you come to this conclusion, but I would say that: >> 1) your domain is likely to use only one QOSM >> (using the definition from the QSPEC terminology draft), >> i.e. one specific set of mechanisms to support QoS, e.g. >> DiffServ with a specific number of different service classes. >> 2) your domain may understand different QSPECs, usually >> one end-to-end QSPEC and one or more local QSPECs as >> long as there your QOSM defines a mapping from these >> QSPEC parameters to your QOSM internal parameters for >> admission control. > > Georgios: Why only one end-to-end QSPEC? > A QNE might support more than one end-to-end QOSMs and more > than one local (intra-domain) QOSMs. > > Therefore, it will be very complex for the QNE, when it receives a > QSPEC > to know to which RMF/QOSM to send the received QSPEC. In > particular, for the > situations that all QOSMs use the same types of QSPEC (private) > parameters. > And the upstream node putting in these QOSMids knows better? > By including the QSPEC Type and QOSM ID a QNE will know exactly how > and > where (to which RMF/QOSM) to send the received QSPEC. > > >> >>> When a QNE supports say more than one end-to-end QOSMs and >> it receives >>> a QSPEC it will not know how to associate this QSPEC or the >> (specific >>> to one QOSM) parameters contained in the QSPEC with the right QOSM. >> >> Why not? I thought it is no problem to have a local table in >> the RMF containing the set of supported QSPEC types. The QOSM >> must know how to interpret the parameters and must assure >> that the requested constraints are actually met (in case of >> admission). From an interface perspective I don't care about >> the particular type of QOSM that you are running as long as >> you can correctly decide about the admission of my QoS >> request (i.e. QSPEC). >> >>> Actually we need both, the QSPEC type and the QOSM ID. >> >> I don't see a reason to signal the QOSM. It's clear that some >> QSPEC types may be specific to particular QOSMs. >> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC >> B locally. QOSM C may be a variant of QOSM A but uses the >> same QSPEC A. It might be the case that QOSM B understands >> QSPEC A _and_ QSPEC B (usually as well as the global E2E >> QSPEC), so I don't see a good reason to signal the QOSM. >> >>> Note that a QNE, such as an Ingress backbone router needs >> to support >>> more than one end-to-end QOSMs and local QOSMs. >> >> Probably, but I don't see any problem in doing so with only >> the QSPEC type. > > Georgios: Please see above! > >> >> Regards, >> Roland >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:46:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODVL-0004eL-L7; Mon, 05 Mar 2007 08:45:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODVK-0004e1-4A for nsis@ietf.org; Mon, 05 Mar 2007 08:45:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODVI-0003hE-K3 for nsis@ietf.org; Mon, 05 Mar 2007 08:45:30 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2007 05:44:37 -0800 X-IronPort-AV: i="4.14,249,1170662400"; d="scan'208"; a="45230401:sNHT2691498798" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l25DaeGP001145; Mon, 5 Mar 2007 05:36:40 -0800 Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l25DacxR011945; Mon, 5 Mar 2007 13:36:39 GMT In-Reply-To: <45EC0B46.6020708@tm.uka.de> References: <45EC0B46.6020708@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <627F24D9-92DD-43CF-BF6C-CFC909E44F61@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 08:36:28 -0500 To: Roland Bless X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3005; t=1173101800; x=1173965800; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20comment=20on=20reintroduction=20of=20QOSM-ID =20in=20qspec=20draft |Sender:=20; bh=FAtbF059afq+6/RD/EWWFGqSzC2F/maOETu7rS1eKes=; b=ASXCL8rpA6YjbRtCVtCpLIly/2ksVI3soc92CDrA2GPZOSqIQqVouuvEE4kdCEwgBpaulzqN qeN74Yqc97t8kJWC9+zqriAm7NZ9nqqUQqQJy1ASF7WY1XTMUGGRUy2Y; Authentication-Results: sj-dkim-5; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "ASH, GERALD R, ATTLABS" , Georgios Karagiannis , nsis , Martin Stiemerling X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Mar 5, 2007, at 7:21 AM, Roland Bless wrote: > Hi Georgios, > > Georgios Karagiannis wrote: >> By using only the QSPEC type, will work only when a QNE >> simultaneously >> supports only one end-to-end QOSM and one local QOSM. > > I don't know how you come to this conclusion, but I would > say that: > 1) your domain is likely to use only one QOSM > (using the definition from the QSPEC terminology draft), > i.e. one specific set of mechanisms to support QoS, e.g. > DiffServ with a specific number of different service classes. > 2) your domain may understand different QSPECs, usually > one end-to-end QSPEC and one or more local QSPECs as > long as there your QOSM defines a mapping from these > QSPEC parameters to your QOSM internal parameters for > admission control. > >> When a QNE supports say more than one end-to-end QOSMs and it >> receives a >> QSPEC it will not know how to associate this QSPEC or the >> (specific to >> one QOSM) parameters contained in the QSPEC with the right QOSM. > > Why not? I thought it is no problem to have a local table in the RMF > containing the set of supported QSPEC types. The QOSM must know how > to interpret the parameters and must assure that the requested > constraints are actually met (in case of admission). From an interface > perspective I don't care about the particular type of QOSM that you > are > running as long as you can correctly decide about the admission of my > QoS request (i.e. QSPEC). > I'll note that this is already on the edge of being too complicated, but having two degrees of freedom of mapping QSPEC parameters onto QoS resources and admission control through multiple QOSMs puts me definitively over the edge. >> Actually we need both, the QSPEC type and the QOSM ID. > > I don't see a reason to signal the QOSM. Me neither. > It's clear that > some QSPEC types may be specific to particular QOSMs. > For instance, QOSM A may use QSPEC A and QOSM B may use > QSPEC B locally. QOSM C may be a variant of QOSM A but > uses the same QSPEC A. It might be the case that QOSM B understands > QSPEC A _and_ QSPEC B (usually as well as the global E2E QSPEC), > so I don't see a good reason to signal the QOSM. > Rereading this, I wonder if we're not already over the too- complicated threshold. QSPEC parameters get registered with IANA. QOSMs are documented in RFCs that explain how they use the QSPEC parameters to do resource allocation, admission control, and scheduling. I'm not sure we even heed QSPEC id's to make this work... >> Note that a QNE, such as an Ingress backbone router needs to >> support more >> than one end-to-end QOSMs and local QOSMs. > > Probably, but I don't see any problem in doing so with only the QSPEC > type. > > Regards, > Roland > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 08:54:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODdB-0007M8-AH; Mon, 05 Mar 2007 08:53:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODdA-0007Ln-FB for nsis@ietf.org; Mon, 05 Mar 2007 08:53:36 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODd7-0005nC-V4 for nsis@ietf.org; Mon, 05 Mar 2007 08:53:36 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25DrPej016238; Mon, 5 Mar 2007 14:53:29 +0100 (MET) From: "Georgios Karagiannis" To: "'David R Oran'" References: <45EC0B46.6020708@tm.uka.de><002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <360938CB-DE8E-4ADC-A961-A65AF700E65B@cisco.com> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 14:53:20 +0100 Message-ID: <004501c75f2d$a5854490$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <360938CB-DE8E-4ADC-A961-A65AF700E65B@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdfK5a0kidNo6pRQLSAKfCyiPF5PgAAbYKg X-Spam-Score: 0.237 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 14:53:30 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: "'ASH, GERALD R, ATTLABS'" , 'Roland Bless' , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave Regarding the following comment: > Therefore, it will be very complex for the QNE, when it receives a > QSPEC to know to which RMF/QOSM to send the received QSPEC. In > particular, for the situations that all QOSMs use the same types of > QSPEC (private) parameters. > Dave: And the upstream node putting in these QOSMids knows better? Georgios: Note that the QNI (for initial QSPEC) or QNI_Ingress (for local QSPEC) will include the QOSM-ID! Best regards, Georgios > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: maandag 5 maart 2007 14:38 > To: Georgios Karagiannis > Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin > Stiemerling' > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > > On Mar 5, 2007, at 7:43 AM, Georgios Karagiannis wrote: > > > Hi Roland > > > > Please see in line! > > > >> -----Original Message----- > >> From: Roland Bless [mailto:bless@tm.uka.de] > >> Sent: maandag 5 maart 2007 13:21 > >> To: Georgios Karagiannis > >> Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis > >> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec > >> draft > >> > >> Hi Georgios, > >> > >> Georgios Karagiannis wrote: > >>> By using only the QSPEC type, will work only when a QNE > >>> simultaneously supports only one end-to-end QOSM and one > local QOSM. > >> > >> I don't know how you come to this conclusion, but I would say that: > >> 1) your domain is likely to use only one QOSM > >> (using the definition from the QSPEC terminology draft), > >> i.e. one specific set of mechanisms to support QoS, e.g. > >> DiffServ with a specific number of different service classes. > >> 2) your domain may understand different QSPECs, usually > >> one end-to-end QSPEC and one or more local QSPECs as > >> long as there your QOSM defines a mapping from these > >> QSPEC parameters to your QOSM internal parameters for > >> admission control. > > > > Georgios: Why only one end-to-end QSPEC? > > A QNE might support more than one end-to-end QOSMs and more > than one > > local (intra-domain) QOSMs. > > > > Therefore, it will be very complex for the QNE, when it receives a > > QSPEC to know to which RMF/QOSM to send the received QSPEC. In > > particular, for the situations that all QOSMs use the same types of > > QSPEC (private) parameters. > > > And the upstream node putting in these QOSMids knows better? > > > By including the QSPEC Type and QOSM ID a QNE will know exactly how > > and where (to which RMF/QOSM) to send the received QSPEC. > > > > > >> > >>> When a QNE supports say more than one end-to-end QOSMs and > >> it receives > >>> a QSPEC it will not know how to associate this QSPEC or the > >> (specific > >>> to one QOSM) parameters contained in the QSPEC with the > right QOSM. > >> > >> Why not? I thought it is no problem to have a local table > in the RMF > >> containing the set of supported QSPEC types. The QOSM must > know how > >> to interpret the parameters and must assure that the requested > >> constraints are actually met (in case of admission). From an > >> interface perspective I don't care about the particular > type of QOSM > >> that you are running as long as you can correctly decide about the > >> admission of my QoS request (i.e. QSPEC). > >> > >>> Actually we need both, the QSPEC type and the QOSM ID. > >> > >> I don't see a reason to signal the QOSM. It's clear that > some QSPEC > >> types may be specific to particular QOSMs. > >> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC B > >> locally. QOSM C may be a variant of QOSM A but uses the > same QSPEC A. > >> It might be the case that QOSM B understands QSPEC A _and_ QSPEC B > >> (usually as well as the global E2E QSPEC), so I don't see a good > >> reason to signal the QOSM. > >> > >>> Note that a QNE, such as an Ingress backbone router needs > >> to support > >>> more than one end-to-end QOSMs and local QOSMs. > >> > >> Probably, but I don't see any problem in doing so with > only the QSPEC > >> type. > > > > Georgios: Please see above! > > > >> > >> Regards, > >> Roland > >> > > > > > > > > _______________________________________________ > > 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 nsis-bounces@ietf.org Mon Mar 05 09:26:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOE7r-00044V-PS; Mon, 05 Mar 2007 09:25:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOE7q-00044P-Q5 for nsis@ietf.org; Mon, 05 Mar 2007 09:25:18 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOE7p-0003yZ-7S for nsis@ietf.org; Mon, 05 Mar 2007 09:25:18 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2007 06:25:15 -0800 X-IronPort-AV: i="4.14,250,1170662400"; d="scan'208"; a="118003995:sNHT1752816186" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l25EPF35021643; Mon, 5 Mar 2007 06:25:15 -0800 Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l25EPDa3027544; Mon, 5 Mar 2007 14:25:14 GMT In-Reply-To: <004501c75f2d$a5854490$4c0d5982@dynamic.ewi.utwente.nl> References: <45EC0B46.6020708@tm.uka.de><002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <360938CB-DE8E-4ADC-A961-A65AF700E65B@cisco.com> <004501c75f2d$a5854490$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05E1A3BE-7480-4B93-AC57-A4C958705165@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 09:25:05 -0500 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4780; t=1173104715; x=1173968715; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20comment=20on=20reintroduction=20of=20QOSM-ID =20in=20qspec=20draft |Sender:=20; bh=X7kw968+S/WUsCheesY2wz6aztIYFg+rcsRkpC1JMDM=; b=is0elCQPIyZsQ+Mk8cxVGp3lrgDUK1gtn9gJptcn3OFKKyv0NEiOIvXS3ANHLROsR7Cg6MuD W7ecuj1Ym1u5AT1k2xwABPyKqSYIgdKkAe65dS9YdL8n7XRUiLW4kFUc; Authentication-Results: sj-dkim-5; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: "'ASH, GERALD R, ATTLABS'" , 'Roland Bless' , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Mar 5, 2007, at 8:53 AM, Georgios Karagiannis wrote: > Hi Dave > > Regarding the following comment: > >> Therefore, it will be very complex for the QNE, when it receives a >> QSPEC to know to which RMF/QOSM to send the received QSPEC. In >> particular, for the situations that all QOSMs use the same types of >> QSPEC (private) parameters. >> > Dave: And the upstream node putting in these QOSMids knows better? > > Georgios: Note that the QNI (for initial QSPEC) or QNI_Ingress (for > local > QSPEC) > will include the QOSM-ID! > That was my point. How does it know? Is there some kind of discovery through GIST? > Best regards, > Georgios > > > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: maandag 5 maart 2007 14:38 >> To: Georgios Karagiannis >> Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin >> Stiemerling' >> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> >> On Mar 5, 2007, at 7:43 AM, Georgios Karagiannis wrote: >> >>> Hi Roland >>> >>> Please see in line! >>> >>>> -----Original Message----- >>>> From: Roland Bless [mailto:bless@tm.uka.de] >>>> Sent: maandag 5 maart 2007 13:21 >>>> To: Georgios Karagiannis >>>> Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis >>>> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec >>>> draft >>>> >>>> Hi Georgios, >>>> >>>> Georgios Karagiannis wrote: >>>>> By using only the QSPEC type, will work only when a QNE >>>>> simultaneously supports only one end-to-end QOSM and one >> local QOSM. >>>> >>>> I don't know how you come to this conclusion, but I would say that: >>>> 1) your domain is likely to use only one QOSM >>>> (using the definition from the QSPEC terminology draft), >>>> i.e. one specific set of mechanisms to support QoS, e.g. >>>> DiffServ with a specific number of different service classes. >>>> 2) your domain may understand different QSPECs, usually >>>> one end-to-end QSPEC and one or more local QSPECs as >>>> long as there your QOSM defines a mapping from these >>>> QSPEC parameters to your QOSM internal parameters for >>>> admission control. >>> >>> Georgios: Why only one end-to-end QSPEC? >>> A QNE might support more than one end-to-end QOSMs and more >> than one >>> local (intra-domain) QOSMs. >>> >>> Therefore, it will be very complex for the QNE, when it receives a >>> QSPEC to know to which RMF/QOSM to send the received QSPEC. In >>> particular, for the situations that all QOSMs use the same types of >>> QSPEC (private) parameters. >>> >> And the upstream node putting in these QOSMids knows better? >> >>> By including the QSPEC Type and QOSM ID a QNE will know exactly how >>> and where (to which RMF/QOSM) to send the received QSPEC. >>> >>> >>>> >>>>> When a QNE supports say more than one end-to-end QOSMs and >>>> it receives >>>>> a QSPEC it will not know how to associate this QSPEC or the >>>> (specific >>>>> to one QOSM) parameters contained in the QSPEC with the >> right QOSM. >>>> >>>> Why not? I thought it is no problem to have a local table >> in the RMF >>>> containing the set of supported QSPEC types. The QOSM must >> know how >>>> to interpret the parameters and must assure that the requested >>>> constraints are actually met (in case of admission). From an >>>> interface perspective I don't care about the particular >> type of QOSM >>>> that you are running as long as you can correctly decide about the >>>> admission of my QoS request (i.e. QSPEC). >>>> >>>>> Actually we need both, the QSPEC type and the QOSM ID. >>>> >>>> I don't see a reason to signal the QOSM. It's clear that >> some QSPEC >>>> types may be specific to particular QOSMs. >>>> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC B >>>> locally. QOSM C may be a variant of QOSM A but uses the >> same QSPEC A. >>>> It might be the case that QOSM B understands QSPEC A _and_ QSPEC B >>>> (usually as well as the global E2E QSPEC), so I don't see a good >>>> reason to signal the QOSM. >>>> >>>>> Note that a QNE, such as an Ingress backbone router needs >>>> to support >>>>> more than one end-to-end QOSMs and local QOSMs. >>>> >>>> Probably, but I don't see any problem in doing so with >> only the QSPEC >>>> type. >>> >>> Georgios: Please see above! >>> >>>> >>>> Regards, >>>> Roland >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 nsis-bounces@ietf.org Mon Mar 05 09:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEEC-00014M-S0; Mon, 05 Mar 2007 09:31:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEEC-00014H-8l for nsis@ietf.org; Mon, 05 Mar 2007 09:31:52 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEEA-0005nN-OE for nsis@ietf.org; Mon, 05 Mar 2007 09:31:52 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25EVTa9018988; Mon, 5 Mar 2007 15:31:42 +0100 (MET) From: "Georgios Karagiannis" To: "'David R Oran'" References: <45EC0B46.6020708@tm.uka.de><002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <360938CB-DE8E-4ADC-A961-A65AF700E65B@cisco.com> <004501c75f2d$a5854490$4c0d5982@dynamic.ewi.utwente.nl> <05E1A3BE-7480-4B93-AC57-A4C958705165@cisco.com> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 15:31:23 +0100 Message-ID: <004d01c75f32$f6980570$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <05E1A3BE-7480-4B93-AC57-A4C958705165@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdfMh1s7nUDAO2dQ86AQc+09KKu7AAADIZw X-Spam-Score: 0.237 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 15:31:43 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: "'ASH, GERALD R, ATTLABS'" , 'Roland Bless' , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave Consider that the reservation request is started by the QNI. The QOSM will then have to include an initial QSPEC with a QOSM-ID into the RESERVE. The QOSM-ID should be assigned by IANA, please see v.12 of the QSPEC template draft. Best regards, Georgios > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: maandag 5 maart 2007 15:25 > To: Georgios Karagiannis > Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin > Stiemerling' > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > > On Mar 5, 2007, at 8:53 AM, Georgios Karagiannis wrote: > > > Hi Dave > > > > Regarding the following comment: > > > >> Therefore, it will be very complex for the QNE, when it receives a > >> QSPEC to know to which RMF/QOSM to send the received QSPEC. In > >> particular, for the situations that all QOSMs use the same > types of > >> QSPEC (private) parameters. > >> > > Dave: And the upstream node putting in these QOSMids knows better? > > > > Georgios: Note that the QNI (for initial QSPEC) or QNI_Ingress (for > > local > > QSPEC) > > will include the QOSM-ID! > > > That was my point. How does it know? Is there some kind of > discovery through GIST? > > > Best regards, > > Georgios > > > > > > > > > >> -----Original Message----- > >> From: David R Oran [mailto:oran@cisco.com] > >> Sent: maandag 5 maart 2007 14:38 > >> To: Georgios Karagiannis > >> Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin > >> Stiemerling' > >> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec > >> draft > >> > >> > >> On Mar 5, 2007, at 7:43 AM, Georgios Karagiannis wrote: > >> > >>> Hi Roland > >>> > >>> Please see in line! > >>> > >>>> -----Original Message----- > >>>> From: Roland Bless [mailto:bless@tm.uka.de] > >>>> Sent: maandag 5 maart 2007 13:21 > >>>> To: Georgios Karagiannis > >>>> Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis > >>>> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID > in qspec > >>>> draft > >>>> > >>>> Hi Georgios, > >>>> > >>>> Georgios Karagiannis wrote: > >>>>> By using only the QSPEC type, will work only when a QNE > >>>>> simultaneously supports only one end-to-end QOSM and one > >> local QOSM. > >>>> > >>>> I don't know how you come to this conclusion, but I > would say that: > >>>> 1) your domain is likely to use only one QOSM > >>>> (using the definition from the QSPEC terminology draft), > >>>> i.e. one specific set of mechanisms to support QoS, e.g. > >>>> DiffServ with a specific number of different service classes. > >>>> 2) your domain may understand different QSPECs, usually > >>>> one end-to-end QSPEC and one or more local QSPECs as > >>>> long as there your QOSM defines a mapping from these > >>>> QSPEC parameters to your QOSM internal parameters for > >>>> admission control. > >>> > >>> Georgios: Why only one end-to-end QSPEC? > >>> A QNE might support more than one end-to-end QOSMs and more > >> than one > >>> local (intra-domain) QOSMs. > >>> > >>> Therefore, it will be very complex for the QNE, when it > receives a > >>> QSPEC to know to which RMF/QOSM to send the received QSPEC. In > >>> particular, for the situations that all QOSMs use the > same types of > >>> QSPEC (private) parameters. > >>> > >> And the upstream node putting in these QOSMids knows better? > >> > >>> By including the QSPEC Type and QOSM ID a QNE will know > exactly how > >>> and where (to which RMF/QOSM) to send the received QSPEC. > >>> > >>> > >>>> > >>>>> When a QNE supports say more than one end-to-end QOSMs and > >>>> it receives > >>>>> a QSPEC it will not know how to associate this QSPEC or the > >>>> (specific > >>>>> to one QOSM) parameters contained in the QSPEC with the > >> right QOSM. > >>>> > >>>> Why not? I thought it is no problem to have a local table > >> in the RMF > >>>> containing the set of supported QSPEC types. The QOSM must > >> know how > >>>> to interpret the parameters and must assure that the requested > >>>> constraints are actually met (in case of admission). From an > >>>> interface perspective I don't care about the particular > >> type of QOSM > >>>> that you are running as long as you can correctly decide > about the > >>>> admission of my QoS request (i.e. QSPEC). > >>>> > >>>>> Actually we need both, the QSPEC type and the QOSM ID. > >>>> > >>>> I don't see a reason to signal the QOSM. It's clear that > >> some QSPEC > >>>> types may be specific to particular QOSMs. > >>>> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC B > >>>> locally. QOSM C may be a variant of QOSM A but uses the > >> same QSPEC A. > >>>> It might be the case that QOSM B understands QSPEC A > _and_ QSPEC B > >>>> (usually as well as the global E2E QSPEC), so I don't see a good > >>>> reason to signal the QOSM. > >>>> > >>>>> Note that a QNE, such as an Ingress backbone router needs > >>>> to support > >>>>> more than one end-to-end QOSMs and local QOSMs. > >>>> > >>>> Probably, but I don't see any problem in doing so with > >> only the QSPEC > >>>> type. > >>> > >>> Georgios: Please see above! > >>> > >>>> > >>>> Regards, > >>>> Roland > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 nsis-bounces@ietf.org Mon Mar 05 09:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEM1-0004Th-Iz; Mon, 05 Mar 2007 09:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEM0-0004TL-9K for nsis@ietf.org; Mon, 05 Mar 2007 09:39:56 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOELx-0000Nc-Ls for nsis@ietf.org; Mon, 05 Mar 2007 09:39:56 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2007 06:39:53 -0800 X-IronPort-AV: i="4.14,250,1170662400"; d="scan'208"; a="118009718:sNHT56410182" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l25EdrZB031050; Mon, 5 Mar 2007 06:39:53 -0800 Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l25Edqa3004999; Mon, 5 Mar 2007 14:39:52 GMT In-Reply-To: <004d01c75f32$f6980570$4c0d5982@dynamic.ewi.utwente.nl> References: <45EC0B46.6020708@tm.uka.de><002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <360938CB-DE8E-4ADC-A961-A65AF700E65B@cisco.com> <004501c75f2d$a5854490$4c0d5982@dynamic.ewi.utwente.nl> <05E1A3BE-7480-4B93-AC57-A4C958705165@cisco.com> <004d01c75f32$f6980570$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 09:39:43 -0500 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6736; t=1173105593; x=1173969593; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20comment=20on=20reintroduction=20of=20QOSM-ID =20in=20qspec=20draft |Sender:=20; bh=NERLyMl0ElZM9pJZk7JhnW8NtfZAjCuu+ZSPGOdMg2s=; b=DUjjqDH1GS3nrjj/dRU7VZPG+NfDjlgNqukD4781bKuDN6sLvXaGta0ugvC/8UOp0s9FmLOL DxNgP7xxaegoSCmt3U1HqeLyHMMnmX03efTsoD01wLORE8i7iV/6zNf+; Authentication-Results: sj-dkim-8; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: "'ASH, GERALD R, ATTLABS'" , 'Roland Bless' , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Mar 5, 2007, at 9:31 AM, Georgios Karagiannis wrote: > Hi Dave > > Consider that the reservation request is started by the QNI. > The QOSM will then have to include an initial QSPEC with a QOSM-ID > into the RESERVE. We're still talking past each other. Why should the QNI have to do this? It may have no clue what QOSMs are downstream. One major reason we went for a registry of QSPEC parameters with IANA registration of everything and the requirement to write an RFC for a QOSM, was to avoid this kind of static binning of things. If you have a QOSM, you've documented it, and it uses QPSEC parameters that are registered with IANA, that's all you need to figure out what to do. It's important to note that there's only one set of resources being allocated and managed, so at some point your implementation has to deal with the fact that if there are multiple QOSMs operating on the same resources they have to know about each other. This was the point Robert was making earlier in the thread. > The QOSM-ID should be assigned by IANA, please > see v.12 of the QSPEC template draft. > This is circular logic. If we don't need it, then we don't have to put it in, and hence you don't need an IANA registry. Cheers, Dave. > Best regards, > Georgios > > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: maandag 5 maart 2007 15:25 >> To: Georgios Karagiannis >> Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin >> Stiemerling' >> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> >> On Mar 5, 2007, at 8:53 AM, Georgios Karagiannis wrote: >> >>> Hi Dave >>> >>> Regarding the following comment: >>> >>>> Therefore, it will be very complex for the QNE, when it receives a >>>> QSPEC to know to which RMF/QOSM to send the received QSPEC. In >>>> particular, for the situations that all QOSMs use the same >> types of >>>> QSPEC (private) parameters. >>>> >>> Dave: And the upstream node putting in these QOSMids knows better? >>> >>> Georgios: Note that the QNI (for initial QSPEC) or QNI_Ingress (for >>> local >>> QSPEC) >>> will include the QOSM-ID! >>> >> That was my point. How does it know? Is there some kind of >> discovery through GIST? >> >>> Best regards, >>> Georgios >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: David R Oran [mailto:oran@cisco.com] >>>> Sent: maandag 5 maart 2007 14:38 >>>> To: Georgios Karagiannis >>>> Cc: 'ASH, GERALD R, ATTLABS'; 'Roland Bless'; 'nsis'; 'Martin >>>> Stiemerling' >>>> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec >>>> draft >>>> >>>> >>>> On Mar 5, 2007, at 7:43 AM, Georgios Karagiannis wrote: >>>> >>>>> Hi Roland >>>>> >>>>> Please see in line! >>>>> >>>>>> -----Original Message----- >>>>>> From: Roland Bless [mailto:bless@tm.uka.de] >>>>>> Sent: maandag 5 maart 2007 13:21 >>>>>> To: Georgios Karagiannis >>>>>> Cc: ASH, GERALD R, ATTLABS; Martin Stiemerling; nsis >>>>>> Subject: Re: [NSIS] comment on reintroduction of QOSM-ID >> in qspec >>>>>> draft >>>>>> >>>>>> Hi Georgios, >>>>>> >>>>>> Georgios Karagiannis wrote: >>>>>>> By using only the QSPEC type, will work only when a QNE >>>>>>> simultaneously supports only one end-to-end QOSM and one >>>> local QOSM. >>>>>> >>>>>> I don't know how you come to this conclusion, but I >> would say that: >>>>>> 1) your domain is likely to use only one QOSM >>>>>> (using the definition from the QSPEC terminology draft), >>>>>> i.e. one specific set of mechanisms to support QoS, e.g. >>>>>> DiffServ with a specific number of different service classes. >>>>>> 2) your domain may understand different QSPECs, usually >>>>>> one end-to-end QSPEC and one or more local QSPECs as >>>>>> long as there your QOSM defines a mapping from these >>>>>> QSPEC parameters to your QOSM internal parameters for >>>>>> admission control. >>>>> >>>>> Georgios: Why only one end-to-end QSPEC? >>>>> A QNE might support more than one end-to-end QOSMs and more >>>> than one >>>>> local (intra-domain) QOSMs. >>>>> >>>>> Therefore, it will be very complex for the QNE, when it >> receives a >>>>> QSPEC to know to which RMF/QOSM to send the received QSPEC. In >>>>> particular, for the situations that all QOSMs use the >> same types of >>>>> QSPEC (private) parameters. >>>>> >>>> And the upstream node putting in these QOSMids knows better? >>>> >>>>> By including the QSPEC Type and QOSM ID a QNE will know >> exactly how >>>>> and where (to which RMF/QOSM) to send the received QSPEC. >>>>> >>>>> >>>>>> >>>>>>> When a QNE supports say more than one end-to-end QOSMs and >>>>>> it receives >>>>>>> a QSPEC it will not know how to associate this QSPEC or the >>>>>> (specific >>>>>>> to one QOSM) parameters contained in the QSPEC with the >>>> right QOSM. >>>>>> >>>>>> Why not? I thought it is no problem to have a local table >>>> in the RMF >>>>>> containing the set of supported QSPEC types. The QOSM must >>>> know how >>>>>> to interpret the parameters and must assure that the requested >>>>>> constraints are actually met (in case of admission). From an >>>>>> interface perspective I don't care about the particular >>>> type of QOSM >>>>>> that you are running as long as you can correctly decide >> about the >>>>>> admission of my QoS request (i.e. QSPEC). >>>>>> >>>>>>> Actually we need both, the QSPEC type and the QOSM ID. >>>>>> >>>>>> I don't see a reason to signal the QOSM. It's clear that >>>> some QSPEC >>>>>> types may be specific to particular QOSMs. >>>>>> For instance, QOSM A may use QSPEC A and QOSM B may use QSPEC B >>>>>> locally. QOSM C may be a variant of QOSM A but uses the >>>> same QSPEC A. >>>>>> It might be the case that QOSM B understands QSPEC A >> _and_ QSPEC B >>>>>> (usually as well as the global E2E QSPEC), so I don't see a good >>>>>> reason to signal the QOSM. >>>>>> >>>>>>> Note that a QNE, such as an Ingress backbone router needs >>>>>> to support >>>>>>> more than one end-to-end QOSMs and local QOSMs. >>>>>> >>>>>> Probably, but I don't see any problem in doing so with >>>> only the QSPEC >>>>>> type. >>>>> >>>>> Georgios: Please see above! >>>>> >>>>>> >>>>>> Regards, >>>>>> Roland >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 nsis-bounces@ietf.org Mon Mar 05 10:01:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEgN-00056Q-QN; Mon, 05 Mar 2007 10:00:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEgM-00055w-Gp for nsis@ietf.org; Mon, 05 Mar 2007 10:00:58 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEg1-00087U-Cv for nsis@ietf.org; Mon, 05 Mar 2007 10:00:58 -0500 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HOEfl-0003Lu-SA; Mon, 05 Mar 2007 16:00:33 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 307E12FC244; Mon, 5 Mar 2007 16:00:21 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HOEfh-0005Gi-U2; Mon, 05 Mar 2007 16:00:18 +0100 Message-ID: <45EC3081.2020909@tm.uka.de> Date: Mon, 05 Mar 2007 16:00:17 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: > Sorry, I meant: > Why only one end-to-end QSPEC? Actually these could be different QSPEC types, but due to better interoperability it should be only one QSPEC which is understood by every node (which is the current QSPEC template). If your QNE knows how to map the different QSPEC types to its internal RMF parameters I see no problem. > A QNE might support more than one end-to-end QOSMs and more > than one local (intra-domain) QOSMs. Hmm, I see conceptually no problem in supporting more than one end-to-end _QSPEC_, but more than one local intra-domain QOSM? This sounds like a virtualization of resources... However, I also see no problem as long as there is a unique mapping from QSPEC type to QOSM/RMF (which could be set by local policy). > Therefore, it will be complex for the QNE, when it > receives a QSPEC to know to which RMF/QOSM to send the > received QSPEC. In particular, for the situations that all Why complex? It should have a static mapping from QSPEC type to RMF (if you support different RMFs). > QOSMs use the same types of QSPEC (private) parameters, but use different > semantics and values for these QSPEC private parameters. That sounds weird, but a cleaner approach would be to define a different QSPEC type for each such case. If I understand you correctly, you suggest to use the QOSM-ID as (semantic) demultiplexer for that purpose. > In the solution that you proposed it will mean that each QOSM will have to > check all > QSPEC parameters to find out if the sematics of some of them can be > understood etc... No, you will have a demultiplexer that decides on the QSPEC type (which wuold be different for different semantic interpretations of the parameters). > And I am not sure if all situations can be covered. Are you? > > > By including the QSPEC Type and QOSM ID a QNE will know > exactly how and where (to which RMF/QOSM) to send the received QSPEC. > Thius is a very clean solution that does not introduce any additional > complexity, just some bits in the common header of the QSPEC object. I see that the use of a QOSM and the RMF as a matter of local policy. So usually, I don't want to use the value of the QOSM-ID of my preceding QNE, but rather decide it locally (I guess that was Dave's point, too). Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 10:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEqV-0001xg-LP; Mon, 05 Mar 2007 10:11:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEqU-0001xZ-Ka for nsis@ietf.org; Mon, 05 Mar 2007 10:11:26 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOEqR-00045q-1m for nsis@ietf.org; Mon, 05 Mar 2007 10:11:26 -0500 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HOEqG-0005XZ-71; Mon, 05 Mar 2007 16:11:14 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8928E2FC244; Mon, 5 Mar 2007 16:11:11 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HOEqC-0005HO-CN; Mon, 05 Mar 2007 16:11:08 +0100 Message-ID: <45EC330B.4010304@tm.uka.de> Date: Mon, 05 Mar 2007 16:11:07 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" References: <45671BDD.8090608@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nsis@ietf.org Subject: [NSIS] Re: Retransmitted Queries X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > hi roland, > > sorry for the delayed reply. No problem as long as there is one :-) > my instinct here is that there is a fundamental (functional) > benefit in having retransmitted queries use different cookies, > and a possible performance benefit in not - but that actually > i believe that performance benefit does not arise in practice. > > the functional benefit is that it is good to know if two > messages are the same or not. one is for reply correlation for > rtt measurement (as you mention). another is for network > debugging - if you see two identical messages, you *know* that > they have been replicated in the network or some buggy piece > of software, rather than the possibility that they are > retransmissions. (my thinking on this is inspired by a certain > amount of time worrying over TCP traces and suchlike, where > it is a major frustration not knowing which instance of a piece > of data is being acknowledged). That's ok. > given this tradeoff, i'd rather leave things as they are. Ok. See below. >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: 24 November 2006 16:21 >> To: Hancock, Robert; nsis@ietf.org >> Subject: Retransmitted Queries >> >> Hi Robert and all, >> >> In section 5.3.3. there is the statement: >> >> Retransmitted Queries MUST use different Query-Cookie values. >> >> Is there any rationale for this (yes, I read sec. 8.5)? >> I cannot see any real benefit in doing >> so (except for the case that you want to measure round-trip times). >> Replay attacks seem to cause no harm, because they do not >> cause additional state to be installed. In the current situation, >> we have often seen the case where retransmissions and responses >> are crossing each other (or two queries are transmitted back-to-back) >> and the responder has to send one response for each query until the >> backoff is large enough to allow a query cookie match for the latest >> query/response pair. > > two points: > > - if you are sending Queries that close together, the fact that > retransmissions can overlap with responses probably means you > shouldn't be. I don't think we want to get into specificying formally I don't get this point. In fact we have seen such behavior in our stress tests due to backlogging effects and so on. > the adaptation algorithms to handle this case, but there is a point > at which making the Queries more frequent doesn't increase the > accuracy with which you track routing state. > > - nothing prevents the Querying node from keeping track of more > than just the most recent Query. in that case, a Response for an > earlier Query will stop the retransmission process. however, one That is a good point and I think that it's worth mentioning in the GIST spec. > would hope that the retransmission timer (T1) is longer than the > RTT, either by configuration or adaptation (see 5.3.3) so the > overlapping response/retransmission situation should be rare in > practice. > >> If we require that every Query must be answered >> by a Response (in order to recover from lost Responses) I see an >> advantage of using the same query cookie for retransmissions: >> The context will be established earlier, as soon as >> the first response hits the querier, so the latter will stop the >> retransmission of queries. Subsequent responses can be dropped >> because state was already established at the querier. > > that in any case is not allowed: you MUST send a Confirm for every > Response (if the Response asks for it). The retransmitted responses > may be to handle lost Confirms, and the Querying node can never > know whether a Confirm for a particular Response arrived or not. You are right. Thanks, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 10:20:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEyy-000174-Rs; Mon, 05 Mar 2007 10:20:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEyw-0000s6-Ol for nsis@ietf.org; Mon, 05 Mar 2007 10:20:10 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEys-0008Qa-Cx for nsis@ietf.org; Mon, 05 Mar 2007 10:20:10 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l25FJkRB022568; Mon, 5 Mar 2007 16:20:04 +0100 (MET) From: "Georgios Karagiannis" To: "'Roland Bless'" References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> <45EC3081.2020909@tm.uka.de> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 16:19:41 +0100 Message-ID: <006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45EC3081.2020909@tm.uka.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdfNwl3CjC5UkxRQvKdQkPzaVxJrwAAUVYw X-Spam-Score: 0.237 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Mar 2007 16:20:04 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland Please see in line! > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: maandag 5 maart 2007 16:00 > To: Georgios Karagiannis > Cc: 'ASH, GERALD R, ATTLABS'; 'nsis'; 'Martin Stiemerling' > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Hi Georgios, > > Georgios Karagiannis wrote: > > Sorry, I meant: > > Why only one end-to-end QSPEC? > > Actually these could be different QSPEC types, but due to > better interoperability it should be only one QSPEC which is > understood by every node (which is the current QSPEC > template). If your QNE knows how to map the different QSPEC > types to its internal RMF parameters I see no problem. Georgios: Please note that any QOSM will have to understand the QSPEC parameters defined in the QSPEC template draft. Thus I agree! > > > A QNE might support more than one end-to-end QOSMs and more > than one > > local (intra-domain) QOSMs. > > Hmm, I see conceptually no problem in supporting more than > one end-to-end _QSPEC_, but more than one local intra-domain QOSM? > This sounds like a virtualization of resources... > However, I also see no problem as long as there is a unique > mapping from QSPEC type to QOSM/RMF (which could be set by > local policy). Georgios: But currently there are only tow QSPEC types defined: "Initial" and "local" > > > Therefore, it will be complex for the QNE, when it receives > a QSPEC to > > know to which RMF/QOSM to send the received QSPEC. In > particular, for > > the situations that all > > Why complex? It should have a static mapping from QSPEC type > to RMF (if you support different RMFs). Georgios: My explanation and questions was: Therefore, it will be complex for the QNE, when it receives a QSPEC to know to which RMF/QOSM to send the received QSPEC. In particular, for the situations that all QOSMs use the same types of QSPEC (private) parameters, but use different semantics and values for these QSPEC private parameters. In the solution that you proposed it will mean that each QOSM will have to check all QSPEC parameters to find out if the sematics of some of them can be understood etc... And I am not sure if all situations can be covered. Are you? > > > QOSMs use the same types of QSPEC (private) parameters, but use > > different semantics and values for these QSPEC private parameters. > > That sounds weird, but a cleaner approach would be to define > a different QSPEC type for each such case. If I understand > you correctly, you suggest to use the QOSM-ID as (semantic) > demultiplexer for that purpose. Georgios: Currently only two types of QSPEC types are specified, see above. I propose to use for demultiplexing both the QSPEC type and QOSM-ID. > > > In the solution that you proposed it will mean that each QOSM will > > have to check all QSPEC parameters to find out if the > sematics of some > > of them can be understood etc... > > No, you will have a demultiplexer that decides on the QSPEC > type (which wuold be different for different semantic > interpretations of the parameters). Georgios: Currently only two QSPEC types are defined "initial" and "local" I propose to use for demultiplexing both the QSPEC type and QOSM-ID. > > > And I am not sure if all situations can be covered. Are you? > > > > > > By including the QSPEC Type and QOSM ID a QNE will know exactly how > > and where (to which RMF/QOSM) to send the received QSPEC. > > Thius is a very clean solution that does not introduce any > additional > > complexity, just some bits in the common header of the QSPEC object. > > I see that the use of a QOSM and the RMF as a matter of local policy. > So usually, I don't want to use the value of the QOSM-ID of > my preceding QNE, but rather decide it locally (I guess that > was Dave's point, too). Georgios: But there are situations where you cannot decide that locally, see above! Best regards, Georgios > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 11:15:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFpo-0004ng-43; Mon, 05 Mar 2007 11:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFpn-0004na-3V for nsis@ietf.org; Mon, 05 Mar 2007 11:14:47 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOFpj-0004BT-J6 for nsis@ietf.org; Mon, 05 Mar 2007 11:14:47 -0500 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HOFpc-0001W7-Ca; Mon, 05 Mar 2007 17:14:39 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id DADA42FC210; Mon, 5 Mar 2007 17:14:35 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HOFpY-0005LS-Ia; Mon, 05 Mar 2007 17:14:32 +0100 Message-ID: <45EC41E8.3030004@tm.uka.de> Date: Mon, 05 Mar 2007 17:14:32 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> <45EC3081.2020909@tm.uka.de> <006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: > Georgios: But currently there are only tow QSPEC types defined: > "Initial" and "local" You are right, I've not finished my review of the latest draft and just checked section 8 (it's not that clear from the definition in sec. 6.1.). I thought that it's rather like: RMD-QSPEC, Y1541-QSPEC etc. (at least that was the intention of my proposal). However, the current QSPEC template concept is different, i.e., you can attach QOSM specific parameters to the QSPEC... My fault. Sorry for the confusion. > Georgios: Currently only two types of QSPEC types are specified, see above. > I propose to use for demultiplexing both the QSPEC type and QOSM-ID. If QSPEC type is defined differently, that wouldn't be necessary. >>> In the solution that you proposed it will mean that each QOSM will >>> have to check all QSPEC parameters to find out if the >> sematics of some >>> of them can be understood etc... >> No, you will have a demultiplexer that decides on the QSPEC >> type (which wuold be different for different semantic >> interpretations of the parameters). > > Georgios: Currently only two QSPEC types are defined "initial" and "local" > I propose to use for demultiplexing both the QSPEC type and QOSM-ID. Maybe I don't understand the exact purpose of the now defined QSPEC type initial/local. My initial suggestion was replacement of the QOSM-ID by the QSPEC-ID. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 12:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOHSb-0000ug-Ff; Mon, 05 Mar 2007 12:58:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOHSa-0000ty-Th for nsis@ietf.org; Mon, 05 Mar 2007 12:58:56 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOHSV-0002Nh-H4 for nsis@ietf.org; Mon, 05 Mar 2007 12:58:56 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1173117530!3078649!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27127 invoked from network); 5 Mar 2007 17:58:50 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-10.tower-146.messagelabs.com with SMTP; 5 Mar 2007 17:58:50 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l25HthhJ013082; Mon, 5 Mar 2007 12:55:44 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh8i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l25Htaxw013027; Mon, 5 Mar 2007 12:55:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Mon, 5 Mar 2007 11:58:39 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC828B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45EC41E8.3030004@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: AcdfQWRnFf7iTAPYQ86x3gLDcRVAcQABTEhg References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> <45EC3081.2020909@tm.uka.de> <006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> <45EC41E8.3030004@tm.uka.de> From: "ASH, GERALD R, ATTLABS" To: "Roland Bless" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, > You are right, I've not finished my review of the latest draft > and just checked section 8 (it's not that clear from the > definition in sec. 6.1.). > I thought that it's rather like: RMD-QSPEC, Y1541-QSPEC etc. > (at least that was the intention of my proposal). > However, the current QSPEC template concept is different, i.e., > you can attach QOSM specific parameters to the QSPEC... ... > My initial suggestion was replacement of the QOSM-ID > by the QSPEC-ID. It wasn't clear to me that your intent was to replace QOSM-ID with QSPEC Type. In any case, as per the IANA Consideration specified in Section 8, additional QSPEC Types can be defined, if need be, through Standards action. So if an RMD-QSPEC, etc. QSPEC Type needs to be defined, that should be done in a separate document (note that in previous QSPEC drafts QOSM-IDs were not specified in the IANA Considerations section). It is necessary IMO for the specification to clearly describe, with bit-level examples, how exactly the QSPEC Type parameter (e.g., RMD-QSPEC type parameter) is going to be used. E.g., I get concerned with comments like "QOSMs use the same types of QSPEC (private) parameters, but use different semantics and values for these QSPEC private parameters." I don't see that the semantics of QSPEC parameters can/should be QOSM dependent. At the very least, that sounds non-interoperable and violating basic architectural principles. Note that it *not* required for a QNE to support any QOSM. In the case that no QOSM is supported, the QNE specifies I-QSPEC and L-QSPEC with the default values specified in Section 8 of the QSPEC draft. >> Georgios: Currently only two types of QSPEC types are specified, see above. >> I propose to use for demultiplexing both the QSPEC type and QOSM-ID. > If QSPEC type is defined differently, that wouldn't be necessary. I agree, but don't think the QSPEC type really needs to be redefined, see the above comments. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 05 15:51:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK93-00015q-1I; Mon, 05 Mar 2007 15:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK8s-00013d-1d; Mon, 05 Mar 2007 15:50:46 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOK8A-0000Jh-P4; Mon, 05 Mar 2007 15:50:46 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B5B4F3290A; Mon, 5 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8A-0005ea-J4; Mon, 05 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-09.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-09.txt Pages : 92 Date : 2007-3-5 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rmd-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rmd-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-5115442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5115442.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Tue Mar 06 03:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOVBB-00018v-OH; Tue, 06 Mar 2007 03:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOVAk-0008Ry-0T for nsis@ietf.org; Tue, 06 Mar 2007 03:37:26 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOV1U-0005V6-1B for nsis@ietf.org; Tue, 06 Mar 2007 03:27:55 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l268Rnd5001970; Tue, 6 Mar 2007 09:27:49 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l268RnRm011907; Tue, 6 Mar 2007 09:27:49 +0100 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:27:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Tue, 6 Mar 2007 09:27:45 +0100 Message-ID: In-Reply-To: <45EC41E8.3030004@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: AcdfQYoax/a/SPBaQFmAXzbNOSd++QAh698A References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> <45EC3081.2020909@tm.uka.de><006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> <45EC41E8.3030004@tm.uka.de> From: "Kappler, Cornelia" To: "Roland Bless" , "Georgios Karagiannis" X-OriginalArrivalTime: 06 Mar 2007 08:27:48.0773 (UTC) FILETIME=[52EDCD50:01C75FC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "ASH, GERALD R, ATTLABS" , nsis , Martin Stiemerling X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland,=20 could you explain the difference between your proposal for QSPEC Type = and the original QOSM ID? Thanks. Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Roland Bless [mailto:bless@tm.uka.de]=20 > Gesendet: Montag, 5. M=E4rz 2007 17:15 > An: Georgios Karagiannis > Cc: 'ASH, GERALD R, ATTLABS'; 'nsis'; 'Martin Stiemerling' > Betreff: Re: [NSIS] comment on reintroduction of QOSM-ID in=20 > qspec draft >=20 > Hi Georgios, >=20 > Georgios Karagiannis wrote: > > Georgios: But currently there are only tow QSPEC types defined: > > "Initial" and "local" >=20 > You are right, I've not finished my review of the latest draft > and just checked section 8 (it's not that clear from the > definition in sec. 6.1.). > I thought that it's rather like: RMD-QSPEC, Y1541-QSPEC etc. > (at least that was the intention of my proposal). > However, the current QSPEC template concept is different, i.e., > you can attach QOSM specific parameters to the QSPEC... > My fault. >=20 > Sorry for the confusion. >=20 > > Georgios: Currently only two types of QSPEC types are=20 > specified, see above. > > I propose to use for demultiplexing both the QSPEC type and QOSM-ID. >=20 > If QSPEC type is defined differently, that wouldn't be necessary. >=20 > >>> In the solution that you proposed it will mean that each=20 > QOSM will=20 > >>> have to check all QSPEC parameters to find out if the=20 > >> sematics of some=20 > >>> of them can be understood etc... > >> No, you will have a demultiplexer that decides on the QSPEC=20 > >> type (which wuold be different for different semantic=20 > >> interpretations of the parameters). > >=20 > > Georgios: Currently only two QSPEC types are defined=20 > "initial" and "local" > > I propose to use for demultiplexing both the QSPEC type and QOSM-ID. >=20 > Maybe I don't understand the exact purpose of the now defined=20 > QSPEC type > initial/local. My initial suggestion was replacement of the QOSM-ID > by the QSPEC-ID. >=20 > Regards, > Roland >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 06 05:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOX7y-00089H-BS; Tue, 06 Mar 2007 05:42:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOX7x-00089C-SA for nsis@ietf.org; Tue, 06 Mar 2007 05:42:41 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOX7s-0004aN-5K for nsis@ietf.org; Tue, 06 Mar 2007 05:42:41 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HOX7n-00007V-As; Tue, 06 Mar 2007 11:42:31 +0100 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1HOX7n-0002wC-1r; Tue, 06 Mar 2007 11:42:31 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3BB9D2FC244; Tue, 6 Mar 2007 11:42:30 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HOX7m-0006zX-9o; Tue, 06 Mar 2007 11:42:30 +0100 Message-ID: <45ED4595.1070301@tm.uka.de> Date: Tue, 06 Mar 2007 11:42:29 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: Re: AW: [NSIS] comment on reintroduction of QOSM-ID in qspec draft References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> <45EC3081.2020909@tm.uka.de><006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> <45EC41E8.3030004@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "ASH, GERALD R, ATTLABS" , Georgios Karagiannis , nsis , Martin Stiemerling X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia, Kappler, Cornelia wrote: > could you explain the difference between your proposal for QSPEC Type and the original QOSM ID? Conceptually only little. As already written earlier (see quote below) it's mainly a name correction as I think it makes sense that a QOSM may (but need not) understand different QSPECs. For example, if my particular QOSM is able to understand the RMD-QSPEC, the Y.1541-QSPEC etc. it doesn't necessarily mean that my used QOSM is actually RMD etc. > My intention was to have an ID for a specific QSPEC type, because > the same QSPEC may be understood by several different QoS-Models. > In that sense it would be a replacement for the QoSM ID. If a QOSM > needs specific (local) parameters it can define its own QSPEC type. > This particular QSPEC definition, however, may be (re-)used/applicable > by other QoSMs, too. That's why I thought it may be better to signal > a QSPEC type instead of a QOSM ID. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 06 05:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOXJU-000897-HH; Tue, 06 Mar 2007 05:54:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOXJS-000891-QN for nsis@ietf.org; Tue, 06 Mar 2007 05:54:34 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOXJQ-0007Qz-7n for nsis@ietf.org; Tue, 06 Mar 2007 05:54:34 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l26AqjpL008899; Tue, 6 Mar 2007 11:54:29 +0100 (MET) From: "Georgios Karagiannis" To: "'Roland Bless'" , "'Kappler, Cornelia'" References: <45EC0B46.6020708@tm.uka.de> <002d01c75f23$ebf08110$4c0d5982@dynamic.ewi.utwente.nl> <002f01c75f25$78a0c7e0$4c0d5982@dynamic.ewi.utwente.nl> <45EC3081.2020909@tm.uka.de><006201c75f39$b5f1dd50$4c0d5982@dynamic.ewi.utwente.nl> <45EC41E8.3030004@tm.uka.de> <45ED4595.1070301@tm.uka.de> Subject: RE: AW: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Tue, 6 Mar 2007 11:52:41 +0100 Message-ID: <001801c75fdd$968c80b0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdf3CfjTZBX0xwFRomcXHjrqaXTDwAAPn9w In-Reply-To: <45ED4595.1070301@tm.uka.de> X-Spam-Score: 0.237 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Mar 2007 11:54:30 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' , 'Martin Stiemerling' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland What I really liked from the QSPEC type is that a QSPEC object can be identidied as "Initial" or "Local". Thus my proposal is: Use 1 bit for the QSPEC type: 1: Local 0: Initial Reintroduce the QOSM ID, which should be assigned by an IANA action for each QOSM. The bit format should be the same as given in v.12 of the QSPEC templated draft. Best regards, Georgios > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: dinsdag 6 maart 2007 11:42 > To: Kappler, Cornelia > Cc: Georgios Karagiannis; ASH, GERALD R, ATTLABS; nsis; > Martin Stiemerling > Subject: Re: AW: [NSIS] comment on reintroduction of QOSM-ID > in qspec draft > > Hi Cornelia, > > Kappler, Cornelia wrote: > > could you explain the difference between your proposal for > QSPEC Type and the original QOSM ID? > > Conceptually only little. > As already written earlier (see quote below) it's mainly a > name correction as I think it makes sense that a QOSM may > (but need not) understand different QSPECs. For example, if > my particular QOSM is able to understand the RMD-QSPEC, the > Y.1541-QSPEC etc. it doesn't necessarily mean that my used > QOSM is actually RMD etc. > > > My intention was to have an ID for a specific QSPEC type, > because the > > same QSPEC may be understood by several different QoS-Models. > > In that sense it would be a replacement for the QoSM ID. If a QOSM > > needs specific (local) parameters it can define its own QSPEC type. > > This particular QSPEC definition, however, may be > (re-)used/applicable > > by other QoSMs, too. That's why I thought it may be better > to signal a > > QSPEC type instead of a QOSM ID. > > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 06 08:52:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOa51-0000KU-I1; Tue, 06 Mar 2007 08:51:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOa50-0000KP-Hn for nsis@ietf.org; Tue, 06 Mar 2007 08:51:50 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOa4y-00065D-20 for nsis@ietf.org; Tue, 06 Mar 2007 08:51:50 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l26DpGqQ006562 for ; Tue, 6 Mar 2007 13:51:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2007 13:51:15 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some comments on draft-ietf-nsis-qspec-15.txt Thread-Index: AcdeoYW/yVJxR2etTna0a0jRox1uSwBQTzTw References: From: "Hancock, Robert" To: "nsis" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, here are some comments. most are minor. robert h. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D general: i think the document needs to be checked for consistency of 2119 capitalisation. some musts/shoulds should be MUSTs/SHOULDs and so on. (I think actually the words themselves are right except where noted below.) p9 para 2 line 5 ("but they ..."): needs editorial fixing s4.3 para 2 (and similarly later): surely not-understood non-mandatory parameters MUST be ignored? is there any meaningful sense in which they could not be? s4.3.1 para 2 "mathematically complete": i have looked for a reference for this for a while - imagine my disappointment when the citation [WROCLAWSKI] resolves to 'TBD'!=20 s4.3.1 final para: i would use a word other than 'composed' for the first three instances ('input' and 'output'?) s4.3.2 para 2: if the delay includes queuing, i would add this explicitly to the 2nd sentence. (currently, it implies it is limited to propagation and processing delays, and it is not obvious whether queuing is a type of processing.) Also, it needs to be clear if it is the mean queuing delay or some other statistic of the delay (since variability is covered in the next paragraph under jitter). s4.3.2 2nd-to-last para: "an QSPEC" --> "a QSPEC" s4.3.3 para 1: i don't see how the second two sentences here relate to TH directives. Could they be deleted? I think the message is already stated earlier in the document. s4.3.4: I could not follow this section. In particular, the example in 4.4 has the QNI populating the PHB value, not the downstream QNE as stated here. s4.4 (and later): there should be some reference to the QoS-NSLP specification to clarify the meaning of the word 'tunnel'. It could refer to tunneling the data+signalling, tunneling the signalling only, or hiding the signalling from the interior some other way (e.g. using an NSLPID which isn't understood in the interior). I'm not suggesting actually defining/discussing all these in the QSPEC document, just noting that the tunnel words as a shorthand may be misleading to people who don't have all the context. You could use a word like 'hiding' and refer to 3.3.1 of Qos-NSLP and 7.2 of GIST. s5.1 last para: presumably this is saying that an edge node could use both techniques, but not for the same traffic (what would be the point of that?) s5.2.1 para 1: presumably only understood parameters MUST be examined? s5.2.2 last para: could say 'provides a bound' rather than unreliable. s5.2.5: i think there should be some notes here pointing out that there is some intelligence needed in mapping the E flags etc. from the inner to the initiator Qspec. (Note that this *not* the same as Qspec mapping, but there is at least some mapping to do - for example, there may be no direct match between the parameters in the local and initiator Qspecs, but that does not mean that no E flags should be raised in the latter.) s5.3: i think that rather than describing the two cases as sender/receiver-initiated, it would be better to describe these two cases as a 2-way transaction and a 3-way transaction. It just so happens that up to now it's natural to use the 2-way handshake for a sender-initiated reservation and the 3-way handshake for a receiver initiated one, because then in each case the first message in the handshake is sent by the flow sender and this can set up the routing state. However, logically GIST can (attempt to) set up the routing state in the reverse direction, so you can for example have a receiver-initiated reservation set up with the 2-way transaction. (this would be the natural way to do a reservation for an inbound flow to a mobile node from a mobility anchor, for example.) I don't think this changes any of the text other than giving things different headings and using the terms QNI/QNR rather than sender/receiver in the descriptions. s5.3.2: Case 4 --> Case 3? s5.3.5: I would delete the clause about pre-emption being based on the Priority parameter. It implies that pre-emption is somehow deterministic, whereas I would say that it is always a matter of QNE policy, which could take all sorts of things into account (and the values of the priority parameter in various messages are just some of these). s5.4 para 1: surely update to all QNEs is needed only if the parameter is always used with M=3D1 and there is no fallback in response to error conditions. (As written, this is much too pessimistic.) s6.2.3 (and later): i would move the definition of the 'indeterminate' encoding earlier, otherwise one is left wondering what this word means. [there are also two typos here, flagand and flagflag.] s6.2.5/6.2.6: remove references to values being measured in microseconds. s6.2.12: i think the initial layout diagram is confusing. it implied to me that the PHB encoding is always a 6 bit field. Actually, the initial diagram should be of a 16 bit field, and then three (rather than two) layout options, for the three cases of prescribed value, value set, and non-standard. And shouldn't the 'X' in the second two layout options actually be a '1'? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 06 15:51:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgcp-0005tI-4x; Tue, 06 Mar 2007 15:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgbl-0002iF-EN; Tue, 06 Mar 2007 15:50:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOgbk-0002pR-8H; Tue, 06 Mar 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0280032A87; Tue, 6 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbj-00067K-RM; Tue, 06 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-sctp-01.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : General Internet Signaling Transport (GIST) over SCTP Author(s) : X. Fu, et al. Filename : draft-ietf-nsis-ntlp-sctp-01.txt Pages : 10 Date : 2007-3-6 The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for the Partial Reliability Extension of SCTP is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ntlp-sctp-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-ntlp-sctp-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: <2007-3-6142110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-sctp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-sctp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-6142110.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Mar 07 04:57:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOssW-0006Bb-3D; Wed, 07 Mar 2007 04:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOssU-00066m-Ar for nsis@ietf.org; Wed, 07 Mar 2007 04:56:10 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOssS-0006EB-Qu for nsis@ietf.org; Wed, 07 Mar 2007 04:56:10 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l279u14U027635; Wed, 7 Mar 2007 09:56:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2007 09:56:01 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Retransmitted Queries Thread-Index: AcdfOJ6Qj8HZorBwRlWR/2+blz/pRgBZZqpQ References: <45671BDD.8090608@tm.uka.de> <45EC330B.4010304@tm.uka.de> From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: nsis@ietf.org Subject: [NSIS] RE: Retransmitted Queries X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi roland, inline below:=20 cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 05 March 2007 15:11 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: Retransmitted Queries >=20 > Hi Robert, >=20 > Hancock, Robert wrote: > > hi roland, > >=20 > > sorry for the delayed reply.=20 >=20 > No problem as long as there is one :-) >=20 > > my instinct here is that there is a fundamental=20 > (functional) benefit=20 > > in having retransmitted queries use different cookies, and=20 > a possible=20 > > performance benefit in not - but that actually i believe that=20 > > performance benefit does not arise in practice. > >=20 > > the functional benefit is that it is good to know if two=20 > messages are=20 > > the same or not. one is for reply correlation for rtt=20 > measurement (as=20 > > you mention). another is for network debugging - if you see two=20 > > identical messages, you *know* that they have been=20 > replicated in the=20 > > network or some buggy piece of software, rather than the=20 > possibility=20 > > that they are retransmissions. (my thinking on this is=20 > inspired by a=20 > > certain amount of time worrying over TCP traces and=20 > suchlike, where it=20 > > is a major frustration not knowing which instance of a=20 > piece of data=20 > > is being acknowledged). >=20 > That's ok. >=20 > > given this tradeoff, i'd rather leave things as they are. >=20 > Ok. See below. >=20 > >> -----Original Message----- > >> From: Roland Bless [mailto:bless@tm.uka.de] > >> Sent: 24 November 2006 16:21 > >> To: Hancock, Robert; nsis@ietf.org > >> Subject: Retransmitted Queries > >> > >> Hi Robert and all, > >> > >> In section 5.3.3. there is the statement: > >> > >> Retransmitted Queries MUST use different Query-Cookie values. > >> > >> Is there any rationale for this (yes, I read sec. 8.5)? > >> I cannot see any real benefit in doing so (except for the=20 > case that=20 > >> you want to measure round-trip times). > >> Replay attacks seem to cause no harm, because they do not cause=20 > >> additional state to be installed. In the current=20 > situation, we have=20 > >> often seen the case where retransmissions and responses=20 > are crossing=20 > >> each other (or two queries are transmitted back-to-back) and the=20 > >> responder has to send one response for each query until=20 > the backoff=20 > >> is large enough to allow a query cookie match for the latest=20 > >> query/response pair. > >=20 > > two points: > >=20 > > - if you are sending Queries that close together, the fact that=20 > > retransmissions can overlap with responses probably means you=20 > > shouldn't be. I don't think we want to get into=20 > specificying formally >=20 > I don't get this point. In fact we have seen such behavior in=20 > our stress tests due to backlogging effects and so on. can you outline the message sequence? i'm not saying that this is logically impossible; i'm saying that if it happens, everyone would benefit if some timers were backed off to avoid it. in fact, there are some notes on this added in the latest version (section 4.4.4). in other words, my claim is that the protocol should not be optimised to handle this circumstance - rather, there should=20 be implementation guidance to avoid this circumstance in the first place. >=20 > > the adaptation algorithms to handle this case, but there is=20 > a point at=20 > > which making the Queries more frequent doesn't increase the=20 > accuracy=20 > > with which you track routing state. > >=20 > > - nothing prevents the Querying node from keeping track of=20 > more than=20 > > just the most recent Query. in that case, a Response for an earlier=20 > > Query will stop the retransmission process. however, one >=20 > That is a good point and I think that it's worth mentioning=20 > in the GIST spec. added issue http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue207 >=20 > > would hope that the retransmission timer (T1) is longer=20 > than the RTT,=20 > > either by configuration or adaptation (see 5.3.3) so the=20 > overlapping=20 > > response/retransmission situation should be rare in practice. > >=20 > >> If we require that every Query must be answered by a Response (in=20 > >> order to recover from lost Responses) I see an advantage=20 > of using the=20 > >> same query cookie for retransmissions: > >> The context will be established earlier, as soon as the first=20 > >> response hits the querier, so the latter will stop the=20 > retransmission=20 > >> of queries. Subsequent responses can be dropped because state was=20 > >> already established at the querier. > >=20 > > that in any case is not allowed: you MUST send a Confirm for every=20 > > Response (if the Response asks for it). The retransmitted responses=20 > > may be to handle lost Confirms, and the Querying node can=20 > never know=20 > > whether a Confirm for a particular Response arrived or not. >=20 > You are right. >=20 > Thanks, > Roland >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 05:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtC8-0005Id-Bl; Wed, 07 Mar 2007 05:16:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtC7-0005IX-59 for nsis@ietf.org; Wed, 07 Mar 2007 05:16:27 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOtC3-0002eZ-3W for nsis@ietf.org; Wed, 07 Mar 2007 05:16:27 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l27AGAGY032539; Wed, 7 Mar 2007 10:16:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST authorisation Date: Wed, 7 Mar 2007 10:16:09 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST authorisation Thread-Index: AcdcE6ypysB2n3K0RLuC1beI17ntKQEi49qg References: <45E6ECA1.1030002@uni-tuebingen.de> From: "Hancock, Robert" To: "Ali Fessi" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi ali, thanks for the feedback. comments on the comments below:=20 > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de]=20 > Sent: 01 March 2007 15:09 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] GIST authorisation >=20 > Hi Robert, >=20 > just my opinion: few comments are inline, otherwise I think=20 > it is fine. >=20 >=20 > Hancock, Robert wrote: > > hi all, > >=20 > > Several review comments on GIST related to the question of=20 > how a node=20 > > should decide to accept the creation of a secured messaging=20 > > association (specifically, how to decide that the TLS=20 > authentication=20 > > step is acceptable). A node can't just accept any authentication as=20 > > acceptable, because then the MA security would provide almost no=20 > > value. (It would prevent people disrupting the MA once established,=20 > > but wouldn't prevent anyone establishing it in the first=20 > place.) This=20 > > is referred to as GIST authorisation (note that it's got=20 > nothing to do=20 > > with authorisation for allocation of resources by the=20 > signalling application). > >=20 > > Conceptually what is required is an algorithm for the node, which=20 > > takes an identity and returns an 'OK/not OK' decision. That=20 > algorithm=20 > > has to use the identity along with some other dat; the=20 > simplest form=20 > > of that data is a list, and the algorithm is just a lookup.=20 > (You can=20 > > imagine other algorithms, such as invoking other protocols to check=20 > > the identity; however, these can all be modelled as=20 > different ways of=20 > > storing and accessing the list.) One needs to define=20 > criteria for when=20 > > an identity should be in the list, but that's about it. > >=20 > > Text based on the above description is in GIST -12=20 > (currently with the=20 > > i-d editor). There are two aspects: the authorisation algorithm=20 > > described abstractly in terms of a list lookup, and TLS-specific=20 > > details about name matching in certificates. The abstract=20 > description=20 > > is attached below; it would be interesting to see if people=20 > see it as > > under- or over-specification. > >=20 > > cheers, > >=20 > > r. > >=20 > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D > > =3D=3D=3D=3D=3D=3D=3D > >=20 > > 4.4.2. GIST Peer Authorisation > >=20 > > When two GIST nodes authenticate using a messaging=20 > association, both > > ends have to decide whether to accept the creation of the MA and > > whether to trust the information sent over it. This can=20 > be seen as > > an authorisation decision: > >=20 > > o Authorised peers are trusted to install correct routing state > > about themselves and not, for example, to claim that=20 > they are on- > > path for a flow when they are not. > >=20 > > o Authorised peers are trusted to obey transport and application > > level flow control rules, and not to attempt to=20 > create overload > > situations. > >=20 > > o Authorised peers are trusted not to send erroneous or=20 > malicious > > error messages, for example asserting that routing=20 > state has been > > lost when it has not. > >=20 > > This specification models the decision as verification by the > > authorising node of the peer's identity against a local list of > > peers, the authorised peer database (APD). The APD is a abstract > > construct, similar to the security policy database of IPsec [39]. > > Implementations MAY provide the associated functionality=20 > in any way > > they choose. This section defines only the requirements for APD > > administration and the consequences of successfully validating a > > peer's identity against it. > >=20 > > The APD consists of a list of entries. Each entry includes an > > identity, the namespace from which the identity comes (e.g. DNS > > domains), the scope within which the entry is=20 > applicable, and whether > > authorisation is allowed or denied. The following are example > > scopes: > >=20 > > Peer Address Ownership: The scope is the IP address at which the > > peer for this MRI should be; the APD entry denotes=20 > the identity as > > the owner of address. If the authorising node can=20 > determine this > > address from local information (such as its own=20 > routing tables), > > matching this entry shows that the peer is the correct on-path > > node and so should be authorised. The determination=20 > is simple if > > the peer is one IP hop downstream, since the IP address can be > > derived from the router's forwarding tables. If the=20 > peer is more > > than one hop away or is upstream, the determination=20 > is harder but > > may still be possible in some circumstances. The=20 > authorising node > > may be able to determine a (small) set of possible=20 > peer addresses, > > and accept that any of these could be the correct peer. > >=20 > > End-System Subnet: The scope is an address range within=20 > which the > > MRI source or destination lie; the APD entry denotes=20 > the identity > > as potentially being on-path between the authorising=20 > node and that > > address range. There may be different source and destination > > scopes, to account for asymmetric routing. > >=20 > > The same identity may appear in multiple entries, and=20 > the order of > > entries in the APD is significant. When a messaging=20 > association is > > authenticated and associated with an MRI, the=20 > authorising node scans > > the APD to find the first entry where the identity matches that > > presented by the peer, and where the scope information=20 > matches the > > circumstances for which the MA is being set up. The identity > > matching process itself depends on the messaging=20 > association protocol > > that carries out the authentication, and details for TLS=20 > are given in > > Section 5.7.3. =20 >=20 > Section 5.7.3 specifies the use of TLS with either=20 > server-only or mutual authentication. It's not clear to me,=20 > in which cases, the server-only authentication can be=20 > sufficient and in which cases, authentication of the client=20 > is additionally needed. It the "GIST peer"/"TLS client" is=20 > not authenticated in any way, then it won't be possible to=20 > take the authorization decisions for GIST listed above. I=20 > know it won't be always possible for the client to provide a=20 > certificate. But there might be a problem here. i think we already say that channel security is mandatory to=20 implement but optional to use. so the server only vs. client/server authentication distinction is just a special case of this: the server always asks for a client certificate, and if the server policy is that it will not signal with unauthorised peers then if the client doesn't provide a certificate, the whole step will fail. >=20 > > Whenever the full set of possible peers for a > > specific scope is known, deny entries SHOULD be added for the > > wildcard identity to reject signalling associations from unknown > > nodes. The ability of the authorising node to reject=20 > inappropriate > > MAs depends directly on the granularity of the APD and=20 > the precision > > of the scope matching process. > >=20 > > If authorisation is allowed, the MA can be used as=20 > normal; otherwise > > it MUST be torn down without further GIST exchanges, and=20 > any routing > > state associated with the MA MUST also be deleted. An error > > condition MAY be logged locally. When an APD entry is=20 > modified or > > deleted, the node MUST re-validate existing MAs and the=20 > routing state > > table against the revised contents of the APD. This may=20 > result in > > MAs being torn down or routing state entries being=20 > deleted. These > > changes SHOULD be indicated to local signalling=20 > applications via the > > NetworkNotification API call (Appendix B.4). > >=20 > > This specification does not define how the APD is=20 > populated. As a > > minimum, an implementation MUST provide an=20 > administrative interface > > through which entries can be added, modified, or deleted. =20 >=20 > I think up to here, it is fine. The rest is probably not=20 > needed - at least in this document. It might be too early to=20 > think of how to populate GIST APDs in the network. But maybe=20 > in few years, we may think of a "GIST APD Propagation Protocol" ;-) i half agree and half disagree. firstly, note that none of the text below is normative for a GIST implementation - it's just supporting background. the purpose is to show that, at least in some circumstances, populating the APD semi-automatically is feasible. whether it is worth showing that is maybe another question. r. >=20 > > More > > sophisticated mechanisms are possible in some scenarios. For > > example, the fact that a node is legitimately associated with a > > specific IP address could be established by direct=20 > embedding of the > > IP address as a particular identity type in a=20 > certificate, or by a > > mapping that address to another identifier type via an additional > > database lookup (such as relating IP addresses in in-addr.arpa to > > domain names). An enterprise network operator could=20 > generate a list > > of all the identities of its border nodes as authorised=20 > to be on the > > signalling path to external destinations, and this could be > > distributed to all hosts inside the network. Regardless of the > > technique, it MUST be ensured that the source data justify the > > authorisation decisions listed at the start of this=20 > section, and that > > the security of the chain of operations on which the APD entry > > depends cannot be compromised. >=20 > cheers, > ali >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 > -- > Ali Fessi > Computer Networks and Internet > University of Tuebingen, Germany > Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 > EMail: ali.fessi@uni-tuebingen.de > Web: http://net.informatik.uni-tuebingen.de/~fessi/ >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 05:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtMZ-0002sk-81; Wed, 07 Mar 2007 05:27:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtMX-0002sT-Ts for nsis@ietf.org; Wed, 07 Mar 2007 05:27:14 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOtMV-0007jm-Cq for nsis@ietf.org; Wed, 07 Mar 2007 05:27:13 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l27AR5vW002739 for ; Wed, 7 Mar 2007 10:27:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-12.txt Date: Wed, 7 Mar 2007 10:27:04 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-12.txt Thread-Index: AcdcQ3PLgor+/m7cSR+0Nok7IauxAgEXwswg References: From: "Hancock, Robert" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org folks, in case you haven't noticed, GIST v12 is now available. this version is supposed to take account of the last set of IESG review comments; you can find the details in the change log (section E.1) at the end. a fair proportion of the changes are clarifications of protocol operation,=20 fixes for comprehensibility or addition of design rationale or explanation of underlying concepts. there are also some real protocol changes (which are highlighted at the start of the change log), most/all of which follow mailing list discussions or meeting discussions or both. please take a=20 look at least at those parts and see what you think.=20 my understanding is that magnus wants to send this document round the WGLC process again, but I don't know when john/martin plan to do that. cheers, robert h.=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 01 March 2007 20:50 > To: i-d-announce@ietf.org > Cc: nsis@ietf.org > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-12.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Next Steps in Signaling=20 > Working Group of the IETF. >=20 > Title : GIST: General Internet Signalling Transport > Author(s) : H. Schulzrinne, R. Hancock > Filename : draft-ietf-nsis-ntlp-12.txt > Pages : 173 > Date : 2007-3-1 > =09 > This document specifies protocol stacks for the routing and transport > of per-flow signalling messages along the path taken by that flow > through the network. The design uses existing transport=20 > and security > protocols under a common messaging layer, the General Internet > Signalling Transport (GIST), which provides a common service for > diverse signalling applications. GIST does not handle signalling > application state itself, but manages its own internal=20 > state and the > configuration of the underlying transport and security protocols to > enable the transfer of messages in both directions along the flow > path. The combination of GIST and the lower layer transport and > security protocols provides a solution for the base protocol > component of the "Next Steps in Signalling" framework. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-nsis-ntlp-12.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-ntlp-12.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 10:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxfH-0000w2-BK; Wed, 07 Mar 2007 10:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxfF-0000vx-Kb for nsis@ietf.org; Wed, 07 Mar 2007 10:02:49 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOxfD-0006ci-9E for nsis@ietf.org; Wed, 07 Mar 2007 10:02:49 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C348213CF81 for ; Wed, 7 Mar 2007 16:02:46 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <228D6060-6C3F-4492-87B1-C590845FAB9C@netlab.nec.de> References: <228D6060-6C3F-4492-87B1-C590845FAB9C@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A0273C0-976C-4E96-84FC-39519BE4268E@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NSIS Agenda for IETF 68 Date: Wed, 7 Mar 2007 16:02:45 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Until now I have only received two requests for a slot for the WG items (QoS NSLP and NATFW NSLP). How about the other WG items? (Mobility, GIST, Tunnel, etc) The deadline for uploading agendas is today... Thanks, Martin Am 04.03.2007 um 22:05 schrieb Martin Stiemerling: > Hi all, > > If you are interested in having a slot at the NSIS meeting at the > IETF, please send the following information: > > Draft name > Presenter's name > Time slot needed. > > As we are behind with all our milestones, time slots will be > granted for WG items only. Any non-WG item will only be presented > if time permits, i.e., after the WG items have been presented. > > Thanks, > > Martin > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 10:06:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxif-00037g-RX; Wed, 07 Mar 2007 10:06:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxie-00037b-T8 for nsis@ietf.org; Wed, 07 Mar 2007 10:06:20 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOxic-00078j-BH for nsis@ietf.org; Wed, 07 Mar 2007 10:06:20 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EC42013CF81; Wed, 7 Mar 2007 16:06:17 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94A294BB-CB4C-44C7-ABC5-E8B495A75F35@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST D-mode encapsulation and transparency issues Date: Wed, 7 Mar 2007 16:06:17 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Sorry for being late with my answer. Howerver, here we go! >>> >>> For IPv4, for a Q-mode packet: >>> the IP-Protocol field MUST = UDP >>> the destination port for UDP MUST = GIST there MAY be arbitrary IP >>> options the RAO MUST be included by the sender, but a node >> MAY decide >>> to intercept packets purely on protocol/port number analysis and so >>> intercept a packet even if the RAO is not present. (This is >> left open >>> this way to allow the possibility that to mitigate IP >> option problems >>> with firewalls, we might allow Q-mode without the RAO in the future. >>> This is part of the separate discussion on RAO handling in general.) >> >> Ok. Should we say for "MAY decide to" the possible >> consequences, i.e., intercepting non-GIST traffic using UDP >> with the GIST port number? > > that aspect will be in the final writeup for the spec, but I didn't > want to get into it here. Ok, fine with me. > >> >>> >>> For IPv6, for a Q-mode packet: >>> the next-header field MUST either be UDP, or some combination of >>> routing/hop-by-hop options/destination options followed by UDP >>> the destination port for UDP MUST = GIST >> >> How about this slightly changed text: >> >> the next-header field of the RAO extended header MUST either be UDP, >> or some combination of IPv6 extension headers followed by UDP >> and the destination port for UDP MUST = GIST > > NO NO NO NO NO NO (repeat ad nauseam) > > the problem with IPv6 is that the term 'extension header' covers a > whole > kitchen sink-full of additional protocols, most of which are *not* > compatible with Q-mode (for example, AH, which is the cause of the > original question, and ESP). of the next header field values allocated > by IANA, i believe that only rtg/hbh/dest are meaningful here. Ok, I see my fault here, i.e., you are right the term 'extension header' covers too much. > > (note that there are some values apparently in the wild which are not > IANA-managed; for example, 135 for a mobility header defined by MIPv6. > unfortunately, the MIPv6 RFC refers to a non-existent appendix for > an explanation of what the mobility header is for, so it's hard to > judge whether it could meaningfully be used in Q-mode, but for now > I assume not.) > >> >> >>> the RAO MUST be included by the sender, and it is RECOMMENDED that a >>> node bases its initial interception decision purely on the >> presence of >>> the RAO without analysing the header chain. >> >> (caution nit picker ahead :-) >> "analysing the header chain" is probably too strong, as somebody >> could >> read it "as do not even read" the header chain. A node must anyway >> analyse >> the header chain for getting to the RAO. How about "without >> analysing >> the >> single extension headers of the header chain"? > > or even: > it is RECOMMENDED that a node bases its initial interception decision > purely on the presence of a hop-by-hop option header, which will be > at the start of the header chain, containing the RAO. Ok, sounds good to me. > >> >>> >>> for either IP version: >>> >>> packets not matching the above criteria MUST be transparently >>> forwarded >>> (at a router) or locally delivered as normal traffic (at a host). No >>> other packets are GIST packets; this includes IP-in-IP tunnelled >>> packets, other tunnelled packets (tunnel mode AH/ESP), or packets >>> which >>> have undergone some additional transport layer processing (transport >>> mode AH/ESP). If IP output processing at a node causes such >> additional >>> encapsulations to be added to a GIST Q-mode packet, this packet >>> will not >>> be identified as GIST until the encapsulation is >> terminated. If the >>> node >>> wishes to signal for data over the network region where the >>> encapsulation applies, it MUST generate additional >> signalling with an >>> MRI matching the encapsulated traffic and outbound GIST >> Q-mode message >>> MUST bypass the encapsulation processing. >> >> Fine with me! >> >>> >>> in general, IP options processing is intended to be carried out >>> independently of GIST processing. On packets transmitted by GIST, IP >>> options MAY be added according to node-local policies on outgoing IP >>> data. On packets forwarded by GIST (without NSLP processing), IP >>> options >>> MUST be processed as for a normally forwarded IP packet. >> >> I fail to get the real meaning of the last sentence. I assume the >> difference is in the words "transmitted" in the first part and >> "forwarded" in the second part. Transmitted refers to "initiated by >> GIST" and "forwarded" as just reach through, i.e., touched by GIST >> but not handled on this node for whatever reason. > > OK: maybe 'transmitted' --> 'originated'. Is that clearer? Yes, much more clearer! Thanks!!! Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 11:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyk6-0001Kk-8t; Wed, 07 Mar 2007 11:11:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyjp-0000qL-3l; Wed, 07 Mar 2007 11:11:37 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOyjo-0006Ig-MU; Wed, 07 Mar 2007 11:11:37 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 70DD3176B0; Wed, 7 Mar 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOyOw-0006TI-5f; Wed, 07 Mar 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-tunnel-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSIS Operation Over IP Tunnels Author(s) : C. Shen, et al. Filename : draft-ietf-nsis-tunnel-02.txt Pages : 33 Date : 2007-3-7 This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-tunnel-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-tunnel-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: <2007-3-7085619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-tunnel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-tunnel-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7085619.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Mar 07 12:43:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP0A3-0003pY-Ad; Wed, 07 Mar 2007 12:42:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP0A2-0003pP-7U for nsis@ietf.org; Wed, 07 Mar 2007 12:42:46 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP0A0-0002jz-P8 for nsis@ietf.org; Wed, 07 Mar 2007 12:42:46 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27HgaET008659; Wed, 7 Mar 2007 19:42:42 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 19:42:33 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 11:42:10 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS Agenda for IETF 68 Date: Wed, 7 Mar 2007 11:42:10 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F472C41@daebe103.NOE.Nokia.com> In-Reply-To: <228D6060-6C3F-4492-87B1-C590845FAB9C@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Agenda for IETF 68 Thread-Index: AcdeoUCj1qnN+DxpRGejKcBg//1CNACPpekw References: <228D6060-6C3F-4492-87B1-C590845FAB9C@netlab.nec.de> From: To: , X-OriginalArrivalTime: 07 Mar 2007 17:42:11.0030 (UTC) FILETIME=[EF312F60:01C760DF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070307194242-1DC3ABB0-42ED8A32/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Just as an FYI to the WG. Due to some personal conflicts, I cannot make the IETF 68, so Martin will run the meeting solo. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 15:01:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2JN-0004CI-2E; Wed, 07 Mar 2007 15:00:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2JM-0004CA-8V for nsis@ietf.org; Wed, 07 Mar 2007 15:00:32 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP2JK-0003LQ-Jc for nsis@ietf.org; Wed, 07 Mar 2007 15:00:32 -0500 Received: from [192.168.178.25] (mnhm-590c0bf4.pool.einsundeins.de [89.12.11.244]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C77D013CF81; Wed, 7 Mar 2007 21:00:27 +0100 (CET) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8237@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA0DDC8237@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <014AAE67-4AF3-4926-87A8-3B98A894760F@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Date: Wed, 7 Mar 2007 21:00:26 +0100 To: "ASH, GERALD R (JERRY), ATTLABS" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Can you submit an updated version of the QSPEC fixing those two glitches after the WGLC has ended and all comments have been handled? Thanks, Martin Am 26.02.2007 um 18:36 schrieb ASH, GERALD R (JERRY), ATTLABS: > Hi All, > > We caught another editing glitch in Section 8 (IANA Considerations) of > the QSPEC document > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt, > which > defines the registry for QSPEC parameters as follows: > > " Parameter ID (12 bits): > The following values are allocated by this specification: > 1-14: assigned as specified in Section 6.2: > Parameter ID 1: > 2: > ... > > The allocation policies for further values are as follows: > 15-63: Standards Action (for QSPEC parameters) > 64-127: Specification Required (for QSPEC parameters) > 128-255: Private/Experimental Use > 255-4095: Reserved > > A specification is required to depreciate, delete, or modify > Parameter IDs. Note that if additional QSPEC parameters are > defined in the future, this requires a standards action > equivalent to > reissuing this document as a QSPEC-bis." > > Prior to our eliminating QSPEC-1 ('mandatory') and QSPEC-2 > ('optional') > parameters this text used to read: > > " The allocation policies for further values are as follows: > 15-63: Standards Action (for QSPEC-1 parameters) > 64-127: Specification Required (for QSPEC-2 parameters) > 128-255: Private/Experimental Use > 255-4095: Reserved > > A specification is required to depreciate, delete, or modify > Parameter IDs. Note that if additional QSPEC-1 parameters are > defined in the future, this requires a standards action > equivalent to > reissuing this document as a QSPEC-bis." > > Rather this text should now say: > > " The allocation policies for further values are as follows: > 15-127: Specification Required > 128-255: Private/Experimental Use > 255-4095: Reserved > > A specification is required to depreciate, delete, or modify > Parameter IDs." > > Note also that all that is required is a specification document (not a > QOSM specification document) to define new QSPEC parameters in the > registry. So the text in Section 5.4 (QSPEC Extensibility) needs > to be > modified accordingly. > > Thanks, > Jerry > > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: Tuesday, February 20, 2007 12:38 PM > To: nsis > Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt > > Hi all, > > The WGLC is actually running until March 6th and not Feb 6th. > > Sorry for the confusion > > Martin > > Am 20.02.2007 um 15:54 schrieb Martin Stiemerling: > >> Dear all, >> >> I would like to start the working group last call for the QSPEC draft >> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). >> >> The WGLC is starting today and will run for two weeks until Tuesday >> Feb 6th. >> >> Please send your comments to the NSIS WG list. >> >> Martin >> >> Anfang der weitergeleiteten E-Mail: >> >>> Von: >>> Datum: 16. Februar 2007 21:50:02 MEZ >>> An: >>> Kopie: >>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Next Steps in Signaling Working >>> Group of the IETF. >>> >>> Title : QoS NSLP QSPEC Template >>> Author(s) : J. Ash, et al. >>> Filename : draft-ietf-nsis-qspec-15.txt >>> Pages : 54 >>> Date : 2007-2-16 >>> >>> The QoS NSLP protocol is used to signal QoS reservations and is >>> independent of a specific QoS model (QOSM) such as IntServ or >>> DiffServ. Rather, all information specific to a QOSM is >>> encapsulated >>> in a separate object, the QSPEC. This document defines a template >>> for the QSPEC including a number of QSPEC parameters. The QSPEC >>> parameters provide a common language to be re-used in several >>> QOSMs >>> and thereby aim to ensure the extensibility and >>> interoperability of >>> QoS NSLP. The node initiating the NSIS signaling adds an >>> initiator >>> QSPEC, which indicates the QSPEC parameters that must be >>> interpreted >>> by the downstream nodes less the reservation fails, thereby >>> ensuring >>> the intention of the NSIS initiator is preserved along the >>> signaling path. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 15:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2gL-0006hm-V6; Wed, 07 Mar 2007 15:24:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2gK-0006hh-Jk for nsis@ietf.org; Wed, 07 Mar 2007 15:24:16 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP2gJ-0001DG-0H for nsis@ietf.org; Wed, 07 Mar 2007 15:24:16 -0500 Received: from [192.168.178.25] (mnhm-590c0bf4.pool.einsundeins.de [89.12.11.244]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2725813CF81 for ; Wed, 7 Mar 2007 21:24:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Date: Wed, 7 Mar 2007 21:24:11 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I have found an editorial nit in Section 6.1 General QSPEC Formats. On page 28, after the Common QSPEC Header figure it says still QOSM ID instead of QSPEC type. Martin Am 20.02.2007 um 15:54 schrieb Martin Stiemerling: > Dear all, > > I would like to start the working group last call for the QSPEC draft > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > The WGLC is starting today and will run for two weeks until Tuesday > Feb 6th. > > Please send your comments to the NSIS WG list. > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: >> Datum: 16. Februar 2007 21:50:02 MEZ >> An: >> Kopie: >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Next Steps in Signaling Working >> Group of the IETF. >> >> Title : QoS NSLP QSPEC Template >> Author(s) : J. Ash, et al. >> Filename : draft-ietf-nsis-qspec-15.txt >> Pages : 54 >> Date : 2007-2-16 >> >> The QoS NSLP protocol is used to signal QoS reservations and is >> independent of a specific QoS model (QOSM) such as IntServ or >> DiffServ. Rather, all information specific to a QOSM is >> encapsulated >> in a separate object, the QSPEC. This document defines a template >> for the QSPEC including a number of QSPEC parameters. The QSPEC >> parameters provide a common language to be re-used in several >> QOSMs >> and thereby aim to ensure the extensibility and >> interoperability of >> QoS NSLP. The node initiating the NSIS signaling adds an >> initiator >> QSPEC, which indicates the QSPEC parameters that must be >> interpreted >> by the downstream nodes less the reservation fails, thereby >> ensuring >> the intention of the NSIS initiator is preserved along the >> signaling >> path. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> 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-qspec-15.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-qspec-15.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. >> >> >> > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 15:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36Y-0002z5-M3; Wed, 07 Mar 2007 15:51:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35P-0001OH-1Q; Wed, 07 Mar 2007 15:50:11 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35M-0001QY-0I; Wed, 07 Mar 2007 15:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8A83C32AB4; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35H-00031y-Dp; Wed, 07 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-statemachine-03.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST State Machine Author(s) : H. Tschofenig, et al. Filename : draft-ietf-nsis-ntlp-statemachine-03.txt,.pdf Pages : 24 Date : 2007-3-7 This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ntlp-statemachine-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7141806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-statemachine-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7141806.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Mar 07 17:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP4sR-0000tz-HI; Wed, 07 Mar 2007 17:44:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36j-0003bQ-8V; Wed, 07 Mar 2007 15:51:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP36i-0007ah-Ri; Wed, 07 Mar 2007 15:51:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 545B417803; Wed, 7 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35I-00033B-27; Wed, 07 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-14.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-14.txt Pages : 100 Date : 2007-3-7 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-nslp-natfw-14.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-nslp-natfw-14.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: <2007-3-7144430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7144430.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Mar 07 17:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP4sk-0001Lk-6v; Wed, 07 Mar 2007 17:45:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP3A1-0006yt-8E for nsis@ietf.org; Wed, 07 Mar 2007 15:54:57 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP39e-0008W4-Er for nsis@ietf.org; Wed, 07 Mar 2007 15:54:56 -0500 Received: from [192.168.178.25] (mnhm-590c0bf4.pool.einsundeins.de [89.12.11.244]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 480D413CF81; Wed, 7 Mar 2007 21:54:31 +0100 (CET) In-Reply-To: <000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com> <000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Wed, 7 Mar 2007 21:54:29 +0100 To: Georgios Karagiannis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios and Jerry, I'm trying to understand what the issue is, so please correct me when I'm wrong! I believe that the QOSM ID is not needed as there is only one local RMF per QNE. This local RMF can actually support multiple QOSMs but this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the chance to pass the QSPEC in a single piece to a single RMF. The mapping between the different initiator QOSM and the local QOSM is solely happening within the RMF. Thanks, Martin Am 02.03.2007 um 11:19 schrieb Georgios Karagiannis: > Hi Jerry > > The main goal of using the QOS-NSLP messages is to > carry a QSPEC object and deliver it to the right QOSM/RMF. > > If a QNE will support simultaneously more than one QOS models, say > QOSM-I1, > QOSM-I2, > and a QoS-NSLP message, which carries a QSPEC that is say > associated with > QOSM-I1, > arrives at a QNE, then the QNE must be able to deliver > the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. > > How the QNE will know to which RMF it should deliver the received > QSPEC? > > Best regards, > Georgios > > > > >> -----Original Message----- >> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >> Sent: donderdag 1 maart 2007 23:49 >> To: Georgios Karagiannis; Martin Stiemerling; nsis >> Cc: ASH, GERALD R, ATTLABS >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> Georgios, >> >> Your examples don't illustrate how and why a QOSM ID field is >> needed and used. >> >> Perhaps you are saying that QoS NSLP and RMF communicate with >> messages and that the I-QOSM ID and L-QOSM ID need to be >> included in those messages so that the QoS NSLP can react >> differently based on which L-QOSM is being used by the RMF? >> >> If so, then this interaction suffers from the problems >> identified in Cornelia's slide (attached) discussed on our >> conference call on 31 January. >> >> If not, please give a more detailed example of how and why a >> QOSM ID field is needed and used. >> >> Jerry >> >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Thursday, March 01, 2007 11:11 AM >> To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> Hi Jerry >> >> The need for the QOSM ID can be seen probably seen in the >> below e-mail: >> >> Suppose that: >> >> A QNE supports the following: >> >> * end-to-end QOS Models: >> QOSMI-1, QOSMI-2, QOSMI-3 >> >> * local QoS Models: >> QOSML-1, QOSML-2, QOSML-3 >> >> Suppose now that the operator of such a QNE wants to use the follwing >> combinations: >> >> * QOSMI-1 with QOSML-3. >> >> Meaning that end-to-end sessions and QOS-NSLP messages that >> are carrying >> >> initial QSPEC of QOSM-I1 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3 >> >> * QOSMI-2 with QOSML-3 >> >> Meaning that end-to-end sessions and QOS-NSLP messages that >> are carrying >> >> initial QSPEC of QOSMI-2 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-3 >> >> * QOSMI-3 with QOSML-1 >> >> initial QSPEC of QOSMI-3 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-1 >> >> * QOSMI-3 with QOSML-2 >> >> initial QSPEC of QOSMI-3 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2 >> -- >> >> >> If the QOSM ID will not be supported these combinations will >> not beable >> to >> be made meaning that >> A QNE will be able to support only one initial (end-to-end) QOSM with >> only >> one local QOSM at a time. >> >> Best Regards, >> Georgios >> >> >> >> >> >>> -----Original Message----- >>> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >>> Sent: woensdag 28 februari 2007 14:43 >>> To: Georgios Karagiannis; Martin Stiemerling; nsis >>> Cc: ASH, GERALD R, ATTLABS >>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >>> qspec draft >>> >>> Georgios, All, >>> >>>> -----Original Message----- >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>> Sent: Wednesday, February 28, 2007 12:37 AM >>>> To: Martin Stiemerling; nsis >>>> Subject: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >>>> >>>> Hi >>>> >>>> I was busy updating some of the QOSM drafts and I have seen that >>>> starting from version 13 of the QSPEC draft, the QOSM ID >> field is >>>> removed form the common header of a QSPEC object and >>> instead of this, >>>> the field QSPEC type is used. >>> >>> The QSPEC Type was introduced to support Roland's QSPEC >>> stacking/encapsulation method (see >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht >>> ml), it does not replace QOSM ID. >>> >>> The QOSM ID was removed in the discussion around the QSPEC-13 >>> draft update, see the post on 1 November 2006 >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht >>> ml, where it says "A QOSM ID need not be defined or signaled >>> and a QNE need not support any particular QOSM". Slide 3 of >>> the QSPEC presentation at IETF-67 makes the same point. The >>> same point is made again in the announcement of the draft to >>> the NSIS list at >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht >>> ml and the point is also made in Appendix A of the QSPEC >>> draft itself. There were no objections to this point. >>> >>>> I agree that QSPEC type (shows if the QSPEC object is >> initial or a >>>> local) is useful and it should be used, but by removing >> the QOSM ID >>>> field it will mean that a QNE can always support only one type of >>>> initial >>>> (end-to-end) QOSM and one type of local QOSM. >>>> That is not reasonable. A QNE should be able to support >>> many QOSMs and >>>> it should be able to distinguish and associate a QSPEC >>> object with a >>>> certain QOSM. >>> >>> There is no mention in any QSPEC draft as to how or why a >>> QOSM ID field is needed or used. A QNE can support any QOSM >>> it wants, it does not depend on a QOSM ID field from the QNI >>> to determine which one. >>> >>> At a minimum, we would need to have a bit-level example of >>> how/why such a field is needed to justify reintroducing the >>> QOSM ID field. >>> >>>> Therefore, I think that it is required that the QOSM ID >>> field should >>>> be reintroduced in the QSPEC common header. The field >> QSPEC type is >>>> also useful ant it should be kept. >>> >>> We need clear justification to reintroduce the complexity of >>> having the QOSM ID field and the IANA registry to maintain >>> the parameter. >>> >>> Jerry >>> >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> On 2/20/2007, "Martin Stiemerling" >>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> I would like to start the working group last call for the >>> QSPEC draft >>>> >>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). >>>>> >>>>> The WGLC is starting today and will run for two weeks >>> until Tuesday >>>>> Feb 6th. >>>>> >>>>> Please send your comments to the NSIS WG list. >>>>> >>>>> Martin >>>>> >>>>> Anfang der weitergeleiteten E-Mail: >>>>> >>>>>> Von: >>>>>> Datum: 16. Februar 2007 21:50:02 MEZ >>>>>> An: >>>>>> Kopie: >>>>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Next Steps in >> Signaling Working >>>>>> Group of the IETF. >>>>>> >>>>>> Title : QoS NSLP QSPEC Template >>>>>> Author(s) : J. Ash, et al. >>>>>> Filename : draft-ietf-nsis-qspec-15.txt >>>>>> Pages : 54 >>>>>> Date : 2007-2-16 >>>>>> >>>>>> The QoS NSLP protocol is used to signal QoS reservations and is >>>>>> independent of a specific QoS model (QOSM) such as >> IntServ or >>>>>> DiffServ. Rather, all information specific to a QOSM is >>>>>> encapsulated >>>>>> in a separate object, the QSPEC. This document defines >>>> a template >>>>>> for the QSPEC including a number of QSPEC parameters. >>> The QSPEC >>>>>> parameters provide a common language to be re-used in >>>> several QOSMs >>>>>> and thereby aim to ensure the extensibility and >>>> interoperability of >>>>>> QoS NSLP. The node initiating the NSIS signaling adds >>>> an initiator >>>>>> QSPEC, which indicates the QSPEC parameters that must be >>>>>> interpreted >>>>>> by the downstream nodes less the reservation fails, thereby >>>>>> ensuring >>>>>> the intention of the NSIS initiator is preserved along the >>>>>> signaling >>>>>> path. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >>>>>> >>>>>> To remove yourself from the I-D Announcement list, send a >>>> message to >>>>>> i-d-announce-request@ietf.org with the word unsubscribe in >>>> the body of >>>>>> the message. >>>>>> You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>> to change your subscription settings. >>>>>> >>>>>> 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-qspec-15.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-qspec-15.txt". >>>>>> >>>>>> NOTE: The mail server at ietf.org can return the document in >>>>>> MIME-encoded form by using the "mpack" utility. >> To use this >>>>>> feature, insert the command "ENCODING mime" >> before the "FILE" >>>>>> command. To decode the response(s), you will >> need "munpack" or >>>>>> a MIME-compliant mail reader. Different MIME-compliant >>>> mail readers >>>>>> exhibit different behavior, especially when dealing with >>>>>> "multipart" MIME messages (i.e. documents which >> have been split >>>>>> up into multiple messages), so check your local >> documentation on >>>>>> how to manipulate these messages. >>>>>> >>>>>> Below is the data which will enable a MIME compliant >> mail reader >>>>>> implementation to automatically retrieve the ASCII >> version of the >>>>>> Internet-Draft.) >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >> > > stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 18:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5Fj-0001E5-Lo; Wed, 07 Mar 2007 18:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5Fj-0001Du-2t for nsis@ietf.org; Wed, 07 Mar 2007 18:08:59 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP5Fi-0004xT-7Z for nsis@ietf.org; Wed, 07 Mar 2007 18:08:59 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27N8prp010627; Thu, 8 Mar 2007 01:08:52 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 01:08:51 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:08:49 -0600 Received: from 10.241.35.107 ([10.241.35.107]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Mar 2007 23:08:47 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From: "Loughney John \(Nokia-NRC/PaloAlto\)" X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: AcdhDY/DT1O89uHRSda1XzkKllH0xQ== To: "ext Martin Stiemerling" , "Georgios Karagianni s" Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Wed, 7 Mar 2007 23:08:09 -0800 Message-ID: <6421801c7610d$8fc31f02$6b23f10a@NOE.Nokia.com> X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 07 Mar 2007 23:08:49.0728 (UTC) FILETIME=[90ED2C00:01C7610D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070308010852-280CBBB0-37601DB4/1648255411-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 1.2 (+) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Martin That is my understanding as well. If there is some other use and/or = issue, it would be good to get a very precise statement on what is = needed and why. John sent from my Nokia E90. --- original message --- From: "ext Martin Stiemerling" Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: 7th March 2007 Time: 2:45:59 pm Hi Georgios and Jerry, I'm trying to understand what the issue is, so please correct me when =20 I'm wrong! I believe that the QOSM ID is not needed as there is only one local =20 RMF per QNE. This local RMF can actually support multiple QOSMs but =20 this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the =20 chance to pass the QSPEC in a single piece to a single RMF. The mapping between the different initiator QOSM and the local QOSM =20 is solely happening within the RMF. Thanks, Martin Am 02.03.2007 um 11:19 schrieb Georgios Karagiannis: > Hi Jerry > > The main goal of using the QOS-NSLP messages is to > carry a QSPEC object and deliver it to the right QOSM/RMF. > > If a QNE will support simultaneously more than one QOS models, say =20 > QOSM-I1, > QOSM-I2, > and a QoS-NSLP message, which carries a QSPEC that is say =20 > associated with > QOSM-I1, > arrives at a QNE, then the QNE must be able to deliver > the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. > > How the QNE will know to which RMF it should deliver the received =20 > QSPEC? > > Best regards, > Georgios > > > > >> -----Original Message----- >> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >> Sent: donderdag 1 maart 2007 23:49 >> To: Georgios Karagiannis; Martin Stiemerling; nsis >> Cc: ASH, GERALD R, ATTLABS >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> Georgios, >> >> Your examples don't illustrate how and why a QOSM ID field is >> needed and used. >> >> Perhaps you are saying that QoS NSLP and RMF communicate with >> messages and that the I-QOSM ID and L-QOSM ID need to be >> included in those messages so that the QoS NSLP can react >> differently based on which L-QOSM is being used by the RMF? >> >> If so, then this interaction suffers from the problems >> identified in Cornelia's slide (attached) discussed on our >> conference call on 31 January. >> >> If not, please give a more detailed example of how and why a >> QOSM ID field is needed and used. >> >> Jerry >> >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Thursday, March 01, 2007 11:11 AM >> To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >> >> Hi Jerry >> >> The need for the QOSM ID can be seen probably seen in the >> below e-mail: >> >> Suppose that: >> >> A QNE supports the following: >> >> * end-to-end QOS Models: >> QOSMI-1, QOSMI-2, QOSMI-3 >> >> * local QoS Models: >> QOSML-1, QOSML-2, QOSML-3 >> >> Suppose now that the operator of such a QNE wants to use the follwing >> combinations: >> >> * QOSMI-1 with QOSML-3. >> >> Meaning that end-to-end sessions and QOS-NSLP messages that >> are carrying >> >> initial QSPEC of QOSM-I1 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3 >> >> * QOSMI-2 with QOSML-3 >> >> Meaning that end-to-end sessions and QOS-NSLP messages that >> are carrying >> >> initial QSPEC of QOSMI-2 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-3 >> >> * QOSMI-3 with QOSML-1 >> >> initial QSPEC of QOSMI-3 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-1 >> >> * QOSMI-3 with QOSML-2 >> >> initial QSPEC of QOSMI-3 should be bound with local sessions >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2 >> -- >> >> >> If the QOSM ID will not be supported these combinations will >> not beable >> to >> be made meaning that >> A QNE will be able to support only one initial (end-to-end) QOSM with >> only >> one local QOSM at a time. >> >> Best Regards, >> Georgios >> >> >> >> >> >>> -----Original Message----- >>> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >>> Sent: woensdag 28 februari 2007 14:43 >>> To: Georgios Karagiannis; Martin Stiemerling; nsis >>> Cc: ASH, GERALD R, ATTLABS >>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >>> qspec draft >>> >>> Georgios, All, >>> >>>> -----Original Message----- >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>> Sent: Wednesday, February 28, 2007 12:37 AM >>>> To: Martin Stiemerling; nsis >>>> Subject: [NSIS] comment on reintroduction of QOSM-ID in >> qspec draft >>>> >>>> Hi >>>> >>>> I was busy updating some of the QOSM drafts and I have seen that >>>> starting from version 13 of the QSPEC draft, the QOSM ID >> field is >>>> removed form the common header of a QSPEC object and >>> instead of this, >>>> the field QSPEC type is used. >>> >>> The QSPEC Type was introduced to support Roland's QSPEC >>> stacking/encapsulation method (see >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht >>> ml), it does not replace QOSM ID. >>> >>> The QOSM ID was removed in the discussion around the QSPEC-13 >>> draft update, see the post on 1 November 2006 >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht >>> ml, where it says "A QOSM ID need not be defined or signaled >>> and a QNE need not support any particular QOSM". Slide 3 of >>> the QSPEC presentation at IETF-67 makes the same point. The >>> same point is made again in the announcement of the draft to >>> the NSIS list at >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht >>> ml and the point is also made in Appendix A of the QSPEC >>> draft itself. There were no objections to this point. >>> >>>> I agree that QSPEC type (shows if the QSPEC object is >> initial or a >>>> local) is useful and it should be used, but by removing >> the QOSM ID >>>> field it will mean that a QNE can always support only one type of >>>> initial >>>> (end-to-end) QOSM and one type of local QOSM. >>>> That is not reasonable. A QNE should be able to support >>> many QOSMs and >>>> it should be able to distinguish and associate a QSPEC >>> object with a >>>> certain QOSM. >>> >>> There is no mention in any QSPEC draft as to how or why a >>> QOSM ID field is needed or used. A QNE can support any QOSM >>> it wants, it does not depend on a QOSM ID field from the QNI >>> to determine which one. >>> >>> At a minimum, we would need to have a bit-level example of >>> how/why such a field is needed to justify reintroducing the >>> QOSM ID field. >>> >>>> Therefore, I think that it is required that the QOSM ID >>> field should >>>> be reintroduced in the QSPEC common header. The field >> QSPEC type is >>>> also useful ant it should be kept. >>> >>> We need clear justification to reintroduce the complexity of >>> having the QOSM ID field and the IANA registry to maintain >>> the parameter. >>> >>> Jerry >>> >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> On 2/20/2007, "Martin Stiemerling" >>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> I would like to start the working group last call for the >>> QSPEC draft >>>> >>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). >>>>> >>>>> The WGLC is starting today and will run for two weeks >>> until Tuesday >>>>> Feb 6th. >>>>> >>>>> Please send your comments to the NSIS WG list. >>>>> >>>>> Martin >>>>> >>>>> Anfang der weitergeleiteten E-Mail: >>>>> >>>>>> Von: >>>>>> Datum: 16. Februar 2007 21:50:02 MEZ >>>>>> An: >>>>>> Kopie: >>>>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Next Steps in >> Signaling Working >>>>>> Group of the IETF. >>>>>> >>>>>> Title : QoS NSLP QSPEC Template >>>>>> Author(s) : J. Ash, et al. >>>>>> Filename : draft-ietf-nsis-qspec-15.txt >>>>>> Pages : 54 >>>>>> Date : 2007-2-16 >>>>>> >>>>>> The QoS NSLP protocol is used to signal QoS reservations and is >>>>>> independent of a specific QoS model (QOSM) such as >> IntServ or >>>>>> DiffServ. Rather, all information specific to a QOSM is >>>>>> encapsulated >>>>>> in a separate object, the QSPEC. This document defines >>>> a template >>>>>> for the QSPEC including a number of QSPEC parameters. >>> The QSPEC >>>>>> parameters provide a common language to be re-used in >>>> several QOSMs >>>>>> and thereby aim to ensure the extensibility and >>>> interoperability of >>>>>> QoS NSLP. The node initiating the NSIS signaling adds >>>> an initiator >>>>>> QSPEC, which indicates the QSPEC parameters that must be >>>>>> interpreted >>>>>> by the downstream nodes less the reservation fails, thereby >>>>>> ensuring >>>>>> the intention of the NSIS initiator is preserved along the >>>>>> signaling >>>>>> path. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >>>>>> >>>>>> To remove yourself from the I-D Announcement list, send a >>>> message to >>>>>> i-d-announce-request@ietf.org with the word unsubscribe in >>>> the body of >>>>>> the message. >>>>>> You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>> to change your subscription settings. >>>>>> >>>>>> 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-qspec-15.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-qspec-15.txt". >>>>>> >>>>>> NOTE: The mail server at ietf.org can return the document in >>>>>> MIME-encoded form by using the "mpack" utility. >> To use this >>>>>> feature, insert the command "ENCODING mime" >> before the "FILE" >>>>>> command. To decode the response(s), you will >> need "munpack" or >>>>>> a MIME-compliant mail reader. Different MIME-compliant >>>> mail readers >>>>>> exhibit different behavior, especially when dealing with >>>>>> "multipart" MIME messages (i.e. documents which >> have been split >>>>>> up into multiple messages), so check your local >> documentation on >>>>>> how to manipulate these messages. >>>>>> >>>>>> Below is the data which will enable a MIME compliant >> mail reader >>>>>> implementation to automatically retrieve the ASCII >> version of the >>>>>> Internet-Draft.) >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >> > > stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 18:39:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5i3-0005fc-UZ; Wed, 07 Mar 2007 18:38:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5i3-0005e2-0K for nsis@ietf.org; Wed, 07 Mar 2007 18:38:15 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HP5hq-0001JP-6Q for nsis@ietf.org; Wed, 07 Mar 2007 18:38:14 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1173310681!11124731!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1089 invoked from network); 7 Mar 2007 23:38:01 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-146.messagelabs.com with SMTP; 7 Mar 2007 23:38:01 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l27Nc1fD025178; Wed, 7 Mar 2007 18:38:01 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l27NbsVb025152; Wed, 7 Mar 2007 18:37:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Wed, 7 Mar 2007 17:37:08 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82AD@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Thread-Index: AcdhCmE6A3PjDvEQTUWdsBu919l+HQAAj9vw References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com><000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com><000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> From: "ASH, GERALD R, ATTLABS" To: "Martin Stiemerling" , "Georgios Karagiannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "ASH, GERALD R, ATTLABS" , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin,=20 > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: Wednesday, March 07, 2007 3:54 PM > To: Georgios Karagiannis > Cc: ASH, GERALD R, ATTLABS; 'nsis' > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in=20 > qspec draft >=20 > Hi Georgios and Jerry, >=20 > I'm trying to understand what the issue is, so please correct=20 > me when I'm wrong! >=20 > I believe that the QOSM ID is not needed as there is only one local =20 > RMF per QNE. This local RMF can actually support multiple QOSMs but =20 > this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the =20 > chance to pass the QSPEC in a single piece to a single RMF. > The mapping between the different initiator QOSM and the local QOSM =20 > is solely happening within the RMF. I agree. =20 In addition, we have defined the QSPEC Type parameter. As specified in Section 8 (IANA Considerations), additional QSPEC Types can be defined, if need be, through Standards action. For example, if an RMD-QSPEC Type needs to be defined, that could be done in a separate document (e.g., the RMD-QOSM specification draft). The specification should clearly describe, with bit-level examples, how exactly the QSPEC Type parameter is going to be used.=20 Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 18:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5tY-00041v-F4; Wed, 07 Mar 2007 18:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5tT-000404-5W; Wed, 07 Mar 2007 18:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP5tS-0003XY-PW; Wed, 07 Mar 2007 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 99A4326ECC; Wed, 7 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP5tS-0003qy-GL; Wed, 07 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-applicability-mobility-signaling-06.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : S. Lee, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-06.txt Pages : 56 Date : 2007-3-7 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suit, and how the protocols operate in different scenarios, with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-applicability-mobility-signaling-06.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-applicability-mobility-signaling-06.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: <2007-3-7154956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7154956.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Mar 07 19:33:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP6Z4-0005Ep-H4; Wed, 07 Mar 2007 19:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP54h-0006WR-5L for nsis@ietf.org; Wed, 07 Mar 2007 17:57:35 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3XQ-0005Ad-2B for nsis@ietf.org; Wed, 07 Mar 2007 16:19:11 -0500 Received: from [192.168.178.25] (mnhm-590c0bf4.pool.einsundeins.de [89.12.11.244]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E977313CF81; Wed, 7 Mar 2007 22:19:06 +0100 (CET) In-Reply-To: References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com> <000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com> <000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39E1188C-CA4C-4D4E-ABB7-CC1BC8E56EF0@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Wed, 7 Mar 2007 22:19:05 +0100 To: Martin Stiemerling X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: "'ASH, GERALD R, ATTLABS'" , Georgios Karagiannis , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, please ignore my last email, I've hit the send button too fast before noticing the rest of the thread. Martin Am 07.03.2007 um 21:54 schrieb Martin Stiemerling: > Hi Georgios and Jerry, > > I'm trying to understand what the issue is, so please correct me > when I'm wrong! > > I believe that the QOSM ID is not needed as there is only one local > RMF per QNE. This local RMF can actually support multiple QOSMs but > this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the > chance to pass the QSPEC in a single piece to a single RMF. > The mapping between the different initiator QOSM and the local QOSM > is solely happening within the RMF. > > Thanks, > > Martin > > Am 02.03.2007 um 11:19 schrieb Georgios Karagiannis: > >> Hi Jerry >> >> The main goal of using the QOS-NSLP messages is to >> carry a QSPEC object and deliver it to the right QOSM/RMF. >> >> If a QNE will support simultaneously more than one QOS models, say >> QOSM-I1, >> QOSM-I2, >> and a QoS-NSLP message, which carries a QSPEC that is say >> associated with >> QOSM-I1, >> arrives at a QNE, then the QNE must be able to deliver >> the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. >> >> How the QNE will know to which RMF it should deliver the received >> QSPEC? >> >> Best regards, >> Georgios >> >> >> >> >>> -----Original Message----- >>> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >>> Sent: donderdag 1 maart 2007 23:49 >>> To: Georgios Karagiannis; Martin Stiemerling; nsis >>> Cc: ASH, GERALD R, ATTLABS >>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >>> qspec draft >>> >>> Georgios, >>> >>> Your examples don't illustrate how and why a QOSM ID field is >>> needed and used. >>> >>> Perhaps you are saying that QoS NSLP and RMF communicate with >>> messages and that the I-QOSM ID and L-QOSM ID need to be >>> included in those messages so that the QoS NSLP can react >>> differently based on which L-QOSM is being used by the RMF? >>> >>> If so, then this interaction suffers from the problems >>> identified in Cornelia's slide (attached) discussed on our >>> conference call on 31 January. >>> >>> If not, please give a more detailed example of how and why a >>> QOSM ID field is needed and used. >>> >>> Jerry >>> >>> -----Original Message----- >>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> Sent: Thursday, March 01, 2007 11:11 AM >>> To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' >>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >>> qspec draft >>> >>> Hi Jerry >>> >>> The need for the QOSM ID can be seen probably seen in the >>> below e-mail: >>> >>> Suppose that: >>> >>> A QNE supports the following: >>> >>> * end-to-end QOS Models: >>> QOSMI-1, QOSMI-2, QOSMI-3 >>> >>> * local QoS Models: >>> QOSML-1, QOSML-2, QOSML-3 >>> >>> Suppose now that the operator of such a QNE wants to use the >>> follwing >>> combinations: >>> >>> * QOSMI-1 with QOSML-3. >>> >>> Meaning that end-to-end sessions and QOS-NSLP messages that >>> are carrying >>> >>> initial QSPEC of QOSM-I1 should be bound with local sessions >>> and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3 >>> >>> * QOSMI-2 with QOSML-3 >>> >>> Meaning that end-to-end sessions and QOS-NSLP messages that >>> are carrying >>> >>> initial QSPEC of QOSMI-2 should be bound with local sessions >>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-3 >>> >>> * QOSMI-3 with QOSML-1 >>> >>> initial QSPEC of QOSMI-3 should be bound with local sessions >>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-1 >>> >>> * QOSMI-3 with QOSML-2 >>> >>> initial QSPEC of QOSMI-3 should be bound with local sessions >>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2 >>> -- >>> >>> >>> If the QOSM ID will not be supported these combinations will >>> not beable >>> to >>> be made meaning that >>> A QNE will be able to support only one initial (end-to-end) QOSM >>> with >>> only >>> one local QOSM at a time. >>> >>> Best Regards, >>> Georgios >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >>>> Sent: woensdag 28 februari 2007 14:43 >>>> To: Georgios Karagiannis; Martin Stiemerling; nsis >>>> Cc: ASH, GERALD R, ATTLABS >>>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in >>>> qspec draft >>>> >>>> Georgios, All, >>>> >>>>> -----Original Message----- >>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>> Sent: Wednesday, February 28, 2007 12:37 AM >>>>> To: Martin Stiemerling; nsis >>>>> Subject: [NSIS] comment on reintroduction of QOSM-ID in >>> qspec draft >>>>> >>>>> Hi >>>>> >>>>> I was busy updating some of the QOSM drafts and I have seen that >>>>> starting from version 13 of the QSPEC draft, the QOSM ID >>> field is >>>>> removed form the common header of a QSPEC object and >>>> instead of this, >>>>> the field QSPEC type is used. >>>> >>>> The QSPEC Type was introduced to support Roland's QSPEC >>>> stacking/encapsulation method (see >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht >>>> ml), it does not replace QOSM ID. >>>> >>>> The QOSM ID was removed in the discussion around the QSPEC-13 >>>> draft update, see the post on 1 November 2006 >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht >>>> ml, where it says "A QOSM ID need not be defined or signaled >>>> and a QNE need not support any particular QOSM". Slide 3 of >>>> the QSPEC presentation at IETF-67 makes the same point. The >>>> same point is made again in the announcement of the draft to >>>> the NSIS list at >>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht >>>> ml and the point is also made in Appendix A of the QSPEC >>>> draft itself. There were no objections to this point. >>>> >>>>> I agree that QSPEC type (shows if the QSPEC object is >>> initial or a >>>>> local) is useful and it should be used, but by removing >>> the QOSM ID >>>>> field it will mean that a QNE can always support only one type of >>>>> initial >>>>> (end-to-end) QOSM and one type of local QOSM. >>>>> That is not reasonable. A QNE should be able to support >>>> many QOSMs and >>>>> it should be able to distinguish and associate a QSPEC >>>> object with a >>>>> certain QOSM. >>>> >>>> There is no mention in any QSPEC draft as to how or why a >>>> QOSM ID field is needed or used. A QNE can support any QOSM >>>> it wants, it does not depend on a QOSM ID field from the QNI >>>> to determine which one. >>>> >>>> At a minimum, we would need to have a bit-level example of >>>> how/why such a field is needed to justify reintroducing the >>>> QOSM ID field. >>>> >>>>> Therefore, I think that it is required that the QOSM ID >>>> field should >>>>> be reintroduced in the QSPEC common header. The field >>> QSPEC type is >>>>> also useful ant it should be kept. >>>> >>>> We need clear justification to reintroduce the complexity of >>>> having the QOSM ID field and the IANA registry to maintain >>>> the parameter. >>>> >>>> Jerry >>>> >>>>> >>>>> Best regards, >>>>> Georgios >>>>> >>>>> >>>>> On 2/20/2007, "Martin Stiemerling" >>>> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> I would like to start the working group last call for the >>>> QSPEC draft >>>>> >>>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). >>>>>> >>>>>> The WGLC is starting today and will run for two weeks >>>> until Tuesday >>>>>> Feb 6th. >>>>>> >>>>>> Please send your comments to the NSIS WG list. >>>>>> >>>>>> Martin >>>>>> >>>>>> Anfang der weitergeleiteten E-Mail: >>>>>> >>>>>>> Von: >>>>>>> Datum: 16. Februar 2007 21:50:02 MEZ >>>>>>> An: >>>>>>> Kopie: >>>>>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Next Steps in >>> Signaling Working >>>>>>> Group of the IETF. >>>>>>> >>>>>>> Title : QoS NSLP QSPEC Template >>>>>>> Author(s) : J. Ash, et al. >>>>>>> Filename : draft-ietf-nsis-qspec-15.txt >>>>>>> Pages : 54 >>>>>>> Date : 2007-2-16 >>>>>>> >>>>>>> The QoS NSLP protocol is used to signal QoS reservations and is >>>>>>> independent of a specific QoS model (QOSM) such as >>> IntServ or >>>>>>> DiffServ. Rather, all information specific to a QOSM is >>>>>>> encapsulated >>>>>>> in a separate object, the QSPEC. This document defines >>>>> a template >>>>>>> for the QSPEC including a number of QSPEC parameters. >>>> The QSPEC >>>>>>> parameters provide a common language to be re-used in >>>>> several QOSMs >>>>>>> and thereby aim to ensure the extensibility and >>>>> interoperability of >>>>>>> QoS NSLP. The node initiating the NSIS signaling adds >>>>> an initiator >>>>>>> QSPEC, which indicates the QSPEC parameters that must be >>>>>>> interpreted >>>>>>> by the downstream nodes less the reservation fails, thereby >>>>>>> ensuring >>>>>>> the intention of the NSIS initiator is preserved along the >>>>>>> signaling >>>>>>> path. >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >>>>>>> >>>>>>> To remove yourself from the I-D Announcement list, send a >>>>> message to >>>>>>> i-d-announce-request@ietf.org with the word unsubscribe in >>>>> the body of >>>>>>> the message. >>>>>>> You can also visit >>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>>> to change your subscription settings. >>>>>>> >>>>>>> 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-qspec-15.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-qspec-15.txt". >>>>>>> >>>>>>> NOTE: The mail server at ietf.org can return the document in >>>>>>> MIME-encoded form by using the "mpack" utility. >>> To use this >>>>>>> feature, insert the command "ENCODING mime" >>> before the "FILE" >>>>>>> command. To decode the response(s), you will >>> need "munpack" or >>>>>>> a MIME-compliant mail reader. Different MIME-compliant >>>>> mail readers >>>>>>> exhibit different behavior, especially when dealing with >>>>>>> "multipart" MIME messages (i.e. documents which >>> have been split >>>>>>> up into multiple messages), so check your local >>> documentation on >>>>>>> how to manipulate these messages. >>>>>>> >>>>>>> Below is the data which will enable a MIME compliant >>> mail reader >>>>>>> implementation to automatically retrieve the ASCII >>> version of the >>>>>>> Internet-Draft.) >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> >>> >>> >>> >> >> > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 07 20:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP713-0007Lx-HN; Wed, 07 Mar 2007 20:01:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP4wN-0006jP-Jt for nsis@ietf.org; Wed, 07 Mar 2007 17:48:59 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP3GQ-0001hw-Q2 for nsis@ietf.org; Wed, 07 Mar 2007 16:02:30 -0500 Received: from [192.168.178.25] (mnhm-590c0bf4.pool.einsundeins.de [89.12.11.244]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EBF3C13CF81; Wed, 7 Mar 2007 22:01:33 +0100 (CET) In-Reply-To: References: <45E6ECA1.1030002@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <997EFFDE-8132-4AAA-AB99-ADE20D500C6A@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST authorisation Date: Wed, 7 Mar 2007 22:01:32 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali and Robert, The proposed text looks fine for me and ... >>> >>> If authorisation is allowed, the MA can be used as >> normal; otherwise >>> it MUST be torn down without further GIST exchanges, and >> any routing >>> state associated with the MA MUST also be deleted. An error >>> condition MAY be logged locally. When an APD entry is >> modified or >>> deleted, the node MUST re-validate existing MAs and the >> routing state >>> table against the revised contents of the APD. This may >> result in >>> MAs being torn down or routing state entries being >> deleted. These >>> changes SHOULD be indicated to local signalling >> applications via the >>> NetworkNotification API call (Appendix B.4). >>> >>> This specification does not define how the APD is >> populated. As a >>> minimum, an implementation MUST provide an >> administrative interface >>> through which entries can be added, modified, or deleted. >> >> I think up to here, it is fine. The rest is probably not >> needed - at least in this document. It might be too early to >> think of how to populate GIST APDs in the network. But maybe >> in few years, we may think of a "GIST APD Propagation Protocol" ;-) > > i half agree and half disagree. firstly, note that none of the text > below is normative for a GIST implementation - it's just supporting > background. the purpose is to show that, at least in some > circumstances, > populating the APD semi-automatically is feasible. whether it is > worth showing that is maybe another question. I'm in favour of leaving the text as is, because it is a) informative only and b) some more text might be good for implementers. The implementers are probably thankful for some verbose text. Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 08 07:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI5c-0004WM-0T; Thu, 08 Mar 2007 07:51:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI5b-0004WH-0k for nsis@ietf.org; Thu, 08 Mar 2007 07:51:23 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPI5Z-000151-I0 for nsis@ietf.org; Thu, 08 Mar 2007 07:51:23 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l28CpG40029683 for ; Thu, 8 Mar 2007 13:51:20 +0100 (MET) From: "Georgios Karagiannis" To: References: Date: Thu, 8 Mar 2007 13:51:11 +0100 Message-ID: <002501c76180$7600caa0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdfaCZ4NeSIa5bQTzuOsZBobQP/yACF+GoA X-Spam-Score: 0.089 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 08 Mar 2007 13:51:20 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [NSIS] Changes in draft-ietf-nsis-rmd-09.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all Below you can find a list with the RMD-QOSM changes: * Modified the draft according to the last QSPEC discussions ** (M, N, Q, T flags, TMOD vs. Bandwidth, etc.. ** the way of how the partial release is performed is changed * an intra-domain RESPONSE message is used by an Egress to send the RMD-QSPEC towards the Ingress during the initial reservation. * emphasized that the triggers between QOS-NSLP and RMF/QOSM have to be used * editorials Best regards, Georgios > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: maandag 5 maart 2007 21:50 > To: i-d-announce@ietf.org > Cc: nsis@ietf.org > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-09.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Next Steps in Signaling > Working Group of the IETF. > > Title : RMD-QOSM - The Resource Management in > Diffserv QOS Model > Author(s) : A. Bader, et al. > Filename : draft-ietf-nsis-rmd-09.txt > Pages : 92 > Date : 2007-3-5 > > This document describes an NSIS QoS Model for networks that use the > Resource Management in Diffserv (RMD) concept. RMD is a technique > for adding admission control and preemption function to > Differentiated Services (Diffserv) networks. The RMD QoS Model > allows devices external to the RMD network to signal reservation > requests to edge nodes in the RMD network. The RMD Ingress > edge nodes > classify the incoming flows into traffic classes and > signals resource > requests for the corresponding traffic class along the > data path to > the Egress edge nodes for each flow. Egress nodes > reconstitute the > original requests and continue forwarding them along the data path > towards the final destination. In addition, RMD defines > notification > functions to indicate overload situations within the domain to the > edge nodes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-rmd-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-rmd-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 08 08:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPIZw-0006dy-VX; Thu, 08 Mar 2007 08:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPIZv-0006dC-MQ for nsis@ietf.org; Thu, 08 Mar 2007 08:22:43 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPIZu-0004l0-BJ for nsis@ietf.org; Thu, 08 Mar 2007 08:22:43 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8576213CF81 for ; Thu, 8 Mar 2007 14:22:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6DA1A21B-7E95-498E-8674-63CD3DA06299@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Thu, 8 Mar 2007 14:22:34 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [NSIS] Draft agenda for IETF-68 in Prague X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Here is the draft agenda for the NSIS session (http://www3.ietf.org/ proceedings/07mar/agenda/nsis.txt): IETF-68, Prague, CZ **Draft Agenda for NSIS WG** Chair(s): John Loughney Martin Stiemerling TUESDAY, March 20, 2007 0900-1130 Morning Session I * Agenda Bashing (10 minutes) NOTE WELL Document Status and Accomplishments Milestones Review * GIST - Robert Hancock (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt * QoS NSLP - Jukka Manner (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt * NAT/FW NSLP - Hannes Tschofenig/Martin Stiemerling (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-14.txt * Mobility Applicability Statement - Takako Sanda (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability- mobility-signaling-06.txt * QSPEC - Jerry Ash (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt * RMD-QOSM - Georgios Karagiannis (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt * Y.1541 QOSM - TBD (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-03.txt * NSIS Operation over IP Tunnels - TBD (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-02.txt * GIST state machine - TBD (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt * GIST over SCTP - Christian Dickmann (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-01.txt stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 04:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb1m-0001P2-Pg; Fri, 09 Mar 2007 04:04:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZp-0007v7-HL; Thu, 08 Mar 2007 15:51:05 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZn-00026C-4R; Thu, 08 Mar 2007 15:51:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C90BF176C6; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007H1-H8; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-13.txt Pages : 85 Date : 2007-3-8 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-qos-nslp-13.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-qos-nslp-13.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: <2007-3-8120857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8120857.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Mar 09 04:05:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb2D-0002B3-Bi; Fri, 09 Mar 2007 04:05:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPlA-0007Gm-Dy for nsis@ietf.org; Thu, 08 Mar 2007 16:02:49 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPPke-0001mV-6g for nsis@ietf.org; Thu, 08 Mar 2007 16:02:48 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1173387294!17317554!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28259 invoked from network); 8 Mar 2007 20:54:54 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-121.messagelabs.com with SMTP; 8 Mar 2007 20:54:54 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l28Ksrjt000441; Thu, 8 Mar 2007 15:54:54 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l28KskrJ000381; Thu, 8 Mar 2007 15:54:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Date: Thu, 8 Mar 2007 14:54:46 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82BD@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Thread-Index: AcdeoYW/yVJxR2etTna0a0jRox1uSwBQTzTwAHEVUQA= References: From: "ASH, GERALD R, ATTLABS" To: "Hancock, Robert" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Thanks a lot for the careful review. Please see responses below.=20 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Tuesday, March 06, 2007 8:51 AM > To: nsis > Subject: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt >=20 > hi, >=20 > here are some comments. most are minor. >=20 > robert h. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D >=20 > general: i think the document needs to be checked for consistency of > 2119 capitalisation. some musts/shoulds should be MUSTs/SHOULDs and so > on. (I think actually the words themselves are right except=20 > where noted below.) OK. =20 > p9 para 2 line 5 ("but they ..."): needs editorial fixing >=20 > s4.3 para 2 (and similarly later): surely not-understood non-mandatory > parameters MUST be ignored? is there any meaningful sense in=20 > which they > could not be? OK. > s4.3.1 para 2 "mathematically complete": i have looked for a reference > for this for a while - imagine my disappointment when the citation > [WROCLAWSKI] resolves to 'TBD'!=20 Agreed. I've tried to run down a reference to the work that supports this statement, but so far without success (I've emailed the possible source of the analysis but so far haven't gotten a reply). Lacking an appropriate reference, the related text/reference will be removed. > s4.3.1 final para: i would use a word other than 'composed' for the > first three instances ('input' and 'output'?) These is quite common terminology used in other RFCs to mean 'accumulated' values, see for example RFC 2210 http://www.ietf.org/rfc/rfc2210.txt?number=3D2210 and search the word "composed" (object names even use the word). =20 > s4.3.2 para 2: if the delay includes queuing, i would add this > explicitly to the 2nd sentence. (currently, it implies it is=20 > limited to > propagation and processing delays, and it is not obvious=20 > whether queuing > is a type of processing.) Also, it needs to be clear if it is the mean > queuing delay or some other statistic of the delay (since=20 > variability is > covered in the next paragraph under jitter). The third sentence in the paragraph says "The mean delay reflects the variable queuing delay that may be present." I think that clarifies your issues? =20 > s4.3.2 2nd-to-last para: "an QSPEC" --> "a QSPEC" OK. =20 > s4.3.3 para 1: i don't see how the second two sentences here relate to > TH directives. Could they be deleted? I think the message is already > stated earlier in the document. I agree that this text may be a bit repetitious. However, there was a very long discussion regarding this text (see NSIS archive) and it was agreed that this text was the resolution of the discussion. I don't think we can delete it. =20 > s4.3.4: I could not follow this section. In particular, the example in > 4.4 has the QNI populating the PHB value, not the downstream QNE as > stated here. Good point. I think the particular sentence could be clarified as follows: "Note that PHB class is normally set by a downstream QNE to tell the QNI how to mark traffic to ensure treatment committed by admission control, however, setting of the parameter by the QNI is not precluded." =20 > s4.4 (and later): there should be some reference to the QoS-NSLP > specification to clarify the meaning of the word 'tunnel'. It could > refer to tunneling the data+signalling, tunneling the signalling only, > or hiding the signalling from the interior some other way=20 > (e.g. using an > NSLPID which isn't understood in the interior). I'm not suggesting > actually defining/discussing all these in the QSPEC document, just > noting that the tunnel words as a shorthand may be misleading=20 > to people > who don't have all the context. You could use a word like 'hiding' and > refer to 3.3.1 of Qos-NSLP and 7.2 of GIST. OK, agree with your suggested re-phrasing. =20 > s5.1 last para: presumably this is saying that an edge node could use > both techniques, but not for the same traffic (what would be the point > of that?) Good question. This text was also added after much discussion on the list. I agree that it isn't clear how both techniques would be used at the same time for the same flow. We can add text to that effect, however, I think it should be confirmed that these techniques are not intended to be used *at the same time for the same flow*. Perhaps Georgios could verify this. =20 > s5.2.1 para 1: presumably only understood parameters MUST be examined? Yes, good point. This text needs to be clarified to say that only the TMOD parameter and parameters marked with M=3D1 MUST be examined. Parameters marked with M=3D0 SHOULD be examined if understood by the = QNE. =20 > s5.2.2 last para: could say 'provides a bound' rather than unreliable. OK. =20 > s5.2.5: i think there should be some notes here pointing out=20 > that there > is some intelligence needed in mapping the E flags etc. from the inner > to the initiator Qspec. (Note that this *not* the same as=20 > Qspec mapping, > but there is at least some mapping to do - for example, there=20 > may be no > direct match between the parameters in the local and initiator Qspecs, > but that does not mean that no E flags should be raised in=20 > the latter.) Agreed. Any text suggestions would be appreciated here. =20 > s5.3: i think that rather than describing the two cases as > sender/receiver-initiated, it would be better to describe these two > cases as a 2-way transaction and a 3-way transaction. It just=20 > so happens > that up to now it's natural to use the 2-way handshake for a > sender-initiated reservation and the 3-way handshake for a receiver > initiated one, because then in each case the first message in the > handshake is sent by the flow sender and this can set up the routing > state. However, logically GIST can (attempt to) set up the=20 > routing state > in the reverse direction, so you can for example have a > receiver-initiated reservation set up with the 2-way=20 > transaction. (this > would be the natural way to do a reservation for an inbound flow to a > mobile node from a mobility anchor, for example.) I don't think this > changes any of the text other than giving things different=20 > headings and > using the terms QNI/QNR rather than sender/receiver in the=20 > descriptions. OK with me to re-title these sub-sections as you suggest. =20 > s5.3.2: Case 4 --> Case 3? Right. =20 > s5.3.5: I would delete the clause about pre-emption being based on the > Priority parameter. It implies that pre-emption is somehow > deterministic, whereas I would say that it is always a matter of QNE > policy, which could take all sorts of things into account (and the > values of the priority parameter in various messages are just some of > these). Point taken. The sentence could be changed as follows: "A flow can be preempted by a QNE based on QNE policy, where a decision to preempt a flow may account for various factors such as, for example, the values of the QSPEC preemption priority and defending priority parameters as described in Section 6.2.8." =20 > s5.4 para 1: surely update to all QNEs is needed only if the parameter > is always used with M=3D1 and there is no fallback in response to = error > conditions. (As written, this is much too pessimistic.) Right. This text should be deleted, a point that was raised on the list at http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html (see also the related comment at http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html). =20 > s6.2.3 (and later): i would move the definition of the 'indeterminate' > encoding earlier, otherwise one is left wondering what this=20 > word means. > [there are also two typos here, flagand and flagflag.] OK on all. =20 > s6.2.5/6.2.6: remove references to values being measured in > microseconds. Good catch. =20 > s6.2.12: i think the initial layout diagram is confusing. it=20 > implied to > me that the PHB encoding is always a 6 bit field. Actually,=20 > the initial > diagram should be of a 16 bit field, and then three (rather than two) > layout options, for the three cases of prescribed value,=20 > value set, and > non-standard. And shouldn't the 'X' in the second two layout options > actually be a '1'? Good comments. This should be clarified as follows: Single PHB: 0 1 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 0 0| +---+---+---+---+---+---+---+---+ Set of PHBs: 0 1 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 1 0| +---+---+---+---+---+---+---+---+ Single non-standard PHB (experimental or local): 0 1 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHD ID CODE |0 0 0 1| +---+---+---+---+---+---+---+---+ Set of non-standard PHBs (experimental or local): 0 1 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHD ID CODE |0 0 1 1| +---+---+---+---+---+---+---+---+ Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 04:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb2V-0002Ql-Ty; Fri, 09 Mar 2007 04:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQDp-00057e-8A for nsis@ietf.org; Thu, 08 Mar 2007 16:32:25 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPQDX-00020F-KZ for nsis@ietf.org; Thu, 08 Mar 2007 16:32:24 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1173387922!16837292!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11157 invoked from network); 8 Mar 2007 21:05:23 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-146.messagelabs.com with SMTP; 8 Mar 2007 21:05:23 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l28L5MTq006887; Thu, 8 Mar 2007 16:05:22 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l28L5HL9006844; Thu, 8 Mar 2007 16:05:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Date: Thu, 8 Mar 2007 15:04:47 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82BF@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <014AAE67-4AF3-4926-87A8-3B98A894760F@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Thread-Index: Acdg80nTHCng/vzeTQa4iofzs4NOXAA0b/3g References: <9473683187ADC049A855ED2DA739ABCA0DDC8237@KCCLUST06EVS1.ugd.att.com> <014AAE67-4AF3-4926-87A8-3B98A894760F@netlab.nec.de> From: "ASH, GERALD R, ATTLABS" To: "Martin Stiemerling" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "ASH, GERALD R, ATTLABS" , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, > Can you submit an updated version of the QSPEC fixing those two =20 > glitches after the WGLC has ended and all comments have been handled? Yes, I'll submit an updated version ASAP, to include the comments/changes identified during the WGLC. =20 Do you know when the ID Editor will begin accepting input again? Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 04:19:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbFM-0004Ba-Eu; Fri, 09 Mar 2007 04:18:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQDn-00057F-N8 for nsis@ietf.org; Thu, 08 Mar 2007 16:32:23 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPPqt-0002ra-FA for nsis@ietf.org; Thu, 08 Mar 2007 16:09:06 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1173387720!13021517!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28249 invoked from network); 8 Mar 2007 21:02:00 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 8 Mar 2007 21:02:00 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l28L1xH2004799; Thu, 8 Mar 2007 16:02:00 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l28L0xks004240; Thu, 8 Mar 2007 16:01:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Date: Thu, 8 Mar 2007 15:01:18 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82BE@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Thread-Index: Acdg9tra44wKq/NMS/qffxcSRktiTwAzaqCA References: From: "ASH, GERALD R, ATTLABS" To: "Martin Stiemerling" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, > I have found an editorial nit in Section 6.1 General QSPEC Formats. =20 > On page 28, after the Common QSPEC Header figure it says still QOSM =20 > ID instead of QSPEC type. Good catch. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 04:31:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbQx-0000Xs-8I; Fri, 09 Mar 2007 04:30:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb8z-0004nR-E7 for nsis@ietf.org; Fri, 09 Mar 2007 04:12:10 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPb8h-0001xw-Qu for nsis@ietf.org; Fri, 09 Mar 2007 04:12:08 -0500 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 09 Mar 2007 11:11:50 +0200 id 0005FE64.45F124D6.00007256 Date: Fri, 9 Mar 2007 11:11:50 +0200 (EET) From: Jukka MJ Manner To: "ASH, GERALD R, ATTLABS" Subject: RE: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82BF@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC8237@KCCLUST06EVS1.ugd.att.com> <014AAE67-4AF3-4926-87A8-3B98A894760F@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82BF@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Martin Stiemerling , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I-D admin starts publishing on the meeting week, Monday 19th. Jukka On Thu, 8 Mar 2007, ASH, GERALD R, ATTLABS wrote: > Hi Martin, > > > Can you submit an updated version of the QSPEC fixing those two > > glitches after the WGLC has ended and all comments have been handled? > > Yes, I'll submit an updated version ASAP, to include the > comments/changes identified during the WGLC. > > Do you know when the ID Editor will begin accepting input again? > > Thanks, > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 04:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbSZ-0002eR-Mz; Fri, 09 Mar 2007 04:32:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbPF-0005qq-6n for nsis@ietf.org; Fri, 09 Mar 2007 04:28:57 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPbOW-0006CO-3J for nsis@ietf.org; Fri, 09 Mar 2007 04:28:57 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l299RtWG031999; Fri, 9 Mar 2007 09:27:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Date: Fri, 9 Mar 2007 09:27:55 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Thread-Index: AcdeoYW/yVJxR2etTna0a0jRox1uSwBQTzTwAHEVUQAAISzIIA== References: <9473683187ADC049A855ED2DA739ABCA0DDC82BD@KCCLUST06EVS1.ugd.att.com> From: "Hancock, Robert" To: "ASH, GERALD R, ATTLABS" , "nsis" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi jerry, a couple of followups:=20 > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Sent: 08 March 2007 20:55 > To: Hancock, Robert; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt >=20 > Hi Robert, >=20 > Thanks a lot for the careful review. Please see responses below.=20 >=20 > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: Tuesday, March 06, 2007 8:51 AM > > To: nsis > > Subject: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt > >=20 > > hi, > >=20 > > here are some comments. most are minor. > >=20 > > robert h. > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D > >=20 > > general: i think the document needs to be checked for consistency of > > 2119 capitalisation. some musts/shoulds should be=20 > MUSTs/SHOULDs and so=20 > > on. (I think actually the words themselves are right except where=20 > > noted below.) >=20 > OK. > =20 > > p9 para 2 line 5 ("but they ..."): needs editorial fixing > >=20 > > s4.3 para 2 (and similarly later): surely not-understood=20 > non-mandatory=20 > > parameters MUST be ignored? is there any meaningful sense in which=20 > > they could not be? >=20 > OK. >=20 > > s4.3.1 para 2 "mathematically complete": i have looked for=20 > a reference=20 > > for this for a while - imagine my disappointment when the citation=20 > > [WROCLAWSKI] resolves to 'TBD'! >=20 > Agreed. I've tried to run down a reference to the work that=20 > supports this statement, but so far without success (I've=20 > emailed the possible source of the analysis but so far=20 > haven't gotten a reply). Lacking an appropriate reference,=20 > the related text/reference will be removed. >=20 > > s4.3.1 final para: i would use a word other than 'composed' for the=20 > > first three instances ('input' and 'output'?) >=20 > These is quite common terminology used in other RFCs to mean=20 > 'accumulated' values, see for example RFC 2210=20 > http://www.ietf.org/rfc/rfc2210.txt?number=3D2210 and search=20 > the word "composed" (object names even use the word). maybe 'input composed' and so on; but i'm not that fussed (i managed to work it out anyway) > =20 > > s4.3.2 para 2: if the delay includes queuing, i would add this=20 > > explicitly to the 2nd sentence. (currently, it implies it=20 > is limited=20 > > to propagation and processing delays, and it is not obvious whether=20 > > queuing is a type of processing.) Also, it needs to be=20 > clear if it is=20 > > the mean queuing delay or some other statistic of the delay (since=20 > > variability is covered in the next paragraph under jitter). >=20 > The third sentence in the paragraph says "The mean delay=20 > reflects the variable queuing delay that may be present." I=20 > think that clarifies your issues? it's actually that sentence which caused the confusion. wouldn't it be easier to have the second sentence say "This delay results from the combination of speed-of-light propagation delay,=20 packet processing, and queueing." ? > =20 > > s4.3.2 2nd-to-last para: "an QSPEC" --> "a QSPEC" >=20 > OK. > =20 > > s4.3.3 para 1: i don't see how the second two sentences=20 > here relate to=20 > > TH directives. Could they be deleted? I think the message=20 > is already=20 > > stated earlier in the document. >=20 > I agree that this text may be a bit repetitious. However,=20 > there was a very long discussion regarding this text (see=20 > NSIS archive) and it was agreed that this text was the=20 > resolution of the discussion. I don't think we can delete it. i agree the text is needed; it's just that it seems you already have it in section 4.1.1 (in a more complete form, in fact) which also seems the right place for it. *** end of followup robert h. > =20 > > s4.3.4: I could not follow this section. In particular, the=20 > example in > > 4.4 has the QNI populating the PHB value, not the downstream QNE as=20 > > stated here. >=20 > Good point. I think the particular sentence could be clarified as > follows: >=20 > "Note that PHB class is normally set by a downstream QNE to=20 > tell the QNI how to mark traffic to ensure treatment=20 > committed by admission control, however, setting of the=20 > parameter by the QNI is not precluded." > =20 > > s4.4 (and later): there should be some reference to the QoS-NSLP=20 > > specification to clarify the meaning of the word 'tunnel'. It could=20 > > refer to tunneling the data+signalling, tunneling the=20 > signalling only,=20 > > or hiding the signalling from the interior some other way=20 > (e.g. using=20 > > an NSLPID which isn't understood in the interior). I'm not=20 > suggesting=20 > > actually defining/discussing all these in the QSPEC document, just=20 > > noting that the tunnel words as a shorthand may be misleading to=20 > > people who don't have all the context. You could use a word like=20 > > 'hiding' and refer to 3.3.1 of Qos-NSLP and 7.2 of GIST. >=20 > OK, agree with your suggested re-phrasing. > =20 > > s5.1 last para: presumably this is saying that an edge node=20 > could use=20 > > both techniques, but not for the same traffic (what would=20 > be the point=20 > > of that?) >=20 > Good question. This text was also added after much=20 > discussion on the list. I agree that it isn't clear how both=20 > techniques would be used at the same time for the same flow. =20 > We can add text to that effect, however, I think it should be=20 > confirmed that these techniques are not intended to be used=20 > *at the same time for the same flow*. Perhaps Georgios could=20 > verify this. > =20 > > s5.2.1 para 1: presumably only understood parameters MUST=20 > be examined? >=20 > Yes, good point. This text needs to be clarified to say that=20 > only the TMOD parameter and parameters marked with M=3D1 MUST=20 > be examined. > Parameters marked with M=3D0 SHOULD be examined if understood=20 > by the QNE. > =20 > > s5.2.2 last para: could say 'provides a bound' rather than=20 > unreliable. >=20 > OK. > =20 > > s5.2.5: i think there should be some notes here pointing out that=20 > > there is some intelligence needed in mapping the E flags=20 > etc. from the=20 > > inner to the initiator Qspec. (Note that this *not* the=20 > same as Qspec=20 > > mapping, but there is at least some mapping to do - for=20 > example, there=20 > > may be no direct match between the parameters in the local and=20 > > initiator Qspecs, but that does not mean that no E flags should be=20 > > raised in the latter.) >=20 > Agreed. Any text suggestions would be appreciated here. > =20 > > s5.3: i think that rather than describing the two cases as=20 > > sender/receiver-initiated, it would be better to describe these two=20 > > cases as a 2-way transaction and a 3-way transaction. It just so=20 > > happens that up to now it's natural to use the 2-way=20 > handshake for a=20 > > sender-initiated reservation and the 3-way handshake for a receiver=20 > > initiated one, because then in each case the first message in the=20 > > handshake is sent by the flow sender and this can set up=20 > the routing=20 > > state. However, logically GIST can (attempt to) set up the routing=20 > > state in the reverse direction, so you can for example have a=20 > > receiver-initiated reservation set up with the 2-way transaction.=20 > > (this would be the natural way to do a reservation for an=20 > inbound flow=20 > > to a mobile node from a mobility anchor, for example.) I=20 > don't think=20 > > this changes any of the text other than giving things different=20 > > headings and using the terms QNI/QNR rather than sender/receiver in=20 > > the descriptions. >=20 > OK with me to re-title these sub-sections as you suggest. > =20 > > s5.3.2: Case 4 --> Case 3? >=20 > Right. > =20 > > s5.3.5: I would delete the clause about pre-emption being=20 > based on the=20 > > Priority parameter. It implies that pre-emption is somehow=20 > > deterministic, whereas I would say that it is always a=20 > matter of QNE=20 > > policy, which could take all sorts of things into account (and the=20 > > values of the priority parameter in various messages are=20 > just some of=20 > > these). >=20 > Point taken. The sentence could be changed as follows: > "A flow can be preempted by a QNE based on QNE policy, where=20 > a decision to preempt a flow may account for various factors=20 > such as, for example, the values of the QSPEC preemption=20 > priority and defending priority parameters as described in=20 > Section 6.2.8." =20 >=20 > > s5.4 para 1: surely update to all QNEs is needed only if=20 > the parameter=20 > > is always used with M=3D1 and there is no fallback in=20 > response to error=20 > > conditions. (As written, this is much too pessimistic.) >=20 > Right. This text should be deleted, a point that was raised=20 > on the list at=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.ht > ml (see also the related comment at=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html). > =20 > > s6.2.3 (and later): i would move the definition of the=20 > 'indeterminate' > > encoding earlier, otherwise one is left wondering what this word=20 > > means. > > [there are also two typos here, flagand and flagflag.] >=20 > OK on all. > =20 > > s6.2.5/6.2.6: remove references to values being measured in=20 > > microseconds. >=20 > Good catch. > =20 > > s6.2.12: i think the initial layout diagram is confusing.=20 > it implied=20 > > to me that the PHB encoding is always a 6 bit field. Actually, the=20 > > initial diagram should be of a 16 bit field, and then three (rather=20 > > than two) layout options, for the three cases of prescribed value,=20 > > value set, and non-standard. And shouldn't the 'X' in the=20 > second two=20 > > layout options actually be a '1'? >=20 > Good comments. This should be clarified as follows: >=20 > Single PHB: >=20 > 0 1 =20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DSCP |0 0 0 0 0 0 0 0 0 0| > +---+---+---+---+---+---+---+---+ >=20 > Set of PHBs: >=20 > 0 1 =20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DSCP |0 0 0 0 0 0 0 0 1 0| > +---+---+---+---+---+---+---+---+ >=20 > Single non-standard PHB (experimental or local): >=20 > 0 1 =20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PHD ID CODE |0 0 0 1| > +---+---+---+---+---+---+---+---+ >=20 > Set of non-standard PHBs (experimental or local): >=20 > 0 1 =20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PHD ID CODE |0 0 1 1| > +---+---+---+---+---+---+---+---+ >=20 > Thanks, > Regards, > Jerry >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 05:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbvr-0006tq-FR; Fri, 09 Mar 2007 05:02:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbvq-0006sI-Eg for nsis@ietf.org; Fri, 09 Mar 2007 05:02:38 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPbvp-000301-OA for nsis@ietf.org; Fri, 09 Mar 2007 05:02:38 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l29A2S5e022750; Fri, 9 Mar 2007 11:02:31 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" References: <9473683187ADC049A855ED2DA739ABCA0DDC824F@KCCLUST06EVS1.ugd.att.com><000b01c75c1c$29054780$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC8270@KCCLUST06EVS1.ugd.att.com><000301c75cb4$56480e60$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in qspec draft Date: Fri, 9 Mar 2007 11:02:23 +0100 Message-ID: <002401c76232$0b7c70a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdhCpdXplOOxxlbTUCzL+mLF3hOawBJwABw In-Reply-To: X-Spam-Score: 0.239 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 09 Mar 2007 11:02:33 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin A QNE can support more RMFs/QOSMs. In this case a QOSM ID is needed otherwise the QNE will not know what to do with the received QSPEC, see e-mail discussions with Roland. Best Regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: woensdag 7 maart 2007 21:54 > To: Georgios Karagiannis > Cc: 'ASH, GERALD R, ATTLABS'; 'nsis' > Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in > qspec draft > > Hi Georgios and Jerry, > > I'm trying to understand what the issue is, so please correct > me when I'm wrong! > > I believe that the QOSM ID is not needed as there is only one > local RMF per QNE. This local RMF can actually support > multiple QOSMs but this is opaque to the QoS NSLP. I.e., the > QoS NSLP has only the chance to pass the QSPEC in a single > piece to a single RMF. > The mapping between the different initiator QOSM and the > local QOSM is solely happening within the RMF. > > Thanks, > > Martin > > Am 02.03.2007 um 11:19 schrieb Georgios Karagiannis: > > > Hi Jerry > > > > The main goal of using the QOS-NSLP messages is to > > carry a QSPEC object and deliver it to the right QOSM/RMF. > > > > If a QNE will support simultaneously more than one QOS models, say > > QOSM-I1, > > QOSM-I2, > > and a QoS-NSLP message, which carries a QSPEC that is say > > associated with > > QOSM-I1, > > arrives at a QNE, then the QNE must be able to deliver > > the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1. > > > > How the QNE will know to which RMF it should deliver the received > > QSPEC? > > > > Best regards, > > Georgios > > > > > > > > > >> -----Original Message----- > >> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > >> Sent: donderdag 1 maart 2007 23:49 > >> To: Georgios Karagiannis; Martin Stiemerling; nsis > >> Cc: ASH, GERALD R, ATTLABS > >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > >> qspec draft > >> > >> Georgios, > >> > >> Your examples don't illustrate how and why a QOSM ID field is > >> needed and used. > >> > >> Perhaps you are saying that QoS NSLP and RMF communicate with > >> messages and that the I-QOSM ID and L-QOSM ID need to be > >> included in those messages so that the QoS NSLP can react > >> differently based on which L-QOSM is being used by the RMF? > >> > >> If so, then this interaction suffers from the problems > >> identified in Cornelia's slide (attached) discussed on our > >> conference call on 31 January. > >> > >> If not, please give a more detailed example of how and why a > >> QOSM ID field is needed and used. > >> > >> Jerry > >> > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: Thursday, March 01, 2007 11:11 AM > >> To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis' > >> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > >> qspec draft > >> > >> Hi Jerry > >> > >> The need for the QOSM ID can be seen probably seen in the > >> below e-mail: > >> > >> Suppose that: > >> > >> A QNE supports the following: > >> > >> * end-to-end QOS Models: > >> QOSMI-1, QOSMI-2, QOSMI-3 > >> > >> * local QoS Models: > >> QOSML-1, QOSML-2, QOSML-3 > >> > >> Suppose now that the operator of such a QNE wants to use > the follwing > >> combinations: > >> > >> * QOSMI-1 with QOSML-3. > >> > >> Meaning that end-to-end sessions and QOS-NSLP messages that > >> are carrying > >> > >> initial QSPEC of QOSM-I1 should be bound with local sessions > >> and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3 > >> > >> * QOSMI-2 with QOSML-3 > >> > >> Meaning that end-to-end sessions and QOS-NSLP messages that > >> are carrying > >> > >> initial QSPEC of QOSMI-2 should be bound with local sessions > >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-3 > >> > >> * QOSMI-3 with QOSML-1 > >> > >> initial QSPEC of QOSMI-3 should be bound with local sessions > >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-1 > >> > >> * QOSMI-3 with QOSML-2 > >> > >> initial QSPEC of QOSMI-3 should be bound with local sessions > >> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2 > >> -- > >> > >> > >> If the QOSM ID will not be supported these combinations will > >> not beable > >> to > >> be made meaning that > >> A QNE will be able to support only one initial > (end-to-end) QOSM with > >> only > >> one local QOSM at a time. > >> > >> Best Regards, > >> Georgios > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > >>> Sent: woensdag 28 februari 2007 14:43 > >>> To: Georgios Karagiannis; Martin Stiemerling; nsis > >>> Cc: ASH, GERALD R, ATTLABS > >>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in > >>> qspec draft > >>> > >>> Georgios, All, > >>> > >>>> -----Original Message----- > >>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>>> Sent: Wednesday, February 28, 2007 12:37 AM > >>>> To: Martin Stiemerling; nsis > >>>> Subject: [NSIS] comment on reintroduction of QOSM-ID in > >> qspec draft > >>>> > >>>> Hi > >>>> > >>>> I was busy updating some of the QOSM drafts and I have seen that > >>>> starting from version 13 of the QSPEC draft, the QOSM ID > >> field is > >>>> removed form the common header of a QSPEC object and > >>> instead of this, > >>>> the field QSPEC type is used. > >>> > >>> The QSPEC Type was introduced to support Roland's QSPEC > >>> stacking/encapsulation method (see > >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht > >>> ml), it does not replace QOSM ID. > >>> > >>> The QOSM ID was removed in the discussion around the QSPEC-13 > >>> draft update, see the post on 1 November 2006 > >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht > >>> ml, where it says "A QOSM ID need not be defined or signaled > >>> and a QNE need not support any particular QOSM". Slide 3 of > >>> the QSPEC presentation at IETF-67 makes the same point. The > >>> same point is made again in the announcement of the draft to > >>> the NSIS list at > >>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht > >>> ml and the point is also made in Appendix A of the QSPEC > >>> draft itself. There were no objections to this point. > >>> > >>>> I agree that QSPEC type (shows if the QSPEC object is > >> initial or a > >>>> local) is useful and it should be used, but by removing > >> the QOSM ID > >>>> field it will mean that a QNE can always support only one type of > >>>> initial > >>>> (end-to-end) QOSM and one type of local QOSM. > >>>> That is not reasonable. A QNE should be able to support > >>> many QOSMs and > >>>> it should be able to distinguish and associate a QSPEC > >>> object with a > >>>> certain QOSM. > >>> > >>> There is no mention in any QSPEC draft as to how or why a > >>> QOSM ID field is needed or used. A QNE can support any QOSM > >>> it wants, it does not depend on a QOSM ID field from the QNI > >>> to determine which one. > >>> > >>> At a minimum, we would need to have a bit-level example of > >>> how/why such a field is needed to justify reintroducing the > >>> QOSM ID field. > >>> > >>>> Therefore, I think that it is required that the QOSM ID > >>> field should > >>>> be reintroduced in the QSPEC common header. The field > >> QSPEC type is > >>>> also useful ant it should be kept. > >>> > >>> We need clear justification to reintroduce the complexity of > >>> having the QOSM ID field and the IANA registry to maintain > >>> the parameter. > >>> > >>> Jerry > >>> > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>> On 2/20/2007, "Martin Stiemerling" > >>> wrote: > >>>> > >>>>> Dear all, > >>>>> > >>>>> I would like to start the working group last call for the > >>> QSPEC draft > >>>> > >>> > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > >>>>> > >>>>> The WGLC is starting today and will run for two weeks > >>> until Tuesday > >>>>> Feb 6th. > >>>>> > >>>>> Please send your comments to the NSIS WG list. > >>>>> > >>>>> Martin > >>>>> > >>>>> Anfang der weitergeleiteten E-Mail: > >>>>> > >>>>>> Von: > >>>>>> Datum: 16. Februar 2007 21:50:02 MEZ > >>>>>> An: > >>>>>> Kopie: > >>>>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt > >>>>>> > >>>>>> A New Internet-Draft is available from the on-line > >>> Internet-Drafts > >>>>>> directories. > >>>>>> This draft is a work item of the Next Steps in > >> Signaling Working > >>>>>> Group of the IETF. > >>>>>> > >>>>>> Title : QoS NSLP QSPEC Template > >>>>>> Author(s) : J. Ash, et al. > >>>>>> Filename : draft-ietf-nsis-qspec-15.txt > >>>>>> Pages : 54 > >>>>>> Date : 2007-2-16 > >>>>>> > >>>>>> The QoS NSLP protocol is used to signal QoS reservations and is > >>>>>> independent of a specific QoS model (QOSM) such as > >> IntServ or > >>>>>> DiffServ. Rather, all information specific to a QOSM is > >>>>>> encapsulated > >>>>>> in a separate object, the QSPEC. This document defines > >>>> a template > >>>>>> for the QSPEC including a number of QSPEC parameters. > >>> The QSPEC > >>>>>> parameters provide a common language to be re-used in > >>>> several QOSMs > >>>>>> and thereby aim to ensure the extensibility and > >>>> interoperability of > >>>>>> QoS NSLP. The node initiating the NSIS signaling adds > >>>> an initiator > >>>>>> QSPEC, which indicates the QSPEC parameters that must be > >>>>>> interpreted > >>>>>> by the downstream nodes less the reservation fails, thereby > >>>>>> ensuring > >>>>>> the intention of the NSIS initiator is preserved along the > >>>>>> signaling > >>>>>> path. > >>>>>> > >>>>>> A URL for this Internet-Draft is: > >>>>>> > >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > >>>>>> > >>>>>> To remove yourself from the I-D Announcement list, send a > >>>> message to > >>>>>> i-d-announce-request@ietf.org with the word unsubscribe in > >>>> the body of > >>>>>> the message. > >>>>>> You can also visit > >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce > >>>>>> to change your subscription settings. > >>>>>> > >>>>>> 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-qspec-15.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-qspec-15.txt". > >>>>>> > >>>>>> NOTE: The mail server at ietf.org can return the document in > >>>>>> MIME-encoded form by using the "mpack" utility. > >> To use this > >>>>>> feature, insert the command "ENCODING mime" > >> before the "FILE" > >>>>>> command. To decode the response(s), you will > >> need "munpack" or > >>>>>> a MIME-compliant mail reader. Different MIME-compliant > >>>> mail readers > >>>>>> exhibit different behavior, especially when dealing with > >>>>>> "multipart" MIME messages (i.e. documents which > >> have been split > >>>>>> up into multiple messages), so check your local > >> documentation on > >>>>>> how to manipulate these messages. > >>>>>> > >>>>>> Below is the data which will enable a MIME compliant > >> mail reader > >>>>>> implementation to automatically retrieve the ASCII > >> version of the > >>>>>> Internet-Draft.) > >>> > >>> _______________________________________________ > >>> nsis mailing list > >>> nsis@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/nsis > >>> > >> > >> > >> > > > > > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 05:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcSV-0007l3-BU; Fri, 09 Mar 2007 05:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcSU-0007ky-3U for nsis@ietf.org; Fri, 09 Mar 2007 05:36:22 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPcSQ-000062-Hy for nsis@ietf.org; Fri, 09 Mar 2007 05:36:22 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 023EB13CF81 for ; Fri, 9 Mar 2007 11:36:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> Content-Type: multipart/mixed; boundary=Apple-Mail-5--291639211 References: From: Martin Stiemerling Subject: Fwd: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Fri, 9 Mar 2007 11:36:12 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --Apple-Mail-5--291639211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Please take a look and review the new version of the QoS NSLP draft. There have been some changes in the main part, plus a new appendix =20 with the NSLP-RMF API. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: > Datum: 8. M=E4rz 2007 21:50:03 MEZ > An: > Kopie: > Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Next Steps in Signaling Working =20 > Group of the IETF. > > Title : NSLP for Quality-of-Service Signaling > Author(s) : J. Manner, et al. > Filename : draft-ietf-nsis-qos-nslp-13.txt > Pages : 85 > Date : 2007-3-8 > =09 > This specification describes the NSIS Signaling Layer Protocol (NSLP) > for signaling QoS reservations in the Internet. It is in accordance > with the framework and requirements developed in NSIS. Together =20 > with > GIST, it provides functionality similar to RSVP and extends it. The > QoS NSLP is independent of the underlying QoS specification or > architecture and provides support for different reservation models. > It is simplified by the elimination of support for multicast flows. > This specification explains the overall protocol approach, design > decisions made and provides examples. It specifies object, message > formats and processing rules. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-qos-nslp-13.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-qos-nslp-13.txt". > =09 > 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.= --Apple-Mail-5--291639211 Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0666; name=ATT152003.TXT Content-Disposition: attachment; filename=ATT152003.TXT Content-Type:=20Message/External-body;=20access-type=3D"mail-server";=0D=0A= =09server=3D"mailserv@ietf.org"=0D=0A=0D=0AContent-Type:=20text/plain=0D=0A= Content-ID:=20<2007-3-8120857.I-D@ietf.org>=0D=0A=0D=0AENCODING=20mime=0D= =0AFILE=20/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt=0D=0A= --Apple-Mail-5--291639211 Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0666; name=draft-ietf-nsis-qos-nslp-13.URL Content-Disposition: attachment; filename=draft-ietf-nsis-qos-nslp-13.URL [InternetShortcut]=0D=0A= URL=3Dftp://ftp.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt=0D= =0A= --Apple-Mail-5--291639211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0666; name=ATT152004.txt Content-Disposition: attachment; filename=ATT152004.txt _______________________________________________=0D nsis mailing list=0D nsis@ietf.org=0D https://www1.ietf.org/mailman/listinfo/nsis=0D --Apple-Mail-5--291639211 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-5--291639211 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-5--291639211-- From nsis-bounces@ietf.org Fri Mar 09 05:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcgd-0002kS-5n; Fri, 09 Mar 2007 05:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcgc-0002gV-6R for nsis@ietf.org; Fri, 09 Mar 2007 05:50:58 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPcgZ-000370-Lc for nsis@ietf.org; Fri, 09 Mar 2007 05:50:58 -0500 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 09 Mar 2007 12:50:52 +0200 id 0005FE85.45F13C0C.00005F9F Date: Fri, 9 Mar 2007 12:50:52 +0200 (EET) From: Jukka MJ Manner To: nsis Subject: Re: Fwd: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt In-Reply-To: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> Message-ID: References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-24482-1173437455-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-24482-1173437455-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.53.3 A diff of the changes since -12 is at: http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-nsis-qo= s-nslp-13-from-12.diff.html Main changes: - Reduced refreshes are the default mechanism for refreshing sessions - RSN needs to be taken into account when a node receives a tear - Summary refresh and summary tear introduced (incl. objects and message processing) - QSPEC staking removed - ACK-REQ flag introduced for diagnostics purposes - Some changes to the INFO_SPEC codes (see the diff) - (very) Initial version of NSLP-RMF API Jukka On Fri, 9 Mar 2007, Martin Stiemerling wrote: > Please take a look and review the new version of the QoS NSLP draft. > > There have been some changes in the main part, plus a new appendix with= the > NSLP-RMF API. > > Thanks, > > Martin > > Anfang der weitergeleiteten E-Mail: > > >Von: > >Datum: 8. M=E4rz 2007 21:50:03 MEZ > >An: > >Kopie: > >Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Next Steps in Signaling Working Group= of > >the IETF. > > > > Title=09=09: NSLP for Quality-of-Service Signaling > > Author(s)=09: J. Manner, et al. > > Filename=09: draft-ietf-nsis-qos-nslp-13.txt > > Pages=09=09: 85 > > Date=09=09: 2007-3-8 > > > >This specification describes the NSIS Signaling Layer Protocol (NSLP) > > for signaling QoS reservations in the Internet. It is in accordance > > with the framework and requirements developed in NSIS. Together wit= h > > GIST, it provides functionality similar to RSVP and extends it. The > > QoS NSLP is independent of the underlying QoS specification or > > architecture and provides support for different reservation models. > > It is simplified by the elimination of support for multicast flows. > > This specification explains the overall protocol approach, design > > decisions made and provides examples. It specifies object, message > > formats and processing rules. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt > > > >To remove yourself from the I-D Announcement list, send a message to > >i-d-announce-request@ietf.org with the word unsubscribe in the body of > >the message. > >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >to change your subscription settings. > > > >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-qos-nslp-13.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: > >=09mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-nsis-qos-nslp-13.txt". > > > >NOTE:=09The 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. > --=_courier-24482-1173437455-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --=_courier-24482-1173437455-0001-2-- From nsis-bounces@ietf.org Fri Mar 09 05:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPckj-0004rD-Vs; Fri, 09 Mar 2007 05:55:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPckj-0004r2-52 for nsis@ietf.org; Fri, 09 Mar 2007 05:55:13 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPckh-00042k-RI for nsis@ietf.org; Fri, 09 Mar 2007 05:55:13 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6ABC113CF81 for ; Fri, 9 Mar 2007 11:55:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Fri, 9 Mar 2007 11:55:10 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org [writing with chair's hat off] Hi all, I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue which came up during the WGLC for the QSPEC draft. The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the QSPEC-Type is - initiator QSPEC or - local QSPEC. When reading the text first I thought that is fine, but given all discussions afterwards and reading again the QPSEC I have now some doubts. I assume two approaches here how to deal with identifying QOSMs on a QNE. 1. Roland's approach with QSPEC-Type identifying the type of QSPEC signalled for (e.g., RMD, Y.1541. etc) (also favoured by Georgios) 2. The current QSPEC approach with QSPEC-Type just saying initiator or local QSPEC. With approach 1. it is straight forward how to identify to which local RMF to forward the received QSPEC. With approach 2 I assume only RMF per QNE. The RMF on the node then automatically knows what the possible local QOSM can be (and remembers this). I one of my past emails I wrote this > > I believe that the QOSM ID is not needed as there is only one local > RMF per QNE. This local RMF can actually support multiple QOSMs but > this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the > chance to pass the QSPEC in a single piece to a single RMF. > The mapping between the different initiator QOSM and the local QOSM > is solely happening within the RMF. What is not clear for approach 2 for me: How does a RMF on a QNE distinguish between the possible available QOSMs? Does the QSPEC assume that the RMFs in one part of a network do know which QOSM is used by heart? Thanks in advance, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 06:02:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcqm-0006sF-Mh; Fri, 09 Mar 2007 06:01:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcqm-0006rU-3S for nsis@ietf.org; Fri, 09 Mar 2007 06:01:28 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPcqk-0005Fo-NH for nsis@ietf.org; Fri, 09 Mar 2007 06:01:28 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4934713CF81 for ; Fri, 9 Mar 2007 12:01:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) References: <6DA1A21B-7E95-498E-8674-63CD3DA06299@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6BDD6134-0BDE-40C9-8E17-251268427E74@netlab.nec.de> Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Date: Fri, 9 Mar 2007 12:01:25 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [NSIS] Some suggested further reading for IETF-68 in Prague X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, There are some individual submissions to the NSIS working group which =20= cannot be presented during the session. However, it suggested that =20 people take a look at the drafts and discuss them if desired. So the suggested further reading (of course, *after* reading the WG =20 drafts :-) is: > Inter-Domain Reservation Aggregation for QoS NSLP > (draft-bless-nsis-resv-aggr-00) >> Draft name: draft-cheng-nsis-multihoming-00 >> > (http://www.ietf.org/internet-drafts/draft-cheng-nsis-=20 > multihoming-00.txt > ) > Draft name: HyPath (draft-cordeiro-nsis-hypath-03) > NSLP Authorization (draft-manner-nsis-nslp-auth-03.txt) Any other further readings is welcome! Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 8. M=E4rz 2007 14:22:34 MEZ > An: nsis > Betreff: [NSIS] Draft agenda for IETF-68 in Prague > > Hi, > > Here is the draft agenda for the NSIS session (http://www3.ietf.org/=20= > proceedings/07mar/agenda/nsis.txt): > > IETF-68, Prague, CZ > > **Draft Agenda for NSIS WG** > > Chair(s): > John Loughney > Martin Stiemerling > > TUESDAY, March 20, 2007 > 0900-1130 Morning Session I > > * Agenda Bashing (10 minutes) > NOTE WELL > Document Status and Accomplishments > Milestones Review > > * GIST - Robert Hancock (20 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt > > * QoS NSLP - Jukka Manner (20 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt > > * NAT/FW NSLP - Hannes Tschofenig/Martin Stiemerling (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-14.txt > > * Mobility Applicability Statement - Takako Sanda (20 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-=20 > mobility-signaling-06.txt > > * QSPEC - Jerry Ash (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt > > * RMD-QOSM - Georgios Karagiannis (15 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt > * Y.1541 QOSM - TBD (15 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-03.txt > * NSIS Operation over IP Tunnels - TBD (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-02.txt > > * GIST state machine - TBD (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt > * GIST over SCTP - Christian Dickmann (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-01.txt > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 06:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcw3-00008v-Fn; Fri, 09 Mar 2007 06:06:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcw1-00008q-JM for nsis@ietf.org; Fri, 09 Mar 2007 06:06:53 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPcvz-0006kZ-1E for nsis@ietf.org; Fri, 09 Mar 2007 06:06:53 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 804D813CF81 for ; Fri, 9 Mar 2007 12:06:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] WGLC for draft-ietf-nsis-qspec-15.txt Date: Fri, 9 Mar 2007 12:06:47 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, the WGLC for draft-ietf-nsis-qspec-15.txt ended on March 6th. Thanks for all reviewers and the received comments. There have been some issues to be solved, such as: - editorial glitches and nits (noted by Jerry, Martin, etc) - the QOSM-ID QSPEC-Type issue - Robert's comments (currently worked on) The editorial comments and Robert's comments are already fixed or in the process of being fixed. The QOSM-ID and QSPEC-Type issue still needs some further discussions, but will hopefully also being fixed soon. Thanks, Martin Am 20.02.2007 um 15:54 schrieb Martin Stiemerling: > Dear all, > > I would like to start the working group last call for the QSPEC draft > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt). > > The WGLC is starting today and will run for two weeks until Tuesday > Feb 6th. > > Please send your comments to the NSIS WG list. > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: >> Datum: 16. Februar 2007 21:50:02 MEZ >> An: >> Kopie: >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Next Steps in Signaling Working >> Group of the IETF. >> >> Title : QoS NSLP QSPEC Template >> Author(s) : J. Ash, et al. >> Filename : draft-ietf-nsis-qspec-15.txt >> Pages : 54 >> Date : 2007-2-16 >> >> The QoS NSLP protocol is used to signal QoS reservations and is >> independent of a specific QoS model (QOSM) such as IntServ or >> DiffServ. Rather, all information specific to a QOSM is >> encapsulated >> in a separate object, the QSPEC. This document defines a template >> for the QSPEC including a number of QSPEC parameters. The QSPEC >> parameters provide a common language to be re-used in several >> QOSMs >> and thereby aim to ensure the extensibility and >> interoperability of >> QoS NSLP. The node initiating the NSIS signaling adds an >> initiator >> QSPEC, which indicates the QSPEC parameters that must be >> interpreted >> by the downstream nodes less the reservation fails, thereby >> ensuring >> the intention of the NSIS initiator is preserved along the >> signaling >> path. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> 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-qspec-15.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-qspec-15.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. >> >> >> > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 06:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPd1h-00031v-NU; Fri, 09 Mar 2007 06:12:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPd1g-00031q-7N for nsis@ietf.org; Fri, 09 Mar 2007 06:12:44 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPd1e-00005J-Ml for nsis@ietf.org; Fri, 09 Mar 2007 06:12:44 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 481AA13CF81 for ; Fri, 9 Mar 2007 12:12:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) References: <6BDD6134-0BDE-40C9-8E17-251268427E74@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Fwd: [NSIS] Some suggested further reading for IETF-68 in Prague Date: Fri, 9 Mar 2007 12:12:41 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org +1: > interdomain QOSM: > http://www.ietf.org/internet-drafts/draft-zhang-nsis-interdomain-=20 > qosm-04.txt Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 9. M=E4rz 2007 12:01:25 MEZ > An: nsis > Betreff: [NSIS] Some suggested further reading for IETF-68 in Prague > > Hi all, > > There are some individual submissions to the NSIS working group =20 > which cannot be presented during the session. However, it suggested =20= > that people take a look at the drafts and discuss them if desired. > > So the suggested further reading (of course, *after* reading the WG =20= > drafts :-) is: > >> Inter-Domain Reservation Aggregation for QoS NSLP >> (draft-bless-nsis-resv-aggr-00) > >>> Draft name: draft-cheng-nsis-multihoming-00 >>> >> (http://www.ietf.org/internet-drafts/draft-cheng-nsis-=20 >> multihoming-00.txt >> ) > >> Draft name: HyPath (draft-cordeiro-nsis-hypath-03) > > >> NSLP Authorization (draft-manner-nsis-nslp-auth-03.txt) > > Any other further readings is welcome! > > Thanks, > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: Martin Stiemerling >> Datum: 8. M=E4rz 2007 14:22:34 MEZ >> An: nsis >> Betreff: [NSIS] Draft agenda for IETF-68 in Prague >> >> Hi, >> >> Here is the draft agenda for the NSIS session (http://=20 >> www3.ietf.org/proceedings/07mar/agenda/nsis.txt): >> >> IETF-68, Prague, CZ >> >> **Draft Agenda for NSIS WG** >> >> Chair(s): >> John Loughney >> Martin Stiemerling >> >> TUESDAY, March 20, 2007 >> 0900-1130 Morning Session I >> >> * Agenda Bashing (10 minutes) >> NOTE WELL >> Document Status and Accomplishments >> Milestones Review >> >> * GIST - Robert Hancock (20 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt >> >> * QoS NSLP - Jukka Manner (20 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt >> >> * NAT/FW NSLP - Hannes Tschofenig/Martin Stiemerling (10 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-14.txt >> >> * Mobility Applicability Statement - Takako Sanda (20 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-=20 >> mobility-signaling-06.txt >> >> * QSPEC - Jerry Ash (10 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt >> >> * RMD-QOSM - Georgios Karagiannis (15 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt >> * Y.1541 QOSM - TBD (15 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-03.txt >> * NSIS Operation over IP Tunnels - TBD (10 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-02.txt >> >> * GIST state machine - TBD (10 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-12.txt >> * GIST over SCTP - Christian Dickmann (10 minutes) >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-01.txt >> >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 >> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 08:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPewZ-0002le-OG; Fri, 09 Mar 2007 08:15:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPewW-0002lU-Ew for nsis@ietf.org; Fri, 09 Mar 2007 08:15:33 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPewI-0005nK-9S for nsis@ietf.org; Fri, 09 Mar 2007 08:15:32 -0500 Received: (qmail invoked by alias); 09 Mar 2007 13:15:16 -0000 Received: from p54987974.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.121.116] by mail.gmx.net (mp016) with SMTP; 09 Mar 2007 14:15:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ye4JLE/ryMy2Rogl2vWw1R1sV9f2xgRQnvcDRXr HKfextch3jhx3+ Message-ID: <45F15DE3.3040201@gmx.net> Date: Fri, 09 Mar 2007 15:15:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [NSIS] QSPEC Draft Review X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I reviewed the QSPEC draft (a little bit late but the WGLC ran during the draft submission deadline period). In addition to the comments I made in past review comments already (and that were already mentioned by Robert in his recent review as well) I would like to point to the following issues: * Am I allowed to register new QoS parameters without defining a new QoSM? * Section 5.4: This text block has to be removed: " The set of QSPEC parameters defined herein is at this point in time considered complete. Additional QSPEC parameters may be defined in the future. However, since this requires an update of all QNEs, this should be considered carefully. The definition of new QSPEC parameter requires standards action and an update of this document. Such an update also needs a new QSPEC version number. Furthermore, all QOSM definitions must be updated to include how the new QSPEC parameter is to be interpreted in the respective QOSM. " since it is not correct anymore (I hope at least). Regarding " Additional QSPEC parameters MAY need to be defined in the future and are defined in separate informational documents specific to a given QOSM. For example, QSPEC parameters are defined in [RMD-QOSM] and [Y.1541-QOSM]. " - I would not use RFC 2119 language here. - Additional QoS parameters do not need informational documents -> see IANA consideration section. I would delete the entire section since it is meaningless. * In the IANA consideration section you write: " Note that if additional QSPEC parameters are defined in the future, this requires a standards action equivalent to reissuing this document as a QSPEC-bis. " I suspect that this is a left-over from old days and has to be deleted. * You have Y.1541 and Y.1571 in the normative references. What are the rules for dealing with non-IETF documents? Are these documents publically available? * Are the references [3GPP-1],[3GPP-2] and [3GPP-3] really normative references? I thought that they were just mentioned informally. * Acknowledgments and Contributors Dave Oran is still listed in the acknowledgments section. There are many contributors listed even though, for most of them, I have not seen them discussing anything on the list while some of the listed persons in the acknowledgment list have spent a lot of time fixing the document over several years. There might be a misbalance. I must admit that I am in general not excited about the way how people are acknowledged in IETF drafts in general given that they are "allowed" to fix documents of draft authors but they get no reward. * You write: "The excess treatment parameter is set by the QNI. It cannot be overwritten." Why not? Why cannot the AAA server set a value that is different to the one set by the initiator? * The IDNITS tool told me the following: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: Nothing found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: * There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: Nothing found here. Checking references for intended status: Proposed Standard - Missing Reference: 'QOS-SIG' is mentioned on line 1312, but not defined - Possible downref: Undefined Non-RFC (?) reference : ref. 'QOS-SIG' - Missing Reference: 'S' is mentioned on line 1704, but not defined - Possible downref: Undefined Non-RFC (?) reference : ref. 'S' - Unused Reference: 'RFC4506' is defined on line 2323, but not referenced - Unused Reference: 'IEEE754' is defined on line 2335, but not referenced - Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2341, but not referenced - Unused Reference: 'RFC3564' is defined on line 2367, but not referenced - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-1' - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-2' - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-3' - Possible downref: Non-RFC (?) normative reference: ref. 'GIST' - Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' Summary: 1 error, 14 warnings Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 10:24:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgwE-0002Zo-JK; Fri, 09 Mar 2007 10:23:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgwD-0002W0-A1 for nsis@ietf.org; Fri, 09 Mar 2007 10:23:21 -0500 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgvK-0004MS-VW for nsis@ietf.org; Fri, 09 Mar 2007 10:22:29 -0500 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 16C9325F74B for ; Fri, 9 Mar 2007 15:22:12 +0000 (WET) Received: from [193.136.207.159] (dhcp-eucpii-159.ci.uc.pt [193.136.207.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id EDF4A25F6C4 for ; Fri, 9 Mar 2007 15:22:11 +0000 (WET) Message-ID: <45F17BA3.60708@dei.uc.pt> Date: Fri, 09 Mar 2007 15:22:11 +0000 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: NSIS Group Content-Type: multipart/mixed; boundary="------------090409060401050107040605" X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [NSIS] [Fwd: I-D ACTION:draft-cordeiro-nsis-hypath-03.txt] X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --------------090409060401050107040605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

The new version of HyPath draft was submitted. This new version includes a lot of changes from the previous. Please take some time to read it.

This new HyPath approach proposes a creation of a the Message Routing Method (MRM) for GIST.

There are two possible approaches to adapt GIST to the hybrid solution:
  - A new MRM;
  - A Path-Coupled MRM extension.

The creation of a new GIST MRM adapts the GIST signaling with the HyPath functionalities in an independent way of the existing MRMs. On the other hand, by extending the current Path-Coupled MRM (adding additional fields) it is possible to maintain the usual path-coupled functionalities and, when required, have the additional HyPath functionalities.This can be achieved by adding a new flag in the reserved area of the MRM (after the already specified D Flag). NSIS entities that are configured to process HyPath messages can search for this flag in Path-Coupled MRM, while other entities naturally ignore  it and process the message normally (ignoring all extra HyPath fields). The HyPath MRM is described in the section 3.5.3 of the draft.

The GIST changes to allow these solutions are few and SHOULD not influence the other functionalities.

Please provide me your comments about this new approach and your opinion about the best solution from the two presented.

BR,
Luís Cordeiro

-------- Original Message --------
Subject: I-D ACTION:draft-cordeiro-nsis-hypath-03.txt
Date: Wed, 07 Mar 2007 18:50:02 -0500
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: GIST Extension for Hybrid On-path Off-path Signaling (HyPath)
	Author(s)	: L. Cordeiro, et al.
	Filename	: draft-cordeiro-nsis-hypath-03.txt
	Pages		: 29
	Date		: 2007-3-7
	
In a multi-domain Internet that offers QoS guaranties for
   applications, there is the need of signaling among the domain
   entities which are responsible for QoS management.  Because different
   do the HyPath approach uses the NSIS protocol and interactions with
   the local routing protocols to achieve an off path signaling in
   hybrid environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-cordeiro-nsis-hypath-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-cordeiro-nsis-hypath-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------090409060401050107040605 Content-Type: Message/External-body; name="draft-cordeiro-nsis-hypath-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-cordeiro-nsis-hypath-03.txt" Content-Type: text/plain Content-ID: <2007-3-7153900.I-D@ietf.org> --------------090409060401050107040605 Content-Type: text/plain; name*0="file:///C|/DOCUME%7E1/CORDEIRO/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/CORDEIRO/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------090409060401050107040605 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --------------090409060401050107040605-- From nsis-bounces@ietf.org Fri Mar 09 12:47:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjAo-0007Mm-4O; Fri, 09 Mar 2007 12:46:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjAm-0007Lw-Rn for nsis@ietf.org; Fri, 09 Mar 2007 12:46:32 -0500 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPjAk-0007vw-IJ for nsis@ietf.org; Fri, 09 Mar 2007 12:46:32 -0500 Received: from win2003.dickmann2003.home (p548A4AAB.dip.t-dialin.net [84.138.74.171]) by www.difra-computer.de (Postfix) with ESMTP id 8E1B33E4030 for ; Fri, 9 Mar 2007 18:41:56 +0100 (CET) Received: from [127.0.0.1] ([192.168.30.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 18:28:43 +0100 Message-ID: <45F19C6A.5060108@christian-dickmann.de> Date: Fri, 09 Mar 2007 12:42:02 -0500 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2007 17:28:43.0811 (UTC) FILETIME=[62E0D730:01C76270] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] GIST Q-Mode Encapsulation Magic Number X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I just read the new GIST draft version (-12) with respect to the new magic number which is sent in front of the Q-Mode packets. From my point of view, the magic number definition is quite well hidden in Section 5.3.2.3. I thought it should be part of the Bit-Level Format Appendix, as it is part of how a GIST packet looks like. In addition, Section 5.1 does not indicate at all, that there is something in front of a GIST packet. Maybe thats a stupid idea, but from an implementors point of view it would be much easier to make the magic number part of the Common Header. This way, it is always included (OK, waste of 4 bytes in non-Queries) which makes it more obvious w.r.t. the specification and makes implementation easier as well. Is there any reason besides wasting 4 bytes for non-Queries to NOT make it part of the Common Header? Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 09 16:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmVT-0007fm-SK; Fri, 09 Mar 2007 16:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmVT-0007fC-Bw for nsis@ietf.org; Fri, 09 Mar 2007 16:20:07 -0500 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPmVS-0006lb-2X for nsis@ietf.org; Fri, 09 Mar 2007 16:20:07 -0500 Received: from win2003.dickmann2003.home (p548A4AAB.dip.t-dialin.net [84.138.74.171]) by www.difra-computer.de (Postfix) with ESMTP id 281F23E4030 for ; Fri, 9 Mar 2007 22:15:31 +0100 (CET) Received: from [127.0.0.1] ([192.168.30.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 22:02:17 +0100 Message-ID: <45F1CE86.6080802@christian-dickmann.de> Date: Fri, 09 Mar 2007 16:15:50 -0500 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2007 21:02:17.0416 (UTC) FILETIME=[3861CC80:01C7628E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] Use of 3-Way Handshake in D-Mode case X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, section 4.3.3 "Message Transmission" states: "If a messaging association is not required, the message is sent in D-mode. The processing in this case depends on the message type and whether routing state exists or not. ... - If the message is not a Query, and routing state exists, ... - If the message is a Query, ... - If no routing state exists, GIST can attempt to use Q-mode as in the Query case. ..." Thus, for a message that is not a Query and where no routing state exists, the third rule applies. The third rule gives only the option of sending the message in Q-mode. Does that mean, that there is no way to carry out a 3-way handshake just for transport of D-Mode messages? The SendMessage primitive has a parameter that suggests "whether GIST should attempt to set up or maintain forward routing state." Also text like "A Confirm MUST be sent in C-mode if a messaging association is being used for this routing state" suggests that there is case of having routing state without C-Mode. Am I missing something? Regards, Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 10 18:27:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQAxa-0001ss-H6; Sat, 10 Mar 2007 18:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQAxZ-0001sn-OR for nsis@ietf.org; Sat, 10 Mar 2007 18:26:45 -0500 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQAxY-0002MN-Eu for nsis@ietf.org; Sat, 10 Mar 2007 18:26:45 -0500 Received: from win2003.dickmann2003.home (p548A7EBF.dip.t-dialin.net [84.138.126.191]) by www.difra-computer.de (Postfix) with ESMTP id 054F53E4030 for ; Sun, 11 Mar 2007 00:22:01 +0100 (CET) Received: from [127.0.0.1] ([192.168.28.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 00:09:00 +0100 Message-ID: <45F33D9D.5020706@christian-dickmann.de> Date: Sat, 10 Mar 2007 18:22:05 -0500 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2007 23:09:01.0958 (UTC) FILETIME=[17749260:01C76369] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [NSIS] MA re-use mechanism in case of TCP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, I am not 100% sure if I already asked this question (I know I intended to do so once, but I can't find any mail I sent about the issue). Section 5.7.1 says about MA re-use: "If multiplexing does occur, which is indicated by sending the Response over an existing messaging association, the following rules apply: o The re-used messaging association MUST NOT have weaker security properties than would have been offered in the full Response that would have been sent without re-use." And it also states: " For such a Response, the security protocols listed in the Stack-Proposal MUST NOT depend on the Query." As a standard GIST nodes should at least support TCP and TLS over TCP, the majority of all Responses will offer both. Using the rule I quoted first means, that the Responder is not allowed to decide to re-use a TCP-only MA, because it is always weaker than the TLS over TCP profile. If that is correct, I think it should be stated somewhere, because the other text in the draft suggests (at least thats what I read) that a re-use of a TCP connection would use the standard procedure (send the Response over the MA). So am I reading these rules correctly? Is this the intended protocol behavior? Do you agree that the TCP case should be stated more explicitly to avoid misunderstanding? Best Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 10 18:43:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBDI-0002qx-DD; Sat, 10 Mar 2007 18:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBDH-0002qs-99 for nsis@ietf.org; Sat, 10 Mar 2007 18:42:59 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQBDD-0004yP-KG for nsis@ietf.org; Sat, 10 Mar 2007 18:42:58 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1173570174!9284869!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28191 invoked from network); 10 Mar 2007 23:42:54 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-121.messagelabs.com with SMTP; 10 Mar 2007 23:42:54 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2ANgs6P008265; Sat, 10 Mar 2007 18:42:54 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2ANgmcY008260; Sat, 10 Mar 2007 18:42:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Sat, 10 Mar 2007 17:42:47 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Thread-Index: AcdiOYFURR0mhumWRnW0vj/0aegsEwBLtl+Q References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> From: "ASH, GERALD R, ATTLABS" To: "Martin Stiemerling" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, Please see below.=20 > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: Friday, March 09, 2007 5:55 AM > To: nsis > Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft >=20 > [writing with chair's hat off] >=20 > Hi all, >=20 > I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue =20 > which came up during the WGLC for the QSPEC draft. >=20 > The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the =20 > QSPEC-Type is > - initiator QSPEC or > - local QSPEC. >=20 > When reading the text first I thought that is fine, but given all =20 > discussions afterwards and reading again the QSPEC I have now some =20 > doubts. I assume two approaches here how to deal with identifying =20 > QOSMs on a QNE. >=20 > 1. Roland's approach with QSPEC-Type identifying the type of QSPEC =20 > signalled for (e.g., RMD, Y.1541. etc) (also favoured by Georgios) > 2. The current QSPEC approach with QSPEC-Type just saying initiator =20 > or local QSPEC. I don't think there are 2 approaches. =20 The QSPEC Type has so far been defined with 2 values assigned in the IANA section, but an IANA registry is defined so that more QSPEC Types can be defined, satisfying approach #1. I don't think there is an approach #2 with only 2 values defined. If the intent is to make QSPEC Type equivalent to QOSM ID (as defined in the QSPEC-12 draft), as I infer from the discussion, then I think we need to: - redefine QSPEC Type 0 =3D no QOSM supported by QNE (it is allowed to = not support any QOSM) - define additional QSPEC Types as specified in the IANA registry, and - use a separate bit to identify the initiator/local QSPEC (as proposed by Georgios). However, what isn't clear in the discussion so far is exactly how the QSPEC Type/QOSM ID information would be used by a QNE. For example, suppose the QNI supports CL-QSPEC Type and signals that. Suppose also that a downstream QNE supports the following: Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type information from the QNI, exactly how is the information used by the QNE? Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does the QNE do with the CL-QSPEC Type information from the QNI, exactly how is the information used by the QNE? Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type information from the QNI, exactly how is the information used by the QNE? Case 4: QNE support no QSPEC Types, Case 3: QNE supports CL-QSPEC-Type and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC-Type information from the QNI, exactly how is the information used by the QNE? We could define another 4 cases where the QNI signals QSPEC Type =3D no QOSM supported. What are the corresponding answers to the above questions for those scenarios? It would be very helpful IMO if this was clarified in more detail than it has been so far. > With approach 1. it is straight forward how to identify to which =20 > local RMF to forward the received QSPEC. Is it, I haven't seen yet how it is 'straightforward to identify which 'local RMF' to forward the received QSPEC? Please see the above examples and let us know how it works for those 8 cases. > With approach 2 I assume only RMF per QNE. The RMF on the node then =20 > automatically knows what the possible local QOSM can be (and =20 > remembers this). I one of my past emails I wrote this >=20 > > > > I believe that the QOSM ID is not needed as there is only=20 > one local =20 > > RMF per QNE. This local RMF can actually support multiple=20 > QOSMs but =20 > > this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the =20 > > chance to pass the QSPEC in a single piece to a single RMF. > > The mapping between the different initiator QOSM and the=20 > local QOSM =20 > > is solely happening within the RMF. >=20 > What is not clear for approach 2 for me: How does a RMF on a QNE =20 > distinguish between the possible available QOSMs? Does the QSPEC =20 > assume that the RMFs in one part of a network do know which QOSM is =20 > used by heart? Well, of course not. See the above comments, I don't think there is an approach #2 with only 2 QSPEC Type values, more can be defined as described.=20 Thanks, Jerry =20 >=20 > Thanks in advance, >=20 > Martin >=20 >=20 > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 10 19:16:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBiw-0002x7-Q3; Sat, 10 Mar 2007 19:15:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBiu-0002w2-RW for nsis@ietf.org; Sat, 10 Mar 2007 19:15:40 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQBit-0002OO-Ht for nsis@ietf.org; Sat, 10 Mar 2007 19:15:40 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-146.messagelabs.com!1173572134!12668260!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30545 invoked from network); 11 Mar 2007 00:15:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-146.messagelabs.com with SMTP; 11 Mar 2007 00:15:34 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2B0FYkh012482; Sat, 10 Mar 2007 19:15:34 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2B0CbBv012110; Sat, 10 Mar 2007 19:15:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Date: Sat, 10 Mar 2007 18:13:19 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82D2@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Thread-Index: AcdeoYW/yVJxR2etTna0a0jRox1uSwBQTzTwAHEVUQAAISzIIABQyNWA References: <9473683187ADC049A855ED2DA739ABCA0DDC82BD@KCCLUST06EVS1.ugd.att.com> From: "ASH, GERALD R, ATTLABS" To: "Hancock, Robert" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Please see below. > > > s4.3.1 final para: i would use a word other than=20 > > >'composed' for the=20 > > > first three instances ('input' and 'output'?) > > These is quite common terminology used in other RFCs to mean=20 > > 'accumulated' values, see for example RFC 2210=20 > > http://www.ietf.org/rfc/rfc2210.txt?number=3D2210 and search=20 > > the word "composed" (object names even use the word). > maybe 'input composed' and so on; but i'm not that fussed > (i managed to work it out anyway) Would this revised text clarify: The output composed value is the minimum of the QNE's value and the input composed value for r, b, and p, and the maximum of the QNE's value and the input composed value for m. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal TMOD resources along the path from QNI to QNR. > > > s4.3.2 para 2: if the delay includes queuing, i would add this=20 > > > explicitly to the 2nd sentence. (currently, it implies it=20 > > > is limited=20 > > > to propagation and processing delays, and it is not=20 > > > obvious whether=20 > > > queuing is a type of processing.) Also, it needs to be=20 > > > clear if it is=20 > > > the mean queuing delay or some other statistic of the=20 > > > delay (since=20 > > > variability is covered in the next paragraph under jitter). > > The third sentence in the paragraph says "The mean delay=20 > > reflects the variable queuing delay that may be present." I=20 > > think that clarifies your issues? > it's actually that sentence which caused the confusion. wouldn't it > be easier to have the second sentence say > "This delay results from the combination of speed-of-light propagation > delay, packet processing, and queueing." ? Yes, that's fine, thanks for the text. > > > s4.3.3 para 1: i don't see how the second two sentences=20 > > > here relate to=20 > > > TH directives. Could they be deleted? I think the message=20 > > > is already=20 > > > stated earlier in the document. > > I agree that this text may be a bit repetitious. However,=20 > > there was a very long discussion regarding this text (see=20 > > NSIS archive) and it was agreed that this text was the=20 > > resolution of the discussion. I don't think we can delete it. > i agree the text is needed; it's just that it seems you already > have it in section 4.1.1 (in a more complete form, in fact) > which also seems the right place for it. I agree that the 2nd paragraph in Section 4.1 says more or less the same thing in a more complete form. However, I think the intent was to associate the text referring to 'RMF triggers' with the 'traffic handling directives' parameters being discussed in Section 4.3.3. So perhaps we can just make a backward reference to Section 4.1, e.g., In addition, as discussed in Section 4.1, an application MAY like to define RMF=20 triggers that cause the QoS NSLP to run semantics within the=20 underlying QoS NSLP signaling state and messaging processing rules,=20 as defined in Section 5.2 of [QoS-SIG]. Note, however, that new QoS=20 NSLP message processing rules can only be defined in Standards Track extensions to the QoS NSLP. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 10 19:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBsS-0007n8-MI; Sat, 10 Mar 2007 19:25:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBsS-0007mw-1z for nsis@ietf.org; Sat, 10 Mar 2007 19:25:32 -0500 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQBsQ-0003IQ-PE for nsis@ietf.org; Sat, 10 Mar 2007 19:25:32 -0500 Received: from win2003.dickmann2003.home (p548A7EBF.dip.t-dialin.net [84.138.126.191]) by www.difra-computer.de (Postfix) with ESMTP id 135EE3E4030 for ; Sun, 11 Mar 2007 01:21:03 +0100 (CET) Received: from [127.0.0.1] ([192.168.28.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 01:08:18 +0100 Message-ID: <45F34B86.1010902@christian-dickmann.de> Date: Sat, 10 Mar 2007 19:21:26 -0500 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2007 00:08:19.0012 (UTC) FILETIME=[5F9FF040:01C76371] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [NSIS] GIST: Is Loose-End MRM REQUIRED? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, I noticed that TCP and TLS over TCP are REQUIRED in the RFC 2119 sense. In addition, for the PC-MRM the downstream encapsulation is REQUIRED, while upstream encapsulation is OPTIONAL (for the sending part). However, the MRMs themselves have no text stating that they are REQUIRED. I would assume that support for PC-MRM is REQUIRED, while support for LE-MRM is OPTIONAL, because there might be special GIST implementations just meant to work with QoS NSLP which do not need LE-MRM to work. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 11 06:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQLAB-0006zn-8b; Sun, 11 Mar 2007 06:20:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQLAA-0006r4-AM for nsis@ietf.org; Sun, 11 Mar 2007 06:20:26 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQL9y-00071a-Gb for nsis@ietf.org; Sun, 11 Mar 2007 06:20:18 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2BAJesZ020915; Sun, 11 Mar 2007 10:19:40 GMT Received: from ehlaptop ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 10:19:40 +0000 From: "Robert Hancock" To: "'ASH, GERALD R, ATTLABS'" , "'nsis'" References: <9473683187ADC049A855ED2DA739ABCA0DDC82BD@KCCLUST06EVS1.ugd.att.com> <9473683187ADC049A855ED2DA739ABCA0DDC82D2@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt Date: Sun, 11 Mar 2007 10:19:42 -0000 Message-ID: <00be01c763c6$c92c3320$0100c90a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdeoYW/yVJxR2etTna0a0jRox1uSwBQTzTwAHEVUQAAISzIIABQyNWAABX0rYA= In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82D2@KCCLUST06EVS1.ugd.att.com> X-OriginalArrivalTime: 11 Mar 2007 10:19:40.0329 (UTC) FILETIME=[C764B990:01C763C6] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org jerry, these would all be fine by me. thanks, r. > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > Sent: 11 March 2007 00:13 > To: Hancock, Robert; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt > > Hi Robert, > > Please see below. > > > > > s4.3.1 final para: i would use a word other than 'composed' for > > > >the first three instances ('input' and 'output'?) > > > > These is quite common terminology used in other RFCs to mean > > > 'accumulated' values, see for example RFC 2210 > > > http://www.ietf.org/rfc/rfc2210.txt?number=2210 and > search the word > > > "composed" (object names even use the word). > > > maybe 'input composed' and so on; but i'm not that fussed > (i managed > > to work it out anyway) > > Would this revised text clarify: > > The output composed value is the minimum of the QNE's value and the > input composed value for r, b, and p, and the maximum of the > QNE's value and the input composed value for m. This quantity, > when composed end-to-end, informs the QNR (or QNI in a RESPONSE > message) of the minimal TMOD resources along the path from QNI to > QNR. > > > > > s4.3.2 para 2: if the delay includes queuing, i would add this > > > > explicitly to the 2nd sentence. (currently, it implies it is > > > > limited to propagation and processing delays, and it is not > > > > obvious whether queuing is a type of processing.) Also, > it needs > > > > to be clear if it is the mean queuing delay or some other > > > > statistic of the delay (since variability is covered in > the next > > > > paragraph under jitter). > > > > The third sentence in the paragraph says "The mean delay reflects > > > the variable queuing delay that may be present." I think that > > > clarifies your issues? > > > it's actually that sentence which caused the confusion. > wouldn't it be > > easier to have the second sentence say "This delay results from the > > combination of speed-of-light propagation delay, packet processing, > > and queueing." ? > > Yes, that's fine, thanks for the text. > > > > > s4.3.3 para 1: i don't see how the second two sentences here > > > > relate to TH directives. Could they be deleted? I think the > > > > message is already stated earlier in the document. > > > > I agree that this text may be a bit repetitious. > However, there was > > > a very long discussion regarding this text (see NSIS > archive) and it > > > was agreed that this text was the resolution of the > discussion. I > > > don't think we can delete it. > > > i agree the text is needed; it's just that it seems you > already have > > it in section 4.1.1 (in a more complete form, in fact) which also > > seems the right place for it. > > I agree that the 2nd paragraph in Section 4.1 says more or > less the same thing in a more complete form. However, I > think the intent was to associate the text referring to 'RMF > triggers' with the 'traffic handling directives' parameters > being discussed in Section 4.3.3. So perhaps we can just > make a backward reference to Section 4.1, e.g., > > In addition, as discussed in Section 4.1, > an application MAY like to define RMF > triggers that cause the QoS NSLP to run semantics within the > underlying QoS NSLP signaling state and messaging > processing rules, > as defined in Section 5.2 of [QoS-SIG]. Note, however, > that new QoS > NSLP message processing rules can only be defined in > Standards Track > extensions to the QoS NSLP. > > Thanks, > Jerry > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 11 09:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQOEb-0002d2-UX; Sun, 11 Mar 2007 09:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQOEZ-0002cx-Rp for nsis@ietf.org; Sun, 11 Mar 2007 09:37:11 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQOEW-0007MV-DP for nsis@ietf.org; Sun, 11 Mar 2007 09:37:11 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1173620227!15898274!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 22855 invoked from network); 11 Mar 2007 13:37:07 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-121.messagelabs.com with SMTP; 11 Mar 2007 13:37:07 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2BDb71C015427; Sun, 11 Mar 2007 09:37:07 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2BDb0Gs015409; Sun, 11 Mar 2007 09:37:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Draft Review Date: Sun, 11 Mar 2007 08:37:00 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F15DE3.3040201@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Draft Review Thread-Index: AcdiTTaQ3BFJBNZmRqiWLa2TnYA+HwBj7Jiw References: <45F15DE3.3040201@gmx.net> From: "ASH, GERALD R, ATTLABS" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes,=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, March 09, 2007 8:15 AM > To: nsis@ietf.org > Subject: [NSIS] QSPEC Draft Review >=20 > Hi all, >=20 > I reviewed the QSPEC draft (a little bit late but the WGLC ran during=20 > the draft submission deadline period). >=20 > In addition to the comments I made in past review comments=20 > already (and=20 > that were already mentioned by Robert in his recent review as well) I=20 > would like to point to the following issues: >=20 > * Am I allowed to register new QoS parameters without=20 > defining a new QoSM? Yes, as discussed on the list http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html. =20 > * Section 5.4: >=20 > This text block has to be removed: > " >=20 > The set of QSPEC parameters defined herein is at this point in time > considered complete. Additional QSPEC parameters may be defined in > the future. However, since this requires an update of all=20 > QNEs, this > should be considered carefully. The definition of new QSPEC > parameter requires standards action and an update of this document. > Such an update also needs a new QSPEC version number. Furthermore, > all QOSM definitions must be updated to include how the new QSPEC > parameter is to be interpreted in the respective QOSM. >=20 > " > since it is not correct anymore (I hope at least). Yes, as discussed on the list http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html. =20 > Regarding > " > Additional QSPEC parameters MAY need to be defined in the future > and are defined in separate informational documents specific to a > given QOSM. For example, QSPEC parameters are defined in > [RMD-QOSM] and [Y.1541-QOSM]. > " >=20 > - I would not use RFC 2119 language here. > - Additional QoS parameters do not need informational=20 > documents -> see=20 > IANA consideration section. >=20 > I would delete the entire section since it is meaningless. It will be clarified as discussed on the list http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html. > * In the IANA consideration section you write: > " > Note that if additional QSPEC parameters are > defined in the future, this requires a standards action=20 > equivalent to > reissuing this document as a QSPEC-bis. > " >=20 > I suspect that this is a left-over from old days and has to=20 > be deleted. Yes, as discussed on the list http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html. =20 > * You have Y.1541 and Y.1571 in the normative references.=20 > What are the=20 > rules for dealing with non-IETF documents? Are these documents=20 > publicly available? Yes. Non-IETF documents are allowed as normative references. =20 > * Are the references [3GPP-1],[3GPP-2] and [3GPP-3] really normative=20 > references? I thought that they were just mentioned informally. Yes. Non-IETF documents are allowed as normative references. > * Acknowledgments and Contributors >=20 > Dave Oran is still listed in the acknowledgments section.=20 > There are many=20 > contributors listed even though, for most of them, I have not=20 > seen them=20 > discussing anything on the list while some of the listed=20 > persons in the=20 > acknowledgment list have spent a lot of time fixing the document over=20 > several years. There might be a misbalance. I must admit that I am in=20 > general not excited about the way how people are acknowledged in IETF=20 > drafts in general given that they are "allowed" to fix documents of=20 > draft authors but they get no reward. >=20 > * You write: "The excess treatment parameter is set by the QNI. It=20 > cannot be overwritten." >=20 > Why not? Why cannot the AAA server set a value that is different to=20 > the one set by the initiator? Parameter is read-only, what would it mean to overwrite what the QNI has already specified? =20 > * The IDNITS tool told me the following: >=20 > Checking boilerplate required by RFC 3978 and 3979, updated=20 > by RFC 4748: > Nothing found here. >=20 > Checking nits according to=20 > http://www.ietf.org/ietf/1id-guidelines.txt: > - No 'Intended status' indicated for this document;=20 > assuming Proposed > Standard >=20 > Checking nits according to http://www.ietf.org/ID-Checklist.html: > * There are 1 instance of lines with non-RFC3330-compliant=20 > IPv4 addresses > in the document. If these are example addresses, they should be=20 > changed. >=20 > Miscellaneous warnings: > Nothing found here. >=20 > Checking references for intended status: Proposed Standard > - Missing Reference: 'QOS-SIG' is mentioned on line 1312,=20 > but not defined > - Possible downref: Undefined Non-RFC (?) reference : ref. 'QOS-SIG' > - Missing Reference: 'S' is mentioned on line 1704, but not defined > - Possible downref: Undefined Non-RFC (?) reference : ref. 'S' > - Unused Reference: 'RFC4506' is defined on line 2323, but=20 > not referenced > - Unused Reference: 'IEEE754' is defined on line 2335, but=20 > not referenced > - Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line=20 > 2341, but not > referenced > - Unused Reference: 'RFC3564' is defined on line 2367, but=20 > not referenced > - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-1' > - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-2' > - Possible downref: Non-RFC (?) normative reference: ref. '3GPP-3' > - Possible downref: Non-RFC (?) normative reference: ref. 'GIST' > - Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' >=20 > Summary: 1 error, 14 warnings OK. I always check idnits too. Thanks, Jerry >=20 >=20 > Ciao > Hannes >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 11 14:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSud-0001BL-0Q; Sun, 11 Mar 2007 14:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSub-0001BG-HS for nsis@ietf.org; Sun, 11 Mar 2007 14:36:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQSua-0007Zw-4X for nsis@ietf.org; Sun, 11 Mar 2007 14:36:53 -0400 Received: (qmail invoked by alias); 11 Mar 2007 18:36:50 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp015) with SMTP; 11 Mar 2007 19:36:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/4zMJUiYr4wENa4zkdLF+Pa3fZ9wFev5mnSa7xfg j5c2b1VgQNVQVs Message-ID: <45F44C40.7080103@gmx.net> Date: Sun, 11 Mar 2007 20:36:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] QSPEC Draft Review References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Good to see that all these issues will be addressed with the next draft update. >> * You write: "The excess treatment parameter is set by the QNI. It >> cannot be overwritten." >> >> Why not? Why cannot the AAA server set a value that is different to >> the one set by the initiator? >> > > Parameter is read-only, what would it mean to overwrite what the QNI has > already specified? > The authorization decision by a policy server may do whatever it wants regardless whether the QNI said it wants to have a certain treatment. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 06:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQhT9-0003AF-9b; Mon, 12 Mar 2007 06:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQhT8-0003A3-6p for nsis@ietf.org; Mon, 12 Mar 2007 06:09:30 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQhT6-0002eC-Kl for nsis@ietf.org; Mon, 12 Mar 2007 06:09:30 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2CA9I8e017204; Mon, 12 Mar 2007 11:09:25 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R, ATTLABS'" , "'Martin Stiemerling'" , "'nsis'" References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Mon, 12 Mar 2007 11:09:13 +0100 Message-ID: <000501c7648e$7f190bf0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdiOYFURR0mhumWRnW0vj/0aegsEwBLtl+QAEifmRA= X-Spam-Score: 0.237 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 12 Mar 2007 11:09:26 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Please see in line! > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > Sent: zondag 11 maart 2007 0:43 > To: Martin Stiemerling; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > > Hi Martin, > > Please see below. > > > -----Original Message----- > > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > > Sent: Friday, March 09, 2007 5:55 AM > > To: nsis > > Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > > > > [writing with chair's hat off] > > > > Hi all, > > > > I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue > > which came up during the WGLC for the QSPEC draft. > > > > The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the > > QSPEC-Type is > > - initiator QSPEC or > > - local QSPEC. > > > > When reading the text first I thought that is fine, but given all > > discussions afterwards and reading again the QSPEC I have now some > > doubts. I assume two approaches here how to deal with identifying > > QOSMs on a QNE. > > > > 1. Roland's approach with QSPEC-Type identifying the type of QSPEC > > signalled for (e.g., RMD, Y.1541. etc) (also favoured by > Georgios) 2. > > The current QSPEC approach with QSPEC-Type just saying initiator or > > local QSPEC. > > I don't think there are 2 approaches. > > The QSPEC Type has so far been defined with 2 values assigned > in the IANA section, but an IANA registry is defined so that > more QSPEC Types can be defined, satisfying approach #1. I > don't think there is an approach #2 with only 2 values defined. > > If the intent is to make QSPEC Type equivalent to QOSM ID (as > defined in the QSPEC-12 draft), as I infer from the > discussion, then I think we need to: > - redefine QSPEC Type 0 = no QOSM supported by QNE (it is > allowed to not support any QOSM) Georgios: I think that according to the QSPEC template draft, this is not possible. A QNE will have to at least support the mandatory parameters. Thus a QNI will include the QOSM ID in the QSPEC object. If a downstream QNE cannot support the QOSM then it will only process the mandatory parameter and if needed mark with N the parameters that are not understood. I think it is good to have the additional bit that specifies that a QOSM is initial or local. In this way the received QSPEC will be processed, depending on what was specified by the QNI, by an initial or local QOSM. In the situation that the QNE that receives the QSPEC is not supporting the QOSM associated with the received QSPEC, then the QNE has to decide to be processed by a default initial QOSM (if it the included QSPEC is initial QSPEC) or by a default local QOSM (if it the included QSPEC is local QSPEC). > - define additional QSPEC Types as specified in the IANA registry, and Georgios: yes, I agree > - use a separate bit to identify the initiator/local QSPEC > (as proposed by Georgios). Georgios: Yes I agree, see above! I think it is good to have the additional bit that specifies that a QOSM is initial or local. In this way the received QSPEC will be processed, depending on what was specified by the QNI, by an initial or local QOSM. In the situation that the QNE that receives the QSPEC is not supporting the QOSM associated with the received QSPEC, then the QNE has to decide to be processed by a default initial QOSM (if it the included QSPEC is initial QSPEC) or by a default local QOSM (if it the included QSPEC is local QSPEC). > > However, what isn't clear in the discussion so far is exactly > how the QSPEC Type/QOSM ID information would be used by a > QNE. For example, suppose the QNI supports CL-QSPEC Type and > signals that. Suppose also that a downstream QNE supports > the following: > Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what > does the QNE do with the CL-QSPEC Type information from the > QNI, exactly how is the information used by the QNE? Georgios: By using the additional bit, the QNE will know that the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a local QSPEC. In this way the QNE wil know how to handle the CL-QSPEC and how to handle the RMD-QSPEC. > Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, > what does the QNE do with the CL-QSPEC Type information from > the QNI, exactly how is the information used by the QNE? Georgios: Again, by using the additional bit the CL-QSPEC will be identified as initial QSPEC and the RMD-QSPEC Type, Y1541-QSPEC as local. The QNE then should use an internal policy that for example says RMD-QSPEC is used on interface 1 and that the Y1541-QSPEC is used on interface 2. > Case 3: QNE only supports RMD-QSPEC Type, what does the QNE > do with the CL-QSPEC Type information from the QNI, exactly > how is the information used by the QNE? Georgios: By using the additional bit, the QNE will know that the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a local QSPEC. In this way the QNE wil know how to handle the CL-QSPEC and How to handle the RMD-QSPEC. > Case 4: QNE support no QSPEC Types, Case 3: QNE supports > CL-QSPEC-Type and RMD-QSPEC Type, what does the QNE do with > the CL-QSPEC-Type information from the QNI, exactly how is > the information used by the QNE? Note that a QNE even if it does not support any QOSM, according to the QSPEC template, it has to support the mandatory parameters and mark with N the optional parameters. > > We could define another 4 cases where the QNI signals QSPEC > Type = no QOSM supported. What are the corresponding answers > to the above questions for those scenarios? Georgios: According to the QSPEC template, I think that this is not possible! > > It would be very helpful IMO if this was clarified in more > detail than it has been so far. > > > With approach 1. it is straight forward how to identify to > which local > > RMF to forward the received QSPEC. > > Is it, I haven't seen yet how it is 'straightforward to > identify which 'local RMF' to forward the received QSPEC? > Please see the above examples and let us know how it works > for those 8 cases. > > > With approach 2 I assume only RMF per QNE. The RMF on the node then > > automatically knows what the possible local QOSM can be > (and remembers > > this). I one of my past emails I wrote this > > > > > > > > I believe that the QOSM ID is not needed as there is only > > one local > > > RMF per QNE. This local RMF can actually support multiple > > QOSMs but > > > this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the > > > chance to pass the QSPEC in a single piece to a single RMF. > > > The mapping between the different initiator QOSM and the > > local QOSM > > > is solely happening within the RMF. > > > > What is not clear for approach 2 for me: How does a RMF on a QNE > > distinguish between the possible available QOSMs? Does the QSPEC > > assume that the RMFs in one part of a network do know which QOSM is > > used by heart? > > Well, of course not. See the above comments, I don't think > there is an approach #2 with only 2 QSPEC Type values, more > can be defined as described. Georgios: Agree, so we have to provide a solution for approach 1. Best regards, Georgios > > Thanks, > Jerry > > > > > Thanks in advance, > > > > Martin > > > > > > stiemerling@netlab.nec.de > > NEC Europe Limited | > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > > Registered in England 2832014 > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 09:55:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkyK-0000wg-Gp; Mon, 12 Mar 2007 09:53:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkyJ-0000tt-5r for nsis@ietf.org; Mon, 12 Mar 2007 09:53:55 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQkyB-000136-JY for nsis@ietf.org; Mon, 12 Mar 2007 09:53:55 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2CDrdI9031280; Mon, 12 Mar 2007 13:53:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Mon, 12 Mar 2007 13:53:38 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST Q-Mode Encapsulation Magic Number Thread-Index: AcdicyvQmKE1tg5gQK+DNPTkdQgz9wCOd16Q References: <45F19C6A.5060108@christian-dickmann.de> From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi christian, i think it is really a conceptual thing: i see the magic number as part of the encapsulation, just like the RAO and the UDP=20 header and port number, since that is the purpose it serves (to demultiplex packets, not to carry information). and to=20 put it in every message would indeed be a waste of bytes,=20 which you could never go back on (since the magic number comes before any version information).=20 another way of putting it: we want the magic number to be something that is checked to find out whether something is a GIST packet, rather than part of parsing the GIST packet. making it part of the common header would blur that distinction. however, it may be that in practice, what you suggest would be simpler. i would be interested to hear what other people think about that. one specific point: we need to ensure that GIST packets without the magic number go to a different UDP port, else you could not know how to receive them properly. that may not be clear enough in the spec at the moment. cheers, robert h. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 09 March 2007 17:42 > To: nsis@ietf.org > Subject: [NSIS] GIST Q-Mode Encapsulation Magic Number >=20 > Hi, >=20 > I just read the new GIST draft version (-12) with respect to=20 > the new magic number which is sent in front of the Q-Mode packets. > From my point of view, the magic number definition is quite=20 > well hidden in Section 5.3.2.3. I thought it should be part=20 > of the Bit-Level Format Appendix, as it is part of how a GIST=20 > packet looks like. In addition, Section 5.1 does not indicate=20 > at all, that there is something in front of a GIST packet. > Maybe thats a stupid idea, but from an implementors point of=20 > view it would be much easier to make the magic number part of=20 > the Common Header.=20 > This way, it is always included (OK, waste of 4 bytes in=20 > non-Queries) which makes it more obvious w.r.t. the=20 > specification and makes implementation easier as well. > Is there any reason besides wasting 4 bytes for non-Queries=20 > to NOT make it part of the Common Header? >=20 > Regards, > Christian Dickmann >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 10:06:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlAA-0004ba-Bp; Mon, 12 Mar 2007 10:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlA7-0004Yz-AR for nsis@ietf.org; Mon, 12 Mar 2007 10:06:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQl9o-0004PK-Gd for nsis@ietf.org; Mon, 12 Mar 2007 10:06:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2CE5dQ9001986; Mon, 12 Mar 2007 14:05:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Use of 3-Way Handshake in D-Mode case Date: Mon, 12 Mar 2007 14:05:38 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Use of 3-Way Handshake in D-Mode case Thread-Index: AcdikPcWnjEruHtiRe6LN5JyAx2CRgCHVXig References: <45F1CE86.6080802@christian-dickmann.de> From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi christian,=20 > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 09 March 2007 21:16 > To: nsis@ietf.org > Subject: [NSIS] Use of 3-Way Handshake in D-Mode case >=20 > Hi Robert, >=20 > section 4.3.3 "Message Transmission" states: > "If a messaging association is not required, the message is sent in > D-mode. The processing in this case depends on the=20 > message type and > whether routing state exists or not. ... > - If the message is not a Query, and routing state exists, ... > - If the message is a Query, ... > - If no routing state exists, GIST can attempt to use Q-mode as in > the Query case. ..." >=20 > Thus, for a message that is not a Query and where no routing=20 > state exists, the third rule applies. The third rule gives=20 > only the option of sending the message in Q-mode. Does that=20 > mean, that there is no way to carry out a 3-way handshake=20 > just for transport of D-Mode messages? that is not the intention. this text hasn't changed for a while; the scope (in fact, the scope of this whole section 4.3) is=20 supposed to be 'how do you send a message based on whatever=20 routing state you already have', and 4.4 explains how to set up routing state if you don't have it. it may be that that final=20 bullet should be extended to say that lack of routing state can be used as a trigger to make a handshake take place. > The SendMessage primitive has a parameter that suggests=20 > "whether GIST should attempt to set up or maintain forward=20 > routing state." Also text like "A Confirm MUST be sent in=20 > C-mode if a messaging association is being used for this=20 > routing state" suggests that there is case of having routing=20 > state without C-Mode. > Am I missing something? no, it is quite possible for the handshake to take place without creating an MA (although you SHOULD only send messages outside an MA when you have provisioned bandwidth for signalling traffic - this is a congestion control issue, and will be in the next version, see http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue208). robert h. >=20 > Regards, > Christian >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 10:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlJn-0000n6-8H; Mon, 12 Mar 2007 10:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlIl-0007lq-5U for nsis@ietf.org; Mon, 12 Mar 2007 10:15:03 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlHX-0005g1-N1 for nsis@ietf.org; Mon, 12 Mar 2007 10:13:50 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2CEDe9v004489; Mon, 12 Mar 2007 14:13:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] MA re-use mechanism in case of TCP Date: Mon, 12 Mar 2007 14:13:39 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] MA re-use mechanism in case of TCP Thread-Index: AcdjbB3elG6DbDDxSmGO+103WjsXZgBQ8KxA References: <45F33D9D.5020706@christian-dickmann.de> From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi,=20 > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 10 March 2007 23:22 > To: nsis@ietf.org > Subject: [NSIS] MA re-use mechanism in case of TCP >=20 > Hi Robert, >=20 > I am not 100% sure if I already asked this question (I know I=20 > intended to do so once, but I can't find any mail I sent=20 > about the issue). > Section 5.7.1 says about MA re-use: > "If multiplexing does occur, > which is indicated by sending the Response over an=20 > existing messaging > association, the following rules apply: >=20 > o The re-used messaging association MUST NOT have weaker security > properties than would have been offered in the full=20 > Response that > would have been sent without re-use." >=20 >=20 > And it also states: " For such a Response, > the security protocols listed in the Stack-Proposal MUST NOT depend > on the Query." >=20 ok so far (but read on...) > As a standard GIST nodes should at least support TCP and TLS=20 > over TCP, the majority of all Responses will offer both.=20 > Using the rule I quoted first means, that the Responder is=20 > not allowed to decide to re-use a TCP-only MA, because it is=20 > always weaker than the TLS over TCP profile.=20 the rule could be read that way, but that is not the intention. after all, if the node was prepared to offer TCP and TLS/TCP in the original response, it is presumably happy to use TCP (and so re-use would be possible). the actual problem is the ambiguity: the first rule could mean "weaker security properties than *all of the options that*=20 would have been offered in the full Response" or "weaker security properties than *any of the options that*=20 would have been offered in the full Response" and I think the valid approach is the first. what we are really trying to rule out is a case such as: - node has MA using only TCP (e.g. for NSLP foo) - node gets Query for NSLP bar, which absolutely requires TLS/TCP e.g. for message privacy - node would send a response listing *only* TLS/TCP for the MA - but re-uses the TCP one instead. so i suspect that this needs to be clarified. r. > If that is correct, I think it should be stated somewhere,=20 > because the other text in the draft suggests (at least thats=20 > what I read) that a re-use of a TCP connection would use the=20 > standard procedure (send the Response over the MA). > So am I reading these rules correctly? Is this the intended=20 > protocol behavior? Do you agree that the TCP case should be=20 > stated more explicitly to avoid misunderstanding? >=20 > Best Regards, > Christian Dickmann >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 10:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlOG-0004ix-OB; Mon, 12 Mar 2007 10:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlOF-0004in-Fg for nsis@ietf.org; Mon, 12 Mar 2007 10:20:43 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlOD-0007DQ-Sq for nsis@ietf.org; Mon, 12 Mar 2007 10:20:43 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2CEJxmu006336; Mon, 12 Mar 2007 14:19:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST: Is Loose-End MRM REQUIRED? Date: Mon, 12 Mar 2007 14:19:58 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST: Is Loose-End MRM REQUIRED? Thread-Index: Acdjc/liMyP95mN/R7SV6xco5EgcfgBPLc1w References: <45F34B86.1010902@christian-dickmann.de> From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi,=20 > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 11 March 2007 00:21 > To: nsis@ietf.org > Subject: [NSIS] GIST: Is Loose-End MRM REQUIRED? >=20 > Hi Robert, >=20 > I noticed that TCP and TLS over TCP are REQUIRED in the RFC=20 > 2119 sense.=20 > In addition, for the PC-MRM the downstream encapsulation is=20 > REQUIRED, while upstream encapsulation is OPTIONAL (for the=20 > sending part). =20 > However, the MRMs themselves have no text stating that they=20 > are REQUIRED. I would assume that support for PC-MRM is=20 > REQUIRED, while support for LE-MRM is OPTIONAL, because there=20 > might be special GIST implementations just meant to work with=20 > QoS NSLP which do not need LE-MRM to work. here, the underlying point is that the MRMs required strictly=20 depend on the NSLPs to be supported. so if you have an NSLP which only uses MRM foo (still to be specified), there is no particular need for a node which only hosts foo to have a GIST implementation which support PC-MRM or LE-MRM. that is why the specification leaves the 2119 status of the MRMs open. OTOH, there is also case that it is good to have MRMs supported because otherwise it becomes a deployment drag for new applications (you have to go and check every implementation and find out whether it supports the MRMs that you need, which is a pain). So, even though the MRMs are not logically required, it is still good for the specification to send a message that you would be silly not to implement them. it would be interesting to know other people's views on this. on balance, there is a good case for saying that both MRMs are SHOULDs. i would even say MUST, except for the fact that the PC-MRM is actually probably the hardest part of the protocol to implement correctly, so making it an unavoidable part of the protocol seems like too much cost for future NSIS applications which don't need it. cheers, robert h. >=20 > Regards, > Christian Dickmann >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 10:47:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQln9-00017F-6D; Mon, 12 Mar 2007 10:46:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQln7-00017A-Rj for nsis@ietf.org; Mon, 12 Mar 2007 10:46:25 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQln6-0003gz-I8 for nsis@ietf.org; Mon, 12 Mar 2007 10:46:25 -0400 Received: from win2003.dickmann2003.home (p548A4DFD.dip.t-dialin.net [84.138.77.253]) by www.difra-computer.de (Postfix) with ESMTP id 9DF6C3E4030 for ; Mon, 12 Mar 2007 15:41:30 +0100 (CET) Received: from [127.0.0.1] ([192.168.30.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 15:30:16 +0100 Message-ID: <45F5670E.3020600@christian-dickmann.de> Date: Mon, 12 Mar 2007 10:43:26 -0400 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number References: <45F19C6A.5060108@christian-dickmann.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2007 14:30:17.0036 (UTC) FILETIME=[F461E0C0:01C764B2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, > i think it is really a conceptual thing: i see the magic number > as part of the encapsulation, just like the RAO and the UDP > header and port number, since that is the purpose it serves > (to demultiplex packets, not to carry information). and to > put it in every message would indeed be a waste of bytes, > which you could never go back on (since the magic number comes > before any version information). > > another way of putting it: we want the magic number to be something > that is checked to find out whether something is a GIST packet, > rather than part of parsing the GIST packet. making it part of > the common header would blur that distinction. > > however, it may be that in practice, what you suggest would be > simpler. i would be interested to hear what other people think > about that. > > one specific point: we need to ensure that GIST packets without > the magic number go to a different UDP port, else you could not > know how to receive them properly. that may not be clear enough > in the spec at the moment. > The last point came to my mind as well. If the magic number stays being part of Q-Mode only, the spec should be very clear about the fact, that you should not use the same port for normal encapsulation, which again makes implementation not easier ... Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 10:50:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlqL-0002Ij-PP; Mon, 12 Mar 2007 10:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlqK-0002HK-Ul for nsis@ietf.org; Mon, 12 Mar 2007 10:49:44 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlqI-0004Pe-Tm for nsis@ietf.org; Mon, 12 Mar 2007 10:49:44 -0400 Received: from win2003.dickmann2003.home (p548A4DFD.dip.t-dialin.net [84.138.77.253]) by www.difra-computer.de (Postfix) with ESMTP id DB90E3E4032 for ; Mon, 12 Mar 2007 15:45:11 +0100 (CET) Received: from [127.0.0.1] ([192.168.30.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 15:36:22 +0100 Message-ID: <45F56881.1030906@christian-dickmann.de> Date: Mon, 12 Mar 2007 10:49:37 -0400 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] MA re-use mechanism in case of TCP References: <45F33D9D.5020706@christian-dickmann.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2007 14:36:22.0642 (UTC) FILETIME=[CE4CED20:01C764B3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, see inline. >> Section 5.7.1 says about MA re-use: >> "If multiplexing does occur, >> which is indicated by sending the Response over an >> existing messaging >> association, the following rules apply: >> >> o The re-used messaging association MUST NOT have weaker security >> properties than would have been offered in the full >> Response that >> would have been sent without re-use." >> >> >> And it also states: " For such a Response, >> the security protocols listed in the Stack-Proposal MUST NOT depend >> on the Query." >> >> > > ok so far (but read on...) > > >> As a standard GIST nodes should at least support TCP and TLS >> over TCP, the majority of all Responses will offer both. >> Using the rule I quoted first means, that the Responder is >> not allowed to decide to re-use a TCP-only MA, because it is >> always weaker than the TLS over TCP profile. >> > > the rule could be read that way, but that is not the intention. > after all, if the node was prepared to offer TCP and TLS/TCP in > the original response, it is presumably happy to use TCP (and > so re-use would be possible). > > the actual problem is the ambiguity: the first rule could mean > "weaker security properties than *all of the options that* > would have been offered in the full Response" > or > "weaker security properties than *any of the options that* > would have been offered in the full Response" > > and I think the valid approach is the first. > > what we are really trying to rule out is a case such as: > - node has MA using only TCP (e.g. for NSLP foo) > - node gets Query for NSLP bar, which absolutely requires TLS/TCP > e.g. for message privacy > - node would send a response listing *only* TLS/TCP for the MA > - but re-uses the TCP one instead. > > so i suspect that this needs to be clarified. > OK, makes sense. And I agree, that this needs to be clarified in the text. Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 10:58:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlyO-0000kb-L0; Mon, 12 Mar 2007 10:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlyN-0000kW-JX for nsis@ietf.org; Mon, 12 Mar 2007 10:58:03 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlyM-0006KU-5P for nsis@ietf.org; Mon, 12 Mar 2007 10:58:03 -0400 Received: from win2003.dickmann2003.home (p548A4DFD.dip.t-dialin.net [84.138.77.253]) by www.difra-computer.de (Postfix) with ESMTP id 036613E4030 for ; Mon, 12 Mar 2007 15:53:30 +0100 (CET) Received: from [127.0.0.1] ([192.168.30.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 15:43:52 +0100 Message-ID: <45F56A3F.6090204@christian-dickmann.de> Date: Mon, 12 Mar 2007 10:57:03 -0400 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] Use of 3-Way Handshake in D-Mode case References: <45F1CE86.6080802@christian-dickmann.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2007 14:43:53.0941 (UTC) FILETIME=[DB4BB050:01C764B4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hancock, Robert wrote: > hi christian, > > >> -----Original Message----- >> From: Christian Dickmann [mailto:mail@christian-dickmann.de] >> Sent: 09 March 2007 21:16 >> To: nsis@ietf.org >> Subject: [NSIS] Use of 3-Way Handshake in D-Mode case >> >> Hi Robert, >> >> section 4.3.3 "Message Transmission" states: >> "If a messaging association is not required, the message is sent in >> D-mode. The processing in this case depends on the >> message type and >> whether routing state exists or not. ... >> - If the message is not a Query, and routing state exists, ... >> - If the message is a Query, ... >> - If no routing state exists, GIST can attempt to use Q-mode as in >> the Query case. ..." >> >> Thus, for a message that is not a Query and where no routing >> state exists, the third rule applies. The third rule gives >> only the option of sending the message in Q-mode. Does that >> mean, that there is no way to carry out a 3-way handshake >> just for transport of D-Mode messages? >> > > that is not the intention. this text hasn't changed for a while; > the scope (in fact, the scope of this whole section 4.3) is > supposed to be 'how do you send a message based on whatever > routing state you already have', and 4.4 explains how to set up > routing state if you don't have it. it may be that that final > bullet should be extended to say that lack of routing state can > be used as a trigger to make a handshake take place. > Very good. I was quite worried after reading that text :) So I think that this short addition to the last bullet would be a good idea. >> The SendMessage primitive has a parameter that suggests >> "whether GIST should attempt to set up or maintain forward >> routing state." Also text like "A Confirm MUST be sent in >> C-mode if a messaging association is being used for this >> routing state" suggests that there is case of having routing >> state without C-Mode. >> Am I missing something? >> > > no, it is quite possible for the handshake to take place without > creating an MA (although you SHOULD only send messages outside > an MA when you have provisioned bandwidth for signalling traffic - > this is a congestion control issue, and will be in the next > version, see > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue208). > Thanks for pointing me to this issue, answered another question I had. Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 12:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQn6e-0005xC-Kc; Mon, 12 Mar 2007 12:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQn6d-0005x7-Bc for nsis@ietf.org; Mon, 12 Mar 2007 12:10:39 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQn6b-0004Ml-UF for nsis@ietf.org; Mon, 12 Mar 2007 12:10:39 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2CGALpw004310; Mon, 12 Mar 2007 16:10:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Use of 3-Way Handshake in D-Mode case Date: Mon, 12 Mar 2007 16:10:21 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Use of 3-Way Handshake in D-Mode case Thread-Index: AcdktvL5hVWakyG0SzGxKPVePIfKPQACfY7Q References: <45F1CE86.6080802@christian-dickmann.de> <45F56A3F.6090204@christian-dickmann.de> From: "Hancock, Robert" To: "Christian Dickmann" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org ok, raised as http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue210 r.=20 > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 12 March 2007 14:57 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] Use of 3-Way Handshake in D-Mode case >=20 > Hancock, Robert wrote: > > hi christian, > > > > =20 > >> -----Original Message----- > >> From: Christian Dickmann [mailto:mail@christian-dickmann.de] > >> Sent: 09 March 2007 21:16 > >> To: nsis@ietf.org > >> Subject: [NSIS] Use of 3-Way Handshake in D-Mode case > >> > >> Hi Robert, > >> > >> section 4.3.3 "Message Transmission" states: > >> "If a messaging association is not required, the message is sent in > >> D-mode. The processing in this case depends on the=20 > message type=20 > >> and > >> whether routing state exists or not. ... > >> - If the message is not a Query, and routing state exists, ... > >> - If the message is a Query, ... > >> - If no routing state exists, GIST can attempt to use Q-mode as in > >> the Query case. ..." > >> > >> Thus, for a message that is not a Query and where no routing state=20 > >> exists, the third rule applies. The third rule gives only=20 > the option=20 > >> of sending the message in Q-mode. Does that mean, that there is no=20 > >> way to carry out a 3-way handshake just for transport of D-Mode=20 > >> messages? > >> =20 > > > > that is not the intention. this text hasn't changed for a=20 > while; the=20 > > scope (in fact, the scope of this whole section 4.3) is=20 > supposed to be=20 > > 'how do you send a message based on whatever routing state=20 > you already=20 > > have', and 4.4 explains how to set up routing state if you=20 > don't have=20 > > it. it may be that that final bullet should be extended to say that=20 > > lack of routing state can be used as a trigger to make a handshake=20 > > take place. > > =20 >=20 > Very good. I was quite worried after reading that text :) So=20 > I think that this short addition to the last bullet would be=20 > a good idea. >=20 > >> The SendMessage primitive has a parameter that suggests=20 > "whether GIST=20 > >> should attempt to set up or maintain forward routing state." Also=20 > >> text like "A Confirm MUST be sent in C-mode if a messaging=20 > >> association is being used for this routing state" suggests=20 > that there=20 > >> is case of having routing state without C-Mode. > >> Am I missing something? > >> =20 > > > > no, it is quite possible for the handshake to take place without=20 > > creating an MA (although you SHOULD only send messages=20 > outside an MA=20 > > when you have provisioned bandwidth for signalling traffic=20 > - this is a=20 > > congestion control issue, and will be in the next version, see=20 > >=20 > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue208). > > =20 >=20 > Thanks for pointing me to this issue, answered another question I had. >=20 > Christian >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 12 12:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQn8h-0008GV-1j; Mon, 12 Mar 2007 12:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQn8e-000898-RQ for nsis@ietf.org; Mon, 12 Mar 2007 12:12:44 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQn8d-0004ZW-5g for nsis@ietf.org; Mon, 12 Mar 2007 12:12:44 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2CGCInx004809; Mon, 12 Mar 2007 16:12:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] MA re-use mechanism in case of TCP Date: Mon, 12 Mar 2007 16:12:18 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] MA re-use mechanism in case of TCP Thread-Index: AcdktcGRKaYV0ncaSIORaOGNNr8D1gAC2kYw References: <45F33D9D.5020706@christian-dickmann.de> <45F56881.1030906@christian-dickmann.de> From: "Hancock, Robert" To: "Christian Dickmann" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org ok opened issue http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue211 r.=20 > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 12 March 2007 14:50 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] MA re-use mechanism in case of TCP >=20 > Hi Robert, >=20 > see inline. >=20 > >> Section 5.7.1 says about MA re-use: > >> "If multiplexing does occur, > >> which is indicated by sending the Response over an existing=20 > >> messaging > >> association, the following rules apply: > >> > >> o The re-used messaging association MUST NOT have=20 > weaker security > >> properties than would have been offered in the full Response=20 > >> that > >> would have been sent without re-use." > >> > >> > >> And it also states: " For such a Response, > >> the security protocols listed in the Stack-Proposal=20 > MUST NOT depend > >> on the Query." > >> > >> =20 > > > > ok so far (but read on...) > > > > =20 > >> As a standard GIST nodes should at least support TCP and TLS over=20 > >> TCP, the majority of all Responses will offer both. > >> Using the rule I quoted first means, that the Responder is not=20 > >> allowed to decide to re-use a TCP-only MA, because it is always=20 > >> weaker than the TLS over TCP profile. > >> =20 > > > > the rule could be read that way, but that is not the intention. > > after all, if the node was prepared to offer TCP and TLS/TCP in > > the original response, it is presumably happy to use TCP (and > > so re-use would be possible). > > > > the actual problem is the ambiguity: the first rule could mean > > "weaker security properties than *all of the options that*=20 > > would have been offered in the full Response" > > or > > "weaker security properties than *any of the options that*=20 > > would have been offered in the full Response" > > > > and I think the valid approach is the first. > > > > what we are really trying to rule out is a case such as: > > - node has MA using only TCP (e.g. for NSLP foo) > > - node gets Query for NSLP bar, which absolutely requires TLS/TCP > > e.g. for message privacy > > - node would send a response listing *only* TLS/TCP for the MA > > - but re-uses the TCP one instead. > > > > so i suspect that this needs to be clarified. > > =20 >=20 > OK, makes sense. And I agree, that this needs to be clarified=20 > in the text. >=20 >=20 > Christian >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cp-0005UT-F0; Tue, 13 Mar 2007 10:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cm-0005Qr-FK for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Ck-0002XJ-3E for nsis@ietf.org; Tue, 13 Mar 2007 10:42:24 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BCB9B13CF86; Tue, 13 Mar 2007 15:42:21 +0100 (CET) In-Reply-To: <000501c7648e$7f190bf0$4c0d5982@dynamic.ewi.utwente.nl> References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> <000501c7648e$7f190bf0$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80A7087A-EC16-4130-8214-F7379F810CF8@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Tue, 13 Mar 2007 14:33:52 +0100 To: Georgios Karagiannis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Am 12.03.2007 um 11:09 schrieb Georgios Karagiannis: > Hi Jerry > > Please see in line! > > >> -----Original Message----- >> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] >> Sent: zondag 11 maart 2007 0:43 >> To: Martin Stiemerling; nsis >> Cc: ASH, GERALD R, ATTLABS >> Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft >> >> Hi Martin, >> >> Please see below. >> >>> -----Original Message----- >>> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >>> Sent: Friday, March 09, 2007 5:55 AM >>> To: nsis >>> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft >>> >>> [writing with chair's hat off] >>> >>> Hi all, >>> >>> I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue >>> which came up during the WGLC for the QSPEC draft. >>> >>> The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the >>> QSPEC-Type is >>> - initiator QSPEC or >>> - local QSPEC. >>> >>> When reading the text first I thought that is fine, but given all >>> discussions afterwards and reading again the QSPEC I have now some >>> doubts. I assume two approaches here how to deal with identifying >>> QOSMs on a QNE. >>> >>> 1. Roland's approach with QSPEC-Type identifying the type of QSPEC >>> signalled for (e.g., RMD, Y.1541. etc) (also favoured by >> Georgios) 2. >>> The current QSPEC approach with QSPEC-Type just saying initiator or >>> local QSPEC. >> >> I don't think there are 2 approaches. >> >> The QSPEC Type has so far been defined with 2 values assigned >> in the IANA section, but an IANA registry is defined so that >> more QSPEC Types can be defined, satisfying approach #1. I >> don't think there is an approach #2 with only 2 values defined. >> >> If the intent is to make QSPEC Type equivalent to QOSM ID (as >> defined in the QSPEC-12 draft), as I infer from the >> discussion, then I think we need to: >> - redefine QSPEC Type 0 = no QOSM supported by QNE (it is >> allowed to not support any QOSM) > > Georgios: I think that according to the QSPEC template draft, this > is not > possible. > A QNE will have to at least support the mandatory parameters. QSPEC Type 0 means no QOSM supported but would anyway require the mandatory parameters, isn't it. I assume this means Type set to 0? > Thus a QNI will include the QOSM ID in the QSPEC object. If a > downstream > QNE cannot support the QOSM then it will only process the mandatory > parameter and if needed > mark with N the parameters that are not understood. > I think it is good to have the additional bit that specifies that a > QOSM is > initial or local. I see this also a good approach, i.e., having the QSPEC Type and a bit saying local/initiator. Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cp-0005UC-8a; Tue, 13 Mar 2007 10:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cn-0005RZ-Go for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Ck-0002XM-AN for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 09CA413CF88 for ; Tue, 13 Mar 2007 15:42:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Tue, 13 Mar 2007 14:35:35 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I would like to encourage people to check the initial version of the =20 NSLP-RMF API. Note that the API is informational only and should just give hints to =20= the implementers. Thanks, Martin Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: > > A diff of the changes since -12 is at: > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-=20 > nsis-qos-nslp-13-from-12.diff.html > > Main changes: > - Reduced refreshes are the default mechanism for refreshing sessions > - RSN needs to be taken into account when a node receives a tear > - Summary refresh and summary tear introduced (incl. objects and =20 > message > processing) > - QSPEC staking removed > - ACK-REQ flag introduced for diagnostics purposes > - Some changes to the INFO_SPEC codes (see the diff) > - (very) Initial version of NSLP-RMF API > > > Jukka > > On Fri, 9 Mar 2007, Martin Stiemerling wrote: > >> Please take a look and review the new version of the QoS NSLP draft. >> >> There have been some changes in the main part, plus a new appendix =20= >> with the >> NSLP-RMF API. >> >> Thanks, >> >> Martin >> >> Anfang der weitergeleiteten E-Mail: >> >>> Von: >>> Datum: 8. M=E4rz 2007 21:50:03 MEZ >>> An: >>> Kopie: >>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Next Steps in Signaling Working =20 >>> Group of >>> the IETF. >>> >>> Title : NSLP for Quality-of-Service Signaling >>> Author(s) : J. Manner, et al. >>> Filename : draft-ietf-nsis-qos-nslp-13.txt >>> Pages : 85 >>> Date : 2007-3-8 >>> >>> This specification describes the NSIS Signaling Layer Protocol =20 >>> (NSLP) >>> for signaling QoS reservations in the Internet. It is in =20 >>> accordance >>> with the framework and requirements developed in NSIS. Together =20= >>> with >>> GIST, it provides functionality similar to RSVP and extends it. =20= >>> The >>> QoS NSLP is independent of the underlying QoS specification or >>> architecture and provides support for different reservation =20 >>> models. >>> It is simplified by the elimination of support for multicast =20 >>> flows. >>> This specification explains the overall protocol approach, design >>> decisions made and provides examples. It specifies object, message >>> formats and processing rules. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >>> body of >>> the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >>> announce >>> to change your subscription settings. >>> >>> 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-qos-nslp-13.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-qos-nslp-13.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cp-0005Uk-Lm; Tue, 13 Mar 2007 10:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cm-0005Qv-QH for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Ck-0002XI-2U for nsis@ietf.org; Tue, 13 Mar 2007 10:42:24 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B069513CF82; Tue, 13 Mar 2007 15:42:21 +0100 (CET) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Tue, 13 Mar 2007 14:33:51 +0100 To: "ASH, GERALD R, ATTLABS" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFrom nsis-bounces@ietf.org Tue Mar 13 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cp-0005UC-8a; Tue, 13 Mar 2007 10:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cn-0005RZ-Go for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Ck-0002XM-AN for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 09CA413CF88 for ; Tue, 13 Mar 2007 15:42:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Tue, 13 Mar 2007 14:35:35 +0100 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I would like to encourage people to check the initial version of the =20 NSLP-RMF API. Note that the API is informational only and should just give hints to =20= the implementers. Thanks, Martin Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: > > A diff of the changes since -12 is at: > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-=20 > nsis-qos-nslp-13-from-12.diff.html > > Main changes: > - Reduced refreshes are the default mechanism for refreshing sessions > - RSN needs to be taken into account when a node receives a tear > - Summary refresh and summary tear introduced (incl. objects and =20 > message > processing) > - QSPEC staking removed > - ACK-REQ flag introduced for diagnostics purposes > - Some changes to the INFO_SPEC codes (see the diff) > - (very) Initial version of NSLP-RMF API > > > Jukka > > On Fri, 9 Mar 2007, Martin Stiemerling wrote: > >> Please take a look and review the new version of the QoS NSLP draft. >> >> There have been some changes in the main part, plus a new appendix =20= >> with the >> NSLP-RMF API. >> >> Thanks, >> >> Martin >> >> Anfang der weitergeleiteten E-Mail: >> >>> Von: >>> Datum: 8. M=E4rz 2007 21:50:03 MEZ >>> An: >>> Kopie: >>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Next Steps in Signaling Working =20 >>> Group of >>> the IETF. >>> >>> Title : NSLP for Quality-of-Service Signaling >>> Author(s) : J. Manner, et al. >>> Filename : draft-ietf-nsis-qos-nslp-13.txt >>> Pages : 85 >>> Date : 2007-3-8 >>> >>> This specification describes the NSIS Signaling Layer Protocol =20 >>> (NSLP) >>> for signaling QoS reservations in the Internet. It is in =20 >>> accordance >>> with the framework and requirements developed in NSIS. Together =20= >>> with >>> GIST, it provides functionality similar to RSVP and extends it. =20= >>> The >>> QoS NSLP is independent of the undext Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Thanks for the response. The issue gets much clearer with this email for me. Please see below. Am 11.03.2007 um 00:42 schrieb ASH, GERALD R, ATTLABS: > Hi Martin, > > Please see below. > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: Friday, March 09, 2007 5:55 AM >> To: nsis >> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft >> >> [writing with chair's hat off] >> >> Hi all, >> >> I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue >> which came up during the WGLC for the QSPEC draft. >> >> The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the >> QSPEC-Type is >> - initiator QSPEC or >> - local QSPEC. >> >> When reading the text first I thought that is fine, but given all >> discussions afterwards and reading again the QSPEC I have now some >> doubts. I assume two approaches here how to deal with identifying >> QOSMs on a QNE. >> >> 1. Roland's approach with QSPEC-Type identifying the type of QSPEC >> signalled for (e.g., RMD, Y.1541. etc) (also favoured by Georgios) >> 2. The current QSPEC approach with QSPEC-Type just saying initiator >> or local QSPEC. > > I don't think there are 2 approaches. > > The QSPEC Type has so far been defined with 2 values assigned in the > IANA section, but an IANA registry is defined so that more QSPEC Types > can be defined, satisfying approach #1. I don't think there is an > approach #2 with only 2 values defined. > > If the intent is to make QSPEC Type equivalent to QOSM ID (as > defined in > the QSPEC-12 draft), as I infer from the discussion, then I think we > need to: > - redefine QSPEC Type 0 = no QOSM supported by QNE (it is allowed > to not > support any QOSM) > - define additional QSPEC Types as specified in the IANA registry, and > - use a separate bit to identify the initiator/local QSPEC (as > proposed > by Georgios). Fine with me. That does make sense to me and clarifies the issue. > > However, what isn't clear in the discussion so far is exactly how the > QSPEC Type/QOSM ID information would be used by a QNE. For example, > suppose the QNI supports CL-QSPEC Type and signals that. Suppose also > that a downstream QNE supports the following: > Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what does > the QNE > do with the CL-QSPEC Type information from the QNI, exactly how is the > information used by the QNE? > Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does > the > QNE do with the CL-QSPEC Type information from the QNI, exactly how is > the information used by the QNE? > Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with > the > CL-QSPEC Type information from the QNI, exactly how is the information > used by the QNE? > Case 4: QNE support no QSPEC Types, Case 3: QNE supports CL-QSPEC-Type > and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC-Type > information from the QNI, exactly how is the information used by the > QNE? > > We could define another 4 cases where the QNI signals QSPEC Type = no > QOSM supported. What are the corresponding answers to the above > questions for those scenarios? > > It would be very helpful IMO if this was clarified in more detail than > it has been so far. Yes, I see the point. This basically boils down to which incoming QOSM is mapped to which outgoing QOSM, i.e., if a mapping is required or desired on how to map initiator to local QOSM. I suppose (also from reading Georgios' email) that this choice is depending on the outgoing interface, better outgoing/local domain. Again, correct me if I'm wrong! Taking, for instance, case 1: An ingress QNE for a domain supports CL- QSPEC erlying QoS specification or >>> architecture and provides support for different reservation =20 >>> models. >>> It is simplified by the elimination of support for multicast =20 >>> flows. >>> This specification explains the overall protocol approach, design >>> decisions made and provides examples. It specifies object, message >>> formats and processing rules. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >>> body of >>> the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >>> announce >>> to change your subscription settings. >>> >>> 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-qos-nslp-13.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-qos-nslp-13.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cp-0005Uk-Lm; Tue, 13 Mar 2007 10:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8Cm-0005Qv-QH for nsis@ietf.org; Tue, 13 Mar 2007 10:42:25 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8Ck-0002XI-2U for nsis@ietf.org; Tue, 13 Mar 2007 10:42:24 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B069513CF82; Tue, 13 Mar 2007 15:42:21 +0100 (CET) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Tue, 13 Mar 2007 14:33:51 +0100 To: "ASH, GERALD R, ATTLABS" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NType and RMD QSPEC Type; the received Type is CL-QSPEC Type. If the traffic stays within the CL-QSPEC Type domain, CL-QSPEC Type is chosen/kept. If the traffic leaves the CL-QSPEC Type domain, e.g., the RMD QSPEC Type is chosen. I assume this is depending on the outgoing interface/domain and is locally configured my a human. For case (QNE only supports RMD-QSPEC Type), the local configuration (again manually) says use RMD-QSPEC Type for outgoing on each interface other than the receiving. > >> With approach 1. it is straight forward how to identify to which >> local RMF to forward the received QSPEC. > > Is it, I haven't seen yet how it is 'straightforward to identify which > 'local RMF' to forward the received QSPEC? Please see the above > examples and let us know how it works for those 8 cases. I hope to have solved this with the two examples. (keeping fingers crossed that I have brought my thoughts to this email :-) > >> With approach 2 I assume only RMF per QNE. The RMF on the node then >> automatically knows what the possible local QOSM can be (and >> remembers this). I one of my past emails I wrote this >> >>> >>> I believe that the QOSM ID is not needed as there is only >> one local >>> RMF per QNE. This local RMF can actually support multiple >> QOSMs but >>> this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the >>> chance to pass the QSPEC in a single piece to a single RMF. >>> The mapping between the different initiator QOSM and the >> local QOSM >>> is solely happening within the RMF. >> >> What is not clear for approach 2 for me: How does a RMF on a QNE >> distinguish between the possible available QOSMs? Does the QSPEC >> assume that the RMFs in one part of a network do know which QOSM is >> used by heart? > > Well, of course not. See the above comments, I don't think there > is an > approach #2 with only 2 QSPEC Type values, more can be defined as > described. Ok, then we are both on the same side. Thanks a lot! Martin > > Thanks, > Jerry > >> >> Thanks in advance, >> >> Martin >> >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ext Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Thanks for the response. The issue gets much clearer with this email for me. Please see below. Am 11.03.2007 um 00:42 schrieb ASH, GERALD R, ATTLABS: > Hi Martin, > > Please see below. > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: Friday, March 09, 2007 5:55 AM >> To: nsis >> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft >> >> [writing with chair's hat off] >> >> Hi all, >> >> I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue >> which came up during the WGLC for the QSPEC draft. >> >> The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the >> QSPEC-Type is >> - initiator QSPEC or >> - local QSPEC. >> >> When reading the text first I thought that is fine, but given all >> discussions afterwards and reading again the QSPEC I have now some >> doubts. I assume two approaches here how to deal with identifying >> QOSMs on a QNE. >> >> 1. Roland's approach with QSPEC-Type identifying the type of QSPEC >> signalled for (e.g., RMD, Y.1541. etc) (also favoured by Georgios) >> 2. The current QSPEC approach with QSPEC-Type just saying initiator >> or local QSPEC. > > I don't think there are 2 approaches. > > The QSPEC Type has so far been defined with 2 values assigned in the > IANA section, but an IANA registry is defined so that more QSPEC Types > can be defined, satisfying approach #1. I don't think there is an > approach #2 with only 2 values defined. > > If the intent is to make QSPEC Type equivalent to QOSM ID (as > defined in > the QSPEC-12 draft), as I infer from the discussion, then I think we > need to: > - redefine QSPEC Type 0 = no QOSM supported by QNE (it is allowed > to not > support any QOSM) > - define additional QSPEC Types as specified in the IANA registry, and > - use a separate bit to identify the initiator/local QSPEC (as > proposed > by Georgios). Fine with me. That does make sense to me and clarifies the issue. > > However, what isn't clear in the discussion so far is exactly how the > QSPEC Type/QOSM ID information would be used by a QNE. For example, > suppose the QNI supports CL-QSPEC Type and signals that. Suppose also > that a downstream QNE supports the following: > Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what does > the QNE > do with the CL-QSPEC Type information from the QNI, exactly how is the > information used by the QNE? > Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does > the > QNE do with the CL-QSPEC Type information from the QNI, exactly how is > the information used by the QNE? > Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with > the > CL-QSPEC Type information from the QNI, exactly how is the information > used by the QNE? > Case 4: QNE support no QSPEC Types, Case 3: QNE supports CL-QSPEC-Type > and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC-Type > information from the QNI, exactly how is the information used by the > QNE? > > We could define another 4 cases where the QNI signals QSPEC Type = no > QOSM supported. What are the corresponding answers to the above > questions for those scenarios? > > It would be very helpful IMO if this was clarified in more detail than > it has been so far. Yes, I see the point. This basically boils down to which incoming QOSM is mapped to which outgoing QOSM, i.e., if a mapping is required or desired on how to map initiator to local QOSM. I suppose (also from reading Georgios' email) that this choice is depending on the outgoing interface, better outgoing/local domain. Again, correct me if I'm wrong! Taking, for instance, case 1: An ingress QNE for a domain supports CL- QSPEC Type and RMD QSPEC Type; the received Type is CL-QSPEC Type. If the traffic stays within the CL-QSPEC Type domain, CL-QSPEC Type is chosen/kept. If the traffic leaves the CL-QSPEC Type domain, e.g., the RMD QSPEC Type is chosen. I assume this is depending on the outgoing interface/domain and is locally configured my a human. For case (QNE only supports RMD-QSPEC Type), the local configuration (again manually) says use RMD-QSPEC Type for outgoing on each interface other than the receiving. > >> With approach 1. it is straight forward how to identify to which >> local RMF to forward the received QSPEC. > > Is it, I haven't seen yet how it is 'straightforward to identify which > 'local RMF' to forward the received QSPEC? Please see the above > examples and let us know how it works for those 8 cases. I hope to have solved this with the two examples. (keeping fingers crossed that I have brought my thoughts to this email :-) > >> With approach 2 I assume only RMF per QNE. The RMF on the node then >> automatically knows what the possible local QOSM can be (and >> remembers this). I one of my past emails I wrote this >> >>> >>> I believe that the QOSM ID is not needed as there is only >> one local >>> RMF per QNE. This local RMF can actually support multiple >> QOSMs but >>> this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the >>> chance to pass the QSPEC in a single piece to a single RMF. >>> The mapping between the different initiator QOSM and the >> local QOSM >>> is solely happening within the RMF. >> >> What is not clear for approach 2 for me: How does a RMF on a QNE >> distinguish between the possible available QOSMs? Does the QSPEC >> assume that the RMFs in one part of a network do know which QOSM is >> used by heart? > > Well, of course not. See the above comments, I don't think there > is an > approach #2 with only 2 QSPEC Type values, more can be defined as > described. Ok, then we are both on the same side. Thanks a lot! Martin > > Thanks, > Jerry > >> >> Thanks in advance, >> >> Martin >> >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 11:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8hr-0002sA-Nt; Tue, 13 Mar 2007 11:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8hq-0002s2-CH for nsis@ietf.org; Tue, 13 Mar 2007 11:14:30 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8hn-0000CD-UJ for nsis@ietf.org; Tue, 13 Mar 2007 11:14:30 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2DFEF4L018552; Tue, 13 Mar 2007 16:14:25 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> <000501c7648e$7f190bf0$4c0d5982@dynamic.ewi.utwente.nl> <80A7087A-EC16-4130-8214-F7379F810CF8@netlab.nec.de> Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Tue, 13 Mar 2007 16:14:09 +0100 Message-ID: <005901c76582$4354c010$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <80A7087A-EC16-4130-8214-F7379F810CF8@netlab.nec.de> Thread-Index: AcdlfdHjBK5PHG74RQ2Svxcp6g/oPAAA3gUg X-Spam-Score: 0.236 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 13 Mar 2007 16:14:25 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: "'ASH, GERALD R, ATTLABS'" , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin Regarding the following paragraph: > QSPEC Type 0 means no QOSM supported but would anyway require > the mandatory parameters, isn't it. I assume this means Type set to 0? I think that this situation does not make sense to me! The mandatory parameters are signaled for a certain QoS goal, which is very much associated with a certain RMF. Best Regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: dinsdag 13 maart 2007 14:34 > To: Georgios Karagiannis > Cc: 'ASH, GERALD R, ATTLABS'; 'nsis' > Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > > Hi Georgios, > > > Am 12.03.2007 um 11:09 schrieb Georgios Karagiannis: > > > Hi Jerry > > > > Please see in line! > > > > > >> -----Original Message----- > >> From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > >> Sent: zondag 11 maart 2007 0:43 > >> To: Martin Stiemerling; nsis > >> Cc: ASH, GERALD R, ATTLABS > >> Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > >> > >> Hi Martin, > >> > >> Please see below. > >> > >>> -----Original Message----- > >>> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > >>> Sent: Friday, March 09, 2007 5:55 AM > >>> To: nsis > >>> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > >>> > >>> [writing with chair's hat off] > >>> > >>> Hi all, > >>> > >>> I'm starting a new email thread for the QOSM-ID / > QSPEC-Type issue > >>> which came up during the WGLC for the QSPEC draft. > >>> > >>> The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) > defines the > >>> QSPEC-Type is > >>> - initiator QSPEC or > >>> - local QSPEC. > >>> > >>> When reading the text first I thought that is fine, but given all > >>> discussions afterwards and reading again the QSPEC I have > now some > >>> doubts. I assume two approaches here how to deal with identifying > >>> QOSMs on a QNE. > >>> > >>> 1. Roland's approach with QSPEC-Type identifying the type > of QSPEC > >>> signalled for (e.g., RMD, Y.1541. etc) (also favoured by > >> Georgios) 2. > >>> The current QSPEC approach with QSPEC-Type just saying > initiator or > >>> local QSPEC. > >> > >> I don't think there are 2 approaches. > >> > >> The QSPEC Type has so far been defined with 2 values > assigned in the > >> IANA section, but an IANA registry is defined so that more QSPEC > >> Types can be defined, satisfying approach #1. I don't > think there is > >> an approach #2 with only 2 values defined. > >> > >> If the intent is to make QSPEC Type equivalent to QOSM ID > (as defined > >> in the QSPEC-12 draft), as I infer from the discussion, > then I think > >> we need to: > >> - redefine QSPEC Type 0 = no QOSM supported by QNE (it is > allowed to > >> not support any QOSM) > > > > Georgios: I think that according to the QSPEC template > draft, this is > > not possible. > > A QNE will have to at least support the mandatory parameters. > > QSPEC Type 0 means no QOSM supported but would anyway require > the mandatory parameters, isn't it. I assume this means Type set to 0? > > > Thus a QNI will include the QOSM ID in the QSPEC object. If a > > downstream QNE cannot support the QOSM then it will only > process the > > mandatory parameter and if needed mark with N the > parameters that are > > not understood. > > I think it is good to have the additional bit that specifies that a > > QOSM is initial or local. > > I see this also a good approach, i.e., having the QSPEC Type > and a bit saying local/initiator. > > Thanks, > > Martin > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > | Registered in England 2832014 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 12:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9XZ-0007Py-OR; Tue, 13 Mar 2007 12:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9XZ-0007Pt-CD for nsis@ietf.org; Tue, 13 Mar 2007 12:07:57 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9XU-0004WG-U4 for nsis@ietf.org; Tue, 13 Mar 2007 12:07:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2DG7XN1015819 for ; Tue, 13 Mar 2007 16:07:33 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 16:07:33 +0000 Message-ID: <45F6CC44.8020009@roke.co.uk> Date: Tue, 13 Mar 2007 16:07:32 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 16:07:33.0259 (UTC) FILETIME=[B57495B0:01C76589] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] QSpec dste/y1541 'not used' value X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, In the latest (-15) QSpec draft, both the and parameters have a class field where "A value of 255 (all 1's) means that the parameter is not used." In normal use, I would have expected that if you weren't using that parameter you would simply not include it in the object. I think this text may be a carry-over from earlier versions (e.g. draft -12) when these classes were sub-parameters in a single parameter, and so the sentence is no longer required. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 12:19:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9i3-0005TM-8T; Tue, 13 Mar 2007 12:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9i2-0005TC-Ru for nsis@ietf.org; Tue, 13 Mar 2007 12:18:46 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HR9i1-0006kb-Js for nsis@ietf.org; Tue, 13 Mar 2007 12:18:46 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1173802723!20026388!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27878 invoked from network); 13 Mar 2007 16:18:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 13 Mar 2007 16:18:43 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DGIhhC018021; Tue, 13 Mar 2007 12:18:43 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DGIYZ3017919; Tue, 13 Mar 2007 12:18:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSpec dste/y1541 'not used' value Date: Tue, 13 Mar 2007 11:18:18 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82E5@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F6CC44.8020009@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSpec dste/y1541 'not used' value Thread-Index: Acdlij6dOBQSuD2TT/uzhbsXklGwJQAAEs4A References: <45F6CC44.8020009@roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org You're right Andrew -- will be corrected in next update. Thanks, Jerry=20 -----Original Message----- From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 Sent: Tuesday, March 13, 2007 12:08 PM To: nsis@ietf.org Subject: [NSIS] QSpec dste/y1541 'not used' value Hi, In the latest (-15) QSpec draft, both the and parameters have a class field where "A value of 255 (all=20 1's) means that the parameter is not used." In normal use, I would have expected that if you weren't using that=20 parameter you would simply not include it in the object. I think this text may be a carry-over from earlier versions (e.g. draft=20 -12) when these classes were sub-parameters in a single =20 parameter, and so the sentence is no longer required. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 12:48:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRA9H-0005FQ-W6; Tue, 13 Mar 2007 12:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRA9G-0005Ct-30 for nsis@ietf.org; Tue, 13 Mar 2007 12:46:54 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRA9E-0004VE-H9 for nsis@ietf.org; Tue, 13 Mar 2007 12:46:54 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1173804409!13397917!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16131 invoked from network); 13 Mar 2007 16:46:51 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 13 Mar 2007 16:46:51 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DGkm71007626; Tue, 13 Mar 2007 12:46:49 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DGkcsD007555; Tue, 13 Mar 2007 12:46:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Tue, 13 Mar 2007 11:46:25 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82E6@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Thread-Index: AcdlfdM0esVN1WYPRA2WbD3Nr1LL/AAC9Ubw References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com> <235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de> From: "ASH, GERALD R, ATTLABS" To: "Martin Stiemerling" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: "ASH, GERALD R, ATTLABS" , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Martin, I agree with your comments, and have these additional comments based on the thread: 1. I've still not seen a clear illustration of how QSPEC Type is used, *at the bit level*. IMO one possible use is that the QNI can signal QSPEC Type to indicate its intent (along with QSPEC parameters, M flags, etc.), which should help a downstream QNE decide how to process the QSPEC in the case where a downstream QNE supports multiple QOSMs. But in the example I posed this doesn't seem to be the case: "Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC Type and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type information from the QNI, exactly how is the information used by the QNE? Georgios: By using the additional bit, the QNE will know that the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a local QSPEC. In this way the QNE will know how to handle the CL-QSPEC and how to handle the RMD-QSPEC." Since the QNI signals its intent is CL-QSPEC, and that is in fact the QSPEC that the QNI signals, why would a QNE then chose the RMD-QSPEC when it supports the CL-QSPEC and that is the QNI's intent? I would still like to see a clear bit level example of how QSPEC Type is used. 2. It is not required for a QNI/QNE to support any QOSM. This is independent of the mandatory requirement for QNEs to signal and interpret the TMOD parameter and for QNEs to interpret QSPEC parameters for which the M flag has been set. 3. It isn't clear to me that the proposed bit to indicate Initiator/Local QSPEC is absolutely required. It would seem that from the syntax of encapsulating the Initiator QSPEC within the Local QSPEC that the QNE could determine which QSPEC is where without these bits. While specifying such a bit isn't a big deal, it would be useful if some implementer could clarify why this bit is needed. Thanks, Jerry -----Original Message----- From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: Tuesday, March 13, 2007 9:34 AM To: ASH, GERALD R, ATTLABS Cc: nsis Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Hi Jerry, Thanks for the response. The issue gets much clearer with this email =20 for me. Please see below. Am 11.03.2007 um 00:42 schrieb ASH, GERALD R, ATTLABS: > Hi Martin, > > Please see below. > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: Friday, March 09, 2007 5:55 AM >> To: nsis >> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft >> >> [writing with chair's hat off] >> >> Hi all, >> >> I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue >> which came up during the WGLC for the QSPEC draft. >> >> The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the >> QSPEC-Type is >> - initiator QSPEC or >> - local QSPEC. >> >> When reading the text first I thought that is fine, but given all >> discussions afterwards and reading again the QSPEC I have now some >> doubts. I assume two approaches here how to deal with identifying >> QOSMs on a QNE. >> >> 1. Roland's approach with QSPEC-Type identifying the type of QSPEC >> signalled for (e.g., RMD, Y.1541. etc) (also favoured by Georgios) >> 2. The current QSPEC approach with QSPEC-Type just saying initiator >> or local QSPEC. > > I don't think there are 2 approaches. > > The QSPEC Type has so far been defined with 2 values assigned in the > IANA section, but an IANA registry is defined so that more QSPEC Types > can be defined, satisfying approach #1. I don't think there is an > approach #2 with only 2 values defined. > > If the intent is to make QSPEC Type equivalent to QOSM ID (as =20 > defined in > the QSPEC-12 draft), as I infer from the discussion, then I think we > need to: > - redefine QSPEC Type 0 =3D no QOSM supported by QNE (it is allowed =20 > to not > support any QOSM) > - define additional QSPEC Types as specified in the IANA registry, and > - use a separate bit to identify the initiator/local QSPEC (as =20 > proposed > by Georgios). Fine with me. That does make sense to me and clarifies the issue. > > However, what isn't clear in the discussion so far is exactly how the > QSPEC Type/QOSM ID information would be used by a QNE. For example, > suppose the QNI supports CL-QSPEC Type and signals that. Suppose also > that a downstream QNE supports the following: > Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what does =20 > the QNE > do with the CL-QSPEC Type information from the QNI, exactly how is the > information used by the QNE? > Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does =20 > the > QNE do with the CL-QSPEC Type information from the QNI, exactly how is > the information used by the QNE? > Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with =20 > the > CL-QSPEC Type information from the QNI, exactly how is the information > used by the QNE? > Case 4: QNE support no QSPEC Types, Case 3: QNE supports CL-QSPEC-Type > and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC-Type > information from the QNI, exactly how is the information used by the > QNE? > > We could define another 4 cases where the QNI signals QSPEC Type =3D = no > QOSM supported. What are the corresponding answers to the above > questions for those scenarios? > > It would be very helpful IMO if this was clarified in more detail than > it has been so far. Yes, I see the point. This basically boils down to which incoming =20 QOSM is mapped to which outgoing QOSM, i.e., if a mapping is required =20 or desired on how to map initiator to local QOSM. I suppose (also from reading Georgios' email) that this choice is =20 depending on the outgoing interface, better outgoing/local domain. =20 Again, correct me if I'm wrong! Taking, for instance, case 1: An ingress QNE for a domain supports CL-=20 QSPEC Type and RMD QSPEC Type; the received Type is CL-QSPEC Type. =20 If the traffic stays within the CL-QSPEC Type domain, CL-QSPEC Type =20 is chosen/kept. If the traffic leaves the CL-QSPEC Type domain, =20 e.g., the RMD QSPEC Type is chosen. I assume this is depending on the =20 outgoing interface/domain and is locally configured my a human. For case (QNE only supports RMD-QSPEC Type), the local configuration =20 (again manually) says use RMD-QSPEC Type for outgoing on each =20 interface other than the receiving. > >> With approach 1. it is straight forward how to identify to which >> local RMF to forward the received QSPEC. > > Is it, I haven't seen yet how it is 'straightforward to identify which > 'local RMF' to forward the received QSPEC? Please see the above > examples and let us know how it works for those 8 cases. I hope to have solved this with the two examples. (keeping fingers =20 crossed that I have brought my thoughts to this email :-) > >> With approach 2 I assume only RMF per QNE. The RMF on the node then >> automatically knows what the possible local QOSM can be (and >> remembers this). I one of my past emails I wrote this >> >>> >>> I believe that the QOSM ID is not needed as there is only >> one local >>> RMF per QNE. This local RMF can actually support multiple >> QOSMs but >>> this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the >>> chance to pass the QSPEC in a single piece to a single RMF. >>> The mapping between the different initiator QOSM and the >> local QOSM >>> is solely happening within the RMF. >> >> What is not clear for approach 2 for me: How does a RMF on a QNE >> distinguish between the possible available QOSMs? Does the QSPEC >> assume that the RMFs in one part of a network do know which QOSM is >> used by heart? > > Well, of course not. See the above comments, I don't think there =20 > is an > approach #2 with only 2 QSPEC Type values, more can be defined as > described. Ok, then we are both on the same side. Thanks a lot! Martin > > Thanks, > Jerry > >> >> Thanks in advance, >> >> Martin >> >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 14:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRByY-0003Mz-SY; Tue, 13 Mar 2007 14:43:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRByX-0003MD-Py for nsis@ietf.org; Tue, 13 Mar 2007 14:43:57 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRByU-0004pF-Lh for nsis@ietf.org; Tue, 13 Mar 2007 14:43:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2DIhceE021442; Tue, 13 Mar 2007 18:43:39 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 18:43:38 +0000 Message-ID: <45F6F0DA.2060007@roke.co.uk> Date: Tue, 13 Mar 2007 18:43:38 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] QSPEC Draft Review References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 18:43:38.0868 (UTC) FILETIME=[83CB1B40:01C7659F] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, On a related point to the following, some comments below: ASH, GERALD R, ATTLABS wrote: >> * Am I allowed to register new QoS parameters without >> defining a new QoSM? > > Yes, as discussed on the list > http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html. > >> * Section 5.4: >> >> This text block has to be removed: >> " >> >> The set of QSPEC parameters defined herein is at this point in time >> considered complete. Additional QSPEC parameters may be defined in >> the future. However, since this requires an update of all >> QNEs, this >> should be considered carefully. The definition of new QSPEC >> parameter requires standards action and an update of this document. >> Such an update also needs a new QSPEC version number. Furthermore, >> all QOSM definitions must be updated to include how the new QSPEC >> parameter is to be interpreted in the respective QOSM. >> >> " >> since it is not correct anymore (I hope at least). > > Yes, as discussed on the list > http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html. Reading through the current -15 draft (and intended changes outlined above), I'm unclear how the version field 'works'. The main text about the version field is in 4.2 and 5.4. The 2nd paragraph of section 4.2 defines the behaviour when a version n+1 device receives a version n message (just carry on, since you have to be backwards compatible). However, the text doesn't say what a version n device does when it receives an n+1 message. (NB: Under the current processing, a message with an unsupported parameter with 'M' set would be rejected the same way regardless of version). So, the version field currently seems to be ignored when processing a QSpec. The consequence of the e-mails you referenced above would seem to be that the version number does not need to be increased if you add a new parameter. This sounds like the correct behaviour to me (given the existence of the 'M' flag). I could possibly imagine a version number being used for more substantive changes in the QSpec. This would probably require a simple 'reject if version is higher than that supported' response, allowing the QNE that sent the RESERVE (or other NSLP message) to retry with a lower QSpec version. On a related topic, I don't know what other people who have been implementing the QSpec think, but the alignment of the fields in the common header seems a bit strange to me. It is currently: Version: 4 bits QSPEC Type: 8 bits QSpec Proc: 8 bits Reserved: 12 bits So, the second and third fields aren't aligned on octet boundaries, although they are 8 bit fields. This is likely to make processing more difficult or inefficient (it always requires a mask/shift). A nicer format, if 'version' is kept as being 4 bits long, might be: Version: 4 bits Reserved: 4 bits QSPEC Type: 8 bits QSpec Proc: 8 bits Reserved: 8 bits Alternatively, version could be expanded to 8 bits. (The GIST version number is 8 bits). regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 16:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDph-00034z-Mm; Tue, 13 Mar 2007 16:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDpf-0002wl-Ux for nsis@ietf.org; Tue, 13 Mar 2007 16:42:55 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRDpc-0006bi-Cl for nsis@ietf.org; Tue, 13 Mar 2007 16:42:55 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1173818570!12306851!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 3655 invoked from network); 13 Mar 2007 20:42:50 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-8.tower-120.messagelabs.com with SMTP; 13 Mar 2007 20:42:50 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DKgmXF006846; Tue, 13 Mar 2007 16:42:50 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DKgM5c006490; Tue, 13 Mar 2007 16:42:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Abstract NSLP-RMF API -- RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Tue, 13 Mar 2007 15:42:40 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract NSLP-RMF API -- RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Thread-Index: AcdlfjERWIJL9FNiTr+CR0dE4/JJNAAMWsZg References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> <44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, All, Regarding informative Appendix A "Abstract NSLP-RMF API" in the updated = QoS NSLP draft = http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt, I = see that in Section A.2 (Triggers from RMF/QOSM towards QOS-NSLP) it = says: " * features_out: it represents among others the flags that can be used by the QOS-NSLP for new generated QoS-NSLP messages: ** BREAK ** REQUEST REDUCED REFRESHES ** RESERVE-INIT ** TEAR ** REPLACE ** ACK-REQ ** PROXY ** SCOPING ** BYPASSING: when the outgoing message should be bypassed then it includes the required bypassing level. Otherwise it is empty. It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress ..." If the RMF/QOSM API triggers various QoS-NSLP messages by setting = 'flags', as above, how would this be interoperable? E.g., QNE-1 has = RMF/QOSM-1 and uses flag-1 to trigger some QoS-NSLP message-1, but = another QNE-2 has RMF/QOSM-2 and uses flag-2 to trigger some other = QoS-NSLP message-2. Could QNE-1 and QNE-2 understand each other and = interoperate correctly? How does sending these flags over the API = affect the QoS NSLP state machine? Thanks a lot for your insights here. Regards, Jerry -----Original Message----- From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: Tuesday, March 13, 2007 9:36 AM To: nsis Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Hi all, I would like to encourage people to check the initial version of the =20 NSLP-RMF API. Note that the API is informational only and should just give hints to =20 the implementers. Thanks, Martin Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: > > A diff of the changes since -12 is at: > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-=20 > nsis-qos-nslp-13-from-12.diff.html > > Main changes: > - Reduced refreshes are the default mechanism for refreshing sessions > - RSN needs to be taken into account when a node receives a tear > - Summary refresh and summary tear introduced (incl. objects and =20 > message > processing) > - QSPEC staking removed > - ACK-REQ flag introduced for diagnostics purposes > - Some changes to the INFO_SPEC codes (see the diff) > - (very) Initial version of NSLP-RMF API > > > Jukka > > On Fri, 9 Mar 2007, Martin Stiemerling wrote: > >> Please take a look and review the new version of the QoS NSLP draft. >> >> There have been some changes in the main part, plus a new appendix =20 >> with the >> NSLP-RMF API. >> >> Thanks, >> >> Martin >> >> Anfang der weitergeleiteten E-Mail: >> >>> Von: >>> Datum: 8. M=E4rz 2007 21:50:03 MEZ >>> An: >>> Kopie: >>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Next Steps in Signaling Working =20 >>> Group of >>> the IETF. >>> >>> Title : NSLP for Quality-of-Service Signaling >>> Author(s) : J. Manner, et al. >>> Filename : draft-ietf-nsis-qos-nslp-13.txt >>> Pages : 85 >>> Date : 2007-3-8 >>> >>> This specification describes the NSIS Signaling Layer Protocol =20 >>> (NSLP) >>> for signaling QoS reservations in the Internet. It is in =20 >>> accordance >>> with the framework and requirements developed in NSIS. Together =20 >>> with >>> GIST, it provides functionality similar to RSVP and extends it. =20 >>> The >>> QoS NSLP is independent of the underlying QoS specification or >>> architecture and provides support for different reservation =20 >>> models. >>> It is simplified by the elimination of support for multicast =20 >>> flows. >>> This specification explains the overall protocol approach, design >>> decisions made and provides examples. It specifies object, message >>> formats and processing rules. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >>> body of >>> the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >>> announce >>> to change your subscription settings. >>> >>> 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-qos-nslp-13.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-qos-nslp-13.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 13 19:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRG0b-0006B7-EK; Tue, 13 Mar 2007 19:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRG0a-0006As-Ap for nsis@ietf.org; Tue, 13 Mar 2007 19:02:20 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRG0Y-0000Ba-Qr for nsis@ietf.org; Tue, 13 Mar 2007 19:02:20 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1173826937!8854684!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5794 invoked from network); 13 Mar 2007 23:02:17 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 13 Mar 2007 23:02:17 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DN2G6A016500; Tue, 13 Mar 2007 19:02:17 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2DN20o8016364; Tue, 13 Mar 2007 19:02:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Draft Review Date: Tue, 13 Mar 2007 17:58:51 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F6F0DA.2060007@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Draft Review Thread-Index: Acdln5Jlq2/0VI6OSV+NPujmOaPBXAAGd6Vw References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: "ASH, GERALD R, ATTLABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew,=20 Thanks for the comments. Please see below. > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Tuesday, March 13, 2007 2:44 PM > To: ASH, GERALD R, ATTLABS > Cc: Hannes Tschofenig; nsis@ietf.org > Subject: Re: [NSIS] QSPEC Draft Review >=20 > Hi, >=20 > On a related point to the following, some comments below: >=20 > ASH, GERALD R, ATTLABS wrote: > >> * Am I allowed to register new QoS parameters without=20 > >> defining a new QoSM? > >=20 > > Yes, as discussed on the list > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html. > > =20 > >> * Section 5.4: > >> > >> This text block has to be removed: > >> " > >> > >> The set of QSPEC parameters defined herein is at this=20 > >> point in time > >> considered complete. Additional QSPEC parameters may=20 > >> be defined in > >> the future. However, since this requires an update of all=20 > >> QNEs, this > >> should be considered carefully. The definition of new QSPEC > >> parameter requires standards action and an update of=20 > >> this document. > >> Such an update also needs a new QSPEC version number. =20 > >> Furthermore, > >> all QOSM definitions must be updated to include how the=20 > >> new QSPEC > >> parameter is to be interpreted in the respective QOSM. > >> > >> " > >> since it is not correct anymore (I hope at least). > > Yes, as discussed on the list > > http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html. > Reading through the current -15 draft (and intended changes outlined=20 > above), I'm unclear how the version field 'works'. >=20 > The main text about the version field is in 4.2 and 5.4. The 2nd=20 > paragraph of section 4.2 defines the behaviour when a version=20 > n+1 device=20 > receives a version n message (just carry on, since you have to be=20 > backwards compatible). However, the text doesn't say what a version n=20 > device does when it receives an n+1 message. (NB: Under the current=20 > processing, a message with an unsupported parameter with 'M'=20 > set would=20 > be rejected the same way regardless of version). So, the=20 > version field=20 > currently seems to be ignored when processing a QSpec. >=20 > The consequence of the e-mails you referenced above would seem to be=20 > that the version number does not need to be increased if you=20 > add a new=20 > parameter. This sounds like the correct behaviour to me (given the=20 > existence of the 'M' flag). I could possibly imagine a version number=20 > being used for more substantive changes in the QSpec. This would=20 > probably require a simple 'reject if version is higher than that=20 > supported' response, allowing the QNE that sent the RESERVE (or other=20 > NSLP message) to retry with a lower QSpec version. I agree with your suggestion here. Some of the current text had to do with QSPEC-1 parameters, now removed, so the text needs to be updated. Based on your suggestion, I propose the following replacement text for the second paragraph in Section 4.2: "The QSPEC consists of a QSPEC version number and QSPEC objects. IANA assigns a new QSPEC version number when substantive changes are made to the QSPEC and this document is reissued. Note that a new QSPEC version number is not needed when new QSPEC parameters are specified in other specification documents, as prescribed in the IANA Considerations section. Later QSPEC versions MUST be backward compatible with earlier QSPEC versions. That is, a version n+1 device must support QSPEC version n (or earlier). On the other hand, if a QSPEC version n (or earlier) device receives an NSLP message specifying QSPEC version n+1, then the version n device responds with a 'Malformed QSPEC' error code (0x03) response, as discussed in Section 5.2.3, allowing the QNE that sent the NSLP message to retry with a lower QSPEC version." Would we need to define another error code besides 0x03 for this case? Note that the first paragraph in Section 5.4 is eliminated based on earlier discussion on the list, so that no reference to QSPEC version number will be made in Section 5.4 after this is done. > On a related topic, I don't know what other people who have been=20 > implementing the QSpec think, but the alignment of the fields in the=20 > common header seems a bit strange to me. It is currently: > Version: 4 bits > QSPEC Type: 8 bits > QSpec Proc: 8 bits > Reserved: 12 bits > So, the second and third fields aren't aligned on octet boundaries,=20 > although they are 8 bit fields. This is likely to make=20 > processing more=20 > difficult or inefficient (it always requires a mask/shift). A nicer=20 > format, if 'version' is kept as being 4 bits long, might be: > Version: 4 bits > Reserved: 4 bits > QSPEC Type: 8 bits > QSpec Proc: 8 bits > Reserved: 8 bits > Alternatively, version could be expanded to 8 bits. (The GIST version=20 > number is 8 bits). Would this order be any better (?): QSPEC Type: 8 bits QSpec Proc: 8 bits Version: 4 bits Reserved: 12 bits Several of the QSPEC parameters may not be aligned on octet boundaries either. Would it be more problematic for the common header to not align?=20 Thanks, Regards, Jerry >=20 > regards, >=20 > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 06:43:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRQw9-0003ix-Kb; Wed, 14 Mar 2007 06:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRQw7-0003gd-UG for nsis@ietf.org; Wed, 14 Mar 2007 06:42:27 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRQw5-0008Tj-5e for nsis@ietf.org; Wed, 14 Mar 2007 06:42:27 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2EAg88V005028; Wed, 14 Mar 2007 11:42:19 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R, ATTLABS'" , "'Martin Stiemerling'" References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com><235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82E6@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Wed, 14 Mar 2007 11:42:03 +0100 Message-ID: <001c01c76625$6cb590d0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82E6@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcdlfdM0esVN1WYPRA2WbD3Nr1LL/AAC9UbwACZmirA= X-Spam-Score: 0.237 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 14 Mar 2007 11:42:20 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Please see in line! > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com] > Sent: dinsdag 13 maart 2007 17:46 > To: Martin Stiemerling > Cc: ASH, GERALD R, ATTLABS; nsis > Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > > Martin, > > I agree with your comments, and have these additional > comments based on the thread: > > 1. I've still not seen a clear illustration of how QSPEC Type > is used, *at the bit level*. IMO one possible use is that > the QNI can signal QSPEC Type to indicate its intent (along > with QSPEC parameters, M flags, etc.), which should help a > downstream QNE decide how to process the QSPEC in the case > where a downstream QNE supports multiple QOSMs. > > But in the example I posed this doesn't seem to be the case: > > "Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC > Type and RMD-QSPEC Type, what does the QNE do with the > CL-QSPEC Type information from the QNI, exactly how is the > information used by the QNE? > > Georgios: By using the additional bit, the QNE will know that > the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a > local QSPEC. In this way the QNE will know how to handle the > CL-QSPEC and how to handle the RMD-QSPEC." > > Jerry: Since the QNI signals its intent is CL-QSPEC, and that is in > fact the QSPEC that the QNI signals, why would a QNE then > chose the RMD-QSPEC when it supports the CL-QSPEC and that is > the QNI's intent? > > I would still like to see a clear bit level example of how > QSPEC Type is used. Georgios: Note that in the situation that a combination of a bound End-to-end scenario is used that uses in this case the CL-QSpec and an edge-to-edge scenario that in this case uses the RMD-QSpec. Furthermore, note that the Ingress node is a QNI and the Egress is a QNR for the edge-to-edge scenario. In this scenario the QNE can be configured to use the CL-QSPEC only by the Ingress and Egress nodes and use the RMD-QOSM at the Ingress, Egress and all Interior nodes. Please noet that the same situation occurs when the Inserv Controlled Load (end-to-end to end TSpec) model used by RSVP is combined with the RSVP aggegation QoS model (RFC3175). > > 2. It is not required for a QNI/QNE to support any QOSM. > This is independent of the mandatory requirement for QNEs to > signal and interpret the TMOD parameter and for QNEs to > interpret QSPEC parameters for which the M flag has been set. Georgios: If a QOSM is not supported by the QNI, then why it should send a QSpec? A QSpec is only sent to achieve a certain QoS provisioning that is associated with a RMF. We of course can define a default QOSM, that can be used by a QNI to just send the default mandatory parameters. But all QNEs will have to know that the recived QSPEC is belonging to this default QOSM. > > 3. It isn't clear to me that the proposed bit to indicate > Initiator/Local QSPEC is absolutely required. It would seem > that from the syntax of encapsulating the Initiator QSPEC > within the Local QSPEC that the QNE could determine which > QSPEC is where without these bits. > While specifying such a bit isn't a big deal, it would be > useful if some implementer could clarify why this bit is needed. Georgios: No the initial QNI will be configured to set the bit to "Initial" value included in the Initial QSpec and the Ingress/Egress QNI (in case of a local QOSM) will be configured to set the bit "Local" in the local QSpec. Best regards, Georgios > > Thanks, > Jerry > > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: Tuesday, March 13, 2007 9:34 AM > To: ASH, GERALD R, ATTLABS > Cc: nsis > Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > > Hi Jerry, > > Thanks for the response. The issue gets much clearer with > this email for me. > Please see below. > > Am 11.03.2007 um 00:42 schrieb ASH, GERALD R, ATTLABS: > > > Hi Martin, > > > > Please see below. > > > >> -----Original Message----- > >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > >> Sent: Friday, March 09, 2007 5:55 AM > >> To: nsis > >> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > >> > >> [writing with chair's hat off] > >> > >> Hi all, > >> > >> I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue > >> which came up during the WGLC for the QSPEC draft. > >> > >> The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the > >> QSPEC-Type is > >> - initiator QSPEC or > >> - local QSPEC. > >> > >> When reading the text first I thought that is fine, but given all > >> discussions afterwards and reading again the QSPEC I have now some > >> doubts. I assume two approaches here how to deal with identifying > >> QOSMs on a QNE. > >> > >> 1. Roland's approach with QSPEC-Type identifying the type of QSPEC > >> signalled for (e.g., RMD, Y.1541. etc) (also favoured by > Georgios) 2. > >> The current QSPEC approach with QSPEC-Type just saying > initiator or > >> local QSPEC. > > > > I don't think there are 2 approaches. > > > > The QSPEC Type has so far been defined with 2 values > assigned in the > > IANA section, but an IANA registry is defined so that more > QSPEC Types > > can be defined, satisfying approach #1. I don't think there is an > > approach #2 with only 2 values defined. > > > > If the intent is to make QSPEC Type equivalent to QOSM ID > (as defined > > in the QSPEC-12 draft), as I infer from the discussion, > then I think > > we need to: > > - redefine QSPEC Type 0 = no QOSM supported by QNE (it is > allowed to > > not support any QOSM) > > - define additional QSPEC Types as specified in the IANA > registry, and > > - use a separate bit to identify the initiator/local QSPEC (as > > proposed by Georgios). > > Fine with me. That does make sense to me and clarifies the issue. > > > > > However, what isn't clear in the discussion so far is > exactly how the > > QSPEC Type/QOSM ID information would be used by a QNE. For > example, > > suppose the QNI supports CL-QSPEC Type and signals that. > Suppose also > > that a downstream QNE supports the following: > > Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what > does the > > QNE do with the CL-QSPEC Type information from the QNI, > exactly how is > > the information used by the QNE? > > Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does > > the QNE do with the CL-QSPEC Type information from the QNI, exactly > > how is the information used by the QNE? > > Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with > > the CL-QSPEC Type information from the QNI, exactly how is the > > information used by the QNE? > > Case 4: QNE support no QSPEC Types, Case 3: QNE supports > CL-QSPEC-Type > > and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC-Type > > information from the QNI, exactly how is the information > used by the > > QNE? > > > > We could define another 4 cases where the QNI signals QSPEC > Type = no > > QOSM supported. What are the corresponding answers to the above > > questions for those scenarios? > > > > It would be very helpful IMO if this was clarified in more > detail than > > it has been so far. > > Yes, I see the point. This basically boils down to which > incoming QOSM is mapped to which outgoing QOSM, i.e., if a > mapping is required or desired on how to map initiator to local QOSM. > > I suppose (also from reading Georgios' email) that this > choice is depending on the outgoing interface, better > outgoing/local domain. > Again, correct me if I'm wrong! > > Taking, for instance, case 1: An ingress QNE for a domain > supports CL- > QSPEC Type and RMD QSPEC Type; the received Type is CL-QSPEC Type. > If the traffic stays within the CL-QSPEC Type domain, > CL-QSPEC Type is chosen/kept. If the traffic leaves the > CL-QSPEC Type domain, e.g., the RMD QSPEC Type is chosen. I > assume this is depending on the outgoing interface/domain and > is locally configured my a human. > > For case (QNE only supports RMD-QSPEC Type), the local > configuration (again manually) says use RMD-QSPEC Type for > outgoing on each interface other than the receiving. > > > > > >> With approach 1. it is straight forward how to identify to which > >> local RMF to forward the received QSPEC. > > > > Is it, I haven't seen yet how it is 'straightforward to > identify which > > 'local RMF' to forward the received QSPEC? Please see the above > > examples and let us know how it works for those 8 cases. > > I hope to have solved this with the two examples. (keeping > fingers crossed that I have brought my thoughts to this email :-) > > > > >> With approach 2 I assume only RMF per QNE. The RMF on the node then > >> automatically knows what the possible local QOSM can be (and > >> remembers this). I one of my past emails I wrote this > >> > >>> > >>> I believe that the QOSM ID is not needed as there is only > >> one local > >>> RMF per QNE. This local RMF can actually support multiple > >> QOSMs but > >>> this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the > >>> chance to pass the QSPEC in a single piece to a single RMF. > >>> The mapping between the different initiator QOSM and the > >> local QOSM > >>> is solely happening within the RMF. > >> > >> What is not clear for approach 2 for me: How does a RMF on a QNE > >> distinguish between the possible available QOSMs? Does the QSPEC > >> assume that the RMFs in one part of a network do know which QOSM is > >> used by heart? > > > > Well, of course not. See the above comments, I don't think there > > is an > > approach #2 with only 2 QSPEC Type values, more can be defined as > > described. > > Ok, then we are both on the same side. > > Thanks a lot! > > Martin > > > > > Thanks, > > Jerry > > > >> > >> Thanks in advance, > >> > >> Martin > >> > >> > >> stiemerling@netlab.nec.de > >> NEC Europe Limited | > >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > >> Registered in England 2832014 > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 06:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRR8K-0001kD-66; Wed, 14 Mar 2007 06:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRR8I-0001jo-AZ for nsis@ietf.org; Wed, 14 Mar 2007 06:55:02 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRR87-0003BP-RJ for nsis@ietf.org; Wed, 14 Mar 2007 06:55:02 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2EAsiqe005996; Wed, 14 Mar 2007 11:54:49 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R, ATTLABS'" , "'Andrew McDonald'" , "'nsis'" References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com> Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS] I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Wed, 14 Mar 2007 11:54:39 +0100 Message-ID: <001e01c76627$2d0ea280$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcdlfjERWIJL9FNiTr+CR0dE4/JJNAAMWsZgAB2wZOA= X-Spam-Score: 0.137 () AWL,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 14 Mar 2007 11:54:49 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry These flags have to be set in for example, the situation that a QNE is = an Initial QNI (in case of an end-toend (initial) QOSM) or=20 an Ingress/Egress QNI in case of an edge-to-edge (local QOSM).=20 This all is needed in order to provide the support for the=20 Bound and combined: * end-to-end and end-to-end scenarios * end-to-end and edge-to-edge scenarios * end-to-end and end-to-edge scenario Best Regards, Georgios > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Sent: dinsdag 13 maart 2007 21:43 > To: Andrew McDonald; nsis > Cc: ASH, GERALD R, ATTLABS > Subject: Abstract NSLP-RMF API -- RE: [NSIS]=20 > I-DACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > Hi Andrew, All, >=20 > Regarding informative Appendix A "Abstract NSLP-RMF API" in=20 > the updated QoS NSLP draft=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1 > 3.txt, I see that in Section A.2 (Triggers from RMF/QOSM=20 > towards QOS-NSLP) it says: >=20 > " * features_out: it represents among others the flags that can > be used by the QOS-NSLP > for new generated QoS-NSLP messages: >=20 > ** BREAK > ** REQUEST REDUCED REFRESHES > ** RESERVE-INIT > ** TEAR > ** REPLACE > ** ACK-REQ > ** PROXY > ** SCOPING > ** BYPASSING: when the outgoing message should be bypassed > then it includes the required bypassing level. Otherwise it > is empty. It can be set only by QNI_Ingress, QNR_Ingress, > QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress, > QNR_Ingress, QNI_Egress, QNR_Egress > ..." >=20 > If the RMF/QOSM API triggers various QoS-NSLP messages by=20 > setting 'flags', as above, how would this be interoperable? =20 > E.g., QNE-1 has RMF/QOSM-1 and uses flag-1 to trigger some=20 > QoS-NSLP message-1, but another QNE-2 has RMF/QOSM-2 and uses=20 > flag-2 to trigger some other QoS-NSLP message-2. Could QNE-1=20 > and QNE-2 understand each other and interoperate correctly? =20 > How does sending these flags over the API affect the QoS NSLP=20 > state machine? >=20 > Thanks a lot for your insights here. >=20 > Regards, > Jerry >=20 > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: Tuesday, March 13, 2007 9:36 AM > To: nsis > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > Hi all, >=20 > I would like to encourage people to check the initial version=20 > of the NSLP-RMF API. >=20 > Note that the API is informational only and should just give=20 > hints to the implementers. >=20 > Thanks, >=20 > Martin >=20 > Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: >=20 > > > > A diff of the changes since -12 is at: > > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf- > > nsis-qos-nslp-13-from-12.diff.html > > > > Main changes: > > - Reduced refreshes are the default mechanism for=20 > refreshing sessions > > - RSN needs to be taken into account when a node receives a tear > > - Summary refresh and summary tear introduced (incl. objects and=20 > > message > > processing) > > - QSPEC staking removed > > - ACK-REQ flag introduced for diagnostics purposes > > - Some changes to the INFO_SPEC codes (see the diff) > > - (very) Initial version of NSLP-RMF API > > > > > > Jukka > > > > On Fri, 9 Mar 2007, Martin Stiemerling wrote: > > > >> Please take a look and review the new version of the QoS=20 > NSLP draft. > >> > >> There have been some changes in the main part, plus a new appendix=20 > >> with the NSLP-RMF API. > >> > >> Thanks, > >> > >> Martin > >> > >> Anfang der weitergeleiteten E-Mail: > >> > >>> Von: > >>> Datum: 8. M=E4rz 2007 21:50:03 MEZ > >>> An: > >>> Kopie: > >>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt > >>> > >>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>> directories. > >>> This draft is a work item of the Next Steps in Signaling Working=20 > >>> Group of the IETF. > >>> > >>> Title : NSLP for Quality-of-Service Signaling > >>> Author(s) : J. Manner, et al. > >>> Filename : draft-ietf-nsis-qos-nslp-13.txt > >>> Pages : 85 > >>> Date : 2007-3-8 > >>> > >>> This specification describes the NSIS Signaling Layer Protocol > >>> (NSLP) > >>> for signaling QoS reservations in the Internet. It is in=20 > >>> accordance > >>> with the framework and requirements developed in NSIS. Together=20 > >>> with > >>> GIST, it provides functionality similar to RSVP and=20 > extends it. =20 > >>> The > >>> QoS NSLP is independent of the underlying QoS specification or > >>> architecture and provides support for different reservation=20 > >>> models. > >>> It is simplified by the elimination of support for multicast=20 > >>> flows. > >>> This specification explains the overall protocol=20 > approach, design > >>> decisions made and provides examples. It specifies=20 > object, message > >>> formats and processing rules. > >>> > >>> A URL for this Internet-Draft is: > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt > >>> > >>> To remove yourself from the I-D Announcement list, send a=20 > message to=20 > >>> i-d-announce-request@ietf.org with the word unsubscribe=20 > in the body=20 > >>> of the message. > >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- > >>> announce > >>> to change your subscription settings. > >>> > >>> Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > >>> username "anonymous" and a password of your e-mail address. After=20 > >>> logging in, type "cd internet-drafts" and then "get=20 > >>> draft-ietf-nsis-qos-nslp-13.txt". > >>> > >>> A list of Internet-Drafts directories can be found in=20 > >>> http://www.ietf.org/shadow.html or=20 > >>> 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-qos-nslp-13.txt". > >>> > >>> NOTE: The mail server at ietf.org can return the document in > >>> MIME-encoded form by using the "mpack" utility. To use this=20 > >>> feature, insert the command "ENCODING mime" before the "FILE" > >>> command. To decode the response(s), you will need "munpack" or a=20 > >>> MIME-compliant mail reader. Different MIME-compliant=20 > mail readers=20 > >>> exhibit different behavior, especially when dealing with=20 > "multipart"=20 > >>> MIME messages (i.e. documents which have been split up=20 > into multiple=20 > >>> messages), so check your local documentation on how to manipulate=20 > >>> these messages. > >>> > >>> Below is the data which will enable a MIME compliant mail reader=20 > >>> implementation to automatically retrieve the ASCII version of the=20 > >>> Internet-Draft. > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL=20 > | Registered in England 2832014 >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 07:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRRD3-00040c-8L; Wed, 14 Mar 2007 06:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRRD1-00040U-SS for nsis@ietf.org; Wed, 14 Mar 2007 06:59:55 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRRCy-0004CI-Dp for nsis@ietf.org; Wed, 14 Mar 2007 06:59:55 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2EAx1YB024429; Wed, 14 Mar 2007 10:59:02 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 10:59:01 +0000 Message-ID: <45F7D575.2010908@roke.co.uk> Date: Wed, 14 Mar 2007 10:59:01 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: Abstract NSLP-RMF API -- RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> <44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 14 Mar 2007 10:59:01.0968 (UTC) FILETIME=[C6477D00:01C76627] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsys002x.roke.co.uk id l2EAx1YB024429 X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jerry, all, I think that some of these aspects do give too much information/control=20 to the RMF. One problem we started to encounter when trying to come up with the=20 initial cut of an API was that there are areas where the 'application'=20 may want to interact with the NSLP. However, the figure 2 diagram in the=20 QoS NSLP document currently shows all these interactions as being=20 mediated by the RMF. It may also be that the API is the wrong 'shape' at=20 the moment, and too RMF-driven. A better model might be to be more=20 NSLP-driven with call-backs into the RMF (e.g. QoS NSLP to RMF: "tell me=20 what to put in this RESERVE I'm going to send", rather than the current=20 RMF to NSLP: "send a RESERVE with this QSpec in it"). Any thoughts on improvements would be useful. regards, Andrew ASH, GERALD R, ATTLABS wrote: > Hi Andrew, All, >=20 > Regarding informative Appendix A "Abstract NSLP-RMF API" in the updated= QoS NSLP draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-n= slp-13.txt, I see that in Section A.2 (Triggers from RMF/QOSM towards QOS= -NSLP) it says: >=20 > " * features_out: it represents among others the flags that can > be used by the QOS-NSLP > for new generated QoS-NSLP messages: >=20 > ** BREAK > ** REQUEST REDUCED REFRESHES > ** RESERVE-INIT > ** TEAR > ** REPLACE > ** ACK-REQ > ** PROXY > ** SCOPING > ** BYPASSING: when the outgoing message should be bypassed > then it includes the required bypassing level. Otherwise it > is empty. It can be set only by QNI_Ingress, QNR_Ingress, > QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress, > QNR_Ingress, QNI_Egress, QNR_Egress > ..." >=20 > If the RMF/QOSM API triggers various QoS-NSLP messages by setting 'flag= s', as above, how would this be interoperable? E.g., QNE-1 has RMF/QOSM-= 1 and uses flag-1 to trigger some QoS-NSLP message-1, but another QNE-2 h= as RMF/QOSM-2 and uses flag-2 to trigger some other QoS-NSLP message-2. = Could QNE-1 and QNE-2 understand each other and interoperate correctly? = How does sending these flags over the API affect the QoS NSLP state machi= ne? >=20 > Thanks a lot for your insights here. >=20 > Regards, > Jerry >=20 > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: Tuesday, March 13, 2007 9:36 AM > To: nsis > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > Hi all, >=20 > I would like to encourage people to check the initial version of the =20 > NSLP-RMF API. >=20 > Note that the API is informational only and should just give hints to =20 > the implementers. >=20 > Thanks, >=20 > Martin >=20 > Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: >=20 >> A diff of the changes since -12 is at: >> http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-=20 >> nsis-qos-nslp-13-from-12.diff.html >> >> Main changes: >> - Reduced refreshes are the default mechanism for refreshing sessions >> - RSN needs to be taken into account when a node receives a tear >> - Summary refresh and summary tear introduced (incl. objects and =20 >> message >> processing) >> - QSPEC staking removed >> - ACK-REQ flag introduced for diagnostics purposes >> - Some changes to the INFO_SPEC codes (see the diff) >> - (very) Initial version of NSLP-RMF API >> >> >> Jukka >> >> On Fri, 9 Mar 2007, Martin Stiemerling wrote: >> >>> Please take a look and review the new version of the QoS NSLP draft. >>> >>> There have been some changes in the main part, plus a new appendix =20 >>> with the >>> NSLP-RMF API. >>> >>> Thanks, >>> >>> Martin >>> >>> Anfang der weitergeleiteten E-Mail: >>> >>>> Von: >>>> Datum: 8. M=E4rz 2007 21:50:03 MEZ >>>> An: >>>> Kopie: >>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Next Steps in Signaling Working =20 >>>> Group of >>>> the IETF. >>>> >>>> Title : NSLP for Quality-of-Service Signaling >>>> Author(s) : J. Manner, et al. >>>> Filename : draft-ietf-nsis-qos-nslp-13.txt >>>> Pages : 85 >>>> Date : 2007-3-8 >>>> >>>> This specification describes the NSIS Signaling Layer Protocol =20 >>>> (NSLP) >>>> for signaling QoS reservations in the Internet. It is in =20 >>>> accordance >>>> with the framework and requirements developed in NSIS. Together =20 >>>> with >>>> GIST, it provides functionality similar to RSVP and extends it. =20 >>>> The >>>> QoS NSLP is independent of the underlying QoS specification or >>>> architecture and provides support for different reservation =20 >>>> models. >>>> It is simplified by the elimination of support for multicast =20 >>>> flows. >>>> This specification explains the overall protocol approach, design >>>> decisions made and provides examples. It specifies object, message >>>> formats and processing rules. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >>>> body of >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >>>> announce >>>> to change your subscription settings. >>>> >>>> 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-qos-nslp-13.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-qos-nslp-13.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --=20 Andrew McDonald Consultant Engineer Tel: +44 (0)1794 833833 Fax: +44 (0)1794 833616 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 08:31:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSd0-0005bG-V7; Wed, 14 Mar 2007 08:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRScz-0005au-SW for nsis@ietf.org; Wed, 14 Mar 2007 08:30:49 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRScu-0007T1-6L for nsis@ietf.org; Wed, 14 Mar 2007 08:30:49 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1173875442!19195327!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20579 invoked from network); 14 Mar 2007 12:30:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 14 Mar 2007 12:30:43 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2ECUgU7010839; Wed, 14 Mar 2007 08:30:42 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2ECUasO010781; Wed, 14 Mar 2007 08:30:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Wed, 14 Mar 2007 07:30:35 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F7D575.2010908@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract NSLP-RMF API -- RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwyw References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de> <44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com> <45F7D575.2010908@roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: "ASH, GERALD R, ATTLABS" , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, All, I agree with you that the Abstract NSLP-RMF API should be significantly = toned down so as to, as you say, *not* make it 'too RMF driven' nor = 'give too much information/control to the RMF'. =20 The way it is now would make the result non-interoperable IMO, as = illustrated in the example I provided below. Furthermore, I think it = should be clarified how the QoS NSLP state machine might be affected by = 'triggers' from the RMF? As in our long discussions earlier, the RMF = must not change the normative QoS NSLP state machine based only on the = informative API interactions and 'RMF/API triggers' alone, right? Thanks, Regards, Jerry=20 -----Original Message----- From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 Sent: Wednesday, March 14, 2007 6:59 AM To: ASH, GERALD R, ATTLABS Cc: nsis Subject: Re: Abstract NSLP-RMF API -- RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qos-nslp-13.txt Jerry, all, I think that some of these aspects do give too much information/control=20 to the RMF. One problem we started to encounter when trying to come up with the=20 initial cut of an API was that there are areas where the 'application'=20 may want to interact with the NSLP. However, the figure 2 diagram in the = QoS NSLP document currently shows all these interactions as being=20 mediated by the RMF. It may also be that the API is the wrong 'shape' at = the moment, and too RMF-driven. A better model might be to be more=20 NSLP-driven with call-backs into the RMF (e.g. QoS NSLP to RMF: "tell me = what to put in this RESERVE I'm going to send", rather than the current=20 RMF to NSLP: "send a RESERVE with this QSpec in it"). Any thoughts on improvements would be useful. regards, Andrew ASH, GERALD R, ATTLABS wrote: > Hi Andrew, All, >=20 > Regarding informative Appendix A "Abstract NSLP-RMF API" in the = updated QoS NSLP draft = http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt, I = see that in Section A.2 (Triggers from RMF/QOSM towards QOS-NSLP) it = says: >=20 > " * features_out: it represents among others the flags that can > be used by the QOS-NSLP > for new generated QoS-NSLP messages: >=20 > ** BREAK > ** REQUEST REDUCED REFRESHES > ** RESERVE-INIT > ** TEAR > ** REPLACE > ** ACK-REQ > ** PROXY > ** SCOPING > ** BYPASSING: when the outgoing message should be bypassed > then it includes the required bypassing level. Otherwise it > is empty. It can be set only by QNI_Ingress, QNR_Ingress, > QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress, > QNR_Ingress, QNI_Egress, QNR_Egress > ..." >=20 > If the RMF/QOSM API triggers various QoS-NSLP messages by setting = 'flags', as above, how would this be interoperable? E.g., QNE-1 has = RMF/QOSM-1 and uses flag-1 to trigger some QoS-NSLP message-1, but = another QNE-2 has RMF/QOSM-2 and uses flag-2 to trigger some other = QoS-NSLP message-2. Could QNE-1 and QNE-2 understand each other and = interoperate correctly? How does sending these flags over the API = affect the QoS NSLP state machine? >=20 > Thanks a lot for your insights here. >=20 > Regards, > Jerry >=20 > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: Tuesday, March 13, 2007 9:36 AM > To: nsis > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > Hi all, >=20 > I would like to encourage people to check the initial version of the =20 > NSLP-RMF API. >=20 > Note that the API is informational only and should just give hints to = > the implementers. >=20 > Thanks, >=20 > Martin >=20 > Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: >=20 >> A diff of the changes since -12 is at: >> http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-=20 >> nsis-qos-nslp-13-from-12.diff.html >> >> Main changes: >> - Reduced refreshes are the default mechanism for refreshing sessions >> - RSN needs to be taken into account when a node receives a tear >> - Summary refresh and summary tear introduced (incl. objects and =20 >> message >> processing) >> - QSPEC staking removed >> - ACK-REQ flag introduced for diagnostics purposes >> - Some changes to the INFO_SPEC codes (see the diff) >> - (very) Initial version of NSLP-RMF API >> >> >> Jukka >> >> On Fri, 9 Mar 2007, Martin Stiemerling wrote: >> >>> Please take a look and review the new version of the QoS NSLP draft. >>> >>> There have been some changes in the main part, plus a new appendix =20 >>> with the >>> NSLP-RMF API. >>> >>> Thanks, >>> >>> Martin >>> >>> Anfang der weitergeleiteten E-Mail: >>> >>>> Von: >>>> Datum: 8. M=E4rz 2007 21:50:03 MEZ >>>> An: >>>> Kopie: >>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Next Steps in Signaling Working =20 >>>> Group of >>>> the IETF. >>>> >>>> Title : NSLP for Quality-of-Service Signaling >>>> Author(s) : J. Manner, et al. >>>> Filename : draft-ietf-nsis-qos-nslp-13.txt >>>> Pages : 85 >>>> Date : 2007-3-8 >>>> >>>> This specification describes the NSIS Signaling Layer Protocol =20 >>>> (NSLP) >>>> for signaling QoS reservations in the Internet. It is in =20 >>>> accordance >>>> with the framework and requirements developed in NSIS. Together =20 >>>> with >>>> GIST, it provides functionality similar to RSVP and extends it. =20 >>>> The >>>> QoS NSLP is independent of the underlying QoS specification or >>>> architecture and provides support for different reservation =20 >>>> models. >>>> It is simplified by the elimination of support for multicast =20 >>>> flows. >>>> This specification explains the overall protocol approach, design >>>> decisions made and provides examples. It specifies object, = message >>>> formats and processing rules. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a message = to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >>>> body of >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >>>> announce >>>> to change your subscription settings. >>>> >>>> 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-qos-nslp-13.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-qos-nslp-13.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail = readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --=20 Andrew McDonald Consultant Engineer Tel: +44 (0)1794 833833 Fax: +44 (0)1794 833616 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 08:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSnJ-0004El-GK; Wed, 14 Mar 2007 08:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSnH-0004Eg-S6 for nsis@ietf.org; Wed, 14 Mar 2007 08:41:27 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRSnG-0001Ry-7o for nsis@ietf.org; Wed, 14 Mar 2007 08:41:27 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2ECfHv1014630; Wed, 14 Mar 2007 13:41:22 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R, ATTLABS'" , "'Andrew McDonald'" References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com> Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS] I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Wed, 14 Mar 2007 13:41:11 +0100 Message-ID: <003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDA= X-Spam-Score: 0.136 () AWL,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 14 Mar 2007 13:41:24 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Regarding the following paragraph: > As in our long discussions earlier, the RMF must not change=20 > the normative QoS NSLP state machine based only on the=20 > informative API interactions and 'RMF/API triggers' alone, right? All the triggers that go into the QOS-NSLP will somehow change the=20 QoS NSLP state machine. The API describes what are the possible in/out triggers=20 that should be taken into account by the QOS-NSLP state machine! Best regards, Georgios > -----Original Message----- > From: ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Sent: woensdag 14 maart 2007 13:31 > To: Andrew McDonald > Cc: ASH, GERALD R, ATTLABS; nsis > Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS]=20 > I-DACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > Hi Andrew, All, >=20 > I agree with you that the Abstract NSLP-RMF API should be=20 > significantly toned down so as to, as you say, *not* make it=20 > 'too RMF driven' nor 'give too much information/control to the RMF'. =20 >=20 > The way it is now would make the result non-interoperable=20 > IMO, as illustrated in the example I provided below. =20 > Furthermore, I think it should be clarified how the QoS NSLP=20 > state machine might be affected by 'triggers' from the RMF? =20 > As in our long discussions earlier, the RMF must not change=20 > the normative QoS NSLP state machine based only on the=20 > informative API interactions and 'RMF/API triggers' alone, right? >=20 > Thanks, > Regards, > Jerry=20 >=20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] > Sent: Wednesday, March 14, 2007 6:59 AM > To: ASH, GERALD R, ATTLABS > Cc: nsis > Subject: Re: Abstract NSLP-RMF API -- RE: [NSIS] I-D=20 > ACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > Jerry, all, >=20 > I think that some of these aspects do give too much=20 > information/control to the RMF. >=20 > One problem we started to encounter when trying to come up=20 > with the initial cut of an API was that there are areas where=20 > the 'application'=20 > may want to interact with the NSLP. However, the figure 2=20 > diagram in the QoS NSLP document currently shows all these=20 > interactions as being mediated by the RMF. It may also be=20 > that the API is the wrong 'shape' at the moment, and too=20 > RMF-driven. A better model might be to be more NSLP-driven=20 > with call-backs into the RMF (e.g. QoS NSLP to RMF: "tell me=20 > what to put in this RESERVE I'm going to send", rather than=20 > the current RMF to NSLP: "send a RESERVE with this QSpec in it"). >=20 > Any thoughts on improvements would be useful. >=20 > regards, >=20 > Andrew >=20 > ASH, GERALD R, ATTLABS wrote: > > Hi Andrew, All, > >=20 > > Regarding informative Appendix A "Abstract NSLP-RMF API" in=20 > the updated QoS NSLP draft=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1 > 3.txt, I see that in Section A.2 (Triggers from RMF/QOSM=20 > towards QOS-NSLP) it says: > >=20 > > " * features_out: it represents among others the flags that can > > be used by the QOS-NSLP > > for new generated QoS-NSLP messages: > >=20 > > ** BREAK > > ** REQUEST REDUCED REFRESHES > > ** RESERVE-INIT > > ** TEAR > > ** REPLACE > > ** ACK-REQ > > ** PROXY > > ** SCOPING > > ** BYPASSING: when the outgoing message should be bypassed > > then it includes the required bypassing level. Otherwise it > > is empty. It can be set only by QNI_Ingress, QNR_Ingress, > > QNI_Egress, QNR_Egress. It can be unset only by=20 > QNI_Ingress, > > QNR_Ingress, QNI_Egress, QNR_Egress > > ..." > >=20 > > If the RMF/QOSM API triggers various QoS-NSLP messages by=20 > setting 'flags', as above, how would this be interoperable? =20 > E.g., QNE-1 has RMF/QOSM-1 and uses flag-1 to trigger some=20 > QoS-NSLP message-1, but another QNE-2 has RMF/QOSM-2 and uses=20 > flag-2 to trigger some other QoS-NSLP message-2. Could QNE-1=20 > and QNE-2 understand each other and interoperate correctly? =20 > How does sending these flags over the API affect the QoS NSLP=20 > state machine? > >=20 > > Thanks a lot for your insights here. > >=20 > > Regards, > > Jerry > >=20 > > -----Original Message----- > > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > > Sent: Tuesday, March 13, 2007 9:36 AM > > To: nsis > > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt > >=20 > > Hi all, > >=20 > > I would like to encourage people to check the initial=20 > version of the=20 > > NSLP-RMF API. > >=20 > > Note that the API is informational only and should just=20 > give hints to=20 > > the implementers. > >=20 > > Thanks, > >=20 > > Martin > >=20 > > Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner: > >=20 > >> A diff of the changes since -12 is at: > >> http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf- > >> nsis-qos-nslp-13-from-12.diff.html > >> > >> Main changes: > >> - Reduced refreshes are the default mechanism for=20 > refreshing sessions > >> - RSN needs to be taken into account when a node receives a tear > >> - Summary refresh and summary tear introduced (incl. objects and=20 > >> message > >> processing) > >> - QSPEC staking removed > >> - ACK-REQ flag introduced for diagnostics purposes > >> - Some changes to the INFO_SPEC codes (see the diff) > >> - (very) Initial version of NSLP-RMF API > >> > >> > >> Jukka > >> > >> On Fri, 9 Mar 2007, Martin Stiemerling wrote: > >> > >>> Please take a look and review the new version of the QoS=20 > NSLP draft. > >>> > >>> There have been some changes in the main part, plus a new=20 > appendix=20 > >>> with the NSLP-RMF API. > >>> > >>> Thanks, > >>> > >>> Martin > >>> > >>> Anfang der weitergeleiteten E-Mail: > >>> > >>>> Von: > >>>> Datum: 8. M=E4rz 2007 21:50:03 MEZ > >>>> An: > >>>> Kopie: > >>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt > >>>> > >>>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>>> directories. > >>>> This draft is a work item of the Next Steps in Signaling Working=20 > >>>> Group of the IETF. > >>>> > >>>> Title : NSLP for Quality-of-Service Signaling > >>>> Author(s) : J. Manner, et al. > >>>> Filename : draft-ietf-nsis-qos-nslp-13.txt > >>>> Pages : 85 > >>>> Date : 2007-3-8 > >>>> > >>>> This specification describes the NSIS Signaling Layer Protocol > >>>> (NSLP) > >>>> for signaling QoS reservations in the Internet. It is in=20 > >>>> accordance > >>>> with the framework and requirements developed in NSIS.=20 > Together=20 > >>>> with > >>>> GIST, it provides functionality similar to RSVP and=20 > extends it. =20 > >>>> The > >>>> QoS NSLP is independent of the underlying QoS specification or > >>>> architecture and provides support for different reservation=20 > >>>> models. > >>>> It is simplified by the elimination of support for multicast=20 > >>>> flows. > >>>> This specification explains the overall protocol=20 > approach, design > >>>> decisions made and provides examples. It specifies=20 > object, message > >>>> formats and processing rules. > >>>> > >>>> A URL for this Internet-Draft is: > >>>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt > >>>> > >>>> To remove yourself from the I-D Announcement list, send=20 > a message=20 > >>>> to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the=20 > >>>> body of the message. > >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- > >>>> announce > >>>> to change your subscription settings. > >>>> > >>>> Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > >>>> username "anonymous" and a password of your e-mail=20 > address. After=20 > >>>> logging in, type "cd internet-drafts" and then "get=20 > >>>> draft-ietf-nsis-qos-nslp-13.txt". > >>>> > >>>> A list of Internet-Drafts directories can be found in=20 > >>>> http://www.ietf.org/shadow.html or=20 > >>>> 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-qos-nslp-13.txt". > >>>> > >>>> NOTE: The mail server at ietf.org can return the document in > >>>> MIME-encoded form by using the "mpack" utility. To use this=20 > >>>> feature, insert the command "ENCODING mime" before the "FILE" > >>>> command. To decode the response(s), you will need=20 > "munpack" or a=20 > >>>> MIME-compliant mail reader. Different MIME-compliant=20 > mail readers=20 > >>>> exhibit different behavior, especially when dealing with=20 > >>>> "multipart" MIME messages (i.e. documents which have=20 > been split up=20 > >>>> into multiple messages), so check your local=20 > documentation on how=20 > >>>> to manipulate these messages. > >>>> > >>>> Below is the data which will enable a MIME compliant mail reader=20 > >>>> implementation to automatically retrieve the ASCII=20 > version of the=20 > >>>> Internet-Draft. > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 > >=20 > > stiemerling@netlab.nec.de > > NEC Europe Limited | > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL |=20 > > Registered in England 2832014 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 > -- > Andrew McDonald > Consultant Engineer > Tel: +44 (0)1794 833833 > Fax: +44 (0)1794 833616 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 10:00:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRU1e-0004vE-UK; Wed, 14 Mar 2007 10:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRU1e-0004v8-Hy for nsis@ietf.org; Wed, 14 Mar 2007 10:00:22 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRU1I-0003nV-RI for nsis@ietf.org; Wed, 14 Mar 2007 10:00:22 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2EDxnAf009705; Wed, 14 Mar 2007 13:59:50 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 13:59:49 +0000 Message-ID: <45F7FFD5.4010605@roke.co.uk> Date: Wed, 14 Mar 2007 13:59:49 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] QSPEC Draft Review References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 13:59:49.0767 (UTC) FILETIME=[08124170:01C76641] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, ASH, GERALD R, ATTLABS wrote: > Based on your suggestion, I propose the following replacement text for > the second paragraph in Section 4.2: > > "The QSPEC consists of a QSPEC version number and QSPEC objects. IANA > assigns a new QSPEC version number when substantive changes are made to > the QSPEC and this document is reissued. Note that a new QSPEC version > number is not needed when new QSPEC parameters are specified in other > specification documents, as prescribed in the IANA Considerations > section. Later QSPEC versions MUST be backward compatible with earlier > QSPEC versions. That is, a version n+1 device must support QSPEC > version n (or earlier). On the other hand, if a QSPEC version n (or > earlier) device receives an NSLP message specifying QSPEC version n+1, > then the version n device responds with a 'Malformed QSPEC' error code > (0x03) response, as discussed in Section 5.2.3, allowing the QNE that > sent the NSLP message to retry with a lower QSPEC version." I don't understand the distinction between adding new parameters outside the QSPEC base document and reissuing the QSPEC base document with the addition of some parameters as the only change. Do you need to increase the version number in either case? Won't the 'M' bits be enough to handle this? I may be missing something, but I think a change that increases the version number is likely to be more radical than simply adding a new parameter. Probably adding a new QSPEC object would be one case (since there is no equivalent of the 'M' bit or NSLP/GIST 'A/B' flags there). The version number field is fairly small (4 bits), so small changes which require only a new parameter seem to be a waste of version numbers, given that there are other compatibility/extension mechanisms in place. > Would we need to define another error code besides 0x03 for this case? It would probably be a good idea. If you've got a bad version number you can probably retry with a lower one. In the general 'malformed' case there isn't necessarily anything you can do to automatically retry. > Note that the first paragraph in Section 5.4 is eliminated based on > earlier discussion on the list, so that no reference to QSPEC version > number will be made in Section 5.4 after this is done. OK >> On a related topic, I don't know what other people who have been >> implementing the QSpec think, but the alignment of the fields in the >> common header seems a bit strange to me. It is currently: >> Version: 4 bits >> QSPEC Type: 8 bits >> QSpec Proc: 8 bits >> Reserved: 12 bits >> So, the second and third fields aren't aligned on octet boundaries, >> although they are 8 bit fields. This is likely to make >> processing more >> difficult or inefficient (it always requires a mask/shift). A nicer >> format, if 'version' is kept as being 4 bits long, might be: >> Version: 4 bits >> Reserved: 4 bits >> QSPEC Type: 8 bits >> QSpec Proc: 8 bits >> Reserved: 8 bits >> Alternatively, version could be expanded to 8 bits. (The GIST version >> number is 8 bits). > > Would this order be any better (?): > > QSPEC Type: 8 bits > QSpec Proc: 8 bits > Version: 4 bits > Reserved: 12 bits > > Several of the QSPEC parameters may not be aligned on octet boundaries > either. Would it be more problematic for the common header to not > align? Keeping the version as the first field is probably a good idea. If we move to a version 2, will it still have QSpec Type and QSpec Proc fields? The other parameters looked ok to me. Where fields are not a multiple of 8 bits they only need masking to extract the relevant data. They don't require glueing together nibbles from consecutive bytes. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 10:14:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUE2-0000ei-Gs; Wed, 14 Mar 2007 10:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUE1-0000eT-S5 for nsis@ietf.org; Wed, 14 Mar 2007 10:13:09 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRUDy-0007av-4x for nsis@ietf.org; Wed, 14 Mar 2007 10:13:09 -0400 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HRUDp-0008Nb-9i; Wed, 14 Mar 2007 15:13:05 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 361222FC012; Wed, 14 Mar 2007 15:12:56 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HRUDo-0004jY-Hc; Wed, 14 Mar 2007 15:12:56 +0100 Message-ID: <45F802E7.2090000@tm.uka.de> Date: Wed, 14 Mar 2007 15:12:55 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number References: <45F19C6A.5060108@christian-dickmann.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > i think it is really a conceptual thing: i see the magic number > as part of the encapsulation, just like the RAO and the UDP > header and port number, since that is the purpose it serves > (to demultiplex packets, not to carry information). and to > put it in every message would indeed be a waste of bytes, > which you could never go back on (since the magic number comes > before any version information). > > another way of putting it: we want the magic number to be something > that is checked to find out whether something is a GIST packet, > rather than part of parsing the GIST packet. making it part of > the common header would blur that distinction. I would agree on that. I see it as part of the encapsulation, too. > however, it may be that in practice, what you suggest would be > simpler. i would be interested to hear what other people think > about that. Hmm. I don't like the idea of carrying around that magic number always... > one specific point: we need to ensure that GIST packets without > the magic number go to a different UDP port, else you could not > know how to receive them properly. that may not be clear enough > in the spec at the moment. That seems to be important and the devil lies in the details... For example: Our implementation currently uses the well-known port as source port for Q-mode packets since it is listening there anyways. However, I assume that responses will not carry a magic number and thus we must change the Q-mode source port to something different... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 10:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUG7-0002cd-ST; Wed, 14 Mar 2007 10:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUG6-0002ao-JR for nsis@ietf.org; Wed, 14 Mar 2007 10:15:18 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRUG5-00085h-7L for nsis@ietf.org; Wed, 14 Mar 2007 10:15:18 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8AF6813CF81; Wed, 14 Mar 2007 15:15:17 +0100 (CET) In-Reply-To: References: <45F34B86.1010902@christian-dickmann.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B265C7F-151F-40F5-BC7E-35E234BE5C61@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST: Is Loose-End MRM REQUIRED? Date: Wed, 14 Mar 2007 15:15:14 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Am 12.03.2007 um 15:19 schrieb Hancock, Robert: > hi, > >> -----Original Message----- >> From: Christian Dickmann [mailto:mail@christian-dickmann.de] >> Sent: 11 March 2007 00:21 >> To: nsis@ietf.org >> Subject: [NSIS] GIST: Is Loose-End MRM REQUIRED? >> >> Hi Robert, >> >> I noticed that TCP and TLS over TCP are REQUIRED in the RFC >> 2119 sense. >> In addition, for the PC-MRM the downstream encapsulation is >> REQUIRED, while upstream encapsulation is OPTIONAL (for the >> sending part). >> However, the MRMs themselves have no text stating that they >> are REQUIRED. I would assume that support for PC-MRM is >> REQUIRED, while support for LE-MRM is OPTIONAL, because there >> might be special GIST implementations just meant to work with >> QoS NSLP which do not need LE-MRM to work. > > here, the underlying point is that the MRMs required strictly > depend on the NSLPs to be supported. so if you have an NSLP which > only uses MRM foo (still to be specified), there is no particular > need for a node which only hosts foo to have a GIST implementation > which support PC-MRM or LE-MRM. that is why the specification leaves > the 2119 status of the MRMs open. > > OTOH, there is also case that it is good to have MRMs supported > because otherwise it becomes a deployment drag for new applications > (you have to go and check every implementation and find out whether > it supports the MRMs that you need, which is a pain). So, even though > the MRMs are not logically required, it is still good for the > specification > to send a message that you would be silly not to implement them. > > it would be interesting to know other people's views on this. on > balance, there is a good case for saying that both MRMs are SHOULDs. It would go for SHOULD as RFC 2119 says for this case: "to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Martin > i would even say MUST, except for the fact that the PC-MRM is > actually probably the hardest part of the protocol to implement > correctly, so making it an unavoidable part of the protocol seems > like too much cost for future NSIS applications which don't need > it. > > cheers, > > robert h. > >> >> Regards, >> Christian Dickmann >> >> >> _______________________________________________ >> 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 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 11:53:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVly-0001nT-3Q; Wed, 14 Mar 2007 11:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVlw-0001ft-Bx for nsis@ietf.org; Wed, 14 Mar 2007 11:52:16 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRVls-0002Qt-UY for nsis@ietf.org; Wed, 14 Mar 2007 11:52:16 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1173887532!10942031!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20927 invoked from network); 14 Mar 2007 15:52:12 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 14 Mar 2007 15:52:12 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2EFqAHV028146; Wed, 14 Mar 2007 11:52:11 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2EFpr7R027910; Wed, 14 Mar 2007 11:52:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Draft Review Date: Wed, 14 Mar 2007 10:52:01 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82F8@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F7FFD5.4010605@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Draft Review Thread-Index: AcdmQQ9Yh6Bh7VbCQm6LuLHVRKpBeAADJa9w References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> <45F7FFD5.4010605@roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: "ASH, GERALD R, ATTLABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, I guess I confused you with my previous post, please see below.=20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Wednesday, March 14, 2007 10:00 AM > To: ASH, GERALD R, ATTLABS > Cc: nsis@ietf.org > Subject: Re: [NSIS] QSPEC Draft Review >=20 > Hi Jerry, >=20 > ASH, GERALD R, ATTLABS wrote: > > Based on your suggestion, I propose the following=20 > > replacement text for > > the second paragraph in Section 4.2: > >=20 > > "The QSPEC consists of a QSPEC version number and QSPEC=20 > > objects. IANA > > assigns a new QSPEC version number when substantive changes=20 > > are made to > > the QSPEC and this document is reissued. Note that a new=20 > > QSPEC version > > number is not needed when new QSPEC parameters are=20 > > specified in other > > specification documents, as prescribed in the IANA Considerations > > section. Later QSPEC versions MUST be backward compatible=20 > > with earlier > > QSPEC versions. That is, a version n+1 device must support QSPEC > > version n (or earlier). On the other hand, if a QSPEC version n (or > > earlier) device receives an NSLP message specifying QSPEC=20 > > version n+1, > > then the version n device responds with a 'Malformed=20 > > QSPEC' error code > > (0x03) response, as discussed in Section 5.2.3, allowing=20 > > the QNE that > > sent the NSLP message to retry with a lower QSPEC version." > I don't understand the distinction between adding new=20 > parameters outside=20 > the QSPEC base document and reissuing the QSPEC base document=20 > with the=20 > addition of some parameters as the only change. Do you need=20 > to increase=20 > the version number in either case? Won't the 'M' bits be enough to=20 > handle this? The QSPEC version number does *not* need to be increased with a new parameter specified outside the base document. I thought this sentence in the proposed replacement text took care of that: 'Note that a new QSPEC version number is not needed when new QSPEC parameters are specified in other specification documents, as prescribed in the IANA Considerations section'. Is that sentence confusing perhaps? If so, please suggest alternative text. Furthermore, I don't see that the base QSPEC document ever needs to be reissued 'with the addition of some parameters as the only change'. I think addition of new parameters can/should be done in separate documents (not reissue the QSPEC document). =20 However, if the QSPEC document is reissued to make 'substantive changes', then IMO a new version number is required, as stated in my proposed replacement text (and as I think you also proposed): 'IANA assigns a new QSPEC version number when substantive changes are made to the QSPEC and this document is reissued.' It seems that my proposed text is not clear, so please suggest clarifications. =20 > I may be missing something, but I think a change that increases the=20 > version number is likely to be more radical than simply adding a new=20 > parameter. Probably adding a new QSPEC object would be one=20 > case (since=20 > there is no equivalent of the 'M' bit or NSLP/GIST 'A/B' flags there). Yes I agree, see above comments. =20 > The version number field is fairly small (4 bits), so small changes=20 > which require only a new parameter seem to be a waste of version=20 > numbers, given that there are other compatibility/extension=20 > mechanisms in place. Yes I agree, see above comments. =20 > > Would we need to define another error code besides 0x03 for=20 > this case? > It would probably be a good idea. If you've got a bad version=20 > number you=20 > can probably retry with a lower one. In the general 'malformed' case=20 > there isn't necessarily anything you can do to automatically retry. OK, can you suggest an error code to be specified in the QoS NSLP document so that we can reference that code in the QSPEC document. =20 > > Note that the first paragraph in Section 5.4 is eliminated based on > > earlier discussion on the list, so that no reference to=20 > > QSPEC version > > number will be made in Section 5.4 after this is done. >=20 > OK >=20 > >> On a related topic, I don't know what other people who have been=20 > >> implementing the QSpec think, but the alignment of the=20 > fields in the=20 > >> common header seems a bit strange to me. It is currently: > >> Version: 4 bits > >> QSPEC Type: 8 bits > >> QSpec Proc: 8 bits > >> Reserved: 12 bits > >> So, the second and third fields aren't aligned on octet=20 > >> boundaries,=20 > >> although they are 8 bit fields. This is likely to make=20 > >> processing more=20 > >> difficult or inefficient (it always requires a=20 > >> mask/shift). A nicer=20 > >> format, if 'version' is kept as being 4 bits long, might be: > >> Version: 4 bits > >> Reserved: 4 bits > >> QSPEC Type: 8 bits > >> QSpec Proc: 8 bits > >> Reserved: 8 bits > >> Alternatively, version could be expanded to 8 bits. (The=20 > >> GIST version number is 8 bits). > >=20 > > Would this order be any better (?): > >=20 > > QSPEC Type: 8 bits > > QSpec Proc: 8 bits > > Version: 4 bits > > Reserved: 12 bits > >=20 > > Several of the QSPEC parameters may not be aligned on octet=20 > > boundaries > > either. Would it be more problematic for the common header to not > > align?=20 >=20 > Keeping the version as the first field is probably a good idea. If we=20 > move to a version 2, will it still have QSpec Type and QSpec=20 > Proc fields? >=20 > The other parameters looked ok to me. Where fields are not a=20 > multiple of=20 > 8 bits they only need masking to extract the relevant data.=20 > They don't=20 > require glueing together nibbles from consecutive bytes. So I suggest we make the Version Number 8 bits (like GIST and as you suggest), and keep the same order, as follows: Version: 8 bits QSPEC Type: 8 bits QSpec Proc: 8 bits Reserved: 8 bits Thanks, Regards, Jerry >=20 > regards, > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 12:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVvd-0007MD-9E; Wed, 14 Mar 2007 12:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVvb-0007M2-P5 for nsis@ietf.org; Wed, 14 Mar 2007 12:02:15 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRVvZ-00044i-BN for nsis@ietf.org; Wed, 14 Mar 2007 12:02:15 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2EG22mU008921; Wed, 14 Mar 2007 16:02:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Wed, 14 Mar 2007 16:02:01 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST Q-Mode Encapsulation Magic Number Thread-Index: AcdmQvRZZ1epjTtXQvSz70YMrz/wCgADoVTw References: <45F19C6A.5060108@christian-dickmann.de> <45F802E7.2090000@tm.uka.de> From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all,=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 14 March 2007 14:13 > To: Hancock, Robert > Cc: Christian Dickmann; nsis@ietf.org > Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number >=20 > Hi Robert, >=20 > Hancock, Robert wrote: > > i think it is really a conceptual thing: i see the magic number as=20 > > part of the encapsulation, just like the RAO and the UDP header and=20 > > port number, since that is the purpose it serves (to demultiplex=20 > > packets, not to carry information). and to put it in every message=20 > > would indeed be a waste of bytes, which you could never go back on=20 > > (since the magic number comes before any version information). > >=20 > > another way of putting it: we want the magic number to be something=20 > > that is checked to find out whether something is a GIST=20 > packet, rather=20 > > than part of parsing the GIST packet. making it part of the common=20 > > header would blur that distinction. >=20 > I would agree on that. I see it as part of the encapsulation, too. >=20 > > however, it may be that in practice, what you suggest would be=20 > > simpler. i would be interested to hear what other people=20 > think about=20 > > that. >=20 > Hmm. I don't like the idea of carrying around that magic=20 > number always... >=20 > > one specific point: we need to ensure that GIST packets without the=20 > > magic number go to a different UDP port, else you could not=20 > know how=20 > > to receive them properly. that may not be clear enough in=20 > the spec at=20 > > the moment. >=20 > That seems to be important and the devil lies in the details... > For example: Our implementation currently uses the well-known=20 > port as source port for Q-mode packets since it is listening=20 > there anyways. > However, I assume that responses will not carry a magic=20 > number and thus we must change the Q-mode source port to=20 > something different... i think this is one thing where we may need to update the current specification text. if the confirm goes back in D-mode, there is no mechanism in the protocol to indicate a port to send it to other=20 than the GIST port; so, in other words, we really should say that the magic number is required for packets to the GIST port. (note that all Q-mode packets go to the GIST port, but not vice versa.) the other point is that you could receive a packet at the GIST=20 port with the incorrect magic number. At a router, this would be an indication that this was not a GIST packet (and it would just get forwarded); but at a host, it is a malformed packet. do we need an error message for that? or should we silently discard it? robert h. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 12:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWMN-0007iG-Do; Wed, 14 Mar 2007 12:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWMM-0007iA-36 for nsis@ietf.org; Wed, 14 Mar 2007 12:29:54 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRWMH-0000c1-CL for nsis@ietf.org; Wed, 14 Mar 2007 12:29:54 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2EGTd4l016947; Wed, 14 Mar 2007 16:29:40 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 16:29:39 +0000 Message-ID: <45F822F3.9@roke.co.uk> Date: Wed, 14 Mar 2007 16:29:39 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] QSPEC Draft Review References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> <45F7FFD5.4010605@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82F8@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82F8@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 16:29:39.0829 (UTC) FILETIME=[F690DA50:01C76655] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, ASH, GERALD R, ATTLABS wrote: >> ASH, GERALD R, ATTLABS wrote: >>> Based on your suggestion, I propose the following >>> replacement text for >>> the second paragraph in Section 4.2: >>> >>> "The QSPEC consists of a QSPEC version number and QSPEC >>> objects. IANA >>> assigns a new QSPEC version number when substantive changes >>> are made to >>> the QSPEC and this document is reissued. Note that a new >>> QSPEC version >>> number is not needed when new QSPEC parameters are >>> specified in other >>> specification documents, as prescribed in the IANA Considerations >>> section. Later QSPEC versions MUST be backward compatible >>> with earlier >>> QSPEC versions. That is, a version n+1 device must support QSPEC >>> version n (or earlier). On the other hand, if a QSPEC version n (or >>> earlier) device receives an NSLP message specifying QSPEC >>> version n+1, >>> then the version n device responds with a 'Malformed >>> QSPEC' error code >>> (0x03) response, as discussed in Section 5.2.3, allowing >>> the QNE that >>> sent the NSLP message to retry with a lower QSPEC version." > >> I don't understand the distinction between adding new >> parameters outside >> the QSPEC base document and reissuing the QSPEC base document >> with the >> addition of some parameters as the only change. Do you need >> to increase >> the version number in either case? Won't the 'M' bits be enough to >> handle this? > > The QSPEC version number does *not* need to be increased with a new > parameter specified outside the base document. I thought this sentence > in the proposed replacement text took care of that: 'Note that a new > QSPEC version number is not needed when new QSPEC parameters are > specified in other specification documents, as prescribed in the IANA > Considerations section'. Is that sentence confusing perhaps? If so, > please suggest alternative text. It's the second half of that sentence that I had difficulty with. I read that as saying "The QSPEC version number does *not* need to be increased with a new parameter specified /outside/ the base document. The QSPEC version number *does* need to be increased with a new parameter specified /inside/ the base document." How about just cutting that sentence down to: "Note that a new QSPEC version number is not needed when new QSPEC parameters are specified." > Furthermore, I don't see that the base QSPEC document ever needs to be > reissued 'with the addition of some parameters as the only change'. I > think addition of new parameters can/should be done in separate > documents (not reissue the QSPEC document). OK. Your previous text suggested to me that there would be circumstances in which new parameters would be defined in other documents, and circumstances in which they'd need to be defined in a new QSPEC document, with the latter requiring the version number to be increased. > However, if the QSPEC document is reissued to make 'substantive > changes', then IMO a new version number is required, as stated in my > proposed replacement text (and as I think you also proposed): 'IANA > assigns a new QSPEC version number when substantive changes are made to > the QSPEC and this document is reissued.' Looks OK. Possibly "incompatible changes" or "changes which are not backwards compatible" would be a bit more precise than just "substantive changes" (where people may want to argue over what 'substantive' means). > It seems that my proposed text is not clear, so please suggest > clarifications. Hopefully the suggestions above help. >>> Would we need to define another error code besides 0x03 for >> this case? > >> It would probably be a good idea. If you've got a bad version >> number you >> can probably retry with a lower one. In the general 'malformed' case >> there isn't necessarily anything you can do to automatically retry. > > OK, can you suggest an error code to be specified in the QoS NSLP > document so that we can reference that code in the QSPEC document. At the QoS NSLP level I think we want to avoid too much knowledge of the internal structure of a QSpec. So, I guess we want to make this fairly generic, e.g. "Incompatible QSpec". BTW, "Malformed QSPEC" seems to be 0x0c rather than 0x03. >>>> On a related topic, I don't know what other people who have been >>>> implementing the QSpec think, but the alignment of the >> fields in the >>>> common header seems a bit strange to me. It is currently: >>>> Version: 4 bits >>>> QSPEC Type: 8 bits >>>> QSpec Proc: 8 bits >>>> Reserved: 12 bits [snip discussion] > So I suggest we make the Version Number 8 bits (like GIST and as you > suggest), and keep the same order, as follows: > > Version: 8 bits > QSPEC Type: 8 bits > QSpec Proc: 8 bits > Reserved: 8 bits I'm happy with that. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 12:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWgq-00053U-6J; Wed, 14 Mar 2007 12:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWgp-0004x5-8E for nsis@ietf.org; Wed, 14 Mar 2007 12:51:03 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRWgn-0005aH-To for nsis@ietf.org; Wed, 14 Mar 2007 12:51:03 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-146.messagelabs.com!1173891061!3826954!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26831 invoked from network); 14 Mar 2007 16:51:01 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-146.messagelabs.com with SMTP; 14 Mar 2007 16:51:01 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2EGp0Cu005240; Wed, 14 Mar 2007 12:51:00 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2EGopcK005178; Wed, 14 Mar 2007 12:50:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Draft Review Date: Wed, 14 Mar 2007 11:50:51 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82FA@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F822F3.9@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Draft Review Thread-Index: AcdmVgGm6t2t3pnDThWyddJGsYmcwAAAWeyw References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> <45F7FFD5.4010605@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82F8@KCCLUST06EVS1.ugd.att.com> <45F822F3.9@roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: "ASH, GERALD R, ATTLABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, I agree with all your suggestions, many thanks. One further comment/question below. Thanks, Regards, Jerry=20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Wednesday, March 14, 2007 12:30 PM > To: ASH, GERALD R, ATTLABS > Cc: nsis@ietf.org > Subject: Re: [NSIS] QSPEC Draft Review >=20 > Hi Jerry, >=20 > ASH, GERALD R, ATTLABS wrote: > >> ASH, GERALD R, ATTLABS wrote: > >>> Based on your suggestion, I propose the following=20 > >>> replacement text for > >>> the second paragraph in Section 4.2: > >>> > >>> "The QSPEC consists of a QSPEC version number and QSPEC=20 > >>> objects. IANA > >>> assigns a new QSPEC version number when substantive changes=20 > >>> are made to > >>> the QSPEC and this document is reissued. Note that a new=20 > >>> QSPEC version > >>> number is not needed when new QSPEC parameters are=20 > >>> specified in other > >>> specification documents, as prescribed in the IANA Considerations > >>> section. Later QSPEC versions MUST be backward compatible=20 > >>> with earlier > >>> QSPEC versions. That is, a version n+1 device must support QSPEC > >>> version n (or earlier). On the other hand, if a QSPEC=20 > version n (or > >>> earlier) device receives an NSLP message specifying QSPEC=20 > >>> version n+1, > >>> then the version n device responds with a 'Malformed=20 > >>> QSPEC' error code > >>> (0x03) response, as discussed in Section 5.2.3, allowing=20 > >>> the QNE that > >>> sent the NSLP message to retry with a lower QSPEC version." > >=20 > >> I don't understand the distinction between adding new=20 > >> parameters outside=20 > >> the QSPEC base document and reissuing the QSPEC base document=20 > >> with the=20 > >> addition of some parameters as the only change. Do you need=20 > >> to increase=20 > >> the version number in either case? Won't the 'M' bits be enough to=20 > >> handle this? > >=20 > > The QSPEC version number does *not* need to be increased with a new > > parameter specified outside the base document. I thought=20 > this sentence > > in the proposed replacement text took care of that: 'Note that a new > > QSPEC version number is not needed when new QSPEC parameters are > > specified in other specification documents, as prescribed=20 > in the IANA > > Considerations section'. Is that sentence confusing=20 > perhaps? If so, > > please suggest alternative text. >=20 > It's the second half of that sentence that I had difficulty=20 > with. I read=20 > that as saying "The QSPEC version number does *not* need to=20 > be increased=20 > with a new parameter specified /outside/ the base document. The QSPEC=20 > version number *does* need to be increased with a new parameter=20 > specified /inside/ the base document." >=20 > How about just cutting that sentence down to: > "Note that a new QSPEC version number is not needed when new QSPEC=20 > parameters are specified." >=20 > > Furthermore, I don't see that the base QSPEC document ever=20 > needs to be > > reissued 'with the addition of some parameters as the only=20 > change'. I > > think addition of new parameters can/should be done in separate > > documents (not reissue the QSPEC document). =20 >=20 > OK. Your previous text suggested to me that there would be=20 > circumstances=20 > in which new parameters would be defined in other documents, and=20 > circumstances in which they'd need to be defined in a new QSPEC=20 > document, with the latter requiring the version number to be=20 > increased. >=20 > > However, if the QSPEC document is reissued to make 'substantive > > changes', then IMO a new version number is required, as stated in my > > proposed replacement text (and as I think you also proposed): 'IANA > > assigns a new QSPEC version number when substantive changes=20 > are made to > > the QSPEC and this document is reissued.' >=20 > Looks OK. Possibly "incompatible changes" or "changes which are not=20 > backwards compatible" would be a bit more precise than just=20 > "substantive=20 > changes" (where people may want to argue over what=20 > 'substantive' means). >=20 > > It seems that my proposed text is not clear, so please suggest > > clarifications. >=20 > Hopefully the suggestions above help. >=20 > >>> Would we need to define another error code besides 0x03 for=20 > >> this case? > >=20 > >> It would probably be a good idea. If you've got a bad version=20 > >> number you=20 > >> can probably retry with a lower one. In the general=20 > 'malformed' case=20 > >> there isn't necessarily anything you can do to automatically retry. > >=20 > > OK, can you suggest an error code to be specified in the QoS NSLP > > document so that we can reference that code in the QSPEC document. >=20 > At the QoS NSLP level I think we want to avoid too much=20 > knowledge of the=20 > internal structure of a QSpec. So, I guess we want to make=20 > this fairly=20 > generic, e.g. "Incompatible QSpec". OK, so what will be the error code for "Incompatible QSPEC", perhaps: o Protocol Error: ... * 0x0f - Incompatible QSPEC in Section 5.1.3.6. (Information Object (INFO_SPEC) and Error Codes) of the QoS NSLP document (?) >=20 > BTW, "Malformed QSPEC" seems to be 0x0c rather than 0x03. >=20 > >>>> On a related topic, I don't know what other people who have been=20 > >>>> implementing the QSpec think, but the alignment of the=20 > >> fields in the=20 > >>>> common header seems a bit strange to me. It is currently: > >>>> Version: 4 bits > >>>> QSPEC Type: 8 bits > >>>> QSpec Proc: 8 bits > >>>> Reserved: 12 bits > [snip discussion] > > So I suggest we make the Version Number 8 bits (like GIST and as you > > suggest), and keep the same order, as follows: > >=20 > > Version: 8 bits > > QSPEC Type: 8 bits > > QSpec Proc: 8 bits > > Reserved: 8 bits >=20 > I'm happy with that. >=20 > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 13:01:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWqY-0001RG-MC; Wed, 14 Mar 2007 13:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWpu-0001DB-I5 for nsis@ietf.org; Wed, 14 Mar 2007 13:00:26 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRWp3-0007YM-1d for nsis@ietf.org; Wed, 14 Mar 2007 12:59:36 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2EGxM38024941; Wed, 14 Mar 2007 16:59:22 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 16:59:22 +0000 Message-ID: <45F829EA.1050609@roke.co.uk> Date: Wed, 14 Mar 2007 16:59:22 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" , Jukka MJ Manner Subject: Re: [NSIS] QSPEC Draft Review References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> <45F7FFD5.4010605@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82F8@KCCLUST06EVS1.ugd.att.com> <45F822F3.9@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82FA@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82FA@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 16:59:22.0392 (UTC) FILETIME=[1D0E6180:01C7665A] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, ASH, GERALD R, ATTLABS wrote: >> At the QoS NSLP level I think we want to avoid too much >> knowledge of the >> internal structure of a QSpec. So, I guess we want to make >> this fairly >> generic, e.g. "Incompatible QSpec". > > OK, so what will be the error code for "Incompatible QSPEC", perhaps: > > o Protocol Error: > ... > * 0x0f - Incompatible QSPEC > > in Section 5.1.3.6. (Information Object (INFO_SPEC) and Error Codes) of > the QoS NSLP document (?) I'll hand this one over at Jukka, as keeper-of-the-nroff. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 14 14:05:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXqJ-0005qL-2X; Wed, 14 Mar 2007 14:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXqH-0005qB-TH for nsis@ietf.org; Wed, 14 Mar 2007 14:04:53 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRXqG-0002tP-K2 for nsis@ietf.org; Wed, 14 Mar 2007 14:04:53 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 14 Mar 2007 20:04:47 +0200 id 0005FEE2.45F8393F.000065CB Date: Wed, 14 Mar 2007 20:04:45 +0200 (EET) From: Jukka MJ Manner To: Andrew McDonald Subject: Re: [NSIS] QSPEC Draft Review In-Reply-To: <45F829EA.1050609@roke.co.uk> Message-ID: References: <45F15DE3.3040201@gmx.net> <9473683187ADC049A855ED2DA739ABCA0DDC82D3@KCCLUST06EVS1.ugd.att.com> <45F6F0DA.2060007@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82EF@KCCLUST06EVS1.ugd.att.com> <45F7FFD5.4010605@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82F8@KCCLUST06EVS1.ugd.att.com> <45F822F3.9@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82FA@KCCLUST06EVS1.ugd.att.com> <45F829EA.1050609@roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "ASH, GERALD R, ATTLABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Works for me. Will add to the next version. Thanks. Jukka On Wed, 14 Mar 2007, Andrew McDonald wrote: > Hi Jerry, > > ASH, GERALD R, ATTLABS wrote: > > > At the QoS NSLP level I think we want to avoid too much knowledge of the > > > internal structure of a QSpec. So, I guess we want to make this fairly > > > generic, e.g. "Incompatible QSpec". > > > > OK, so what will be the error code for "Incompatible QSPEC", perhaps: > > > > o Protocol Error: > > ... > > * 0x0f - Incompatible QSPEC > > > > in Section 5.1.3.6. (Information Object (INFO_SPEC) and Error Codes) of > > the QoS NSLP document (?) > > I'll hand this one over at Jukka, as keeper-of-the-nroff. > > Andrew > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 00:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRhyZ-00006D-72; Thu, 15 Mar 2007 00:54:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRhyY-000068-Fb for nsis@ietf.org; Thu, 15 Mar 2007 00:54:06 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRhyW-0004dD-OY for nsis@ietf.org; Thu, 15 Mar 2007 00:54:06 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2F4rOZn020459 for ; Thu, 15 Mar 2007 06:54:02 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 06:53:36 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 23:53:33 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2007 23:53:33 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F4F093E@daebe103.NOE.Nokia.com> In-Reply-To: <002801c764ae$b4fdaf80$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on draft-ietf-nsis-rmd-09.txt Thread-Index: AcdfaCZ4NeSIa5bQTzuOsZBobQP/yACF+GoAAMuUwkAAaxp/IA== References: <002801c764ae$b4fdaf80$4c0d5982@dynamic.ewi.utwente.nl> From: To: X-OriginalArrivalTime: 15 Mar 2007 04:53:33.0384 (UTC) FILETIME=[E23CDC80:01C766BD] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070315065402-4E3DEBB0-28597B78/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [NSIS] WGLC on draft-ietf-nsis-rmd-09.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Georgios has updated the RMD document, please see http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt.=20 Since the QSPEC WGLC has finished and it seems that most of the open issues should be resolved, we would like to issue a WGLC on RMD. Since it is almost IETF week, we would need to issue a=20 3 WGLC (this is what the current recommendation is). However, it would be great to have people review the document before IETF meeting, so any issues can be discussed face-to-face. The WGLC will end April 4th. thanks, John and Martin > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: donderdag 8 maart 2007 13:51 > To: nsis@ietf.org > Subject: [NSIS] Changes in draft-ietf-nsis-rmd-09.txt >=20 > Dear all >=20 > Below you can find a list with the RMD-QOSM changes: >=20 > * Modified the draft according to the last QSPEC discussions > ** (M, N, Q, T flags, TMOD vs. Bandwidth, etc.. > ** the way of how the partial release is performed is changed >=20 > * an intra-domain RESPONSE message is used by an Egress to send the > RMD-QSPEC towards the Ingress during the initial reservation. >=20 > * emphasized that the triggers between QOS-NSLP and RMF/QOSM have to=20 > be used >=20 > * editorials >=20 > Best regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: maandag 5 maart 2007 21:50 > > To: i-d-announce@ietf.org > > Cc: nsis@ietf.org > > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-09.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the Next Steps in Signaling > Working Group > > of the IETF. > >=20 > > Title : RMD-QOSM - The Resource Management in=20 > > Diffserv QOS Model > > Author(s) : A. Bader, et al. > > Filename : draft-ietf-nsis-rmd-09.txt > > Pages : 92 > > Date : 2007-3-5 > > =09 > > This document describes an NSIS QoS Model for networks that use the=20 > > Resource Management in Diffserv (RMD) concept. RMD is a > technique > > for adding admission control and preemption function to=20 > > Differentiated Services (Diffserv) networks. The RMD QoS Model=20 > > allows devices external to the RMD network to signal reservation=20 > > requests to edge nodes in the RMD network. The RMD Ingress edge=20 > > nodes > > classify the incoming flows into traffic classes and signals=20 > > resource > > requests for the corresponding traffic class along the > data path to > > the Egress edge nodes for each flow. Egress nodes > reconstitute the > > original requests and continue forwarding them along the > data path > > towards the final destination. In addition, RMD defines=20 > > notification > > functions to indicate overload situations within the > domain to the > > edge nodes. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt > >=20 > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-ietf-nsis-rmd-09.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-nsis-rmd-09.txt". > > =09 > > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >> > draft-ietf-nsis-rmd-09.txt". >> >=20 >> > A list of Internet-Drafts directories can be found in=20 >> > http://www.ietf.org/shadow.html or=20 >> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >=20 >> > Internet-Drafts can also be obtained by e-mail. >> >=20 >> > Send a message to: >> > mailserv@ietf.org. >> > In the body type: >> > "FILE /internet-drafts/draft-ietf-nsis-rmd-09.txt". >> > =09 >> > 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. >> >=20 >> > Below is the data which will enable a MIME compliant mail reader=20 >> > implementation to automatically retrieve the ASCII version of the=20 >> > Internet-Draft. >> >=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 00:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRi00-0000Ut-3e; Thu, 15 Mar 2007 00:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRhzz-0000Un-E8 for nsis@ietf.org; Thu, 15 Mar 2007 00:55:35 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRhzx-0004mQ-Vb for nsis@ietf.org; Thu, 15 Mar 2007 00:55:35 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2F4tTZM023534; Thu, 15 Mar 2007 06:55:30 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 06:55:17 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 23:55:10 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS] I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Wed, 14 Mar 2007 23:55:10 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F4F0956@daebe103.NOE.Nokia.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract NSLP-RMF API -- RE: [NSIS] I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAAmGRJA= References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com> From: To: , X-OriginalArrivalTime: 15 Mar 2007 04:55:10.0429 (UTC) FILETIME=[1C14C0D0:01C766BE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070315065530-5BDC9BB0-502CB377/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, >I agree with you that the Abstract NSLP-RMF API should be=20 >significantly toned down so as to, as you say, *not* make it=20 >'too RMF driven' nor 'give too much information/control to the RMF'. =20 I agree. >The way it is now would make the result non-interoperable IMO,=20 >as illustrated in the example I provided below. Furthermore,=20 >I think it should be clarified how the QoS NSLP state machine=20 >might be affected by 'triggers' from the RMF? As in our long=20 >discussions earlier, the RMF must not change the normative QoS=20 >NSLP state machine based only on the informative API=20 >interactions and 'RMF/API triggers' alone, right? I agree with this as well. APIs are generally illustrative in the IETF. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 00:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRhzy-0000UR-Sh; Thu, 15 Mar 2007 00:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRhzw-0000UL-V5 for nsis@ietf.org; Thu, 15 Mar 2007 00:55:32 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRhzv-0004lK-Fd for nsis@ietf.org; Thu, 15 Mar 2007 00:55:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2F4sunN015134 for ; Thu, 15 Mar 2007 06:55:29 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 06:55:14 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 23:55:11 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Wed, 14 Mar 2007 23:55:11 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F4F0959@daebe103.NOE.Nokia.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82F1@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Thread-Index: AcdlfdM0esVN1WYPRA2WbD3Nr1LL/AAC9UbwACZmirAAAqvV8AAKwfDw References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com><235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC82E6@KCCLUST06EVS1.ugd.att.com> <001c01c76625$6cb590d0$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC82F1@KCCLUST06EVS1.ugd.att.com> From: To: X-OriginalArrivalTime: 15 Mar 2007 04:55:11.0586 (UTC) FILETIME=[1CC54C20:01C766BE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070315065529-32798BB0-144083AF/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, >> 1. I've still not seen a clear illustration of how QSPEC=20 >Type is used,=20 >> *at the bit level*. IMO one possible use is that the QNI can signal=20 >> QSPEC Type to indicate its intent (along with QSPEC parameters, M=20 >> flags, etc.), which should help a downstream QNE decide how=20 >to process=20 >> the QSPEC in the case where a downstream QNE supports multiple QOSMs. >>=20 >> But in the example I posed this doesn't seem to be the case: >>=20 >> "Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC Type and=20 >> RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type=20 >> information from the QNI, exactly how is the information used by the=20 >> QNE? >>=20 >> Georgios: By using the additional bit, the QNE will know that the=20 >> CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a=20 >local QSPEC.=20 >> In this way the QNE will know how to handle the CL-QSPEC and how to=20 >> handle the RMD-QSPEC." >>=20 >> Jerry: Since the QNI signals its intent is CL-QSPEC, and that is in=20 >> fact the QSPEC that the QNI signals, why would a QNE then chose the=20 >> RMD-QSPEC when it supports the CL-QSPEC and that is the QNI's intent? >>=20 >> I would still like to see a clear bit level example of how=20 >QSPEC Type=20 >> is used. > >Georgios: Note that in the situation that a combination of a=20 >bound End-to-end scenario is used that uses in this case the=20 >CL-QSpec and an edge-to-edge scenario that in this case uses=20 >the RMD-QSpec. >Furthermore, note that the Ingress node is a QNI and the=20 >Egress is a QNR > >for the edge-to-edge scenario. >In this scenario the QNE can be configured to use the CL-QSPEC=20 >only by the Ingress and Egress nodes and use the RMD-QOSM at=20 >the Ingress, Egress and all Interior nodes. >=20 >Please noet that the same situation occurs when the Inserv=20 >Controlled Load (end-to-end to end TSpec) model used by RSVP=20 >is combined with the RSVP aggegation QoS model (RFC3175). I think I still don't fully see how this works in practice. I don't know if any other QoSMs are supporting this functionality, nor have I seen other people explain that is something that the need. It could be that I don't exactly see what you are proposing. In generally, I would like to know what is needed, not what is possible. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 00:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRi02-0000VL-Ao; Thu, 15 Mar 2007 00:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRi01-0000VD-4q for nsis@ietf.org; Thu, 15 Mar 2007 00:55:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRhzz-0004mv-NT for nsis@ietf.org; Thu, 15 Mar 2007 00:55:37 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2F4spaQ021489; Thu, 15 Mar 2007 06:55:28 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 06:55:15 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 23:55:11 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Wed, 14 Mar 2007 23:55:11 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> In-Reply-To: <003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract NSLP-RMF API -- RE: [NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDAACMfqcA== References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com> <003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , X-OriginalArrivalTime: 15 Mar 2007 04:55:11.0335 (UTC) FILETIME=[1C9EFF70:01C766BE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070315065528-4E3DEBB0-66E2182E/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, >Regarding the following paragraph: >> As in our long discussions earlier, the RMF must not change the=20 >> normative QoS NSLP state machine based only on the informative API=20 >> interactions and 'RMF/API triggers' alone, right? > >All the triggers that go into the QOS-NSLP will somehow change=20 >the QoS NSLP state machine. The API describes what are the=20 >possible in/out triggers that should be taken into account by=20 >the QOS-NSLP state machine! I think we really need to be more precise than "...will somehow change=20 the QoS NSLP state machine." If we don't have it fully explained, I doubt it can very well be specified. We should be very explicit about what drives the state changes, to ensure that we have an interporable specification. John =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 06:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRmtq-0006Pq-Ez; Thu, 15 Mar 2007 06:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRmtp-0006Pf-Bw for nsis@ietf.org; Thu, 15 Mar 2007 06:09:33 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRmtn-00081G-UT for nsis@ietf.org; Thu, 15 Mar 2007 06:09:33 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2FA9F5X011750; Thu, 15 Mar 2007 11:09:29 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com><003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> Subject: RE: Abstract NSLP-RMF API -- RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Thu, 15 Mar 2007 11:09:10 +0100 Message-ID: <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDAACMfqcAAkRXqA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 15 Mar 2007 11:09:29 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John But all API triggers that are going in and out the QOS-NSLP will change the QOS-NSLP state machine. Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 15 maart 2007 5:55 > To: karagian@cs.utwente.nl; gash@att.com; andrew.mcdonald@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: Abstract NSLP-RMF API -- > RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt > > Georgios, > > > >Regarding the following paragraph: > >> As in our long discussions earlier, the RMF must not change the > >> normative QoS NSLP state machine based only on the informative API > >> interactions and 'RMF/API triggers' alone, right? > > > >All the triggers that go into the QOS-NSLP will somehow > change the QoS > >NSLP state machine. The API describes what are the possible in/out > >triggers that should be taken into account by the QOS-NSLP state > >machine! > > I think we really need to be more precise than "...will > somehow change the QoS NSLP state machine." If we don't have > it fully explained, I doubt it can very well be specified. > > We should be very explicit about what drives the state > changes, to ensure that we have an interporable specification. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 06:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnOl-00051X-9y; Thu, 15 Mar 2007 06:41:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnOk-000504-96 for nsis@ietf.org; Thu, 15 Mar 2007 06:41:30 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRnOg-00066Q-FU for nsis@ietf.org; Thu, 15 Mar 2007 06:41:30 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2FAfEr4022428; Thu, 15 Mar 2007 10:41:14 GMT Received: from ehlaptop ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 10:41:14 +0000 From: "Robert Hancock" To: "'Georgios Karagiannis'" , , , References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com><003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl><071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Thu, 15 Mar 2007 10:41:14 -0000 Message-ID: <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDAACMfqcAAkRXqAAACuWeA= X-OriginalArrivalTime: 15 Mar 2007 10:41:14.0245 (UTC) FILETIME=[7447A350:01C766EE] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, > Hi John > > But all API triggers that are going in and out the QOS-NSLP > will change the QOS-NSLP state machine. > IMHO there should be a system of fines for use of the phrase "change the QoS-NSLP state machine". do we really mean 'change the state machine' or 'cause transitions within the state machine'? - they're quite different things. any protocol state machine will have some transitions which are triggered by events defined as part of the protocol specification, and other transitions which can be caused by arbitrary local events. provided the qos NSLP identifies which come into the second class, and the RMF API allows only these to be triggered, there shouldn't be a problem. r. PS since many of us will soon be in prague, which is the home of some excellent beer, that could be an appropriate mechanism for the penalty system. > Best regards, > Georgios > > > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: donderdag 15 maart 2007 5:55 > > To: karagian@cs.utwente.nl; gash@att.com; andrew.mcdonald@roke.co.uk > > Cc: nsis@ietf.org > > Subject: RE: Abstract NSLP-RMF API -- > > RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt > > > > Georgios, > > > > > > >Regarding the following paragraph: > > >> As in our long discussions earlier, the RMF must not change the > > >> normative QoS NSLP state machine based only on the > informative API > > >> interactions and 'RMF/API triggers' alone, right? > > > > > >All the triggers that go into the QOS-NSLP will somehow > > change the QoS > > >NSLP state machine. The API describes what are the possible in/out > > >triggers that should be taken into account by the QOS-NSLP state > > >machine! > > > > I think we really need to be more precise than "...will > somehow change > > the QoS NSLP state machine." If we don't have it fully > explained, I > > doubt it can very well be specified. > > > > We should be very explicit about what drives the state changes, to > > ensure that we have an interporable specification. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 07:26:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRo5G-0007AO-V4; Thu, 15 Mar 2007 07:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRo5F-0007AA-50 for nsis@ietf.org; Thu, 15 Mar 2007 07:25:25 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRo5C-0000KH-Ln for nsis@ietf.org; Thu, 15 Mar 2007 07:25:25 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2FBP4Wx018649; Thu, 15 Mar 2007 12:25:09 +0100 (MET) From: "Georgios Karagiannis" To: "'Robert Hancock'" , , , References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com><003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl><071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> Subject: RE: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Thu, 15 Mar 2007 12:24:58 +0100 Message-ID: <000901c766f4$940e5890$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDAACMfqcAAkRXqAAACuWeAAAfMSMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 15 Mar 2007 12:25:15 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert Thank you for the clarification the below is exactly what I meant: 'cause transitions within the state machine' Best Regards, Georgios > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > Sent: donderdag 15 maart 2007 11:41 > To: 'Georgios Karagiannis'; john.loughney@nokia.com; > gash@att.com; andrew.mcdonald@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: Abstract NSLP-RMF API > --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt > > hi all, > > Hi John > > > > But all API triggers that are going in and out the QOS-NSLP will > > change the QOS-NSLP state machine. > > > > IMHO there should be a system of fines for use of the phrase > "change the QoS-NSLP state machine". do we really mean > 'change the state machine' or 'cause transitions within the > state machine'? - they're quite different things. > > any protocol state machine will have some transitions which > are triggered by events defined as part of the protocol > specification, and other transitions which can be caused by > arbitrary local events. provided the qos NSLP identifies > which come into the second class, and the RMF API allows only > these to be triggered, there shouldn't be a problem. > > r. > > PS since many of us will soon be in prague, which is the home > of some excellent beer, that could be an appropriate > mechanism for the penalty system. > > > Best regards, > > Georgios > > > > > > > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: donderdag 15 maart 2007 5:55 > > > To: karagian@cs.utwente.nl; gash@att.com; > andrew.mcdonald@roke.co.uk > > > Cc: nsis@ietf.org > > > Subject: RE: Abstract NSLP-RMF API -- > > > RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt > > > > > > Georgios, > > > > > > > > > >Regarding the following paragraph: > > > >> As in our long discussions earlier, the RMF must not > change the > > > >> normative QoS NSLP state machine based only on the > > informative API > > > >> interactions and 'RMF/API triggers' alone, right? > > > > > > > >All the triggers that go into the QOS-NSLP will somehow > > > change the QoS > > > >NSLP state machine. The API describes what are the > possible in/out > > > >triggers that should be taken into account by the QOS-NSLP state > > > >machine! > > > > > > I think we really need to be more precise than "...will > > somehow change > > > the QoS NSLP state machine." If we don't have it fully > > explained, I > > > doubt it can very well be specified. > > > > > > We should be very explicit about what drives the state > changes, to > > > ensure that we have an interporable specification. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 07:42:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoLE-00011J-UU; Thu, 15 Mar 2007 07:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoLD-000115-Ep for nsis@ietf.org; Thu, 15 Mar 2007 07:41:55 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRoLA-0003es-6l for nsis@ietf.org; Thu, 15 Mar 2007 07:41:55 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2FBfkhS004991 for ; Thu, 15 Mar 2007 11:41:46 GMT Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:41:46 +0000 Message-ID: <45F930FA.7030403@roke.co.uk> Date: Thu, 15 Mar 2007 11:41:46 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 11:41:46.0183 (UTC) FILETIME=[E9156570:01C766F6] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [NSIS] minor qspec parameter issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, A couple of further comments about details of the QSpec parameter encodings. RPH Priority has a value defined for RPH namespace of "255 - not used". I assume that, like the DSTE/Y.1541 issues noted previously this is left over from an earlier draft version, and no longer required. In the Excess Treatment parameter there is an 8-bit "Remark Value" field. Further description is provided in the paragraph beginning "When excess treatment is set to 'remark', ...". There is a sentence in the middle of that paragraph that appears to be a deviation from English as we know it: | For example, packets may be remarked to drop remarked to pertain | to a particular QoS class". It looks like it first appeared in draft -11 and has never made sense. :-) A further question: My interpretation is that the 'remark value' is a DSCP. Is that right? In which case, could the text be made clearer? Also, should this be a 6 bit field, rather than an 8 bit field? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 07:50:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoSo-0004ki-7Z; Thu, 15 Mar 2007 07:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoSn-0004kS-1l for nsis@ietf.org; Thu, 15 Mar 2007 07:49:45 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRoSl-0005D3-J5 for nsis@ietf.org; Thu, 15 Mar 2007 07:49:45 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2FBnZKw020461; Thu, 15 Mar 2007 12:49:41 +0100 (MET) From: "Georgios Karagiannis" To: , References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com><235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82E6@KCCLUST06EVS1.ugd.att.com><001c01c76625$6cb590d0$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC82F1@KCCLUST06EVS1.ugd.att.com> <071568CA7B789D4AA170CEF8C9613B4F4F0959@daebe103.NOE.Nokia.com> Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Thu, 15 Mar 2007 12:49:30 +0100 Message-ID: <000f01c766f8$01212360$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F4F0959@daebe103.NOE.Nokia.com> Thread-Index: AcdlfdM0esVN1WYPRA2WbD3Nr1LL/AAC9UbwACZmirAAAqvV8AAKwfDwACd2ymA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.238 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 15 Mar 2007 12:49:43 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John What I have explained is something that is needed to support the following bound and combined session signaling scenarios: * End-to-end session and edge-to-edge (local) session * End-to-end session and end-to-edge session In NSIS the end-to-end and edge-to-edge situation can occur When: * the end-to-end CL-QOSM is bound and combined with an edge-to-edge (local) Y.1541 * the end-to-end CL-QOSM is bound and combined with an edge-to-edge (local) RMD-QOSM In the RSVP context this occurs when the end-to-end RSVP session is combined with the edge-to-edge local RSVP aggregation session Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 15 maart 2007 5:55 > To: nsis@ietf.org > Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft > > Hi Georgios, > > > >> 1. I've still not seen a clear illustration of how QSPEC > >Type is used, > >> *at the bit level*. IMO one possible use is that the QNI > can signal > >> QSPEC Type to indicate its intent (along with QSPEC parameters, M > >> flags, etc.), which should help a downstream QNE decide how > >to process > >> the QSPEC in the case where a downstream QNE supports > multiple QOSMs. > >> > >> But in the example I posed this doesn't seem to be the case: > >> > >> "Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC > Type and > >> RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type > >> information from the QNI, exactly how is the information > used by the > >> QNE? > >> > >> Georgios: By using the additional bit, the QNE will know that the > >> CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a > >local QSPEC. > >> In this way the QNE will know how to handle the CL-QSPEC > and how to > >> handle the RMD-QSPEC." > >> > >> Jerry: Since the QNI signals its intent is CL-QSPEC, and > that is in > >> fact the QSPEC that the QNI signals, why would a QNE then > chose the > >> RMD-QSPEC when it supports the CL-QSPEC and that is the > QNI's intent? > >> > >> I would still like to see a clear bit level example of how > >QSPEC Type > >> is used. > > > >Georgios: Note that in the situation that a combination of a bound > >End-to-end scenario is used that uses in this case the > CL-QSpec and an > >edge-to-edge scenario that in this case uses the RMD-QSpec. > >Furthermore, note that the Ingress node is a QNI and the Egress is a > >QNR > > > >for the edge-to-edge scenario. > >In this scenario the QNE can be configured to use the > CL-QSPEC only by > >the Ingress and Egress nodes and use the RMD-QOSM at the Ingress, > >Egress and all Interior nodes. > > > >Please noet that the same situation occurs when the Inserv > Controlled > >Load (end-to-end to end TSpec) model used by RSVP is > combined with the > >RSVP aggegation QoS model (RFC3175). > > I think I still don't fully see how this works in practice. I > don't know if any other QoSMs are supporting this > functionality, nor have I seen other people explain that is > something that the need. > It could be that I don't exactly see what you are proposing. > In generally, I would like to know what is needed, not what > is possible. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 08:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpFb-0006Ac-Ng; Thu, 15 Mar 2007 08:40:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpFa-00068M-9c for nsis@ietf.org; Thu, 15 Mar 2007 08:40:10 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRpFX-0003QC-MI for nsis@ietf.org; Thu, 15 Mar 2007 08:40:10 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2FCdYol025868; Thu, 15 Mar 2007 14:39:55 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 14:39:55 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 07:39:52 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Thu, 15 Mar 2007 07:39:51 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F4F09D4@daebe103.NOE.Nokia.com> In-Reply-To: <000901c766f4$940e5890$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDAACMfqcAAkRXqAAACuWeAAAfMSMAACq2oA References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com><003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl><071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> <000901c766f4$940e5890$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , , X-OriginalArrivalTime: 15 Mar 2007 12:39:52.0701 (UTC) FILETIME=[0735D2D0:01C766FF] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I think Robert's clarification is a good one as well.=20 >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 15 March, 2007 04:25 >To: 'Robert Hancock'; Loughney John (Nokia-NRC/PaloAlto);=20 >gash@att.com; andrew.mcdonald@roke.co.uk >Cc: nsis@ietf.org >Subject: RE: Abstract NSLP-RMF API=20 >--RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt > >Hi Robert > >Thank you for the clarification the below is exactly what I meant: >'cause transitions within the state machine' > >Best Regards, >Georgios > > > >=20 > >> -----Original Message----- >> From: Robert Hancock [mailto:robert.hancock@roke.co.uk] >> Sent: donderdag 15 maart 2007 11:41 >> To: 'Georgios Karagiannis'; john.loughney@nokia.com; gash@att.com;=20 >> andrew.mcdonald@roke.co.uk >> Cc: nsis@ietf.org >> Subject: RE: Abstract NSLP-RMF API >> --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt >>=20 >> hi all, >> > Hi John >> >=20 >> > But all API triggers that are going in and out the QOS-NSLP will=20 >> > change the QOS-NSLP state machine. >> >=20 >>=20 >> IMHO there should be a system of fines for use of the phrase "change=20 >> the QoS-NSLP state machine". do we really mean 'change the state=20 >> machine' or 'cause transitions within the state machine'? - they're=20 >> quite different things. >>=20 >> any protocol state machine will have some transitions which are=20 >> triggered by events defined as part of the protocol=20 >specification, and=20 >> other transitions which can be caused by arbitrary local events.=20 >> provided the qos NSLP identifies which come into the second=20 >class, and=20 >> the RMF API allows only these to be triggered, there shouldn't be a=20 >> problem. >>=20 >> r. >>=20 >> PS since many of us will soon be in prague, which is the=20 >home of some=20 >> excellent beer, that could be an appropriate mechanism for=20 >the penalty=20 >> system. >>=20 >> > Best regards, >> > Georgios >> >=20 >> >=20 >> > =20 >> >=20 >> > > -----Original Message----- >> > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> > > Sent: donderdag 15 maart 2007 5:55 >> > > To: karagian@cs.utwente.nl; gash@att.com; >> andrew.mcdonald@roke.co.uk >> > > Cc: nsis@ietf.org >> > > Subject: RE: Abstract NSLP-RMF API --=20 >> > > RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt >> > >=20 >> > > Georgios, >> > >=20 >> > >=20 >> > > >Regarding the following paragraph: >> > > >> As in our long discussions earlier, the RMF must not >> change the >> > > >> normative QoS NSLP state machine based only on the >> > informative API >> > > >> interactions and 'RMF/API triggers' alone, right? >> > > > >> > > >All the triggers that go into the QOS-NSLP will somehow >> > > change the QoS >> > > >NSLP state machine. The API describes what are the >> possible in/out >> > > >triggers that should be taken into account by the=20 >QOS-NSLP state=20 >> > > >machine! >> > >=20 >> > > I think we really need to be more precise than "...will >> > somehow change >> > > the QoS NSLP state machine." If we don't have it fully >> > explained, I >> > > doubt it can very well be specified. >> > >=20 >> > > We should be very explicit about what drives the state >> changes, to >> > > ensure that we have an interporable specification. >> > >=20 >> > > John >> > >=20 >> > > _______________________________________________ >> > > nsis mailing list >> > > nsis@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/nsis >> > >=20 >> >=20 >> >=20 >> >=20 >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >=20 >>=20 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 08:58:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpWr-00013W-ER; Thu, 15 Mar 2007 08:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpWp-00013R-TS for nsis@ietf.org; Thu, 15 Mar 2007 08:57:59 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRpWo-0001X7-D1 for nsis@ietf.org; Thu, 15 Mar 2007 08:57:59 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C798713CF82; Thu, 15 Mar 2007 13:57:57 +0100 (CET) In-Reply-To: <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> References: DEFANGED[0]:<5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab. " " DEFANGED[0]:nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com><003d01c76636$0f16d450$4 " " c0d5982@dynamic.ewi.utwente.nl><071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <256033D4-2270-483F-A606-8CF55DD5F8D3@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Thu, 15 Mar 2007 13:57:55 +0100 To: Robert Hancock X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: john.loughney@nokia.com, gash@att.com, 'Georgios Karagiannis' , andrew.mcdonald@roke.co.uk, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, all, Am 15.03.2007 um 11:41 schrieb Robert Hancock: > hi all, >> Hi John >> >> But all API triggers that are going in and out the QOS-NSLP >> will change the QOS-NSLP state machine. >> > > IMHO there should be a system of fines for use of the phrase > "change the QoS-NSLP state machine". do we really mean 'change > the state machine' or 'cause transitions within the state > machine'? - they're quite different things. This is a long lasting confusion and all discussion simply talk about 'cause transitions within the state machine'. [...] > > PS since many of us will soon be in prague, which is the home > of some excellent beer, that could be an appropriate mechanism > for the penalty system. I highly endorse this! :-) Martin > >> Best regards, >> Georgios >> >> >> >> >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>> Sent: donderdag 15 maart 2007 5:55 >>> To: karagian@cs.utwente.nl; gash@att.com; andrew.mcdonald@roke.co.uk >>> Cc: nsis@ietf.org >>> Subject: RE: Abstract NSLP-RMF API -- >>> RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt >>> >>> Georgios, >>> >>> >>>> Regarding the following paragraph: >>>>> As in our long discussions earlier, the RMF must not change the >>>>> normative QoS NSLP state machine based only on the >> informative API >>>>> interactions and 'RMF/API triggers' alone, right? >>>> >>>> All the triggers that go into the QOS-NSLP will somehow >>> change the QoS >>>> NSLP state machine. The API describes what are the possible in/out >>>> triggers that should be taken into account by the QOS-NSLP state >>>> machine! >>> >>> I think we really need to be more precise than "...will >> somehow change >>> the QoS NSLP state machine." If we don't have it fully >> explained, I >>> doubt it can very well be specified. >>> >>> We should be very explicit about what drives the state changes, to >>> ensure that we have an interporable specification. >>> >>> John >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 09:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRptZ-00057o-FB; Thu, 15 Mar 2007 09:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRptY-00057g-0X for nsis@ietf.org; Thu, 15 Mar 2007 09:21:28 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRptW-0006X5-H5 for nsis@ietf.org; Thu, 15 Mar 2007 09:21:27 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2FDLFj0027350; Thu, 15 Mar 2007 14:21:25 +0100 (MET) From: "Georgios Karagiannis" To: References: <7E745AF7-3638-4D6C-A3C7-F521F7BF3371@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82D1@KCCLUST06EVS1.ugd.att.com><235F6080-AC27-467E-B182-8B682AFBF34E@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82E6@KCCLUST06EVS1.ugd.att.com><001c01c76625$6cb590d0$4c0d5982@dynamic.ewi.utwente.nl><9473683187ADC049A855ED2DA739ABCA0DDC82F1@KCCLUST06EVS1.ugd.att.com> <071568CA7B789D4AA170CEF8C9613B4F4F0959@daebe103.NOE.Nokia.com> <000f01c766f8$01212360$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F4F09DE@daebe103.NOE.Nokia.com> Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft Date: Thu, 15 Mar 2007 14:21:10 +0100 Message-ID: <001801c76704$d17abb00$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcdlfdM0esVN1WYPRA2WbD3Nr1LL/AAC9UbwACZmirAAAqvV8AAKwfDwACd2ymAAAiRckAAAG5MQAAErMqA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.238 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 15 Mar 2007 14:21:25 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John An example of how the explained operation can work is described in the RMD-QOSM. Please check for example Sections: * 4.6.1.1.1. Operation in Ingress node * 4.6.1.1.2 Operation in the Interior nodes * 4.6.1.1.3 Operation in the Egress node In http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt Best Regards, Georgios > > > > >-----Original Message----- > > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >Sent: 15 March, 2007 04:50 > > >To: Loughney John (Nokia-NRC/PaloAlto); nsis@ietf.org > > >Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in > > QSPEC draft > > > > > >Hi John > > > > > >What I have explained is something that is needed to support the > > >following bound and combined session signaling scenarios: > > > > > >* End-to-end session and edge-to-edge (local) session > > >* End-to-end session and end-to-edge session > > > > > >In NSIS the end-to-end and edge-to-edge situation can occur > > >When: > > >* the end-to-end CL-QOSM is bound and combined with > > > an edge-to-edge (local) Y.1541 > > >* the end-to-end CL-QOSM is bound and combined with > > > an edge-to-edge (local) RMD-QOSM > > > > > >In the RSVP context this occurs when the end-to-end RSVP > session is > > >combined with the edge-to-edge local RSVP aggregation session > > > > > > > > >Best regards, > > >Georgios > > > > > > > > > > > >> -----Original Message----- > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > >> Sent: donderdag 15 maart 2007 5:55 > > >> To: nsis@ietf.org > > >> Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in > > >QSPEC draft > > >> > > >> Hi Georgios, > > >> > > >> > > >> >> 1. I've still not seen a clear illustration of how QSPEC > > >> >Type is used, > > >> >> *at the bit level*. IMO one possible use is that the QNI > > >> can signal > > >> >> QSPEC Type to indicate its intent (along with QSPEC > > parameters, M > > >> >> flags, etc.), which should help a downstream QNE decide how > > >> >to process > > >> >> the QSPEC in the case where a downstream QNE supports > > >> multiple QOSMs. > > >> >> > > >> >> But in the example I posed this doesn't seem to be the case: > > >> >> > > >> >> "Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC > > >> Type and > > >> >> RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type > > >> >> information from the QNI, exactly how is the information > > >> used by the > > >> >> QNE? > > >> >> > > >> >> Georgios: By using the additional bit, the QNE will > > know that the > > >> >> CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a > > >> >local QSPEC. > > >> >> In this way the QNE will know how to handle the CL-QSPEC > > >> and how to > > >> >> handle the RMD-QSPEC." > > >> >> > > >> >> Jerry: Since the QNI signals its intent is CL-QSPEC, and > > >> that is in > > >> >> fact the QSPEC that the QNI signals, why would a QNE then > > >> chose the > > >> >> RMD-QSPEC when it supports the CL-QSPEC and that is the > > >> QNI's intent? > > >> >> > > >> >> I would still like to see a clear bit level example of how > > >> >QSPEC Type > > >> >> is used. > > >> > > > >> >Georgios: Note that in the situation that a combination > > of a bound > > >> >End-to-end scenario is used that uses in this case the > > >> CL-QSpec and an > > >> >edge-to-edge scenario that in this case uses the RMD-QSpec. > > >> >Furthermore, note that the Ingress node is a QNI and the > > >Egress is a > > >> >QNR > > >> > > > >> >for the edge-to-edge scenario. > > >> >In this scenario the QNE can be configured to use the > > >> CL-QSPEC only by > > >> >the Ingress and Egress nodes and use the RMD-QOSM at > the Ingress, > > >> >Egress and all Interior nodes. > > >> > > > >> >Please noet that the same situation occurs when the Inserv > > >> Controlled > > >> >Load (end-to-end to end TSpec) model used by RSVP is > > >> combined with the > > >> >RSVP aggegation QoS model (RFC3175). > > >> > > >> I think I still don't fully see how this works in > practice. I don't > > >> know if any other QoSMs are supporting this > functionality, nor have > > >> I seen other people explain that is something that the need. > > >> It could be that I don't exactly see what you are proposing. > > >> In generally, I would like to know what is needed, not what is > > >> possible. > > >> > > >> thanks, > > >> John > > >> > > >> _______________________________________________ > > >> nsis mailing list > > >> nsis@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/nsis > > >> > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 16:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwv8-0005IM-7Y; Thu, 15 Mar 2007 16:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwv6-0005Ef-Fk for nsis@ietf.org; Thu, 15 Mar 2007 16:51:32 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRwuk-00033V-W1 for nsis@ietf.org; Thu, 15 Mar 2007 16:51:32 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1173991870!21926005!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 31344 invoked from network); 15 Mar 2007 20:51:10 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 15 Mar 2007 20:51:10 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FKp9gU014700; Thu, 15 Mar 2007 16:51:10 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FKoRZU014112; Thu, 15 Mar 2007 16:51:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Date: Thu, 15 Mar 2007 15:50:34 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8305@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract NSLP-RMF API --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt Thread-Index: AcdmJ+ZsF39tiHJFQRiKTeDwoNkAWwACkwywAADYiDAACMfqcAAkRXqAAACuWeAAE7WZ8A== References: <5A4CD7D0-62CE-46DD-9B5A-328692A4D1B8@netlab.nec.de><44827776-731D-4AB5-B9C0-DDDD30DFC291@netlab.nec.de><9473683187ADC049A855ED2DA739ABCA0DDC82EC@KCCLUST06EVS1.ugd.att.com><45F7D575.2010908@roke.co.uk><9473683187ADC049A855ED2DA739ABCA0DDC82F3@KCCLUST06EVS1.ugd.att.com><003d01c76636$0f16d450$4c0d5982@dynamic.ewi.utwente.nl><071568CA7B789D4AA170CEF8C9613B4F4F0958@daebe103.NOE.Nokia.com> <000801c766ea$02cdca50$4c0d5982@dynamic.ewi.utwente.nl> <011901c766ee$74bd4880$0100c90a@comm.ad.roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Robert Hancock" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, All, > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 > Sent: Thursday, March 15, 2007 6:41 AM > To: 'Georgios Karagiannis'; john.loughney@nokia.com; ASH,=20 > GERALD R, ATTLABS; andrew.mcdonald@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: Abstract NSLP-RMF API=20 > --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt >=20 > hi all,=20 > > Hi John > >=20 > > But all API triggers that are going in and out the QOS-NSLP=20 > > will change the QOS-NSLP state machine. > >=20 >=20 > IMHO there should be a system of fines for use of the phrase > "change the QoS-NSLP state machine". do we really mean 'change > the state machine' or 'cause transitions within the state > machine'? - they're quite different things.=20 Right, FSMs =3D states, events/triggers, actions, and transitions... Perhaps we're guilty of fast and loose terminology but I suspect some might know what it is and may have even designed FSMs for real protocols (e.g., moi). However I'd be delighted to discuss this at length over several beers, and it will surely become clearer and clearer as more and more beers are consumed :-) =20 > any protocol state machine will have some transitions which=20 > are triggered by events defined as part of the protocol=20 > specification, and other transitions which can be caused > by arbitrary local events. provided the qos NSLP identifies > which come into the second class, and the RMF API allows only > these to be triggered, there shouldn't be a problem. It's the 'arbitrary local events' over the RMF API that I think the discussion is about, and which ones are actually allowed events/triggers within the NSLP FSM, and which events/triggers make sense coming from an RMF over an API. =20 For example, we have in Appendix A: "A.2 Triggers from RMF/QOSM towards QOS-NSLP ... * features_out: it represents among others the flags that can be used by the QOS-NSLP for new generated QoS-NSLP messages: ** BREAK ** REQUEST REDUCED REFRESHES ** RESERVE-INIT ** TEAR ** REPLACE ** ACK-REQ ** PROXY ** SCOPING ** BYPASSING: when the outgoing message should be bypassed then it includes the required bypassing level. Otherwise it is empty. It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress ** BINDING () when BINDING is required then it includes a BOUND_SESSION_ID list. Otherwise it is empty. It can only be requested by the following QNE types: QNI, QNR, QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress It seems that many of these triggers are defined within the 'QoS NSLP FSM' but some may not be (BYPASSING, BINDING, etc.). Also, do all these events/triggers make sense in the FSM coming from the RMF API (e.g., REQUEST REDUCED REFRESHES?). And for BYPASSING and BINDING it says "It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress", so is the RMF API included in being able to set?=20 In particular, are we going to see the QoS NSLP FSM with all its states, events/triggers, actions, and transitions so that this discussion about NSLP FSM will become more precise? Thanks, Jerry >=20 > r. >=20 > PS since many of us will soon be in prague, which is the home > of some excellent beer, that could be an appropriate mechanism > for the penalty system. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 15 17:34:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxa6-0005rr-9a; Thu, 15 Mar 2007 17:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxa4-0005ni-W1 for nsis@ietf.org; Thu, 15 Mar 2007 17:33:52 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRxa3-0003Et-Kr for nsis@ietf.org; Thu, 15 Mar 2007 17:33:52 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1173994430!14248881!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11878 invoked from network); 15 Mar 2007 21:33:50 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 15 Mar 2007 21:33:50 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FLXnff010155; Thu, 15 Mar 2007 17:33:49 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FLXmr7010144; Thu, 15 Mar 2007 17:33:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] minor qspec parameter issues Date: Thu, 15 Mar 2007 16:31:57 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8306@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45F930FA.7030403@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] minor qspec parameter issues Thread-Index: Acdm9zu3rCOIjWFAQK+PCXxbA2J7XAATZGZQ References: <45F930FA.7030403@roke.co.uk> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew,=20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Thursday, March 15, 2007 7:42 AM > To: nsis > Subject: [NSIS] minor qspec parameter issues >=20 > Hi, >=20 > A couple of further comments about details of the QSpec=20 > parameter encodings. >=20 > RPH Priority has a value defined for RPH namespace of "255 -=20 > not used".=20 > I assume that, like the DSTE/Y.1541 issues noted previously=20 > this is left=20 > over from an earlier draft version, and no longer required. Right, I had included all the extra "255 - not used" cases within your previous comment. =20 > In the Excess Treatment parameter there is an 8-bit "Remark Value"=20 > field. Further description is provided in the paragraph=20 > beginning "When=20 > excess treatment is set to 'remark', ...". There is a sentence in the=20 > middle of that paragraph that appears to be a deviation from=20 > English as=20 > we know it: > | For example, packets may be remarked to drop remarked to pertain > | to a particular QoS class". > It looks like it first appeared in draft -11 and has never=20 > made sense. :-) I recently noticed that sentence also, it should be: " For example, packets may be remarked to drop or remarked to pertain to a particular QoS class." =20 =20 > A further question: My interpretation is that the 'remark value' is a=20 > DSCP. Is that right? In which case, could the text be made clearer?=20 > Also, should this be a 6 bit field, rather than an 8 bit field? Agree with your comments. Perhaps this replacement text is clearer: " When excess treatment is set to 'remark', the excess treatment parameter MUST carry the remark value, and the remark values and procedures MUST be specified in the QOSM specification document. For example, packets may be remarked to drop or remarked to pertain to a particular QoS class (DSCP value). In the latter case, remarking relates to a DiffServ model where packets arrive marked as belonging to a certain QoS class/DSCP, and when they are identified as excess, they should then be remarked to a different QoS Class (DSCP value) indicated in the "Remark Value", as follows: Remark Value (6 bits): indicates either drop (set to 0) or DSCP value to remark packets to when identified as excess" Thanks, Regards, Jerry =20 >=20 > regards, >=20 > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 16 08:28:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBWd-0000At-MP; Fri, 16 Mar 2007 08:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBWc-0000Ao-IX for nsis@ietf.org; Fri, 16 Mar 2007 08:27:14 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSBWb-0006aQ-8K for nsis@ietf.org; Fri, 16 Mar 2007 08:27:14 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B5E2F13CF81 for ; Fri, 16 Mar 2007 13:27:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <36CAB19E-3CE9-4EB2-ADFE-140D080C2041@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Fri, 16 Mar 2007 13:27:11 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [NSIS] Send IETF-68 slides on Monday! X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Please send your slides for the NSIS WG session to nsis- chairs@tools.ietf.org **until Monday noon (CET)**. The slides will be uploaded to the web site below and thus give all attendees the chance to read through them beforehand. Slides will be available here: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 16 10:33:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDUU-0001Ji-Ta; Fri, 16 Mar 2007 10:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDUT-0001Ja-7p for nsis@ietf.org; Fri, 16 Mar 2007 10:33:09 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDUP-0006Ih-Kn for nsis@ietf.org; Fri, 16 Mar 2007 10:33:09 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3EE76122 for ; Fri, 16 Mar 2007 15:33:02 +0100 (NFT) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 28884-02 for ; Fri, 16 Mar 2007 15:32:59 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C087B148 for ; Fri, 16 Mar 2007 15:32:58 +0100 (NFT) Message-ID: <45FAAA97.8090509@uni-tuebingen.de> Date: Fri, 16 Mar 2007 15:32:55 +0100 From: Ali Fessi User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] Metering NSLP Drafts X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, we re-submitted the Metering NSLP drafts with some updates. The drafts are already in a good shape. But since the WG is currently too busy with other work items such as GIST, QSPEC, etc. we will postpone discussions on the MNSLP to after the Prague meeting. But just in case you need something to read in your leisure time, here are the links ;-) http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-04.txt http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-05.txt See you in Prague for those who will be attending the meeting! cheers, ali -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 19 08:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTH3M-0001vS-8s; Mon, 19 Mar 2007 08:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTH3K-0001us-BR for nsis@ietf.org; Mon, 19 Mar 2007 08:33:30 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTH3G-00033J-0v for nsis@ietf.org; Mon, 19 Mar 2007 08:33:30 -0400 Received: from [130.129.19.51] (dhcp-1333.ietf68.org [130.129.19.51]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6748313CF81 for ; Mon, 19 Mar 2007 13:33:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <95345186-BAE9-407D-8E57-BAEF131C898D@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Mon, 19 Mar 2007 13:33:20 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [NSIS] Changes in NATFW NSLP -14 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Here is the list of changes between draft-ietf-nsis-nslp-natfw-13.txt and draft-ietf-nsis-nslp-natfw-14.txt. The html diff is available here: http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-14- from-13.html - Removed leftover of NATFW_CREDENTIAL from Appendix D and IANA considerations (- Update boilerplate ) - NATFW_DTINFO object MUST be included when using the LE-MRM. Otherwise the NATs and firewalls have no information about the used transport protocol, i.e., not enough parameters for making policy decisions. - Adding text to Section 3.4 "Calculation of Signaling Session Lifetime" about choosing signaling session lifetimes with respect to IP address lease times. - Reworked Appendix A "Selecting Signaling Destination Addresses for EXT". - Replaced upstream by inbound and downstream by outbound. - Added new asynchronous notification 'NATFW signaling session lifetime expired' (0x04) - Changed NOTIFY semantics, i.e., now allowing to send inbound and outbound, depending on notification type - Clarified when the lifetime of a session starts in Section 3.2.3 "NATFW NSLP Signaling Sessions" - In Section 3.7.6.2 "Proxying for a Data Sender", added clarification on how to teardown the CREATE send by the proxy - Clarified throughout the text what type of sessions is always meant, i.e., if either application session or NATFW NSLP signaling session - Clarified on "mode" word usage. There is now only the proxy mode operation left. All other "modes" have basically been messages. - Reworked the NAT semantics part of EXT, as some cases where missing (this includes making the NATFW_DTINFO object mandatory if LE-MRM is used) -Section 2.8 "Multihomed Network with NAT", changed figure slightly to better illustrate what is meant. Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 19 11:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJZG-0003Y3-QF; Mon, 19 Mar 2007 11:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJZF-0003Xe-Hh for nsis@ietf.org; Mon, 19 Mar 2007 11:14:37 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJZ9-00025F-Q9 for nsis@ietf.org; Mon, 19 Mar 2007 11:14:37 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HTJZ4-0003wm-5G for ; Mon, 19 Mar 2007 16:14:29 +0100 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1HTJZ3-0002TT-Uh; Mon, 19 Mar 2007 16:14:25 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 263CF2FC012 for ; Mon, 19 Mar 2007 16:14:24 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HTJZ3-0004JT-6m for nsis@ietf.org; Mon, 19 Mar 2007 16:14:25 +0100 Message-ID: <45FEA8D0.5000207@tm.uka.de> Date: Mon, 19 Mar 2007 16:14:24 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [NSIS] Further QSPEC comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, too late for the WG last call, but I have a few comments nevertheless [but they are no showstoppers :-)]. The document seems to come closer to a usable version, great! My comments: * There seems to be a mix of different strategies: (A) allow to attach special parameters which may not be understood by every QNE (QoSM). We have the M-flags for this purpose etc. The QSPEC-type doesn't change, i.e., we could use one QSPEC for all QoSMs. Each RMF has to parse all QSPEC parameters and decide on each parameter type whether it understands them or not (which may not be a problem if M-flag is not set). (B) allow to attach special/new parameters (and even a different overall layout) by defining a different QPEC-Type. In this model each QoSM that needs QOSM-specific parameters simply defines a corresponding layout of different parameters it requires and get a new QSPEC type. The RMF then simply knows which QSPEC types it understands. Probably we could combine both approaches, but currently we have more (A), so a QSPEC type would probably not be necessary. If this is adopted, a good idea would be to have a flag on a parameter level that flags it as being only of local significance... * 4.3.2 defines PLR as packet loss _rate_ whereas 6.2.5 defines PLR as packet loss _ratio_. Please clarify If it's ratio and not rate then you probably have a cut&paste error in 6.2.5: "value. The PLRs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero." last sentence makes no sense to me... * 4.3.3 Traffic Handling Directives I'm probably don't get the full motivation for this. At least from a DiffServ point of view it's usually defined in the PDB what to do with excess packets. Probably in rare cases there is a choice between shaping or dropping, but usually the application cannot decide on this. So as feedback signal from a QNE maybe useful, but as desired by application? * 4.3.4 Traffic classifiers I don't know why an _application_ should specify a PHB it want resources for? Usually it's up to the QoSM to map a QSPEC request to a particular service class (and thus PHB). Especially, I don't know what the following sentence should mean: "Note that PHB class is normally set by a downstream QNE to tell the QNI how to mark traffic to ensure treatment committed by admission control." Usually you mark packets with a _DSCP_ (may be part of a PHB group). This mapping may vary from domain to domain and normally the first-hop router will set/police this initially. So letting a QNE signal a PHB class internally (i.e. inside its DiffServ domain) is probably useful, but usually the QNI need not know about the mapping to a PHB. So IMHO this needs clarification! * 4.4 I disagree with the statement: "The QNI would normally signal a reservation according to the requirements of its supported QOSM." This would be counter productive when considering interoperability. Consider a mobile node that moves or roams between different domains. The QoSM may change with each attachment to a new domain. I guess it's not a good idea if the node must be aware of the QoSM that is used in the currently attached domain. (Even if it would that that Diffserv is used, it may not know the specific mapping to PHBs/DSCPs anyway) . * p.16 "In the XG domain, the initiator QSPEC is translated into a local QSPEC using a similar procedure as described above. The local QSPEC becomes the current QSPEC used within the XG domain, that is, the it becomes the first QSPEC on the stack, and the initiator QSPEC is second. This saves the QNEs within the XG domain the trouble of re-translating the initiator QSPEC, and simplifies processing in the local domain. At the egress edge of the XG domain, the translated local QSPEC is popped, and the initiator QSPEC returns to the number one position." I guess that there are remnants from the former stacking mechanism (see stack..popped...) * 5.3 Note that QoS NSLP does not mandate the usage of a RESPONSE message. In fact, a RESPONSE message will only be generated if the QNI includes an RII (Request Identification Information) in the RESERVE message. That's not correct, because RESPONSE messages are always generated in case of an error or failure IIRC. The above statement thus only refers to positive responses. * 6.1 QSPEC-Type: I already commented on that one. Is related also to first comment. QSPEC Proc.: it is confusing that the text talks about a set of bits. I guess it would be better to call it "field", because then it is less likely that someone it with flags (e.g., the following could be misinterpreted as being bit positions, not values...): The Message Sequence field can attain the following values: 0: Sender-Initiated Reservations 1: Receiver-Initiated Reservations 2: Resource Queries * 6.2 Please check for clear definition of a unit for a given parameter! TMOD: what are the units for r,b,p and m? 6.2.5 "value. The PLRs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero." makes no sense if PLR is a ratio. 6.2.6 " value. The PERs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero." makes no sense for a ratio. * I already voted for removal of QOSM specific parameters in 6.2.12, 6.2.13 and 6.2.14. They are still in. Maybe related to the first point. Probably needs discussion... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 19 13:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLEe-0005ow-N8; Mon, 19 Mar 2007 13:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLEd-0005o4-5F for nsis@ietf.org; Mon, 19 Mar 2007 13:01:27 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLEa-0003Bq-RN for nsis@ietf.org; Mon, 19 Mar 2007 13:01:27 -0400 Received: from win2003.dickmann2003.home (p548A51BF.dip.t-dialin.net [84.138.81.191]) by www.difra-computer.de (Postfix) with ESMTP id 975F33E4030 for ; Mon, 19 Mar 2007 17:55:50 +0100 (CET) Received: from [127.0.0.1] ([192.168.40.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:44:07 +0100 Message-ID: <45FEC0FC.1030902@christian-dickmann.de> Date: Mon, 19 Mar 2007 17:57:32 +0100 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 16:44:07.0786 (UTC) FILETIME=[CFF954A0:01C76A45] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [NSIS] QSPEC presentation tomorrow X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I just had a brief look at the QSPEC slides for tomorrow. The presentation focuses on the changes, which is common practice, but I think in the case of QSPEC a short overview of what the current version specifies would be very helpful. This draft has seen so much changes and discussions, which I wasn't able to fully follow, so I would appreciate a short overview explaining the found consensus. Thank you and see you tomorrow. Regards, Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 20 13:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThjK-00081d-R6; Tue, 20 Mar 2007 13:02:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThjJ-00080G-CJ; Tue, 20 Mar 2007 13:02:37 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HThjB-00084k-S5; Tue, 20 Mar 2007 13:02:37 -0400 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HThj0-0000S5-BK; Tue, 20 Mar 2007 18:02:25 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A1CDC2FC012; Tue, 20 Mar 2007 18:02:16 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HThiz-0006FT-3O; Tue, 20 Mar 2007 18:02:18 +0100 Message-ID: <46001396.6020108@tm.uka.de> Date: Tue, 20 Mar 2007 18:02:14 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" , nsis-imp@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [NSIS] Next NSIS Interop in Karlsruhe in May 9th-11th X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, subject nearly says it all. We found a date for the next NSIS interop test in Karlsruhe, Germany. It's from Wednesday 9th til Friday 11th 2007 hosted at the University of Karlsruhe, Institute of Telematics, Germany. Please indicate if you intend to participate and with which protocol implementations (we agreed on GIST draft-13). So far Siemens Roke Manor, U of Coimbra, U of Göttingen have indicated their interest (but for local arrangements, however, it would also be good to know how many people from each group will participate). First info for travel arrangements: nearest Airports are Frankfurt (FRA) or Stuttgart (STR) both nearly 1 hour by train/car away from Karlsruhe. Frankfurt is the larger airport and has a good direct train connection (60min) to Karlsruhe main station. I will put a list of recommended hotels together and more travel information soon. For the impatient some tourism information about Karlsruhe: http://www1.karlsruhe.de/Tourismus/index.php?cmspage=0&setlang=en&show=0 Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 20 13:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThnv-0003Zq-9n; Tue, 20 Mar 2007 13:07:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThnu-0003ZT-0o for nsis@ietf.org; Tue, 20 Mar 2007 13:07:22 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThnl-0005NZ-EY for nsis@ietf.org; Tue, 20 Mar 2007 13:07:21 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 20 Mar 2007 19:02:06 +0200 id 0005FEFB.4600138E.00002A16 Date: Tue, 20 Mar 2007 19:02:06 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [NSIS] QoS NSLP: Reason for tearing X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org We have discussed a bit the NSLP tear operation, and would propose to add an INFO_SPEC also to the RESERVE message. This INFO_SPEC would be used to indicate the reason for a tearing RESERVE. Possible reasons include internal QNE error, Path Truncated, pre-emption, etc. Since the RESERVE is sent towards the QNE, a NOTIFY MAY be sent towards the QNI. Any comments on this? Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 20 13:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi5U-000703-PE; Tue, 20 Mar 2007 13:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi5T-0006zJ-Vh for nsis@ietf.org; Tue, 20 Mar 2007 13:25:32 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTi56-0008RH-Uo for nsis@ietf.org; Tue, 20 Mar 2007 13:25:31 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 20 Mar 2007 19:15:07 +0200 id 0005FEEC.4600169B.00007D43 Date: Tue, 20 Mar 2007 19:15:07 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [NSIS] QoS NSLP: pre-emption X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org The pre-emption functionality is after all quite a complex issue. We have had some discussion about it, and would propose the following: - If a QNE receives a RESERVE for a flow that causes other flow(s) to be pre-empted, for each of these flows, the QNE will send a tearing RESERVE downstream and add an INFO_SPEC with pre-emption error code and a BOUND_SESSION_ID that indicates the flow that caused the pre-emption - After sending the tearing RESERVE(s), the QNE will send the (reserving) RESERVE - Upon receiving this/these tearing RESERVEs, a QNE will set a timer that indicates that the indicated session MUST be torn down in the future, and sends the tearing RESERVE further downstream. - Upon receiving the (reserving) RESERVE, the QNE will remove the pending resources, and make the new reservation. - If the (reserving) RESERVE never arrives, e.g., the path of the pre-empted and high priority flows diverged at some point, the timer will cause the resources to be removed eventually. Effectively, this causes a sort of "switch resouces from these sessions to the session indicated in the BOUND_SESSION once the RESERVE arrives". If the RESERVE never arrives, upstream nodes have already removed the resources, so the downstream node must do likewise. This operation has the following benefits: 1. Downstream nodes are able to make the same decision when pre-empting low priority flows due to the high priority flow. 2. We make sure the resources are put aside for the indicated high priority flow in downstream nodes before the RESERVE actually arrives. Any comments? (I wonder if I explained the idea properly) Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 20 13:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi76-00004y-D4; Tue, 20 Mar 2007 13:27:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi4q-0006Zy-Di; Tue, 20 Mar 2007 13:24:52 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTi2y-00047i-Sk; Tue, 20 Mar 2007 13:23:19 -0400 Received: from [130.129.32.133] (dhcp-2085.ietf68.org [130.129.32.133]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CFABC13CF81; Tue, 20 Mar 2007 18:22:55 +0100 (CET) In-Reply-To: <46001396.6020108@tm.uka.de> References: <46001396.6020108@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <45D3E9B4-56B5-45E6-8429-1230B795508B@netlab.nec.de> Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Date: Tue, 20 Mar 2007 18:22:54 +0100 To: Roland Bless X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nsis-imp@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Nsis-imp] Next NSIS Interop in Karlsruhe in May 9th-11th X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Thanks to Roland for organising this event. Martin Am 20.03.2007 um 18:02 schrieb Roland Bless: > Hi, > > subject nearly says it all. > We found a date for the next NSIS interop test in Karlsruhe, Germany. > It's from Wednesday 9th til Friday 11th 2007 hosted at the University > of Karlsruhe, Institute of Telematics, Germany. > > Please indicate if you intend to participate and with which > protocol implementations (we agreed on GIST draft-13). > So far Siemens Roke Manor, U of Coimbra, U of G=F6ttingen have > indicated their interest (but for local arrangements, however, it > would also be good to know how many people from each group will > participate). > > First info for travel arrangements: > nearest Airports are Frankfurt (FRA) > or Stuttgart (STR) > both nearly 1 hour by train/car away from Karlsruhe. > Frankfurt is the larger airport and has a good direct > train connection (60min) to Karlsruhe main station. > > I will put a list of recommended hotels together and more > travel information soon. > > For the impatient some tourism information about Karlsruhe: > http://www1.karlsruhe.de/Tourismus/index.php?=20 > cmspage=3D0&setlang=3Den&show=3D0 > > Regards, > Roland > > _______________________________________________ > NSIS-imp mailing list > NSIS-imp@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/nsis-imp stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 21 05:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTx1J-0006Vl-7r; Wed, 21 Mar 2007 05:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTx1H-0006VI-GN for nsis@ietf.org; Wed, 21 Mar 2007 05:22:11 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTx0q-0001XW-61 for nsis@ietf.org; Wed, 21 Mar 2007 05:22:11 -0400 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HTx0n-0006bn-Pw for ; Wed, 21 Mar 2007 10:21:43 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 0E9972FC012 for ; Wed, 21 Mar 2007 10:21:40 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HTx0n-0007VX-02 for nsis@ietf.org; Wed, 21 Mar 2007 10:21:41 +0100 Message-ID: <4600F923.6040502@tm.uka.de> Date: Wed, 21 Mar 2007 10:21:39 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] QoS NSLP BREAK flag X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Max Laier (who is currently updating our QoS NSLP implementation) found some inconsistency in the QoS NSLP spec that is related to the BREAK flag: > Currently there are three "BREAK" flags defined in qos-nslp-13, one for > every message type (except NOTIFY). These flags, while carrying the same > information and semantics, have different flag values depending on the > message type. This is not optimal from a implementation PoV. I'd > suggest, that the BREAK flag be either moved into the generic flags, or > at least be given a common value for all message types that support it. > From the limited description of when to set the BREAK flag, I gather that > none of the actions really depend on the message type, thus inclusion in > the generic flags seems the logical solution. I support this view. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 21 06:28:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTy3F-0003Js-8a; Wed, 21 Mar 2007 06:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTy3E-0003Jk-Iw for nsis@ietf.org; Wed, 21 Mar 2007 06:28:16 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTy37-0004YD-3h for nsis@ietf.org; Wed, 21 Mar 2007 06:28:16 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1174472888!11257662!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16743 invoked from network); 21 Mar 2007 10:28:08 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 21 Mar 2007 10:28:08 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2LAS7Yo006728; Wed, 21 Mar 2007 06:28:07 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2LAS1KN006717; Wed, 21 Mar 2007 06:28:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Further QSPEC comments Date: Wed, 21 Mar 2007 05:28:01 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC832B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <45FEA8D0.5000207@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Further QSPEC comments Thread-Index: AcdqOZFp5g5aW7BLTjC6moHD9DSlAABZQJjg References: <45FEA8D0.5000207@tm.uka.de> From: "ASH, GERALD R, ATTLABS" To: "Roland Bless" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Roland, All,=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Monday, March 19, 2007 11:14 AM > To: nsis@ietf.org > Subject: [NSIS] Further QSPEC comments >=20 > Hi, >=20 > too late for the WG last call, but I have a few comments > nevertheless [but they are no showstoppers :-)]. > The document seems to come closer to a usable version, > great! > My comments: > * There seems to be a mix of different strategies: > (A) allow to attach special parameters which may not be > understood by every QNE (QoSM). We have the M-flags for this > purpose etc. The QSPEC-type doesn't change, i.e., > we could use one QSPEC for all QoSMs. Each RMF has to > parse all QSPEC parameters and decide on each parameter type whether > it understands them or not (which may not be a problem if > M-flag is not set). > (B) allow to attach special/new parameters (and even a different > overall layout) by defining a different QSPEC-Type. In this model > each QoSM that needs QOSM-specific parameters simply defines a > corresponding layout of different parameters it requires and > get a new QSPEC type. The RMF then simply knows which QSPEC > types it understands. >=20 > Probably we could combine both approaches, but currently > we have more (A), so a QSPEC type would probably > not be necessary. If this is adopted, a good idea would be > to have a flag on a parameter level that flags it as being > only of local significance... As discussed in the NSIS meeting yesterday, IMO we don't want to introduce a new strategy at this point such as (B) (which I don't clearly understand). Strategy (A) is the right approach IMO: QNI sets the M flag =3D 1 for QSPEC parameters that must be interpreted by downstream QNEs, and sets M flag =3D 0 for QSPEC parameters that should = be interpreted but can be ignored by the QNE if need be. =20 > * 4.3.2 defines PLR as packet loss _rate_ whereas 6.2.5 > defines PLR as packet loss _ratio_. Please clarify > If it's ratio and not rate then you probably have a > cut&paste error in 6.2.5: PLR is packet loss ratio, will correct. > "value. The PLRs are reported in units of 10^-11. A system with > resolution less than one microsecond MUST set unused=20 > digits to zero." > last sentence makes no sense to me... Caught earlier by Robert, will correct. > * 4.3.3 Traffic Handling Directives > I'm probably don't get the full motivation for this. > At least from a DiffServ point of view it's usually > defined in the PDB what to do with excess packets. > Probably in rare cases there is a choice between > shaping or dropping, but usually the application > cannot decide on this. So as feedback signal from > a QNE maybe useful, but as desired by application? So we should allow that 'setting the excess treatment parameter by a downstream QNE/RMF is not precluded'? I think Hannes had a similar comment. > * 4.3.4 Traffic classifiers > I don't know why an _application_ should specify > a PHB it want resources for? Usually it's up to > the QoSM to map a QSPEC request to a particular > service class (and thus PHB). Especially, I don't > know what the following sentence should mean: > "Note that PHB class is normally set by a downstream > QNE to tell the QNI how to mark traffic to ensure > treatment committed by admission control." > Usually you mark packets with a _DSCP_ (may be part > of a PHB group). This mapping may vary from domain > to domain and normally the first-hop router will > set/police this initially. So letting a QNE signal > a PHB class internally (i.e. inside its DiffServ domain) > is probably useful, but usually the QNI need not know > about the mapping to a PHB. > So IMHO this needs clarification! It was added that 'setting the PHB class by the QNI is not precluded', based on comments from Robert. Perhaps you would like to suggest further revised text? =20 > * 4.4 > I disagree with the statement: > "The QNI would normally signal a reservation > according to the requirements of its supported QOSM." > This would be counter productive when considering > interoperability. Consider a mobile node that moves > or roams between different domains. The QoSM may change > with each attachment to a new domain. > I guess it's not a good idea if the node must be aware > of the QoSM that is used in the currently attached domain. > (Even if it would that that Diffserv is used, it may > not know the specific mapping to PHBs/DSCPs anyway) OK, good point, will revise accordingly. > * p.16 > "In the XG domain, the initiator QSPEC is translated into a local > QSPEC using a similar procedure as described above. The=20 > local QSPEC > becomes the current QSPEC used within the XG domain, that is, the > it becomes the first QSPEC on the stack, and the initiator QSPEC is > second. This saves the QNEs within the XG domain the trouble of > re-translating the initiator QSPEC, and simplifies processing in > the local domain. At the egress edge of the XG domain, the > translated local QSPEC is popped, and the initiator QSPEC=20 > returns to > the number one position." > I guess that there are remnants from the former stacking mechanism > (see stack..popped...) OK, will revise. =20 > * 5.3 > Note that QoS NSLP does not mandate the usage of a=20 > RESPONSE message. > In fact, a RESPONSE message will only be generated if the QNI > includes an RII (Request Identification Information) in the RESERVE > message. >=20 > That's not correct, because RESPONSE messages are always generated > in case of an error or failure IIRC. The above statement thus only > refers to positive responses. OK, will clarify. =20 > * 6.1 > QSPEC-Type: I already commented on that one. Is related=20 > also to first comment. > QSPEC Proc.: it is confusing that the text talks about a=20 > set of bits. > I guess it would be better to call it "field", because then it is > less likely that someone it with flags (e.g., the following could be > misinterpreted as being bit positions, not values...): > The Message Sequence field can attain the following > values: >=20 > 0: Sender-Initiated Reservations > 1: Receiver-Initiated Reservations > 2: Resource Queries OK, will refer to 'field' rather than 'set of bits'. > * 6.2 > Please check for clear definition of a unit for a given parameter! > TMOD: what are the units for r,b,p and m? > 6.2.5 > "value. The PLRs are reported in units of 10^-11. A system with > resolution less than one microsecond MUST set unused=20 > digits to zero." > makes no sense if PLR is a ratio. Right, pointed out by Robert also. > 6.2.6 > " value. The PERs are reported in units of 10^-11. A=20 > system with > resolution less than one microsecond MUST set unused=20 > digits to zero." > makes no sense for a ratio. Right, pointed out by Robert also. > * I already voted for removal of QOSM specific parameters in > 6.2.12, 6.2.13 and 6.2.14. They are still in. Maybe related > to the first point. Probably needs discussion... As discussed earlier, I see no benefit in moving these necessary QSPEC parameters to some other draft(s) that don't even exist yet or have possible authors. Quite the opposite, it will just set NSIS back with more drafts and more delay. No one else has commented on this suggestion. Thanks, Jerry =20 > Regards, > Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 21 06:56:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyTd-0003pk-3e; Wed, 21 Mar 2007 06:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyTb-0003of-WB for nsis@ietf.org; Wed, 21 Mar 2007 06:55:32 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTyTa-0005w8-7r for nsis@ietf.org; Wed, 21 Mar 2007 06:55:31 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 21 Mar 2007 12:55:25 +0200 id 0005FECA.46010F1D.00007A31 Date: Wed, 21 Mar 2007 12:55:25 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP BREAK flag In-Reply-To: <4600F923.6040502@tm.uka.de> Message-ID: References: <4600F923.6040502@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Sounds good to me. Jukka On Wed, 21 Mar 2007, Roland Bless wrote: > Hi, > > Max Laier (who is currently updating our QoS NSLP implementation) > found some inconsistency in the QoS NSLP spec > that is related to the BREAK flag: > > > Currently there are three "BREAK" flags defined in qos-nslp-13, one for > > every message type (except NOTIFY). These flags, while carrying the same > > information and semantics, have different flag values depending on the > > message type. This is not optimal from a implementation PoV. I'd > > suggest, that the BREAK flag be either moved into the generic flags, or > > at least be given a common value for all message types that support it. > > From the limited description of when to set the BREAK flag, I gather that > > none of the actions really depend on the message type, thus inclusion in > > the generic flags seems the logical solution. > > I support this view. > > Regards, > Roland > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 21 07:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyre-0004xl-QO; Wed, 21 Mar 2007 07:20:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyrd-0004xf-PO for nsis@ietf.org; Wed, 21 Mar 2007 07:20:21 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTyra-0005c5-9u for nsis@ietf.org; Wed, 21 Mar 2007 07:20:21 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 21 Mar 2007 13:20:17 +0200 id 0005FE96.460114F1.00007BA7 Date: Wed, 21 Mar 2007 13:20:17 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] GIST: Comment to 7.1.4 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org As requested by Rob, I propose to add the following at the end of the first paragraph. It would help highlight a bit more what mobility can cause. Change from: "This will appear to GIST as a route flap; route flapping can also be caused by problems in the basic network connectivity or routing protocol operation." To: "This will appear to GIST as a route flap; route flapping can also be caused by problems in the basic network connectivity or routing protocol operation, for example, a mobile node may be switching back and forth between two links, or may appear to have disappeared even though it is still present." Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 22 13:30:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR6h-000246-RI; Thu, 22 Mar 2007 13:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR6g-00021h-Lm for nsis@ietf.org; Thu, 22 Mar 2007 13:29:46 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUR6W-0003si-LA for nsis@ietf.org; Thu, 22 Mar 2007 13:29:46 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2MHTRmo017249; Thu, 22 Mar 2007 17:29:27 GMT Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 17:29:27 +0000 Message-ID: <4602BCF7.7030805@roke.co.uk> Date: Thu, 22 Mar 2007 17:29:27 +0000 From: Andrew McDonald User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP: Reason for tearing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 17:29:27.0828 (UTC) FILETIME=[A47C0D40:01C76CA7] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka MJ Manner wrote: > We have discussed a bit the NSLP tear operation, and would propose to add > an INFO_SPEC also to the RESERVE message. This INFO_SPEC would be used to > indicate the reason for a tearing RESERVE. Possible reasons include > internal QNE error, Path Truncated, pre-emption, etc. Since the RESERVE is > sent towards the QNE, a NOTIFY MAY be sent towards the QNI. In principle this sounds OK. However, I'm not sure whether using the INFO_SPEC for this is the right way to do it. The reason codes for tearing aren't the same as the error codes in the INFO_SPEC. The optional error-specific information also probably does not make sense in this context. So, should we define something else to carrying this information? Or, should we 'profile' the INFO_SPEC for this use? (In the second case, we'd have to consider what to do if an inappropriate code is used, e.g. "mandatory object missing"). One factor in the decision might be what you do with this information when you receive it - if it is purely informational then the choice might be less critical. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 22 13:37:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURDO-0005so-7p; Thu, 22 Mar 2007 13:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURDM-0005sE-No for nsis@ietf.org; Thu, 22 Mar 2007 13:36:40 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HURDL-0005ZI-E0 for nsis@ietf.org; Thu, 22 Mar 2007 13:36:40 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 22 Mar 2007 19:36:34 +0200 id 00060376.4602BEA2.00001EC1 Date: Thu, 22 Mar 2007 19:36:32 +0200 (EET) From: Jukka MJ Manner To: Andrew McDonald Subject: Re: [NSIS] QoS NSLP: Reason for tearing In-Reply-To: <4602BCF7.7030805@roke.co.uk> Message-ID: References: <4602BCF7.7030805@roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, The purpose is of course for diagnostics. Whatever the error code is, it doesn't affect the implementation a bit. Yet, it allows a humanoid (or AI) to get the information that e.g. a QNE had an internal system error. This would allow to take measures. Furthermore, the error specific information can be used to provide the source of the error node, the QNE that killed a reservation. This is not possible currently. Jukka On Thu, 22 Mar 2007, Andrew McDonald wrote: > Jukka MJ Manner wrote: > > We have discussed a bit the NSLP tear operation, and would propose to add > > an INFO_SPEC also to the RESERVE message. This INFO_SPEC would be used to > > indicate the reason for a tearing RESERVE. Possible reasons include > > internal QNE error, Path Truncated, pre-emption, etc. Since the RESERVE is > > sent towards the QNE, a NOTIFY MAY be sent towards the QNI. > > In principle this sounds OK. However, I'm not sure whether using the > INFO_SPEC for this is the right way to do it. > > The reason codes for tearing aren't the same as the error codes in the > INFO_SPEC. The optional error-specific information also probably does > not make sense in this context. So, should we define something else to > carrying this information? Or, should we 'profile' the INFO_SPEC for > this use? (In the second case, we'd have to consider what to do if an > inappropriate code is used, e.g. "mandatory object missing"). One factor > in the decision might be what you do with this information when you > receive it - if it is purely informational then the choice might be less > critical. > > Andrew > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 22 17:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUUhC-0008Lp-5B; Thu, 22 Mar 2007 17:19:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUUhB-0008Li-1d for nsis@ietf.org; Thu, 22 Mar 2007 17:19:41 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUUh9-00056O-P3 for nsis@ietf.org; Thu, 22 Mar 2007 17:19:41 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 22 Mar 2007 23:19:37 +0200 id 0005FF10.4602F2E9.00004974 Date: Thu, 22 Mar 2007 23:19:34 +0200 (EET) From: Jukka MJ Manner To: "Hancock, Robert" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: NSIS Working Group Subject: [NSIS] GIST: NSLP data in QUERY X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I've been thinking about how GIST uses the Q-mode. If an NSLP asks for reliable or secure mode, GIST will send the query without NSLP payload. Yet, would it be possible to still allow an NSLP to include information carried in the query. There does not seem to be any protocol issues, rather it would be an API issue: allow an NSLP to indicate data that is carried in the query. This data is passed on the receiving node to the NSLP and GIST just forgets about it (same as if the sending node would have asked for unreliable and unsecure mode). The benefit is that the receiving NSLP can be given more information than simply the MRI and NSLP ID to make the decision on whether it wants to peer with the sending node or not. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 23 04:56:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfY6-0005aO-4J; Fri, 23 Mar 2007 04:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfY4-0005a1-6b for nsis@ietf.org; Fri, 23 Mar 2007 04:55:00 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUfXz-0000RT-2B for nsis@ietf.org; Fri, 23 Mar 2007 04:55:00 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HUfXv-0004eH-V9; Fri, 23 Mar 2007 09:54:54 +0100 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1HUfXv-0004b6-8R; Fri, 23 Mar 2007 09:54:51 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id CB5AF2FC012; Fri, 23 Mar 2007 09:54:48 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HUfXo-0002e2-Pj; Fri, 23 Mar 2007 09:54:50 +0100 Message-ID: <460395CF.1010405@tm.uka.de> Date: Fri, 23 Mar 2007 09:54:39 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] GIST: NSLP data in QUERY References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > I've been thinking about how GIST uses the Q-mode. If an NSLP asks for > reliable or secure mode, GIST will send the query without NSLP payload. > Yet, would it be possible to still allow an NSLP to include information > carried in the query. If the semantics for this data is different, yes. > There does not seem to be any protocol issues, rather it would be an API > issue: allow an NSLP to indicate data that is carried in the query. This > data is passed on the receiving node to the NSLP and GIST just forgets > about it (same as if the sending node would have asked for unreliable and > unsecure mode). Yep. Indeed the API must be changed in order to indicate what should be passed as "Early-Data" since the transport semantics are different (unreliable/unprotected) than for the rest of the data. > The benefit is that the receiving NSLP can be given more information than > simply the MRI and NSLP ID to make the decision on whether it wants to > peer with the sending node or not. This could be useful for several things (esp. connection acceptance policy). However, we have two restrictions here: - NSLP Data must fit into one (UDP) datagram - retransmissions of this portion of data must be performed by the NSLP itself. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 23 05:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfi6-0005ID-2C; Fri, 23 Mar 2007 05:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfi0-0005A4-7s for nsis@ietf.org; Fri, 23 Mar 2007 05:05:16 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUfd7-0001bg-GU for nsis@ietf.org; Fri, 23 Mar 2007 05:00:23 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 23 Mar 2007 11:00:12 +0200 id 000600C5.4603971C.00005BE6 Date: Fri, 23 Mar 2007 11:00:11 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] GIST: NSLP data in QUERY In-Reply-To: <460395CF.1010405@tm.uka.de> Message-ID: References: <460395CF.1010405@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, On Fri, 23 Mar 2007, Roland Bless wrote: > Hi Jukka, > > Jukka MJ Manner wrote: > > I've been thinking about how GIST uses the Q-mode. If an NSLP asks for > > reliable or secure mode, GIST will send the query without NSLP payload. > > Yet, would it be possible to still allow an NSLP to include information > > carried in the query. > > If the semantics for this data is different, yes. It can be different, or copies of certain NSLP objects. GIST doesn't need to care anyway, it's just a feature of NSLPs. > > > There does not seem to be any protocol issues, rather it would be an API > > issue: allow an NSLP to indicate data that is carried in the query. This > > data is passed on the receiving node to the NSLP and GIST just forgets > > about it (same as if the sending node would have asked for unreliable and > > unsecure mode). > > Yep. Indeed the API must be changed in order to > indicate what should be passed as "Early-Data" since the > transport semantics are different (unreliable/unprotected) > than for the rest of the data. That sounds good to me. > > > The benefit is that the receiving NSLP can be given more information than > > simply the MRI and NSLP ID to make the decision on whether it wants to > > peer with the sending node or not. > > This could be useful for several things (esp. connection acceptance policy). > However, we have two restrictions here: > - NSLP Data must fit into one (UDP) datagram > - retransmissions of this portion of data must be performed by the > NSLP itself. Yes, good points. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 23 19:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUsjv-0001c5-Fk; Fri, 23 Mar 2007 19:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUsjt-0001c0-Pg for nsis@ietf.org; Fri, 23 Mar 2007 19:00:05 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUsjs-0004en-GJ for nsis@ietf.org; Fri, 23 Mar 2007 19:00:05 -0400 Received: from win2003.dickmann2003.home (p548a5220.dip.t-dialin.net [84.138.82.32]) by www.difra-computer.de (Postfix) with ESMTP id D1BA03E4033 for ; Fri, 23 Mar 2007 23:53:52 +0100 (CET) Received: from [127.0.0.1] ([192.168.40.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 23:45:44 +0100 Message-ID: <46045BD5.1030201@christian-dickmann.de> Date: Fri, 23 Mar 2007 23:59:33 +0100 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] GIST: NSLP data in QUERY References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2007 22:45:44.0726 (UTC) FILETIME=[FE02A360:01C76D9C] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, > I've been thinking about how GIST uses the Q-mode. If an NSLP asks for > reliable or secure mode, GIST will send the query without NSLP payload. > Yet, would it be possible to still allow an NSLP to include information > carried in the query. > > There does not seem to be any protocol issues, rather it would be an API > issue: allow an NSLP to indicate data that is carried in the query. This > data is passed on the receiving node to the NSLP and GIST just forgets > about it (same as if the sending node would have asked for unreliable and > unsecure mode). > > The benefit is that the receiving NSLP can be given more information than > simply the MRI and NSLP ID to make the decision on whether it wants to > peer with the sending node or not. > From my point of view, GIST should not allow such a feature. While I understand your NSLP-centric reasons, I see one big problem: The NSLP does not even know when GIST sends a Query! So how would this work anyway? And whenever the NSLP creates a new session, why not send one unreliable message first and then the secure (or reliable) one? Thus, could you please clarify how you expect the API to change to enable the feature you desire and why this is better than sending one unreliable message from the NSLP first? Regards, Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 24 13:29:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVA2B-000818-RX; Sat, 24 Mar 2007 13:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVA2A-000813-Vh for nsis@ietf.org; Sat, 24 Mar 2007 13:28:06 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVA29-0001ms-Ln for nsis@ietf.org; Sat, 24 Mar 2007 13:28:06 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 24 Mar 2007 19:28:00 +0200 id 000603A6.46055FA0.00000FD9 Date: Sat, 24 Mar 2007 19:28:00 +0200 (EET) From: Jukka MJ Manner To: Christian Dickmann Subject: Re: [NSIS] GIST: NSLP data in QUERY In-Reply-To: <46045BD5.1030201@christian-dickmann.de> Message-ID: References: <46045BD5.1030201@christian-dickmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org First of all, you don't need to provide this extra information, if your NSLP doesn't ned it for peering decisions. Second, you can provide it every time you don't have a SII-Handle for the session. If GIST has already an MA for the session, the extra information is not used. If no MA is present, GIST will include the extra piece of information in the QUERY. This is much simpler that creating some wierd NSLP-level initial peering message handshake, after which you can actually send the meaningful data message. Jukka On Fri, 23 Mar 2007, Christian Dickmann wrote: > Hi Jukka, > > > I've been thinking about how GIST uses the Q-mode. If an NSLP asks for > > reliable or secure mode, GIST will send the query without NSLP payload. Yet, > > would it be possible to still allow an NSLP to include information carried > > in the query. > > > > There does not seem to be any protocol issues, rather it would be an API > > issue: allow an NSLP to indicate data that is carried in the query. This > > data is passed on the receiving node to the NSLP and GIST just forgets about > > it (same as if the sending node would have asked for unreliable and unsecure > > mode). > > > > The benefit is that the receiving NSLP can be given more information than > > simply the MRI and NSLP ID to make the decision on whether it wants to peer > > with the sending node or not. > > > > From my point of view, GIST should not allow such a feature. While I > understand your NSLP-centric reasons, I see one big problem: The NSLP does not > even know when GIST sends a Query! So how would this work anyway? > And whenever the NSLP creates a new session, why not send one unreliable > message first and then the secure (or reliable) one? > > Thus, could you please clarify how you expect the API to change to enable the > feature you desire and why this is better than sending one unreliable message > from the NSLP first? > > Regards, > Christian > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 24 14:36:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVB5z-0007Ab-CG; Sat, 24 Mar 2007 14:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVB5y-0007AW-GZ for nsis@ietf.org; Sat, 24 Mar 2007 14:36:06 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVB5x-0004iE-7F for nsis@ietf.org; Sat, 24 Mar 2007 14:36:06 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 24 Mar 2007 20:36:04 +0200 id 000603B0.46056F94.00005BB8 Date: Sat, 24 Mar 2007 20:36:04 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [NSIS] QSPEC: Pre-emption X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org We (at least Roland, Andrew, Georgios) have thought a bit more about the pre-emption, and how&where it should be described. Basically, it is a "problem" of QOSMs. The NSLP provides certain messages to inform of pre-emption, and who caused it (my recent proposal on the mailing list). But, how does a QNE choose a flow to be pre-empted in the first place is out of scope of the NSLP. Yet, it might be good to say a few words about how to choose the "right" flow to pre-empt to help QOSM designers. One simple idea we have talked about is that the QNE should try to choose a low(er) priority flow where the MRI is "close" (esp. the target IP) to the higher priority flow. This has the benefit that the pre-empted flow may share most of the path with the high priority flow. If the pre-empted flow has a random MRI, in case of heavy congestion, QNEs downstream may not see the same low(er) priority flow, and, thus, pre-empt other flows. Thus, in order to accommodate one high priority flow, the network may be killing N other flows. Do you think giving advise on pre-emption to QOSM designers is out of scope of the QSPEC Template? Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 08:44:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVoXL-00051F-Mn; Mon, 26 Mar 2007 08:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVoXK-000518-HA for nsis@ietf.org; Mon, 26 Mar 2007 08:42:58 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVoXH-000844-3r for nsis@ietf.org; Mon, 26 Mar 2007 08:42:58 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2QCgfvS024852; Mon, 26 Mar 2007 14:42:50 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" References: Date: Mon, 26 Mar 2007 14:42:36 +0200 Message-ID: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrFOdzouNN+hK9S+OPHabhrzFgLwEibaRg In-Reply-To: X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 26 Mar 2007 14:42:51 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: 'NSIS Working Group' Subject: [NSIS] Updated QoS NSLP: pre-emption text X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka and all Your description covers almost all the items of the solution that we have found during our discussions on the coridors of the Hilton hotel in Prague. However, below I include some more details: Step_1: ------ If a QNE receives a RESERVE for a session that causes other session(s) to be pre-empted, for each of these session, the QNE will send a tearing RESERVE downstream and add an INFO_SPEC with pre-emption error code and a BOUND_SESSION_ID that indicates the session that caused the pre-emption. Note that the value of this BOUND_SESSION_ID will have a new Binding Code value, which will have to be specified in the QOS-NSLP. Furthermore, the selection of which flows will have to be terminated should be specified by the QOSM. An example of this selection process can be based on the MRI associated with the high and lower priority sessions. In particular the QNE cans select low(er) priority session(s) where the MRI is "close" (esp. the target IP) to the one associated with the higher priority session. This has the benefit that the pre-empted session may share most of the path with the high priority session. Furthermore, the amount of the sessions that have to be preempted per each high priority session, has to be specified by the QOSM, since the QOSM has to compare the reserved resources by the lower priority sessions and the requested resources by the high priority session. Step_2: ----- For each of the sent tearing RESERVE, the QNE will send a NOTIFY message with an INFO-SPEC that indicates the pre-emption error code towards the QNI. Step_3 ------ After sending the tearing RESERVE(s), the QNE will send the (reserving) RESERVE Step_4: ----- Upon receiving the first tearing RESERVE, the QNE creates a so called (we called it like this) preemption state, which is identified by the SESSION_ID carried in the preemption related BOUND_SESSION_ID object. Furthermore, this preemption state will include the SESSION_ID of the session associated with the tearing RESERVE. If subsequently additional tearing RESERVE(s) are arriving, which include in their preemption related BOUND_SESSION_ID object(s) the value of the same SESSION_ID (of the high priority session) as the one included in the first arrived tearing RESERVE message, then the associated SESSION_IDs of these tearing RESERVE messages will be included in the already created preemption state. The QNE then will set a timer that indicates that the indicated session MUST be torn down in the future, and sends the tearing RESERVE(s) further downstream. Step_5: ----- Upon receiving the (reserving) RESERVE, the QNE will remove the pending resources, and make the new reservation. If the QNE will not receive all the tearing RESRVEs sent by the previous upstream QNE, it will have to calculate and select new lower priority sessions that have to be terminated. The selection process is similar to the process described in Step_1. Step_6: ----- If the (reserving) RESERVE never arrives, e.g., the path of the pre-empted and high priority flows diverged at some point, the timer will cause the resources to be removed eventually. Effectively, this causes a sort of "switch resouces from these sessions to the session indicated in the BOUND_SESSION once the RESERVE arrives". If the RESERVE never arrives, upstream nodes have already removed the resources, so the downstream node must do likewise. This operation has the following benefits: 1. Downstream nodes are able to make the same decision when pre-empting low priority flows due to the high priority flow. 2. We make sure the resources are put aside for the indicated high priority flow in downstream nodes before the RESERVE actually arrives. 3. Lower priority sessions are selected that atre assoicated with A destination IP address (included in MRI) that is "close" (esp. the target IP) to the one associated with the higher priority session. This has the benefit that the pre-empted session may share most of the path with the high priority session. Best regards, Georgios > > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: dinsdag 20 maart 2007 18:15 > To: NSIS Working Group > Subject: [NSIS] QoS NSLP: pre-emption > > > The pre-emption functionality is after all quite a complex > issue. We have had some discussion about it, and would > propose the following: > > - If a QNE receives a RESERVE for a flow that causes other > flow(s) to be pre-empted, for each of these flows, the QNE > will send a tearing RESERVE downstream and add an INFO_SPEC > with pre-emption error code and a BOUND_SESSION_ID that > indicates the flow that caused the pre-emption > > - After sending the tearing RESERVE(s), the QNE will send the > (reserving) > RESERVE > > - Upon receiving this/these tearing RESERVEs, a QNE will set > a timer that indicates that the indicated session MUST be > torn down in the future, and sends the tearing RESERVE > further downstream. > > - Upon receiving the (reserving) RESERVE, the QNE will remove > the pending resources, and make the new reservation. > > - If the (reserving) RESERVE never arrives, e.g., the path of > the pre-empted and high priority flows diverged at some > point, the timer will cause the resources to be removed eventually. > > Effectively, this causes a sort of "switch resouces from > these sessions to the session indicated in the BOUND_SESSION > once the RESERVE arrives". If the RESERVE never arrives, > upstream nodes have already removed the resources, so the > downstream node must do likewise. > > This operation has the following benefits: > > 1. Downstream nodes are able to make the same decision when > pre-empting > low priority flows due to the high priority flow. > > 2. We make sure the resources are put aside for the indicated high > priority flow in downstream nodes before the RESERVE > actually arrives. > > > Any comments? (I wonder if I explained the idea properly) > > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:12:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVozY-0002eV-KU; Mon, 26 Mar 2007 09:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVozX-0002Y8-MG for nsis@ietf.org; Mon, 26 Mar 2007 09:12:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVozV-0003U5-W7 for nsis@ietf.org; Mon, 26 Mar 2007 09:12:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2QDBRwe022515; Mon, 26 Mar 2007 14:11:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text Date: Mon, 26 Mar 2007 14:11:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Updated QoS NSLP: pre-emption text Thread-Index: AcdrFOdzouNN+hK9S+OPHabhrzFgLwEibaRgAAIreNA= References: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> From: "Hancock, Robert" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, This is a very detailed description, but I don't really understand the problem that is being solved. (That is, what are the special things that we are trying to require of the solution.) I interpret from some of the previous discussion that the potential issue is that if pre-emption is carried out along a path, but the pre-empted flows are selected independently at each node on the path, you could end up with large numbers of flows being preempted in an uncoordinated way (i.e. more than the minimal number necessary); whereas, if one node knows that flows X/Y/Z have already been preempted then it can choose to discard these first rather than randomly=20 choosing A/B/C. Is this a correct understanding? (If it is, I believe there are=20 simpler solutions, but I thought I'd check the understanding first.) r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 26 March 2007 13:43 > To: 'Jukka MJ Manner' > Cc: 'NSIS Working Group' > Subject: [NSIS] Updated QoS NSLP: pre-emption text >=20 > Hi Jukka and all >=20 > Your description covers almost all the items of the solution=20 > that we have found during our discussions on the coridors of=20 > the Hilton hotel in Prague. >=20 > However, below I include some more details: > =20 > Step_1:=20 > ------ > If a QNE receives a RESERVE for a session that causes other > session(s) to be pre-empted, for each of these session, the=20 > QNE will send a tearing RESERVE downstream and add an=20 > INFO_SPEC with pre-emption error code and a BOUND_SESSION_ID=20 > that indicates the session that caused the pre-emption. Note=20 > that the value of this BOUND_SESSION_ID will have a new=20 > Binding Code value, which will have to be specified in the QOS-NSLP. > Furthermore, the selection of which > flows will have to be terminated should be specified by the=20 > QOSM. An example of this selection process can be based on=20 > the MRI associated with the high and lower priority sessions. > In particular the QNE cans select low(er) priority session(s)=20 > where the MRI is "close" (esp. the target IP) to the one=20 > associated with the higher priority session.=20 > This has the benefit that the pre-empted session may share=20 > most of the path with the high priority session.=20 > Furthermore, the amount of the sessions that have to be=20 > preempted per each high priority session, has to be specified=20 > by the QOSM, since the QOSM has to compare the reserved=20 > resources by the lower priority sessions and the requested=20 > resources by the high priority session.=20 >=20 >=20 >=20 > Step_2: > ----- > For each of the sent tearing RESERVE, the QNE will send a=20 > NOTIFY message with an INFO-SPEC that indicates the=20 > pre-emption error code towards the QNI. >=20 >=20 > Step_3 > ------ > After sending the tearing RESERVE(s), the QNE will send the > (reserving) RESERVE >=20 > Step_4: > ----- > Upon receiving the first tearing RESERVE, the QNE creates a=20 > so called (we called it like this) preemption state, which is=20 > identified by the SESSION_ID carried in the preemption=20 > related BOUND_SESSION_ID object. Furthermore, this preemption=20 > state will include the SESSION_ID of the session associated=20 > with the tearing RESERVE. > If subsequently additional tearing RESERVE(s) are arriving,=20 > which include in their preemption related BOUND_SESSION_ID=20 > object(s) the value of the same SESSION_ID (of the high=20 > priority session) as the one included in the first arrived=20 > tearing RESERVE message, then the associated SESSION_IDs of=20 > these tearing RESERVE messages will be included in the=20 > already created preemption state. The QNE then will set a=20 > timer that indicates that the indicated session MUST be torn=20 > down in the future, and sends the tearing RESERVE(s) further=20 > downstream. >=20 > Step_5: > ----- > Upon receiving the (reserving) RESERVE, the QNE will remove=20 > the pending resources, and make the new reservation. If the=20 > QNE will not receive all the tearing RESRVEs sent by the=20 > previous upstream QNE, it will have to calculate and select=20 > new lower priority sessions that have to be terminated. The=20 > selection process is similar to the process described in Step_1. >=20 >=20 > =20 > Step_6: > ----- > If the (reserving) RESERVE never arrives, e.g., the path of=20 > the pre-empted and high priority flows diverged at some=20 > point, the timer will cause the resources to be removed eventually. >=20 > Effectively, this causes a sort of "switch resouces from=20 > these sessions to the session indicated in the BOUND_SESSION=20 > once the RESERVE arrives". If the RESERVE never arrives,=20 > upstream nodes have already removed the resources, so the=20 > downstream node must do likewise. >=20 > This operation has the following benefits: > =20 > 1. Downstream nodes are able to make the same decision when=20 > pre-empting low priority flows due to the high priority flow. > =20 > 2. We make sure the resources are put aside for the indicated=20 > high priority flow in downstream nodes before the RESERVE=20 > actually arrives. >=20 > 3. Lower priority sessions are selected that atre assoicated=20 > with A destination IP address (included in MRI) that is=20 > "close" (esp. the target IP) to the one associated with the=20 > higher priority session.=20 > This has the benefit that the pre-empted session may share=20 > most of the path with the high priority session.=20 >=20 > Best regards, > Georgios >=20 >=20 >=20 > >=20 > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: dinsdag 20 maart 2007 18:15 > > To: NSIS Working Group > > Subject: [NSIS] QoS NSLP: pre-emption > >=20 > >=20 > > The pre-emption functionality is after all quite a complex=20 > issue. We=20 > > have had some discussion about it, and would propose the following: > >=20 > > - If a QNE receives a RESERVE for a flow that causes other > > flow(s) to be pre-empted, for each of these flows, the QNE=20 > will send a=20 > > tearing RESERVE downstream and add an INFO_SPEC with=20 > pre-emption error=20 > > code and a BOUND_SESSION_ID that indicates the flow that caused the=20 > > pre-emption > >=20 > > - After sending the tearing RESERVE(s), the QNE will send the > > (reserving) > > RESERVE > >=20 > > - Upon receiving this/these tearing RESERVEs, a QNE will=20 > set a timer=20 > > that indicates that the indicated session MUST be torn down in the=20 > > future, and sends the tearing RESERVE further downstream. > >=20 > > - Upon receiving the (reserving) RESERVE, the QNE will remove the=20 > > pending resources, and make the new reservation. > >=20 > > - If the (reserving) RESERVE never arrives, e.g., the path of the=20 > > pre-empted and high priority flows diverged at some point,=20 > the timer=20 > > will cause the resources to be removed eventually. > >=20 > > Effectively, this causes a sort of "switch resouces from these=20 > > sessions to the session indicated in the BOUND_SESSION once the=20 > > RESERVE arrives". If the RESERVE never arrives, upstream nodes have=20 > > already removed the resources, so the downstream node must do=20 > > likewise. > >=20 > > This operation has the following benefits: > >=20 > > 1. Downstream nodes are able to make the same decision when=20 > > pre-empting > > low priority flows due to the high priority flow. > >=20 > > 2. We make sure the resources are put aside for the indicated high=20 > > priority flow in downstream nodes before the RESERVE actually=20 > > arrives. > >=20 > >=20 > > Any comments? (I wonder if I explained the idea properly) > >=20 > > Jukka > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:15:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVp29-0005TH-F7; Mon, 26 Mar 2007 09:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVp28-0005TB-EI for nsis@ietf.org; Mon, 26 Mar 2007 09:14:48 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVp27-0003k4-11 for nsis@ietf.org; Mon, 26 Mar 2007 09:14:48 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2QDEcuD023445; Mon, 26 Mar 2007 14:14:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC: Pre-emption Date: Mon, 26 Mar 2007 14:14:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC: Pre-emption Thread-Index: AcduQ47iYGjYH2fbQVmGURx4KJFROwBZLa6Q References: From: "Hancock, Robert" To: "Jukka MJ Manner" , "NSIS Working Group" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, a very simple answer:=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: 24 March 2007 18:36 > To: NSIS Working Group > Subject: [NSIS] QSPEC: Pre-emption >=20 >=20 > We (at least Roland, Andrew, Georgios) have thought a bit=20 > more about the pre-emption, and how&where it should be=20 > described. Basically, it is a "problem" of QOSMs. The NSLP=20 > provides certain messages to inform of pre-emption, and who=20 > caused it (my recent proposal on the mailing list). >=20 > But, how does a QNE choose a flow to be pre-empted in the=20 > first place is out of scope of the NSLP. Yet, it might be=20 > good to say a few words about how to choose the "right" flow=20 > to pre-empt to help QOSM designers. >=20 > One simple idea we have talked about is that the QNE should=20 > try to choose a low(er) priority flow where the MRI is=20 > "close" (esp. the target IP) to the higher priority flow.=20 > This has the benefit that the pre-empted flow may share most=20 > of the path with the high priority flow. If the pre-empted=20 > flow has a random MRI, in case of heavy congestion, QNEs=20 > downstream may not see the same low(er) priority flow, and,=20 > thus, pre-empt other flows.=20 > Thus, in order to accommodate one high priority flow, the=20 > network may be killing N other flows. >=20 > Do you think giving advise on pre-emption to QOSM designers=20 > is out of scope of the QSPEC Template? basically I would say no. At least any normative text will hit endless debates about regulation and lawfulness. At most one could point out the consequences of particular strategies, but it would be preferable IMHO to refer to other documents. (In other words, I assume that anything useful that can be written on this topic in the IETF has already been written.) robert h. >=20 > Cheers, > Jukka >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVp62-00065S-9c; Mon, 26 Mar 2007 09:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVp61-00065M-Jg for nsis@ietf.org; Mon, 26 Mar 2007 09:18:49 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVp5z-0004C2-Da for nsis@ietf.org; Mon, 26 Mar 2007 09:18:49 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2QDIbok027597; Mon, 26 Mar 2007 15:18:45 +0200 (MEST) From: "Georgios Karagiannis" To: "'Hancock, Robert'" , "'Jukka MJ Manner'" References: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text Date: Mon, 26 Mar 2007 15:18:31 +0200 Message-ID: <009501c76fa9$437b78f0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrFOdzouNN+hK9S+OPHabhrzFgLwEibaRgAAIreNAAAFg0AA== In-Reply-To: X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 26 Mar 2007 15:18:46 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: 'NSIS Working Group' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert I assumed that Jukka's problem description was clear enough The problem description that you gave below is correct! Best Regards, Georgios > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@ROKE.CO.UK] > Sent: maandag 26 maart 2007 15:11 > To: Georgios Karagiannis; Jukka MJ Manner > Cc: NSIS Working Group > Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text > > hi all, > > This is a very detailed description, but I don't really > understand the problem that is being solved. (That is, what > are the special things that we are trying to require of the solution.) > > I interpret from some of the previous discussion that the > potential issue is that if pre-emption is carried out along a > path, but the pre-empted flows are selected independently at > each node on the path, you could end up with large numbers of > flows being preempted in an uncoordinated way (i.e. more than > the minimal number necessary); whereas, if one node knows > that flows X/Y/Z have already been preempted then it can > choose to discard these first rather than randomly choosing A/B/C. > > Is this a correct understanding? (If it is, I believe there > are simpler solutions, but I thought I'd check the > understanding first.) > > r. > > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 26 March 2007 13:43 > > To: 'Jukka MJ Manner' > > Cc: 'NSIS Working Group' > > Subject: [NSIS] Updated QoS NSLP: pre-emption text > > > > Hi Jukka and all > > > > Your description covers almost all the items of the > solution that we > > have found during our discussions on the coridors of the > Hilton hotel > > in Prague. > > > > However, below I include some more details: > > > > Step_1: > > ------ > > If a QNE receives a RESERVE for a session that causes other > > session(s) to be pre-empted, for each of these session, the > QNE will > > send a tearing RESERVE downstream and add an INFO_SPEC with > > pre-emption error code and a BOUND_SESSION_ID that indicates the > > session that caused the pre-emption. Note that the value of this > > BOUND_SESSION_ID will have a new Binding Code value, which > will have > > to be specified in the QOS-NSLP. > > Furthermore, the selection of which > > flows will have to be terminated should be specified by the > QOSM. An > > example of this selection process can be based on the MRI > associated > > with the high and lower priority sessions. > > In particular the QNE cans select low(er) priority session(s) where > > the MRI is "close" (esp. the target IP) to the one > associated with the > > higher priority session. > > This has the benefit that the pre-empted session may share > most of the > > path with the high priority session. > > Furthermore, the amount of the sessions that have to be > preempted per > > each high priority session, has to be specified by the > QOSM, since the > > QOSM has to compare the reserved resources by the lower priority > > sessions and the requested resources by the high priority session. > > > > > > > > Step_2: > > ----- > > For each of the sent tearing RESERVE, the QNE will send a NOTIFY > > message with an INFO-SPEC that indicates the pre-emption error code > > towards the QNI. > > > > > > Step_3 > > ------ > > After sending the tearing RESERVE(s), the QNE will send the > > (reserving) RESERVE > > > > Step_4: > > ----- > > Upon receiving the first tearing RESERVE, the QNE creates a > so called > > (we called it like this) preemption state, which is > identified by the > > SESSION_ID carried in the preemption related > BOUND_SESSION_ID object. > > Furthermore, this preemption state will include the > SESSION_ID of the > > session associated with the tearing RESERVE. > > If subsequently additional tearing RESERVE(s) are arriving, which > > include in their preemption related BOUND_SESSION_ID > > object(s) the value of the same SESSION_ID (of the high priority > > session) as the one included in the first arrived tearing RESERVE > > message, then the associated SESSION_IDs of these tearing RESERVE > > messages will be included in the already created preemption > state. The > > QNE then will set a timer that indicates that the indicated session > > MUST be torn down in the future, and sends the tearing RESERVE(s) > > further downstream. > > > > Step_5: > > ----- > > Upon receiving the (reserving) RESERVE, the QNE will remove the > > pending resources, and make the new reservation. If the QNE > will not > > receive all the tearing RESRVEs sent by the previous > upstream QNE, it > > will have to calculate and select new lower priority sessions that > > have to be terminated. The selection process is similar to > the process > > described in Step_1. > > > > > > > > Step_6: > > ----- > > If the (reserving) RESERVE never arrives, e.g., the path of the > > pre-empted and high priority flows diverged at some point, > the timer > > will cause the resources to be removed eventually. > > > > Effectively, this causes a sort of "switch resouces from these > > sessions to the session indicated in the BOUND_SESSION once the > > RESERVE arrives". If the RESERVE never arrives, upstream nodes have > > already removed the resources, so the downstream node must do > > likewise. > > > > This operation has the following benefits: > > > > 1. Downstream nodes are able to make the same decision when > > pre-empting low priority flows due to the high priority flow. > > > > 2. We make sure the resources are put aside for the indicated high > > priority flow in downstream nodes before the RESERVE > actually arrives. > > > > 3. Lower priority sessions are selected that atre assoicated with A > > destination IP address (included in MRI) that is "close" (esp. the > > target IP) to the one associated with the higher priority session. > > This has the benefit that the pre-empted session may share > most of the > > path with the high priority session. > > > > Best regards, > > Georgios > > > > > > > > > > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: dinsdag 20 maart 2007 18:15 > > > To: NSIS Working Group > > > Subject: [NSIS] QoS NSLP: pre-emption > > > > > > > > > The pre-emption functionality is after all quite a complex > > issue. We > > > have had some discussion about it, and would propose the > following: > > > > > > - If a QNE receives a RESERVE for a flow that causes other > > > flow(s) to be pre-empted, for each of these flows, the QNE > > will send a > > > tearing RESERVE downstream and add an INFO_SPEC with > > pre-emption error > > > code and a BOUND_SESSION_ID that indicates the flow that > caused the > > > pre-emption > > > > > > - After sending the tearing RESERVE(s), the QNE will send the > > > (reserving) > > > RESERVE > > > > > > - Upon receiving this/these tearing RESERVEs, a QNE will > > set a timer > > > that indicates that the indicated session MUST be torn > down in the > > > future, and sends the tearing RESERVE further downstream. > > > > > > - Upon receiving the (reserving) RESERVE, the QNE will remove the > > > pending resources, and make the new reservation. > > > > > > - If the (reserving) RESERVE never arrives, e.g., the path of the > > > pre-empted and high priority flows diverged at some point, > > the timer > > > will cause the resources to be removed eventually. > > > > > > Effectively, this causes a sort of "switch resouces from these > > > sessions to the session indicated in the BOUND_SESSION once the > > > RESERVE arrives". If the RESERVE never arrives, upstream > nodes have > > > already removed the resources, so the downstream node must do > > > likewise. > > > > > > This operation has the following benefits: > > > > > > 1. Downstream nodes are able to make the same decision when > > > pre-empting > > > low priority flows due to the high priority flow. > > > > > > 2. We make sure the resources are put aside for the > indicated high > > > priority flow in downstream nodes before the RESERVE actually > > > arrives. > > > > > > > > > Any comments? (I wonder if I explained the idea properly) > > > > > > Jukka > > > > > > _______________________________________________ > > > 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 nsis-bounces@ietf.org Mon Mar 26 09:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVp9r-0006qU-8X; Mon, 26 Mar 2007 09:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVp9q-0006qP-B2 for nsis@ietf.org; Mon, 26 Mar 2007 09:22:46 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVp9k-0004hI-Sz for nsis@ietf.org; Mon, 26 Mar 2007 09:22:46 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1174915358!20608997!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20744 invoked from network); 26 Mar 2007 13:22:38 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 26 Mar 2007 13:22:38 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2QDMbCX027026; Mon, 26 Mar 2007 09:22:37 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2QDMWl0026914; Mon, 26 Mar 2007 09:22:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC: Pre-emption Date: Mon, 26 Mar 2007 08:22:31 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC834D@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC: Pre-emption Thread-Index: AcduRAvy6qvoQx/aQ3uc5QuFw8Cs0ABZPZsw References: From: "ASH, GERALD R, ATTLABS" To: "Jukka MJ Manner" , "NSIS Working Group" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "ASH, GERALD R, ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka, All,=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Saturday, March 24, 2007 2:36 PM > To: NSIS Working Group > Subject: [NSIS] QSPEC: Pre-emption >=20 >=20 > We (at least Roland, Andrew, Georgios) have thought a bit=20 > more about the=20 > pre-emption, and how&where it should be described. Basically, it is a=20 > "problem" of QOSMs. The NSLP provides certain messages to inform of=20 > pre-emption, and who caused it (my recent proposal on the=20 > mailing list). >=20 > But, how does a QNE choose a flow to be pre-empted in the=20 > first place is=20 > out of scope of the NSLP. Yet, it might be good to say a few=20 > words about=20 > how to choose the "right" flow to pre-empt to help QOSM designers. >=20 > One simple idea we have talked about is that the QNE should=20 > try to choose=20 > a low(er) priority flow where the MRI is "close" (esp. the=20 > target IP) to=20 > the higher priority flow. This has the benefit that the=20 > pre-empted flow=20 > may share most of the path with the high priority flow. If=20 > the pre-empted=20 > flow has a random MRI, in case of heavy congestion, QNEs=20 > downstream may=20 > not see the same low(er) priority flow, and, thus, pre-empt=20 > other flows.=20 > Thus, in order to accommodate one high priority flow, the=20 > network may be killing N other flows. >=20 > Do you think giving advise on pre-emption to QOSM designers is out of=20 > scope of the QSPEC Template? I agree with Robert, this is definitely out of scope for QSPEC. Enough is said already in the document and the RFC references provide the sufficient details. We are asking for endless debate if we try to plow new ground here. Thanks, Jerry =20 >=20 > Cheers, > Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:30:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpGc-000057-5k; Mon, 26 Mar 2007 09:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpGa-000052-Fb for nsis@ietf.org; Mon, 26 Mar 2007 09:29:44 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpGX-0005wK-JS for nsis@ietf.org; Mon, 26 Mar 2007 09:29:44 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2QDTNfF009930; Mon, 26 Mar 2007 16:29:33 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 16:29:07 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 08:29:05 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC: Pre-emption Date: Mon, 26 Mar 2007 08:29:05 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F595F9C@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC: Pre-emption Thread-Index: AcduQ47iYGjYH2fbQVmGURx4KJFROwBZLa6QAACWjHA= References: From: To: , , X-OriginalArrivalTime: 26 Mar 2007 13:29:05.0090 (UTC) FILETIME=[B983E220:01C76FAA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070326162933-26A35BB0-09E6AD29/1732129897-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Without looking too closely into the details, I do think that refering to the MLPP drafts in TSVWG would be good. I know they caused a lot of discussing in TSVWG, for example. John=20 >-----Original Message----- >From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 >Sent: 26 March, 2007 06:15 >To: Jukka MJ Manner; NSIS Working Group >Subject: RE: [NSIS] QSPEC: Pre-emption > >hi, > >a very simple answer:=20 > >> -----Original Message----- >> From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> Sent: 24 March 2007 18:36 >> To: NSIS Working Group >> Subject: [NSIS] QSPEC: Pre-emption >>=20 >>=20 >> We (at least Roland, Andrew, Georgios) have thought a bit more about=20 >> the pre-emption, and how&where it should be described. Basically, it=20 >> is a "problem" of QOSMs. The NSLP provides certain messages=20 >to inform=20 >> of pre-emption, and who caused it (my recent proposal on the mailing=20 >> list). >>=20 >> But, how does a QNE choose a flow to be pre-empted in the=20 >first place=20 >> is out of scope of the NSLP. Yet, it might be good to say a=20 >few words=20 >> about how to choose the "right" flow to pre-empt to help QOSM=20 >> designers. >>=20 >> One simple idea we have talked about is that the QNE should try to=20 >> choose a low(er) priority flow where the MRI is "close" (esp. the=20 >> target IP) to the higher priority flow. >> This has the benefit that the pre-empted flow may share most of the=20 >> path with the high priority flow. If the pre-empted flow has=20 >a random=20 >> MRI, in case of heavy congestion, QNEs downstream may not=20 >see the same=20 >> low(er) priority flow, and, thus, pre-empt other flows. >> Thus, in order to accommodate one high priority flow, the=20 >network may=20 >> be killing N other flows. >>=20 >> Do you think giving advise on pre-emption to QOSM designers=20 >is out of=20 >> scope of the QSPEC Template? > >basically I would say no. At least any normative text will hit=20 >endless debates about regulation and lawfulness. At most one=20 >could point out the consequences of particular strategies, but=20 >it would be preferable IMHO to refer to other documents. >(In other words, I assume that anything useful that can be=20 >written on this topic in the IETF has already been written.) > >robert h. > >>=20 >> Cheers, >> Jukka >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpfm-0001SA-Oj; Mon, 26 Mar 2007 09:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpfi-0001Rr-SL for nsis@ietf.org; Mon, 26 Mar 2007 09:55:42 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpfh-0002AZ-DI for nsis@ietf.org; Mon, 26 Mar 2007 09:55:42 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 26 Mar 2007 16:55:34 +0300 id 0005FEDF.4607D0D6.00007B25 Date: Mon, 26 Mar 2007 16:55:33 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] QSPEC: Pre-emption In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Rob, Good point. Let's drop this item. Jukka On Mon, 26 Mar 2007, Hancock, Robert wrote: > hi, > > a very simple answer: > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: 24 March 2007 18:36 > > To: NSIS Working Group > > Subject: [NSIS] QSPEC: Pre-emption > > > > > > We (at least Roland, Andrew, Georgios) have thought a bit > > more about the pre-emption, and how&where it should be > > described. Basically, it is a "problem" of QOSMs. The NSLP > > provides certain messages to inform of pre-emption, and who > > caused it (my recent proposal on the mailing list). > > > > But, how does a QNE choose a flow to be pre-empted in the > > first place is out of scope of the NSLP. Yet, it might be > > good to say a few words about how to choose the "right" flow > > to pre-empt to help QOSM designers. > > > > One simple idea we have talked about is that the QNE should > > try to choose a low(er) priority flow where the MRI is > > "close" (esp. the target IP) to the higher priority flow. > > This has the benefit that the pre-empted flow may share most > > of the path with the high priority flow. If the pre-empted > > flow has a random MRI, in case of heavy congestion, QNEs > > downstream may not see the same low(er) priority flow, and, > > thus, pre-empt other flows. > > Thus, in order to accommodate one high priority flow, the > > network may be killing N other flows. > > > > Do you think giving advise on pre-emption to QOSM designers > > is out of scope of the QSPEC Template? > > basically I would say no. At least any normative text will hit > endless debates about regulation and lawfulness. At most one > could point out the consequences of particular strategies, but > it would be preferable IMHO to refer to other documents. > (In other words, I assume that anything useful that can be > written on this topic in the IETF has already been written.) > > robert h. > > > > > Cheers, > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpgL-0001WT-It; Mon, 26 Mar 2007 09:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpgK-0001WN-BB for nsis@ietf.org; Mon, 26 Mar 2007 09:56:20 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpgJ-0002GR-Ia for nsis@ietf.org; Mon, 26 Mar 2007 09:56:20 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2QDu3gX000471; Mon, 26 Mar 2007 14:56:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text Date: Mon, 26 Mar 2007 14:56:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Updated QoS NSLP: pre-emption text Thread-Index: AcdrFOdzouNN+hK9S+OPHabhrzFgLwEibaRgAAIreNAAAFg0AAAA8xFA References: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> <009501c76fa9$437b78f0$4c0d5982@dynamic.ewi.utwente.nl> From: "Hancock, Robert" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org ok, so i read between the lines correctly. what i don't see is the need to send two sets of reserve messages=20 to carry out the pre-emption (the tear[s] followed by the=20 installation). this would cause some issues message ordering (race conditions) which are always hard to implement right, especially when taking account of error conditions. after all, the downstream node always has to have the freedom to repeat the algorithm "select flows to be pre-empted". this might=20 be for several reasons: - some of the already pre-empted flows don't go through the=20 downstream node (need to find more resources) - all the pre-empted flows go through the downstream node but it still needs to pre-empt more (less headroom for example) therefore, there can be no strict need to send the tear[s] first. all that is needed is for the pre-empting node to send the pre-empting reserve with a list of the SIDs that it has already pre-empted as bound sessions. this means that the pre-empting reserve can be sent immediately. at some point in the future,=20 the node can (if it wants) send explicit tears for the=20 sessions it is removing, but that can be normal operation. when the downstream node gets the pre-empting reserve, the list of bound sessions gets used as another hint in the selection algorithm. the main difference in terms of message processing rules is that in jukka's version, the BOUND_SESSION id refers to a session that doesn't exist yet, so a node receving the tear has to=20 remember it From nsis-bounces@ietf.org Mon Mar 26 09:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpfm-0001SA-Oj; Mon, 26 Mar 2007 09:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpfi-0001Rr-SL for nsis@ietf.org; Mon, 26 Mar 2007 09:55:42 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpfh-0002AZ-DI for nsis@ietf.org; Mon, 26 Mar 2007 09:55:42 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 26 Mar 2007 16:55:34 +0300 id 0005FEDF.4607D0D6.00007B25 Date: Mon, 26 Mar 2007 16:55:33 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] QSPEC: Pre-emption In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Rob, Good point. Let's drop this item. Jukka On Mon, 26 Mar 2007, Hancock, Robert wrote: > hi, > > a very simple answer: > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: 24 March 2007 18:36 > > To: NSIS Working Group > > Subject: [NSIS] QSPEC: Pre-emption > > > > > > We (at least Roland, Andrew, Georgios) have thought a bit > > more about the pre-emption, and how&where it should be > > described. Basically, it is a "problem" of QOSMs. The NSLP > > provides certain messages to inform of pre-emption, and who > > caused it (my recent proposal on the mailing list). > > > > But, how does a QNE choose a flow to be pre-empted in the > > first place is out of scope of the NSLP. Yet, it might be > > good to say a few words about how to choose the "right" flow > > to pre-empt to help QOSM designers. > > > > One simple idea we have talked about is that the QNE should > > try to choose a low(er) priority flow where the MRI is > > "close" (esp. the target IP) to the higher priority flow. > > This has the benefit that the pre-empted flow may share most > > of the path with the high priority flow. If the pre-empted > > flow has a random MRI, in case of heavy congestion, QNEs > > downstream may not see the same low(er) priority flow, and, > > thus, pre-empt other flows. > > Thus, in order to accommodate one high priority flow, the > > network may be killing N other flows. > > > > Do you think giving advise on pre-emption to QOSM designers > > is out of scope of the QSPEC Template? > > basically I would say no. At least any normative text will hit > endless debates about regulation and lawfulness. At most one > could point out the consequences of particular strategies, but > it would be preferable IMHO to refer to other documents. > (In other words, I assume that anything useful that can be > written on this topic in the IETF has already been written.) > > robert h. > > > > > Cheers, > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.iefor when the new reserve turns up. in what is=20 suggested above, the BOUND_SESSION ids refer either to - existing sessions at the node (i.e. already known), or - unknown sessions (presumably whose routes have diverged), which can just be ignored. robert h. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 26 March 2007 14:19 > To: Hancock, Robert; 'Jukka MJ Manner' > Cc: 'NSIS Working Group' > Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text >=20 > Hi Robert >=20 > I assumed that Jukka's problem description was clear enough >=20 > The problem description that you gave below is correct! >=20 > Best Regards, > Georgios >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@ROKE.CO.UK] > > Sent: maandag 26 maart 2007 15:11 > > To: Georgios Karagiannis; Jukka MJ Manner > > Cc: NSIS Working Group > > Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text > >=20 > > hi all, > >=20 > > This is a very detailed description, but I don't really=20 > understand the=20 > > problem that is being solved. (That is, what are the special things=20 > > that we are trying to require of the solution.) > >=20 > > I interpret from some of the previous discussion that the potential=20 > > issue is that if pre-emption is carried out along a path, but the=20 > > pre-empted flows are selected independently at each node on=20 > the path,=20 > > you could end up with large numbers of flows being preempted in an=20 > > uncoordinated way (i.e. more than the minimal number necessary);=20 > > whereas, if one node knows that flows X/Y/Z have already been=20 > > preempted then it can choose to discard these first rather than=20 > > randomly choosing A/B/C. > >=20 > > Is this a correct understanding? (If it is, I believe there are=20 > > simpler solutions, but I thought I'd check the understanding first.) > >=20 > > r. > >=20 > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 26 March 2007 13:43 > > > To: 'Jukka MJ Manner' > > > Cc: 'NSIS Working Group' > > > Subject: [NSIS] Updated QoS NSLP: pre-emption text > > >=20 > > > Hi Jukka and all > > >=20 > > > Your description covers almost all the items of the > > solution that we > > > have found during our discussions on the coridors of the > > Hilton hotel > > > in Prague. > > >=20 > > > However, below I include some more details: > > > =20 > > > Step_1:=20 > > > ------ > > > If a QNE receives a RESERVE for a session that causes other > > > session(s) to be pre-empted, for each of these session, the > > QNE will > > > send a tearing RESERVE downstream and add an INFO_SPEC with=20 > > > pre-emption error code and a BOUND_SESSION_ID that indicates the=20 > > > session that caused the pre-emption. Note that the value of this=20 > > > BOUND_SESSION_ID will have a new Binding Code value, which > > will have > > > to be specified in the QOS-NSLP. > > > Furthermore, the selection of which > > > flows will have to be terminated should be specified by the > > QOSM. An > > > example of this selection process can be based on the MRI > > associated > > > with the high and lower priority sessions. > > > In particular the QNE cans select low(er) priority=20 > session(s) where=20 > > > the MRI is "close" (esp. the target IP) to the one > > associated with the > > > higher priority session. > > > This has the benefit that the pre-empted session may share > > most of the > > > path with the high priority session. > > > Furthermore, the amount of the sessions that have to be > > preempted per > > > each high priority session, has to be specified by the > > QOSM, since the > > > QOSM has to compare the reserved resources by the lower priority=20 > > > sessions and the requested resources by the high priority session. > > >=20 > > >=20 > > >=20 > > > Step_2: > > > ----- > > > For each of the sent tearing RESERVE, the QNE will send a NOTIFY=20 > > > message with an INFO-SPEC that indicates the pre-emption=20 > error code=20 > > > towards the QNI. > > >=20 > tf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpgL-0001WT-It; Mon, 26 Mar 2007 09:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpgK-0001WN-BB for nsis@ietf.org; Mon, 26 Mar 2007 09:56:20 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpgJ-0002GR-Ia for nsis@ietf.org; Mon, 26 Mar 2007 09:56:20 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2QDu3gX000471; Mon, 26 Mar 2007 14:56:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text Date: Mon, 26 Mar 2007 14:56:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Updated QoS NSLP: pre-emption text Thread-Index: AcdrFOdzouNN+hK9S+OPHabhrzFgLwEibaRgAAIreNAAAFg0AAAA8xFA References: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> <009501c76fa9$437b78f0$4c0d5982@dynamic.ewi.utwente.nl> From: "Hancock, Robert" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org ok, so i read between the lines correctly. what i don't see is the need to send two sets of reserve messages=20 to carry out the pre-emption (the tear[s] followed by the=20 installation). this would cause some issues message ordering (race conditions) which are always hard to implement right, especially when taking account of error conditions. after all, the downstream node always has to have the freedom to repeat the algorithm "select flows to be pre-empted". this might=20 be for several reasons: - some of the already pre-empted flows don't go through the=20 downstream node (need to find more resources) - all the pre-empted flows go through the downstream node but it still needs to pre-empt more (less headroom for example) therefore, there can be no strict need to send the tear[s] first. all that is needed is for the pre-empting node to send the pre-empting reserve with a list of the SIDs that it has already pre-empted as bound sessions. this means that the pre-empting reserve can be sent immediately. at some point in the future,=20 the node can (if it wants) send explicit tears for the=20 sessions it is removing, but that can be normal operation. when the downstream node gets the pre-empting reserve, the list of bound sessions gets used as another hint in the selection algorithm. the main difference in terms of message processing rules is that in jukka's version, the BOUND_SESSION id refers to a session that doesn't exist yet, so a node receving the tear has to=20 remember it > >=20 > > > Step_3 > > > ------ > > > After sending the tearing RESERVE(s), the QNE will send the > > > (reserving) RESERVE > > >=20 > > > Step_4: > > > ----- > > > Upon receiving the first tearing RESERVE, the QNE creates a > > so called > > > (we called it like this) preemption state, which is > > identified by the > > > SESSION_ID carried in the preemption related > > BOUND_SESSION_ID object.=20 > > > Furthermore, this preemption state will include the > > SESSION_ID of the > > > session associated with the tearing RESERVE. > > > If subsequently additional tearing RESERVE(s) are arriving, which=20 > > > include in their preemption related BOUND_SESSION_ID > > > object(s) the value of the same SESSION_ID (of the high priority > > > session) as the one included in the first arrived tearing RESERVE=20 > > > message, then the associated SESSION_IDs of these tearing RESERVE=20 > > > messages will be included in the already created preemption > > state. The > > > QNE then will set a timer that indicates that the=20 > indicated session=20 > > > MUST be torn down in the future, and sends the tearing RESERVE(s)=20 > > > further downstream. > > >=20 > > > Step_5: > > > ----- > > > Upon receiving the (reserving) RESERVE, the QNE will remove the=20 > > > pending resources, and make the new reservation. If the QNE > > will not > > > receive all the tearing RESRVEs sent by the previous > > upstream QNE, it > > > will have to calculate and select new lower priority=20 > sessions that=20 > > > have to be terminated. The selection process is similar to > > the process > > > described in Step_1. > > >=20 > > >=20 > > > =20 > > > Step_6: > > > ----- > > > If the (reserving) RESERVE never arrives, e.g., the path of the=20 > > > pre-empted and high priority flows diverged at some point, > > the timer > > > will cause the resources to be removed eventually. > > >=20 > > > Effectively, this causes a sort of "switch resouces from these=20 > > > sessions to the session indicated in the BOUND_SESSION once the=20 > > > RESERVE arrives". If the RESERVE never arrives, upstream=20 > nodes have=20 > > > already removed the resources, so the downstream node must do=20 > > > likewise. > > >=20 > > > This operation has the following benefits: > > > =20 > > > 1. Downstream nodes are able to make the same decision when=20 > > > pre-empting low priority flows due to the high priority flow. > > > =20 > > > 2. We make sure the resources are put aside for the=20 > indicated high=20 > > > priority flow in downstream nodes before the RESERVE > > actually arrives. > > >=20 > > > 3. Lower priority sessions are selected that atre=20 > assoicated with A=20 > > > destination IP address (included in MRI) that is "close"=20 > (esp. the=20 > > > target IP) to the one associated with the higher priority session. > > > This has the benefit that the pre-empted session may share > > most of the > > > path with the high priority session. > > >=20 > > > Best regards, > > > Georgios > > >=20 > > >=20 > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: dinsdag 20 maart 2007 18:15 > > > > To: NSIS Working Group > > > > Subject: [NSIS] QoS NSLP: pre-emption > > > >=20 > > > >=20 > > > > The pre-emption functionality is after all quite a complex > > > issue. We > > > > have had some discussion about it, and would propose the > > following: > > > >=20 > > > > - If a QNE receives a RESERVE for a flow that causes other > > > > flow(s) to be pre-empted, for each of these flows, the QNE > > > will send a > > > > tearing RESERVE downstream and add an INFO_SPEC with > > > pre-emption error > > > > code and a BOUND_SESSION_ID that indicates the flow that > > caused the > > > > pre-emption > > > >=20 > > > > - After sending the tearing RESERVE(s), the QNE will send the > > > > (reserving) > > > > RESERVE > > > >=20 > > > > - Upon receiving this/these tearing RESERVEs, a QNE will > > > set a timer > > > > that indicates that the indicated session MUST be torn > > down in the > > > > future, and sends the tfor when the new reserve turns up. in what is=20 suggested above, the BOUND_SESSION ids refer either to - existing sessions at the node (i.e. already known), or - unknown sessions (presumably whose routes have diverged), which can just be ignored. robert h. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 26 March 2007 14:19 > To: Hancock, Robert; 'Jukka MJ Manner' > Cc: 'NSIS Working Group' > Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text >=20 > Hi Robert >=20 > I assumed that Jukka's problem description was clear enough >=20 > The problem description that you gave below is correct! >=20 > Best Regards, > Georgios >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@ROKE.CO.UK] > > Sent: maandag 26 maart 2007 15:11 > > To: Georgios Karagiannis; Jukka MJ Manner > > Cc: NSIS Working Group > > Subject: RE: [NSIS] Updated QoS NSLP: pre-emption text > >=20 > > hi all, > >=20 > > This is a very detailed description, but I don't really=20 > understand the=20 > > problem that is being solved. (That is, what are the special things=20 > > that we are trying to require of the solution.) > >=20 > > I interpret from some of the previous discussion that the potential=20 > > issue is that if pre-emption is carried out along a path, but the=20 > > pre-empted flows are selected independently at each node on=20 > the path,=20 > > you could end up with large numbers of flows being preempted in an=20 > > uncoordinated way (i.e. more than the minimal number necessary);=20 > > whereas, if one node knows that flows X/Y/Z have already been=20 > > preempted then it can choose to discard these first rather than=20 > > randomly choosing A/B/C. > >=20 > > Is this a correct understanding? (If it is, I believe there are=20 > > simpler solutions, but I thought I'd check the understanding first.) > >=20 > > r. > >=20 > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 26 March 2007 13:43 > > > To: 'Jukka MJ Manner' > > > Cc: 'NSIS Working Group' > > > Subject: [NSIS] Updated QoS NSLP: pre-emption text > > >=20 > > > Hi Jukka and all > > >=20 > > > Your description covers almost all the items of the > > solution that we > > > have found during our discussions on the coridors of the > > Hilton hotel > > > in Prague. > > >=20 > > > However, below I include some more details: > > > =20 > > > Step_1:=20 > > > ------ > > > If a QNE receives a RESERVE for a session that causes other > > > session(s) to be pre-empted, for each of these session, the > > QNE will > > > send a tearing RESERVE downstream and add an INFO_SPEC with=20 > > > pre-emption error code and a BOUND_SESSION_ID that indicates the=20 > > > session that caused the pre-emption. Note that the value of this=20 > > > BOUND_SESSION_ID will have a new Binding Code value, which > > will have > > > to be specified in the QOS-NSLP. > > > Furthermore, the selection of which > > > flows will have to be terminated should be specified by the > > QOSM. An > > > example of this selection process can be based on the MRI > > associated > > > with the high and lower priority sessions. > > > In particular the QNE cans select low(er) priority=20 > session(s) where=20 > > > the MRI is "close" (esp. the target IP) to the one > > associated with the > > > higher priority session. > > > This has the benefit that the pre-empted session may share > > most of the > > > path with the high priority session. > > > Furthermore, the amount of the sessions that have to be > > preempted per > > > each high priority session, has to be specified by the > > QOSM, since the > > > QOSM has to compare the reserved resources by the lower priority=20 > > > sessions and the requested resources by the high priority session. > > >=20 > > >=20 > > >=20 > > > Step_2: > > > ----- > > > For each of the sent tearing RESERVE, the QNE will send a NOTIFY=20 > > > message with an INFO-SPEC that indicates the pre-emption=20 > error code=20 > > > towards the QNI. > > >=20 > earing RESERVE further downstream. > > > >=20 > > > > - Upon receiving the (reserving) RESERVE, the QNE will=20 > remove the=20 > > > > pending resources, and make the new reservation. > > > >=20 > > > > - If the (reserving) RESERVE never arrives, e.g., the=20 > path of the=20 > > > > pre-empted and high priority flows diverged at some point, > > > the timer > > > > will cause the resources to be removed eventually. > > > >=20 > > > > Effectively, this causes a sort of "switch resouces from these=20 > > > > sessions to the session indicated in the BOUND_SESSION once the=20 > > > > RESERVE arrives". If the RESERVE never arrives, upstream > > nodes have > > > > already removed the resources, so the downstream node must do=20 > > > > likewise. > > > >=20 > > > > This operation has the following benefits: > > > >=20 > > > > 1. Downstream nodes are able to make the same decision when=20 > > > > pre-empting > > > > low priority flows due to the high priority flow. > > > >=20 > > > > 2. We make sure the resources are put aside for the > > indicated high > > > > priority flow in downstream nodes before the RESERVE=20 > actually=20 > > > > arrives. > > > >=20 > > > >=20 > > > > Any comments? (I wonder if I explained the idea properly) > > > >=20 > > > > Jukka > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >=20 > > > Step_3 > > > ------ > > > After sending the tearing RESERVE(s), the QNE will send the > > > (reserving) RESERVE > > >=20 > > > Step_4: > > > ----- > > > Upon receiving the first tearing RESERVE, the QNE creates a > > so called > > > (we called it like this) preemption state, which is > > identified by the > > > SESSION_ID carried in the preemption related > > BOUND_SESSION_ID object.=20 > > > Furthermore, this preemption state will include the > > SESSION_ID of the > > > session associated with the tearing RESERVE. > > > If subsequently additional tearing RESERVE(s) are arriving, which=20 > > > include in their preemption related BOUND_SESSION_ID > > > object(s) the value of the same SESSION_ID (of the high priority > > > session) as the one included in the first arrived tearing RESERVE=20 > > > message, then the associated SESSION_IDs of these tearing RESERVE=20 > > > messages will be included in the already created preemption > > state. The > > > QNE then will set a timer that indicates that the=20 > indicated session=20 > > > MUST be torn down in the future, and sends the tearing RESERVE(s)=20 > > > further downstream. > > >=20 > > > Step_5: > > > ----- > > > Upon receiving the (reserving) RESERVE, the QNE will remove the=20 > > > pending resources, and make the new reservation. If the QNE > > will not > > > receive all the tearing RESRVEs sent by the previous > > upstream QNE, it > > > will have to calculate and select new lower priority=20 > sessions that=20 > > > have to be terminated. The selection process is similar to > > the process > > > described in Step_1. > > >=20 > > >=20 > > > =20 > > > Step_6: > > > ----- > > > If the (reserving) RESERVE never arrives, e.g., the path of the=20 > > > pre-empted and high priority flows diverged at some point, > > the timer > > > will cause the resources to be removed eventually. > > >=20 > > > Effectively, this causes a sort of "switch resouces from these=20 > > > sessions to the session indicated in the BOUND_SESSION once the=20 > > > RESERVE arrives". If the RESERVE never arrives, upstream=20 > nodes have=20 > > > already removed the resources, so the downstream node must do=20 > > > likewise. > > >=20 > > > This operation has the following benefits: > > > =20 > > > 1. Downstream nodes are able to make the same decision when=20 > > > pre-empting low priority flows due to the high priority flow. > > > =20 > > > 2. We make sure the resources are put aside for the=20 > indicated high=20 > > > priority flow in downstream nodes before the RESERVE > > actually arrives. > > >=20 > > > 3. Lower priority sessions are selected that atre=20 > assoicated with A=20 > > > destination IP address (included in MRI) that is "close"=20 > (esp. the=20 > > > target IP) to the one associated with the higher priority session. > > > This has the benefit that the pre-empted session may share > > most of the > > > path with the high priority session. > > >=20 > > > Best regards, > > > Georgios > > >=20 > > >=20 > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: dinsdag 20 maart 2007 18:15 > > > > To: NSIS Working Group > > > > Subject: [NSIS] QoS NSLP: pre-emption > > > >=20 > > > >=20 > > > > The pre-emption functionality is after all quite a complex > > > issue. We > > > > have had some discussion about it, and would propose the > > following: > > > >=20 > > > > - If a QNE receives a RESERVE for a flow that causes other > > > > flow(s) to be pre-empted, for each of these flows, the QNE > > > will send a > > > > tearing RESERVE downstream and add an INFO_SPEC with > > > pre-emption error > > > > code and a BOUND_SESSION_ID that indicates the flow that > > caused the > > > > pre-emption > > > >=20 > > > > - After sending the tearing RESERVE(s), the QNE will send the > > > > (reserving) > > > > RESERVE > > > >=20 > > > > - Upon receiving this/these tearing RESERVEs, a QNE will > > > set a timer > > > > that indicates that the indicated session MUST be torn > > down in the > > > > future, and sends the tearing RESERVE further downstream. > > > >=20 > > > > - Upon receiving the (reserving) RESERVE, the QNE will=20 > remove the=20 > > > > pending resources, and make the new reservation. > > > >=20 > > > > - If the (reserving) RESERVE never arrives, e.g., the=20 > path of the=20 > > > > pre-empted and high priority flows diverged at some point, > > > the timer > > > > will cause the resources to be removed eventually. > > > >=20 > > > > Effectively, this causes a sort of "switch resouces from these=20 > > > > sessions to the session indicated in the BOUND_SESSION once the=20 > > > > RESERVE arrives". If the RESERVE never arrives, upstream > > nodes have > > > > already removed the resources, so the downstream node must do=20 > > > > likewise. > > > >=20 > > > > This operation has the following benefits: > > > >=20 > > > > 1. Downstream nodes are able to make the same decision when=20 > > > > pre-empting > > > > low priority flows due to the high priority flow. > > > >=20 > > > > 2. We make sure the resources are put aside for the > > indicated high > > > > priority flow in downstream nodes before the RESERVE=20 > actually=20 > > > > arrives. > > > >=20 > > > >=20 > > > > Any comments? (I wonder if I explained the idea properly) > > > >=20 > > > > Jukka > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpgq-0001Zy-SU; Mon, 26 Mar 2007 09:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpgp-0001Zs-Oi for nsis@ietf.org; Mon, 26 Mar 2007 09:56:51 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpgo-0002Li-6R for nsis@ietf.org; Mon, 26 Mar 2007 09:56:51 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 26 Mar 2007 16:56:49 +0300 id 0005FEEA.4607D121.00003796 Date: Mon, 26 Mar 2007 16:56:49 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis In-Reply-To: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: 'NSIS Working Group' Subject: [NSIS] Re: Updated QoS NSLP: pre-emption text X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Such text may go into the RMD document since it is only one way to implement pre-emption handling. The NSLP should provide the means, and the QOSMs define how to implement it. Jukka On Mon, 26 Mar 2007, Georgios Karagiannis wrote: > Hi Jukka and all > > Your description covers almost all the items of the solution > that we have found during our discussions > on the coridors of the Hilton hotel in Prague. > > However, below I include some more details: > > Step_1: > ------ > If a QNE receives a RESERVE for a session that causes other > session(s) to be pre-empted, for each of these session, the QNE > will send a tearing RESERVE downstream and add an INFO_SPEC > with pre-emption error code and a BOUND_SESSION_ID that > indicates the session that caused the pre-emption. Note that the value of > this BOUND_SESSION_ID will have a new Binding Code value, which will > have to be specified in the QOS-NSLP. > Furthermore, the selection of which > flows will have to be terminated should be specified > by the QOSM. An example of this selection process > can be based on the MRI associated with the high and lower priority > sessions. > In particular the QNE cans select low(er) priority session(s) where the MRI > is "close" (esp. the target IP) to the one associated with the higher > priority session. > This has the benefit that the pre-empted session may share most of > the path with the high priority session. > Furthermore, the amount of the sessions that have to be preempted > per each high priority session, has to be specified by the QOSM, > since the QOSM has to compare the reserved resources by the > lower priority sessions and the > requested resources by the high priority session. > > > > Step_2: > ----- > For each of the sent tearing RESERVE, the QNE will send a > NOTIFY message with an INFO-SPEC that indicates the pre-emption > error code towards the QNI. > > > Step_3 > ------ > After sending the tearing RESERVE(s), the QNE will send the > (reserving) RESERVE > > Step_4: > ----- > Upon receiving the first tearing RESERVE, the QNE creates a so called (we > called it like this) > preemption state, which is identified by the SESSION_ID carried > in the preemption related BOUND_SESSION_ID object. Furthermore, this > preemption state > will include the SESSION_ID of the session associated with the tearing > RESERVE. > If subsequently additional tearing RESERVE(s) are arriving, which include > in their preemption related BOUND_SESSION_ID object(s) the value of the same > SESSION_ID (of the > high priority session) as the one included in the first arrived tearing > RESERVE message, > then the associated SESSION_IDs of these tearing RESERVE messages will be > included in the already > created preemption state. The QNE then will set > a timer that indicates that the indicated session MUST be > torn down in the future, and sends the tearing RESERVE(s) > further downstream. > > Step_5: > ----- > Upon receiving the (reserving) RESERVE, the QNE will remove > the pending resources, and make the new reservation. If the QNE will not > receive all > the tearing RESRVEs sent by the previous upstream QNE, it will have to > calculate > and select new lower priority sessions that have to be terminated. The > selection process is > similar to the process described in Step_1. > > > > Step_6: > ----- > If the (reserving) RESERVE never arrives, e.g., the path of > the pre-empted and high priority flows diverged at some > point, the timer will cause the resources to be removed eventually. > > Effectively, this causes a sort of "switch resouces from > these sessions to the session indicated in the BOUND_SESSION > once the RESERVE arrives". If the RESERVE never arrives, > upstream nodes have already removed the resources, so the > downstream node must do likewise. > > This operation has the following benefits: > > 1. Downstream nodes are able to make the same decision when > pre-empting low priority flows due to the high priority flow. > > 2. We make sure the resources are put aside for the indicated high > priority flow in downstream nodes before the RESERVE > actually arrives. > > 3. Lower priority sessions are selected that atre assoicated with > A destination IP address (included in MRI) that is > "close" (esp. the target IP) to the one associated with the higher priority > session. > This has the benefit that the pre-empted session may share most of > the path with the high priority session. > > Best regards, > Georgios > > > > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: dinsdag 20 maart 2007 18:15 > > To: NSIS Working Group > > Subject: [NSIS] QoS NSLP: pre-emption > > > > > > The pre-emption functionality is after all quite a complex > > issue. We have had some discussion about it, and would > > propose the following: > > > > - If a QNE receives a RESERVE for a flow that causes other > > flow(s) to be pre-empted, for each of these flows, the QNE > > will send a tearing RESERVE downstream and add an INFO_SPEC > > with pre-emption error code and a BOUND_SESSION_ID that > > indicates the flow that caused the pre-emption > > > > - After sending the tearing RESERVE(s), the QNE will send the > > (reserving) > > RESERVE > > > > - Upon receiving this/these tearing RESERVEs, a QNE will set > > a timer that indicates that the indicated session MUST be > > torn down in the future, and sends the tearing RESERVE > > further downstream. > > > > - Upon receiving the (reserving) RESERVE, the QNE will remove > > the pending resources, and make the new reservation. > > > > - If the (reserving) RESERVE never arrives, e.g., the path of > > the pre-empted and high priority flows diverged at some > > point, the timer will cause the resources to be removed eventually. > > > > Effectively, this causes a sort of "switch resouces from > > these sessions to the session indicated in the BOUND_SESSION > > once the RESERVE arrives". If the RESERVE never arrives, > > upstream nodes have already removed the resources, so the > > downstream node must do likewise. > > > > This operation has the following benefits: > > > > 1. Downstream nodes are able to make the same decision when > > pre-empting > > low priority flows due to the high priority flow. > > > > 2. We make sure the resources are put aside for the indicated high > > priority flow in downstream nodes before the RESERVE > > actually arrives. > > > > > > Any comments? (I wonder if I explained the idea properly) > > > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 09:59:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpiq-0003DA-1c; Mon, 26 Mar 2007 09:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpio-0003D3-Ci for nsis@ietf.org; Mon, 26 Mar 2007 09:58:54 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpim-0002bP-RA for nsis@ietf.org; Mon, 26 Mar 2007 09:58:54 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2QDwlAP000601; Mon, 26 Mar 2007 15:58:51 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" References: <008301c76fa4$3e9a0770$4c0d5982@dynamic.ewi.utwente.nl> Date: Mon, 26 Mar 2007 15:58:42 +0200 Message-ID: <009801c76fae$dff77e40$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdvrp4NkPPYJvQcT9aTo9olHmQiZgAADKKA In-Reply-To: X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 26 Mar 2007 15:58:52 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: 'NSIS Working Group' Subject: [NSIS] RE: Updated QoS NSLP: pre-emption text X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka I agree! Best regards, Georgios > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: maandag 26 maart 2007 15:57 > To: Georgios Karagiannis > Cc: 'NSIS Working Group' > Subject: Re: Updated QoS NSLP: pre-emption text > > > Hi Georgios, > > Such text may go into the RMD document since it is only one > way to implement pre-emption handling. The NSLP should > provide the means, and the QOSMs define how to implement it. > > Jukka > > On Mon, 26 Mar 2007, Georgios Karagiannis wrote: > > > Hi Jukka and all > > > > Your description covers almost all the items of the > solution that we > > have found during our discussions on the coridors of the > Hilton hotel > > in Prague. > > > > However, below I include some more details: > > > > Step_1: > > ------ > > If a QNE receives a RESERVE for a session that causes other > > session(s) to be pre-empted, for each of these session, the > QNE will > > send a tearing RESERVE downstream and add an INFO_SPEC with > > pre-emption error code and a BOUND_SESSION_ID that indicates the > > session that caused the pre-emption. Note that the value of this > > BOUND_SESSION_ID will have a new Binding Code value, which > will have > > to be specified in the QOS-NSLP. > > Furthermore, the selection of which > > flows will have to be terminated should be specified by the > QOSM. An > > example of this selection process can be based on the MRI > associated > > with the high and lower priority sessions. > > In particular the QNE cans select low(er) priority session(s) where > > the MRI is "close" (esp. the target IP) to the one > associated with the > > higher priority session. > > This has the benefit that the pre-empted session may share > most of the > > path with the high priority session. > > Furthermore, the amount of the sessions that have to be > preempted per > > each high priority session, has to be specified by the > QOSM, since the > > QOSM has to compare the reserved resources by the lower priority > > sessions and the requested resources by the high priority session. > > > > > > > > Step_2: > > ----- > > For each of the sent tearing RESERVE, the QNE will send a NOTIFY > > message with an INFO-SPEC that indicates the pre-emption error code > > towards the QNI. > > > > > > Step_3 > > ------ > > After sending the tearing RESERVE(s), the QNE will send the > > (reserving) RESERVE > > > > Step_4: > > ----- > > Upon receiving the first tearing RESERVE, the QNE creates a > so called > > (we called it like this) preemption state, which is > identified by the > > SESSION_ID carried in the preemption related > BOUND_SESSION_ID object. > > Furthermore, this preemption state will include the > SESSION_ID of the > > session associated with the tearing RESERVE. > > If subsequently additional tearing RESERVE(s) are arriving, which > > include in their preemption related BOUND_SESSION_ID object(s) the > > value of the same SESSION_ID (of the high priority session) > as the one > > included in the first arrived tearing RESERVE message, then the > > associated SESSION_IDs of these tearing RESERVE messages will be > > included in the already created preemption state. The QNE then will > > set a timer that indicates that the indicated session MUST be torn > > down in the future, and sends the tearing RESERVE(s) further > > downstream. > > > > Step_5: > > ----- > > Upon receiving the (reserving) RESERVE, the QNE will remove the > > pending resources, and make the new reservation. If the QNE > will not > > receive all the tearing RESRVEs sent by the previous > upstream QNE, it > > will have to calculate and select new lower priority sessions that > > have to be terminated. The selection process is similar to > the process > > described in Step_1. > > > > > > > > Step_6: > > ----- > > If the (reserving) RESERVE never arrives, e.g., the path of > > the pre-empted and high priority flows diverged at some > > point, the timer will cause the resources to be removed eventually. > > > > Effectively, this causes a sort of "switch resouces from > > these sessions to the session indicated in the BOUND_SESSION > > once the RESERVE arrives". If the RESERVE never arrives, > > upstream nodes have already removed the resources, so the > > downstream node must do likewise. > > > > This operation has the following benefits: > > > > 1. Downstream nodes are able to make the same decision when > > pre-empting low priority flows due to the high priority flow. > > > > 2. We make sure the resources are put aside for the indicated high > > priority flow in downstream nodes before the RESERVE > > actually arrives. > > > > 3. Lower priority sessions are selected that atre assoicated with > > A destination IP address (included in MRI) that is > > "close" (esp. the target IP) to the one associated with the > higher priority > > session. > > This has the benefit that the pre-empted session may share most of > > the path with the high priority session. > > > > Best regards, > > Georgios > > > > > > > > > > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: dinsdag 20 maart 2007 18:15 > > > To: NSIS Working Group > > > Subject: [NSIS] QoS NSLP: pre-emption > > > > > > > > > The pre-emption functionality is after all quite a complex > > > issue. We have had some discussion about it, and would > > > propose the following: > > > > > > - If a QNE receives a RESERVE for a flow that causes other > > > flow(s) to be pre-empted, for each of these flows, the QNE > > > will send a tearing RESERVE downstream and add an INFO_SPEC > > > with pre-emption error code and a BOUND_SESSION_ID that > > > indicates the flow that caused the pre-emption > > > > > > - After sending the tearing RESERVE(s), the QNE will send the > > > (reserving) > > > RESERVE > > > > > > - Upon receiving this/these tearing RESERVEs, a QNE will set > > > a timer that indicates that the indicated session MUST be > > > torn down in the future, and sends the tearing RESERVE > > > further downstream. > > > > > > - Upon receiving the (reserving) RESERVE, the QNE will remove > > > the pending resources, and make the new reservation. > > > > > > - If the (reserving) RESERVE never arrives, e.g., the path of > > > the pre-empted and high priority flows diverged at some > > > point, the timer will cause the resources to be removed > eventually. > > > > > > Effectively, this causes a sort of "switch resouces from > > > these sessions to the session indicated in the BOUND_SESSION > > > once the RESERVE arrives". If the RESERVE never arrives, > > > upstream nodes have already removed the resources, so the > > > downstream node must do likewise. > > > > > > This operation has the following benefits: > > > > > > 1. Downstream nodes are able to make the same decision when > > > pre-empting > > > low priority flows due to the high priority flow. > > > > > > 2. We make sure the resources are put aside for the > indicated high > > > priority flow in downstream nodes before the RESERVE > > > actually arrives. > > > > > > > > > Any comments? (I wonder if I explained the idea properly) > > > > > > Jukka > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 26 10:51:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqWv-000069-Qd; Mon, 26 Mar 2007 10:50:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqWv-000064-1Z for nsis@ietf.org; Mon, 26 Mar 2007 10:50:41 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqWs-0003wi-I1 for nsis@ietf.org; Mon, 26 Mar 2007 10:50:41 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2007 07:50:38 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2QEoblH023995; Mon, 26 Mar 2007 07:50:37 -0700 Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2QEoYwn011916; Mon, 26 Mar 2007 14:50:34 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] QSPEC: Pre-emption Date: Mon, 26 Mar 2007 10:50:27 -0400 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4168; t=1174920637; x=1175784637; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=3A=20Pre-emption |Sender:=20; bh=t37bObB/+CKc77doqzZHqGljOOotJ/92cnf7xJrNZKE=; b=KBcnj3LsNw3u7a7hrcWOJ+Ig+Jfg6nHo0fc2mNWKDEqxtS+YGpQHvnFaYcOWNQ1/7WwdjQ1O ErglcwUwmFgme1LKo0kvsvPXfhWTZgDm4FP3O9DawxxJE3lzFzHuIMoK; Authentication-Results: sj-dkim-6; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Jukka MJ Manner , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I'll note that what started this thread is in fact a protocol issue and not a local preemption algorithm issue. I was actually pointing this out to Jukka and some others in a hallway conversation and it stimulated them to do some thinking on the subject. It turns out that purely local preemption algorithms interact quite badly under heavy load and cause considerable "collateral damage" whereby many more flows get preempted than the number required to recover the resources needed to admit the higher precedence flow. this can be particularly bad in a distaster management situation where many of the higher-precedence flows wind up not being fully established due to host overload or failures. We have observed this in real world deployments with RSVP. Cisco has a proprietary (and IPR encumbered) technique to overcome this. It uses an RSVP extension. We have no plans to introduce this into the IETF. I suspect there are other approaches that would not infringe, but nevertheless I want to be on record that I am NOT suggesting that the NSIS go in a particular direction here and later discover it runs up against Cisco IPR. If this happens by accident, I will of course inform the WG of the possible overlap. If you want a more detailed description of the failure scenarios, I'll be happy to go into more depth without discussing solutions. I think Jukka et. al. understood them quite well after our conversation though. One last "shot across the bow". I believe this is yet one more example of why priority/preemption, along with some other abstractions, really ought to have been a separate "sub-layer" in NSIS between GIST and the various signaling applications. Why should NSLP, NAT-FW, and mobility all separately solve the state preemption problem? But you folks all know that's been my opinion for a very long time... Cheers, Dave. On Mar 26, 2007, at 9:14 AM, Hancock, Robert wrote: > hi, > > a very simple answer: > >> -----Original Message----- >> From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> Sent: 24 March 2007 18:36 >> To: NSIS Working Group >> Subject: [NSIS] QSPEC: Pre-emption >> >> >> We (at least Roland, Andrew, Georgios) have thought a bit >> more about the pre-emption, and how&where it should be >> described. Basically, it is a "problem" of QOSMs. The NSLP >> provides certain messages to inform of pre-emption, and who >> caused it (my recent proposal on the mailing list). >> >> But, how does a QNE choose a flow to be pre-empted in the >> first place is out of scope of the NSLP. Yet, it might be >> good to say a few words about how to choose the "right" flow >> to pre-empt to help QOSM designers. >> >> One simple idea we have talked about is that the QNE should >> try to choose a low(er) priority flow where the MRI is >> "close" (esp. the target IP) to the higher priority flow. >> This has the benefit that the pre-empted flow may share most >> of the path with the high priority flow. If the pre-empted >> flow has a random MRI, in case of heavy congestion, QNEs >> downstream may not see the same low(er) priority flow, and, >> thus, pre-empt other flows. >> Thus, in order to accommodate one high priority flow, the >> network may be killing N other flows. >> >> Do you think giving advise on pre-emption to QOSM designers >> is out of scope of the QSPEC Template? > > basically I would say no. At least any normative text will hit > endless debates about regulation and lawfulness. At most one > could point out the consequences of particular strategies, but > it would be preferable IMHO to refer to other documents. > (In other words, I assume that anything useful that can be > written on this topic in the IETF has already been written.) > > robert h. > >> >> Cheers, >> Jukka >> >> _______________________________________________ >> 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 nsis-bounces@ietf.org Mon Mar 26 14:12:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtff-0007EZ-7r; Mon, 26 Mar 2007 14:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtfe-0007EI-9E for nsis@ietf.org; Mon, 26 Mar 2007 14:11:54 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVtfc-0002xK-MQ for nsis@ietf.org; Mon, 26 Mar 2007 14:11:54 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 26 Mar 2007 21:11:51 +0300 id 0005FE9A.46080CE7.0000289E Date: Mon, 26 Mar 2007 21:11:51 +0300 (EEST) From: Jukka MJ Manner To: David R Oran Subject: Re: [NSIS] QSPEC: Pre-emption In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Yes, I think I understood the concepts relatively well. The problem is after all quite challenging - would be a fun exercise to figure out new ways to perform pre-emption with minimized collateral damage. In this respect, I was proposing to add certain rather simple mechanisms to the QoS NSLP to allow QoSM designers to built various pre-emption mechanisms. I don't want to define any specific approach in the NSLP spec, just enable certain functionality, like telling the reason for a tear-down event. This should not infringe any Cisco IPR (I hope) - I'll leave it up to QoSM designers that would want to implement pre-emption to figure out the right way to use NSLP messages. Thanks for the note, Dave. Jukka On Mon, 26 Mar 2007, David R Oran wrote: > I'll note that what started this thread is in fact a protocol issue and not a > local preemption algorithm issue. I was actually pointing this out to Jukka > and some others in a hallway conversation and it stimulated them to do some > thinking on the subject. > > It turns out that purely local preemption algorithms interact quite badly > under heavy load and cause considerable "collateral damage" whereby many more > flows get preempted than the number required to recover the resources needed > to admit the higher precedence flow. this can be particularly bad in a > distaster management situation where many of the higher-precedence flows wind > up not being fully established due to host overload or failures. We have > observed this in real world deployments with RSVP. > > Cisco has a proprietary (and IPR encumbered) technique to overcome this. It > uses an RSVP extension. We have no plans to introduce this into the IETF. I > suspect there are other approaches that would not infringe, but nevertheless > I want to be on record that I am NOT suggesting that the NSIS go in a > particular direction here and later discover it runs up against Cisco IPR. If > this happens by accident, I will of course inform the WG of the possible > overlap. > > If you want a more detailed description of the failure scenarios, I'll be > happy to go into more depth without discussing solutions. I think Jukka et. > al. understood them quite well after our conversation though. > > One last "shot across the bow". I believe this is yet one more example of why > priority/preemption, along with some other abstractions, really ought to have > been a separate "sub-layer" in NSIS between GIST and the various signaling > applications. Why should NSLP, NAT-FW, and mobility all separately solve the > state preemption problem? But you folks all know that's been my opinion for a > very long time... > > Cheers, Dave. > > On Mar 26, 2007, at 9:14 AM, Hancock, Robert wrote: > > >hi, > > > >a very simple answer: > > > > >-----Original Message----- > > >From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > >Sent: 24 March 2007 18:36 > > >To: NSIS Working Group > > >Subject: [NSIS] QSPEC: Pre-emption > > > > > > > > >We (at least Roland, Andrew, Georgios) have thought a bit > > >more about the pre-emption, and how&where it should be > > >described. Basically, it is a "problem" of QOSMs. The NSLP > > >provides certain messages to inform of pre-emption, and who > > >caused it (my recent proposal on the mailing list). > > > > > >But, how does a QNE choose a flow to be pre-empted in the > > >first place is out of scope of the NSLP. Yet, it might be > > >good to say a few words about how to choose the "right" flow > > >to pre-empt to help QOSM designers. > > > > > >One simple idea we have talked about is that the QNE should > > >try to choose a low(er) priority flow where the MRI is > > >"close" (esp. the target IP) to the higher priority flow. > > >This has the benefit that the pre-empted flow may share most > > >of the path with the high priority flow. If the pre-empted > > >flow has a random MRI, in case of heavy congestion, QNEs > > >downstream may not see the same low(er) priority flow, and, > > >thus, pre-empt other flows. > > >Thus, in order to accommodate one high priority flow, the > > >network may be killing N other flows. > > > > > >Do you think giving advise on pre-emption to QOSM designers > > >is out of scope of the QSPEC Template? > > > >basically I would say no. At least any normative text will hit > >endless debates about regulation and lawfulness. At most one > >could point out the consequences of particular strategies, but > >it would be preferable IMHO to refer to other documents. > >(In other words, I assume that anything useful that can be > >written on this topic in the IETF has already been written.) > > > >robert h. > > > > > > > >Cheers, > > >Jukka > > > > >>_______________________________________________ > > >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 nsis-bounces@ietf.org Tue Mar 27 04:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW71V-0004ea-5R; Tue, 27 Mar 2007 04:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW71T-0004eS-PP for nsis@ietf.org; Tue, 27 Mar 2007 04:27:19 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW71P-0001tX-7V for nsis@ietf.org; Tue, 27 Mar 2007 04:27:19 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l2R8Qaw1017753; Tue, 27 Mar 2007 10:27:05 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , "'David R Oran'" References: Subject: RE: [NSIS] QSPEC: Pre-emption Date: Tue, 27 Mar 2007 10:26:30 +0200 Message-ID: <000601c77049$a6866ea0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acdv0pb42Xnye3mDTAOmzYpUchmnjwAdvGpg X-Spam-Score: 0.539 () AWL,FVGT_s_OBFU_Q1,J_CHICKENPOX_35 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 27 Mar 2007 10:27:06 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: 'NSIS Working Group' , "'Hancock, Robert'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka I think that your proposal is a reasonable one! Best Regards, Georgios > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: maandag 26 maart 2007 20:12 > To: David R Oran > Cc: NSIS Working Group; Hancock,Robert > Subject: Re: [NSIS] QSPEC: Pre-emption > > > Yes, I think I understood the concepts relatively well. The > problem is after all quite challenging - would be a fun > exercise to figure out new ways to perform pre-emption with > minimized collateral damage. > > In this respect, I was proposing to add certain rather simple > mechanisms to the QoS NSLP to allow QoSM designers to built > various pre-emption mechanisms. > > I don't want to define any specific approach in the NSLP > spec, just enable certain functionality, like telling the > reason for a tear-down event. This should not infringe any > Cisco IPR (I hope) - I'll leave it up to QoSM designers that > would want to implement pre-emption to figure out the right > way to use NSLP messages. > > Thanks for the note, Dave. > > Jukka > > On Mon, 26 Mar 2007, David R Oran wrote: > > > I'll note that what started this thread is in fact a protocol issue > > and not a local preemption algorithm issue. I was actually pointing > > this out to Jukka and some others in a hallway conversation and it > > stimulated them to do some thinking on the subject. > > > > It turns out that purely local preemption algorithms interact quite > > badly under heavy load and cause considerable "collateral damage" > > whereby many more flows get preempted than the number required to > > recover the resources needed to admit the higher precedence > flow. this > > can be particularly bad in a distaster management situation > where many > > of the higher-precedence flows wind up not being fully > established due > > to host overload or failures. We have observed this in real > world deployments with RSVP. > > > > Cisco has a proprietary (and IPR encumbered) technique to overcome > > this. It uses an RSVP extension. We have no plans to introduce this > > into the IETF. I suspect there are other approaches that would not > > infringe, but nevertheless I want to be on record that I am NOT > > suggesting that the NSIS go in a particular direction here > and later > > discover it runs up against Cisco IPR. If this happens by > accident, I > > will of course inform the WG of the possible overlap. > > > > If you want a more detailed description of the failure > scenarios, I'll > > be happy to go into more depth without discussing > solutions. I think Jukka et. > > al. understood them quite well after our conversation though. > > > > One last "shot across the bow". I believe this is yet one > more example > > of why priority/preemption, along with some other > abstractions, really > > ought to have been a separate "sub-layer" in NSIS between > GIST and the > > various signaling applications. Why should NSLP, NAT-FW, > and mobility > > all separately solve the state preemption problem? But you > folks all > > know that's been my opinion for a very long time... > > > > Cheers, Dave. > > > > On Mar 26, 2007, at 9:14 AM, Hancock, Robert wrote: > > > > >hi, > > > > > >a very simple answer: > > > > > > >-----Original Message----- > > > >From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > >Sent: 24 March 2007 18:36 > > > >To: NSIS Working Group > > > >Subject: [NSIS] QSPEC: Pre-emption > > > > > > > > > > > >We (at least Roland, Andrew, Georgios) have thought a bit more > > > >about the pre-emption, and how&where it should be described. > > > >Basically, it is a "problem" of QOSMs. The NSLP provides certain > > > >messages to inform of pre-emption, and who caused it (my recent > > > >proposal on the mailing list). > > > > > > > >But, how does a QNE choose a flow to be pre-empted in the first > > > >place is out of scope of the NSLP. Yet, it might be good > to say a > > > >few words about how to choose the "right" flow to > pre-empt to help > > > >QOSM designers. > > > > > > > >One simple idea we have talked about is that the QNE > should try to > > > >choose a low(er) priority flow where the MRI is "close" > (esp. the > > > >target IP) to the higher priority flow. > > > >This has the benefit that the pre-empted flow may share > most of the > > > >path with the high priority flow. If the pre-empted flow has a > > > >random MRI, in case of heavy congestion, QNEs downstream may not > > > >see the same low(er) priority flow, and, thus, pre-empt other > > > >flows. > > > >Thus, in order to accommodate one high priority flow, > the network > > > >may be killing N other flows. > > > > > > > >Do you think giving advise on pre-emption to QOSM > designers is out > > > >of scope of the QSPEC Template? > > > > > >basically I would say no. At least any normative text will hit > > >endless debates about regulation and lawfulness. At most one could > > >point out the consequences of particular strategies, but > it would be > > >preferable IMHO to refer to other documents. > > >(In other words, I assume that anything useful that can be > written on > > >this topic in the IETF has already been written.) > > > > > >robert h. > > > > > > > > > > >Cheers, > > > >Jukka > > > > > > >>_______________________________________________ > > > >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 nsis-bounces@ietf.org Wed Mar 28 04:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWT6t-0003BR-E2; Wed, 28 Mar 2007 04:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWT6r-00037Y-Ak for nsis@ietf.org; Wed, 28 Mar 2007 04:02:21 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWT3I-0000CR-Tu for nsis@ietf.org; Wed, 28 Mar 2007 03:58:49 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HWT3G-0005M8-3n; Wed, 28 Mar 2007 09:58:40 +0200 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1HWT3F-0007Ip-Qf; Wed, 28 Mar 2007 09:58:37 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 49EDE2FC013; Wed, 28 Mar 2007 09:58:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HWT3E-0001oy-Rn; Wed, 28 Mar 2007 09:58:36 +0200 Message-ID: <460A202C.8060300@tm.uka.de> Date: Wed, 28 Mar 2007 09:58:36 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] GIST: NSLP data in QUERY References: <460395CF.1010405@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Jukka MJ Manner wrote: > On Fri, 23 Mar 2007, Roland Bless wrote: >> Jukka MJ Manner wrote: >>> I've been thinking about how GIST uses the Q-mode. If an NSLP asks for >>> reliable or secure mode, GIST will send the query without NSLP payload. >>> Yet, would it be possible to still allow an NSLP to include information >>> carried in the query. >> If the semantics for this data is different, yes. > > It can be different, or copies of certain NSLP objects. GIST doesn't need > to care anyway, it's just a feature of NSLPs. I meant the transport semantics, e.g. reliable/unreliable transport of this NSLP data. So the NSLP would transfer a first data chunk unreliably/unsecured in the Query and after the handshake then reliable... So this first data chunk has different semantics within NSLP than the other NSLP data that follow and this must be made explicitly visible at the API. That was my point. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 28 05:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWUVX-0000Ho-RT; Wed, 28 Mar 2007 05:31:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWUVV-0000Hf-8r for nsis@ietf.org; Wed, 28 Mar 2007 05:31:53 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWUVS-0006sI-Sz for nsis@ietf.org; Wed, 28 Mar 2007 05:31:53 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 28 Mar 2007 12:31:45 +0300 id 0005FEDD.460A3601.000054ED Date: Wed, 28 Mar 2007 12:31:45 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] GIST: NSLP data in QUERY In-Reply-To: <460A202C.8060300@tm.uka.de> Message-ID: References: <460395CF.1010405@tm.uka.de> <460A202C.8060300@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: NSIS Working Group , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Yes, good point. Yet... on the other hand, if you don't get a QUERY through, then you won't get to set up an MA anyway, so basically the extra data is also sent in a reliable way. But it is not secured. Jukka On Wed, 28 Mar 2007, Roland Bless wrote: > Hi, > > Jukka MJ Manner wrote: > > On Fri, 23 Mar 2007, Roland Bless wrote: > >> Jukka MJ Manner wrote: > >>> I've been thinking about how GIST uses the Q-mode. If an NSLP asks for > >>> reliable or secure mode, GIST will send the query without NSLP payload. > >>> Yet, would it be possible to still allow an NSLP to include information > >>> carried in the query. > >> If the semantics for this data is different, yes. > > > > It can be different, or copies of certain NSLP objects. GIST doesn't need > > to care anyway, it's just a feature of NSLPs. > > I meant the transport semantics, e.g. reliable/unreliable transport > of this NSLP data. So the NSLP would transfer a first data chunk > unreliably/unsecured in the Query and after the handshake then > reliable... > So this first data chunk has different semantics within NSLP than > the other NSLP data that follow and this must be made explicitly > visible at the API. That was my point. > > Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 28 08:00:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWWoX-0002x9-MF; Wed, 28 Mar 2007 07:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWWoW-0002x4-Pp for nsis@ietf.org; Wed, 28 Mar 2007 07:59:40 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWWoQ-000108-9K for nsis@ietf.org; Wed, 28 Mar 2007 07:59:40 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2SBxOLv019109; Wed, 28 Mar 2007 12:59:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST: NSLP data in QUERY Date: Wed, 28 Mar 2007 12:59:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST: NSLP data in QUERY Thread-Index: AcdxG/M4/Mm9HNtaQy+h4HRMHDFCKAAB4Vfg References: <460395CF.1010405@tm.uka.de> <460A202C.8060300@tm.uka.de> From: "Hancock, Robert" To: "Jukka MJ Manner" , "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, it's good to keep working through this, because there are several subtleties. but i think the current design and API handles nearly=20 everything i have seen mentioned so far. the main points are more NSLP=20 (or, in fact, signalling application) design issues rather than GIST=20 issues. specifically: - a signalling application has to define the algorithm that it uses when deciding whether to peer. if the algorithm is 'always true' then there is nothing else to do. if the algorithm depends on information beyond the information in the MRI/SID/NSLPID then this information has to be defined as part of the NSLP specification. - almost by definition, this information cannot need security=20 protection from GIST, because that is only possible after peering. (if security protection is needed, that would have to be done in=20 the NLSP itself; or else one needs something much more complex, probably involving multiple NSLPIDs.) - so far as reliability is concerned, again this is more a matter of NSLP design. if one is probing for a peer, the response from the peer indicates that the original message was delivered. if you get no response within some timeout, there is no peer to respond. the NSLP needs to make sure that it doesn't retransmit within the validity time it provides with the message (since the GIST level can retransmit Queries during this period). the more important thing to note is that the NSLP payload can be delivered multiple times, so it needs to be idempotent. - the API already provides the hooks to express reliability and security requirements. so, for a probing message, you just leave these unset. - and the API also allows the NSLP to be aware of the routing status: at the querying node the fact that there is no SII means that no routing state exists; at the responding node, the fact that this is done with the routing state check flag set in RecvMessage means that this decision is being made. - another issue is how the NSLP influences the refresh of this conditional peering. GIST handles making sure that the routing state as defined by the MRM is up to date, but if there is NSLP-dependent information that should be used in the peering decision that will not be taken care of. OTOH, the timescales over which MRM-related state and NSLP-related state might need to be checked can be quite independent, so I don't think there is a need to extend the definition of normal GIST routing state refresh to cover this. if the NSLP really does want to check that the NSLP-dependent peering is still valid, it can always force a refresh with the InvalidateState call. This will start a=20 refresh at some point in the future. - what is slightly messy is that the NSLP would have to do Invalidate and then SendMessage to provide the NSLP data for the Query payload, so there are API-internal race conditions. One could regard this as just an implementation issue; another possibility would be to extend Invalidate with the option to provide an NSLP payload and associated fields (excluding transfer attributes, since they must be null). i created http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213 to cover this specific point. r. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: 28 March 2007 10:32 > To: Roland Bless > Cc: NSIS Working Group; Hancock, Robert > Subject: Re: [NSIS] GIST: NSLP data in QUERY >=20 >=20 > Hi, > Yes, good point. >=20 > Yet... on the other hand, if you don't get a QUERY through,=20 > then you won't get to set up an MA anyway, so basically the=20 > extra data is also sent in a reliable way. But it is not secured. >=20 > Jukka >=20 > On Wed, 28 Mar 2007, Roland Bless wrote: >=20 > > Hi, > >=20 > > Jukka MJ Manner wrote: > > > On Fri, 23 Mar 2007, Roland Bless wrote: > > >> Jukka MJ Manner wrote: > > >>> I've been thinking about how GIST uses the Q-mode. If=20 > an NSLP asks=20 > > >>> for reliable or secure mode, GIST will send the query=20 > without NSLP payload. > > >>> Yet, would it be possible to still allow an NSLP to include=20 > > >>> information carried in the query. > > >> If the semantics for this data is different, yes. > > >=20 > > > It can be different, or copies of certain NSLP objects.=20 > GIST doesn't=20 > > > need to care anyway, it's just a feature of NSLPs. > >=20 > > I meant the transport semantics, e.g. reliable/unreliable=20 > transport of=20 > > this NSLP data. So the NSLP would transfer a first data chunk=20 > > unreliably/unsecured in the Query and after the handshake then=20 > > reliable... > > So this first data chunk has different semantics within=20 > NSLP than the=20 > > other NSLP data that follow and this must be made=20 > explicitly visible=20 > > at the API. That was my point. > >=20 > > Regards, > > Roland > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 28 09:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYBM-0000VY-45; Wed, 28 Mar 2007 09:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYBK-0000NL-Bx for nsis@ietf.org; Wed, 28 Mar 2007 09:27:18 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWYBH-0001gr-TE for nsis@ietf.org; Wed, 28 Mar 2007 09:27:18 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2SDR4k1006124; Wed, 28 Mar 2007 14:27:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST: Comment to 7.1.4 Date: Wed, 28 Mar 2007 14:27:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST: Comment to 7.1.4 Thread-Index: AcdrqyKH2ZLHezBsRT6bSzdXGnIoHQFkZPLQ References: From: "Hancock, Robert" To: "Jukka MJ Manner" , "NSIS Working Group" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org created=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue214 i think this is a good clarification. it would help for the other mobility people to read this section also. robert h.=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: 21 March 2007 11:20 > To: NSIS Working Group > Subject: [NSIS] GIST: Comment to 7.1.4 >=20 >=20 > As requested by Rob, I propose to add the following at the=20 > end of the first paragraph. It would help highlight a bit=20 > more what mobility can cause. >=20 > Change from: >=20 > "This will appear to GIST as a route flap; route flapping can=20 > also be caused by problems in the basic network connectivity=20 > or routing protocol operation." >=20 > To: >=20 > "This will appear to GIST as a route flap; route flapping can=20 > also be caused by problems in the basic network connectivity=20 > or routing protocol operation, for example, a mobile node may=20 > be switching back and forth between two links, or may appear=20 > to have disappeared even though it is still present." >=20 >=20 > Jukka >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 28 10:20:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYzm-0004SK-Qu; Wed, 28 Mar 2007 10:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYzl-0004SD-6t for nsis@ietf.org; Wed, 28 Mar 2007 10:19:25 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWYzj-0003VE-NH for nsis@ietf.org; Wed, 28 Mar 2007 10:19:25 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2SEJELs018850 for ; Wed, 28 Mar 2007 15:19:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Wed, 28 Mar 2007 15:19:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST Q-Mode Encapsulation Magic Number Thread-Index: AcdmQvRZZ1epjTtXQvSz70YMrz/wCgADoVTwArxsXAA= References: <45F19C6A.5060108@christian-dickmann.de><45F802E7.2090000@tm.uka.de> From: "Hancock, Robert" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi (to myself and others), we had a few conversations about this in Prague. I'm reluctantly starting to think that it might be better to use the magic number on all D-mode messages. the main issue is NAT handling. in a NAT-free world, I still find it reasonable to treat the GIST port specially (I think in our implementation it already has to be treated specially for some RAO-related reasons, but don't quote me on that ...). however, i know that some people use the GIST port as the source for Queries. (you already have to use it as the source for Responses.) if you source Queries from the GIST port and you are behind a NAT, then the Responder will not know that what it sends back is going to go to the GIST port and so would not insert the magic number. we could partly address this by being more prescriptive about what ports get used when, but this seems to be adding rather than removing complexity, and I expect there would still be cases where port re-writing could get us into trouble. OTOH, the fact that the encapsulation is UDP is pretty well invariant. for the case where an end system receives a GIST message without the magic number, I am still unclear on whether to generate an error or silently discard. robert h. > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: 14 March 2007 16:02 > To: Roland Bless > Cc: nsis@ietf.org > Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number >=20 > hi all,=20 >=20 > > -----Original Message----- > > From: Roland Bless [mailto:bless@tm.uka.de] > > Sent: 14 March 2007 14:13 > > To: Hancock, Robert > > Cc: Christian Dickmann; nsis@ietf.org > > Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number > >=20 > > Hi Robert, > >=20 > > Hancock, Robert wrote: > > > i think it is really a conceptual thing: i see the magic=20 > number as=20 > > > part of the encapsulation, just like the RAO and the UDP=20 > header and=20 > > > port number, since that is the purpose it serves (to demultiplex=20 > > > packets, not to carry information). and to put it in=20 > every message=20 > > > would indeed be a waste of bytes, which you could never=20 > go back on=20 > > > (since the magic number comes before any version information). > > >=20 > > > another way of putting it: we want the magic number to be=20 > something=20 > > > that is checked to find out whether something is a GIST > > packet, rather > > > than part of parsing the GIST packet. making it part of=20 > the common=20 > > > header would blur that distinction. > >=20 > > I would agree on that. I see it as part of the encapsulation, too. > >=20 > > > however, it may be that in practice, what you suggest would be=20 > > > simpler. i would be interested to hear what other people > > think about > > > that. > >=20 > > Hmm. I don't like the idea of carrying around that magic number=20 > > always... > >=20 > > > one specific point: we need to ensure that GIST packets=20 > without the=20 > > > magic number go to a different UDP port, else you could not > > know how > > > to receive them properly. that may not be clear enough in > > the spec at > > > the moment. > >=20 > > That seems to be important and the devil lies in the details... > > For example: Our implementation currently uses the=20 > well-known port as=20 > > source port for Q-mode packets since it is listening there anyways. > > However, I assume that responses will not carry a magic number and=20 > > thus we must change the Q-mode source port to something different... >=20 > i think this is one thing where we may need to update the=20 > current specification text. if the confirm goes back in=20 > D-mode, there is no mechanism in the protocol to indicate a=20 > port to send it to other than the GIST port; so, in other=20 > words, we really should say that the magic number is required=20 > for packets to the GIST port. (note that all Q-mode packets=20 > go to the GIST port, but not vice versa.) >=20 > the other point is that you could receive a packet at the=20 > GIST port with the incorrect magic number. At a router, this=20 > would be an indication that this was not a GIST packet (and=20 > it would just get forwarded); but at a host, it is a=20 > malformed packet. do we need an error message for that? or=20 > should we silently discard it? >=20 > robert h. >=20 > >=20 > > Regards, > > Roland > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 28 15:51:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWeAd-0000zW-7J; Wed, 28 Mar 2007 15:51:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWeAD-00009P-Cd; Wed, 28 Mar 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWeAC-0007js-RZ; Wed, 28 Mar 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A82B22ACA3; Wed, 28 Mar 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HWe9i-0004a7-E0; Wed, 28 Mar 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Mar 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-16.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-16.txt Pages : 55 Date : 2007-3-28 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-qspec-16.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-qspec-16.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: <2007-3-28121250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-28121250.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Mar 29 23:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX7i7-0007Y9-Gu; Thu, 29 Mar 2007 23:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX7i6-0007Y0-IW for nsis@ietf.org; Thu, 29 Mar 2007 23:23:30 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX7i5-0005MF-7W for nsis@ietf.org; Thu, 29 Mar 2007 23:23:30 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2U3NJt8013645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Mar 2007 23:23:24 -0400 (EDT) In-Reply-To: References: <45F19C6A.5060108@christian-dickmann.de><45F802E7.2090000@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Thu, 29 Mar 2007 23:23:17 -0400 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I'm all for consistency. Besides a few extra bits, is there any disadvantage in including the magic number? On Mar 28, 2007, at 10:19 AM, Hancock, Robert wrote: > hi (to myself and others), > > we had a few conversations about this in Prague. I'm reluctantly > starting to think that it might be better to use the magic number > on all D-mode messages. > > the main issue is NAT handling. in a NAT-free world, I still find > it reasonable to treat the GIST port specially (I think in our > implementation it already has to be treated specially for some > RAO-related reasons, but don't quote me on that ...). > > however, i know that some people use the GIST port as the source > for Queries. (you already have to use it as the source for Responses.) > if you source Queries from the GIST port and you are behind a NAT, > then the Responder will not know that what it sends back is going > to go to the GIST port and so would not insert the magic number. > > we could partly address this by being more prescriptive about > what ports get used when, but this seems to be adding rather than > removing complexity, and I expect there would still be cases where > port re-writing could get us into trouble. OTOH, the fact that the > encapsulation is UDP is pretty well invariant. > > for the case where an end system receives a GIST message without > the magic number, I am still unclear on whether to generate an > error or silently discard. > > robert h. > >> -----Original Message----- >> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >> Sent: 14 March 2007 16:02 >> To: Roland Bless >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number >> >> hi all, >> >>> -----Original Message----- >>> From: Roland Bless [mailto:bless@tm.uka.de] >>> Sent: 14 March 2007 14:13 >>> To: Hancock, Robert >>> Cc: Christian Dickmann; nsis@ietf.org >>> Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number >>> >>> Hi Robert, >>> >>> Hancock, Robert wrote: >>>> i think it is really a conceptual thing: i see the magic >> number as >>>> part of the encapsulation, just like the RAO and the UDP >> header and >>>> port number, since that is the purpose it serves (to demultiplex >>>> packets, not to carry information). and to put it in >> every message >>>> would indeed be a waste of bytes, which you could never >> go back on >>>> (since the magic number comes before any version information). >>>> >>>> another way of putting it: we want the magic number to be >> something >>>> that is checked to find out whether something is a GIST >>> packet, rather >>>> than part of parsing the GIST packet. making it part of >> the common >>>> header would blur that distinction. >>> >>> I would agree on that. I see it as part of the encapsulation, too. >>> >>>> however, it may be that in practice, what you suggest would be >>>> simpler. i would be interested to hear what other people >>> think about >>>> that. >>> >>> Hmm. I don't like the idea of carrying around that magic number >>> always... >>> >>>> one specific point: we need to ensure that GIST packets >> without the >>>> magic number go to a different UDP port, else you could not >>> know how >>>> to receive them properly. that may not be clear enough in >>> the spec at >>>> the moment. >>> >>> That seems to be important and the devil lies in the details... >>> For example: Our implementation currently uses the >> well-known port as >>> source port for Q-mode packets since it is listening there anyways. >>> However, I assume that responses will not carry a magic number and >>> thus we must change the Q-mode source port to something different... >> >> i think this is one thing where we may need to update the >> current specification text. if the confirm goes back in >> D-mode, there is no mechanism in the protocol to indicate a >> port to send it to other than the GIST port; so, in other >> words, we really should say that the magic number is required >> for packets to the GIST port. (note that all Q-mode packets >> go to the GIST port, but not vice versa.) >> >> the other point is that you could receive a packet at the >> GIST port with the incorrect magic number. At a router, this >> would be an indication that this was not a GIST packet (and >> it would just get forwarded); but at a host, it is a >> malformed packet. do we need an error message for that? or >> should we silently discard it? >> >> robert h. >> >>> >>> Regards, >>> Roland >>> >> >> _______________________________________________ >> 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 nsis-bounces@ietf.org Fri Mar 30 05:03:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0m-0001rp-Dq; Fri, 30 Mar 2007 05:03:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0k-0001jL-Hk for nsis@ietf.org; Fri, 30 Mar 2007 05:03:06 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXD0i-0000Bw-UU for nsis@ietf.org; Fri, 30 Mar 2007 05:03:06 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7280213CF81; Fri, 30 Mar 2007 11:03:04 +0200 (CEST) In-Reply-To: References: <45F19C6A.5060108@christian-dickmann.de><45F802E7.2090000@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Fri, 30 Mar 2007 11:03:03 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert and all, Am 28.03.2007 um 16:19 schrieb Hancock, Robert: > hi (to myself and others), > > we had a few conversations about this in Prague. I'm reluctantly > starting to think that it might be better to use the magic number > on all D-mode messages. > > the main issue is NAT handling. in a NAT-free world, I still find > it reasonable to treat the GIST port specially (I think in our > implementation it already has to be treated specially for some > RAO-related reasons, but don't quote me on that ...). Putting the magic number always in would be consistent and GIST would be prepared for whatever it encounters en-route :-) > > however, i know that some people use the GIST port as the source > for Queries. (you already have to use it as the source for Responses.) > if you source Queries from the GIST port and you are behind a NAT, > then the Responder will not know that what it sends back is going > to go to the GIST port and so would not insert the magic number. It is always a bad idea to rely on a specific transport layer port, as for NATing reasons. GIST should allow to take any source port for Queries. I know that some implementations didn't work properly when using a different source port as the standard source port for GIST. I.e., these implementations were always replying to the standard GIST source port even though the actual source port was random. Apparently, this made some unnecessary troubles. > > we could partly address this by being more prescriptive about > what ports get used when, but this seems to be adding rather than > removing complexity, and I expect there would still be cases where > port re-writing could get us into trouble. OTOH, the fact that the > encapsulation is UDP is pretty well invariant. See above. > > for the case where an end system receives a GIST message without > the magic number, I am still unclear on whether to generate an > error or silently discard. IFrom nsis-bounces@ietf.org Fri Mar 30 05:03:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0m-0001rp-Dq; Fri, 30 Mar 2007 05:03:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0k-0001jL-Hk for nsis@ietf.org; Fri, 30 Mar 2007 05:03:06 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXD0i-0000Bw-UU for nsis@ietf.org; Fri, 30 Mar 2007 05:03:06 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7280213CF81; Fri, 30 Mar 2007 11:03:04 +0200 (CEST) In-Reply-To: References: <45F19C6A.5060108@christian-dickmann.de><45F802E7.2090000@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Fri, 30 Mar 2007 11:03:03 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert and all, Am 28.03.2007 um 16:19 schrieb Hancock, Robert: > hi (to myself and others), > > we had a few conversations about this in Prague. I'm reluctantly > starting to think that it might be better to use the magic number > on all D-mode messages. > > the main issue is NAT handling. in a NAT-free world, I still find > it reasonable to treat the GIST port specially (I think in our > implementation it already has to be treated specially for some > RAO-related reasons, but don't quote me on that ...). Putting the magic number always in would be consistent and GIST would be prepared for whatever it encounters en-route :-) > > however, i know that some people use the GIST port as the source > for Queries. (you already have to use it as the source for Responses.) > if you source Queries from the GIST port and you are behind a NAT, > then the Responder will not know that what it sends back is going > to go to the GIST port and so would not insert the magic number. It is always a bad idea to rely on a specific transport layer port, as for NATing reasons. GIST should allow to take any source port for Queries. I know that some implementations didn't work properly when using a different source port as the standard source port for GIST. I.e., these implementations were always replying to the standard GIST source port even though the actual source port was random. Apparently, this made some unnecessary troubles. > > we could partly address this by being more prescriptive about > what ports get used when, but this seems to be adding rather than > removing complexity, and I expect there would still be cases where > port re-writing could get us into trouble. OTOH, the fact that the > encapsulation is UDP is pretty well invariant. See above. > > for the case where an end system receives a GIST message without > the magic number, I am still unclear on whether to generate an > error or silently discard. I tend so say "send an error" message, given that the magic number MUST be present anyway. Martin > > robert h. > >> -----Original Message----- >> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >> Sent: 14 March 2007 16:02 >> To: Roland Bless >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number >> >> hi all, >> >>> -----Original Message----- >>> From: Roland Bless [mailto:bless@tm.uka.de] >>> Sent: 14 March 2007 14:13 >>> To: Hancock, Robert >>> Cc: Christian Dickmann; nsis@ietf.org >>> Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number >>> >>> Hi Robert, >>> >>> Hancock, Robert wrote: >>>> i think it is really a conceptual thing: i see the magic >> number as >>>> part of the encapsulation, just like the RAO and the UDP >> header and >>>> port number, since that is the purpose it serves (to demultiplex >>>> packets, not to carry information). and to put it in >> every message >>>> would indeed be a waste of bytes, which you could never >> go back on >>>> (since the magic number comes before any version information). >>>> >>>> another way of putting it: we want the magic number to be >> something >>>> that is checked to find out whether something is a GIST >>> packet, rather >>>> than part of parsing the GIST packet. making it part of >> the common >>>> header would blur that distinction. >>> >>> I would agree on that. I see it as part of the encapsulation, too. >>> >>>> however, it may be that in practice, what you suggest would be >>>> simpler. i would be interested to hear what other people >>> think about >>>> that. >>> >>> Hmm. I don't like the idea of carrying around that magic number >>> always... >>> >>>> one specific point: we need to ensure that GIST packets >> without the >>>> magic number go to a different UDP port, else you could not >>> know how >>>> to receive them properly. that may not be clear enough in >>> the spec at >>>> the moment. >>> >>> That seems to be important and the devil lies in the details... >>> For example: Our implementation currently uses the >> well-known port as >>> source port for Q-mode packets since it is listening there anyways. >>> However, I assume that responses will not carry a magic number and >>> thus we must change the Q-mode source port to something different... >> >> i think this is one thing where we may need to update the >> current specification text. if the confirm goes back in >> D-mode, there is no mechanism in the protocol to indicate a >> port to send it to other than the GIST port; so, in other >> words, we really should say that the magic number is required >> for packets to the GIST port. (note that all Q-mode packets >> go to the GIST port, but not vice versa.) >> >> the other point is that you could receive a packet at the >> GIST port with the incorrect magic number. At a router, this >> would be an indication that this was not a GIST packet (and >> it would just get forwarded); but at a host, it is a >> malformed packet. do we need an error message for that? or >> should we silently discard it? >> >> robert h. >> >>> >>> Regards, >>> Roland >>> >> >> _______________________________________________ >> 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 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 30 05:03:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0n-0001yY-OM; Fri, 30 Mar 2007 05:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0n-0001vK-59 for nsis@ietf.org; Fri, 30 Mar 2007 05:03:09 -0400 Received: tend so say "send an error" message, given that the magic number MUST be present anyway. Martin > > robert h. > >> -----Original Message----- >> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >> Sent: 14 March 2007 16:02 >> To: Roland Bless >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number >> >> hi all, >> >>> -----Original Message----- >>> From: Roland Bless [mailto:bless@tm.uka.de] >>> Sent: 14 March 2007 14:13 >>> To: Hancock, Robert >>> Cc: Christian Dickmann; nsis@ietf.org >>> Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number >>> >>> Hi Robert, >>> >>> Hancock, Robert wrote: >>>> i think it is really a conceptual thing: i see the magic >> number as >>>> part of the encapsulation, just like the RAO and the UDP >> header and >>>> port number, since that is the purpose it serves (to demultiplex >>>> packets, not to carry information). and to put it in >> every message >>>> would indeed be a waste of bytes, which you could never >> go back on >>>> (since the magic number comes before any version information). >>>> >>>> another way of putting it: we want the magic number to be >> something >>>> that is checked to find out whether something is a GIST >>> packet, rather >>>> than part of parsing the GIST packet. making it part of >> the common >>>> header would blur that distinction. >>> >>> I would agree on that. I see it as part of the encapsulation, too. >>> >>>> however, it may be that in practice, what you suggest would be >>>> simpler. i would be interested to hear what other people >>> think about >>>> that. >>> >>> Hmm. I don't like the idea of carrying around that magic number >>> always... >>> >>>> one specific point: we need to ensure that GIST packets >> without the >>>> magic number go to a different UDP port, else you could not >>> know how >>>> to receive them properly. that may not be clear enough in >>> the spec at >>>> the moment. >>> >>> That seems to be important and the devil lies in the details... >>> For example: Our implementation currently uses the >> well-known port as >>> source port for Q-mode packets since it is listening there anyways. >>> However, I assume that responses will not carry a magic number and >>> thus we must change the Q-mode source port to something different... >> >> i think this is one thing where we may need to update the >> current specification text. if the confirm goes back in >> D-mode, there is no mechanism in the protocol to indicate a >> port to send it to other than the GIST port; so, in other >> words, we really should say that the magic number is required >> for packets to the GIST port. (note that all Q-mode packets >> go to the GIST port, but not vice versa.) >> >> the other point is that you could receive a packet at the >> GIST port with the incorrect magic number. At a router, this >> would be an indication that this was not a GIST packet (and >> it would just get forwarded); but at a host, it is a >> malformed packet. do we need an error message for that? or >> should we silently discard it? >> >> robert h. >> >>> >>> Regards, >>> Roland >>> >> >> _______________________________________________ >> 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 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 30 05:03:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0n-0001yY-OM; Fri, 30 Mar 2007 05:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0n-0001vK-59 for nsis@ietf.org; Fri, 30 Mar 2007 05:03:09 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXD0l-0000C4-Sa for nsis@ietf.org; Fri, 30 Mar 2007 05:03:09 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 72DF613CF82 for ; Fri, 30 Mar 2007 11:03:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <636BD0D5-AB09-4BA8-A25F-BD6E29CE298D@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Fri, 30 Mar 2007 11:03:07 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] Away for vacation April 4th to April 15th X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Just to let you know: I will be on vacation from April 4th to April 15th. Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXD0l-0000C4-Sa for nsis@ietf.org; Fri, 30 Mar 2007 05:03:09 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 72DF613CF82 for ; Fri, 30 Mar 2007 11:03:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <636BD0D5-AB09-4BA8-A25F-BD6E29CE298D@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Fri, 30 Mar 2007 11:03:07 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] Away for vacation April 4th to April 15th X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Just to let you know: I will be on vacation from April 4th to April 15th. Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 30 05:17:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXDEE-0003L1-3A; Fri, 30 Mar 2007 05:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXDED-0003Kw-A7 for nsis@ietf.org; Fri, 30 Mar 2007 05:17:01 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXDEB-0002G9-QY for nsis@ietf.org; Fri, 30 Mar 2007 05:17:01 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2U9G1n4001949; Fri, 30 Mar 2007 10:16:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Fri, 30 Mar 2007 10:16:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST Q-Mode Encapsulation Magic Number Thread-Index: AcdyetMEwB2KlAWnT4Gce4d8y5JwnAAMM8sg References: <45F19C6A.5060108@christian-dickmann.de><45F802E7.2090000@tm.uka.de> From: "Hancock, Robert" To: "Henning Schulzrinne" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi,=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: 30 March 2007 04:23 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number >=20 > I'm all for consistency. Besides a few extra bits, is there=20 > any disadvantage in including the magic number? by now, it's just the bits. conceptually, there is a big difference between Q- and 'normal'=20 D-mode encapsulations. but the difference is only easy to detect at the sender, and can be hard to detect at the receiver,=20 especially when it is an endpoint.=20 the Postel principle seems to apply here. robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 30 09:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGhY-0001sO-Kt; Fri, 30 Mar 2007 08:59:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGhW-0001sH-Ov for nsis@ietf.org; Fri, 30 Mar 2007 08:59:30 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXGhV-0007Ym-By for nsis@ietf.org; Fri, 30 Mar 2007 08:59:30 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2UCxN3I025998 for ; Fri, 30 Mar 2007 15:59:27 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 15:59:15 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 07:59:09 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2007 07:59:07 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F61F338@daebe103.NOE.Nokia.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F61F32F@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RMD WGLC - no comments Thread-Index: AcdyynpmXAufqx1pSkOvXJo6a/If+QAALJ2w References: <071568CA7B789D4AA170CEF8C9613B4F61F32F@daebe103.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 30 Mar 2007 12:59:09.0794 (UTC) FILETIME=[35167420:01C772CB] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070330155927-656FABB0-776C11CA/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] RMD WGLC - no comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Noone has commented about the RMD document during the WGLC. Does this mean everyone is OK with the current document and feel it accurately reflects WG concensus? Or does it mean noone has read it, and the interest level is low from the WG?=20 Could people who have read the document please send a mail saying so? For people who have an opinion, please comment. I need this information before I can send this forward to the IESG. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis