From nsis-bounces@ietf.org Wed Mar 01 10:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESs7-0000G8-9R; Wed, 01 Mar 2006 10:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESs5-00006S-SA for nsis@ietf.org; Wed, 01 Mar 2006 10:04:09 -0500 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.encs.concordia.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESs4-0000oR-Kl for nsis@ietf.org; Wed, 01 Mar 2006 10:04:09 -0500 Received: from localhost (nul-web@tact-96.encs.concordia.ca [132.205.96.48]) by perseverance.encs.concordia.ca (8.12.11/8.12.11) with ESMTP id k21F47cp003337 for ; Wed, 1 Mar 2006 10:04:07 -0500 X-Received-HTTP: from pavlov.encs.concordia.ca (pavlov.encs.concordia.ca [132.205.95.47]) by mail.encs.concordia.ca (Horde MIME library) with HTTP; Wed, 01 Mar 2006 10:04:07 -0500 Message-ID: <20060301100407.t8o58e8ulfwocswo@mail.encs.concordia.ca> Date: Wed, 01 Mar 2006 10:04:07 -0500 From: Bo Gao To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Scanned-By: MIMEDefang 2.43 on perseverance.encs.concordia.ca at 2006/03/01 10:04:07 EST X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [NSIS] A question about timer 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 Hello, I am a student of a Canadian University and trying to implement GIST right now. We are using Linux and C/C++. We know there are several timers in GIST like state timer and refresh timer and retransmission timer, which we must take care of. I checked our Linux(Fedora Core) system in our university and found there is a timer_create system call supported in our Linux. Also we know that when the timer expires, it can send a signal. We am planing to use only one Signal Handler for all of the timers. In the Signal Handler, we are going to distinguish different signals and write something to a local pipe or fifo. So we can treat the local pipe or fifo as a member of a fdset, which should includes the RAW socket and all other sockets associated with Message Associations. So we can use select() in our main thread to detect all of messages(GIST message, timers). Can anybody give some advices and suggestions as we are still in design phase? Also the problem right now is there seems to be only two kinds of signals(USRSIG1, USRSIG2) we can use. But certainly,we have more than two types of timers. Is it possible we can use something else rather than signal number to distinguish different timers? Any comment will be very helpful. Sincerely, Bo GaoE-mail: gao_b@cs.concordia.ca Computer Science Dept, Concordia University, Montreal _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 01 10:04:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESso-0002Of-TB; Wed, 01 Mar 2006 10:04:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESsl-0002DT-Sg for nsis@ietf.org; Wed, 01 Mar 2006 10:04:52 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESsh-0000rf-4o for nsis@ietf.org; Wed, 01 Mar 2006 10:04:51 -0500 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IVG00KGXF7XQB@mailout1.samsung.com> for nsis@ietf.org; Thu, 02 Mar 2006 00:04:45 +0900 (KST) Received: from LocalHost ([75.2.91.249]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IVG0079ZF7WO3@mmp1.samsung.com> for nsis@ietf.org; Thu, 02 Mar 2006 00:04:45 +0900 (KST) Date: Thu, 02 Mar 2006 00:04:37 +0900 From: Sung-Hyuck Lee Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft To: Shivanajay Marwaha , nsis@ietf.org Message-id: <001e01c63d41$79995ba0$f95b024b@LocalHost> Organization: SAIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5F09D220B62F79418461A978CA0921BDB240F4@pslexc01.psl.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Pek Yew Tan 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 Hello Shivanajay, ----- Original Message ----- From: "Shivanajay Marwaha" >> > Dear Seong-Ho, >> > >> >Thanks for your reply. Regarding your question on CRN >> >operation/discovery failure, we are actually referring to >> the mobility >> >scenario when multiple interfaces are used for one session >> (e.g. load >> >balancing as indicated in section 5.2.5 of the mobility >> applicability >> >draft). Detailed description of the issue is as >> > following: >> > >> > As described in Section 5.2.5, 2nd paragraph of the mobility draft, >> > the MN is using two paths for the same session (i.e. Path 1 >> and Path >> > 2). In this case, as suggested by section 5.2.5 of the >> mobility draft, >> > same Session ID with different Flow IDs will be used for >> the two paths. >> > >> > When one of these paths (Path 2) experiences a mobiity event, e.g. >> > one of the multiple interfaces of the MN handovers to >> another network, >> > a new path is resulted, i.e. Path 3. Yet, NSIS will use the same >> > Session ID with a new Flow ID for this path. Therefore, two >> types of >> > CRNs will now exist:- CRN for Path 1 and Path 3; and CRN >> for Path 2 and Path 3. >> > >> > If the NSIS signaling over Path 3 triggers a CRN discovery, the CRN >> > discovery may lead to discovery of a QNE which is a CRN for >> path 1 and >> > Path 3 only, instead of correctly identifying a QNE which >>> is a CRN for >> > Path 2 and Path 3. This is because the current NSIS CRN Discovery >> > Procedure does not provide information about whether a CRN >>> is caused >> > by the mobility event or multiple interfaces. >> >> [SHL] "CD (CRN_Discovery) flag" described in Section 5.1.4.1 >> can solve this issue because the CD flag can prevent NEs to >> incorrectly perform the process of CRN discovery. For >> example, once CRN between Path 2 and Path 3 is discovered, >> the CD flag is set and thus downstream NEs don't perform the >> process of CRN discovery. Therefore, the CRN discovery >> between Path 1 and Path 3 doesn't occur. >> >> After handover, if a merging point between Path 1 and Path 3 >> exists before the CRN between Path 2 and Path 3, the merging >> point between Path 1 and Path 3 becomes CRN and thus 'CD >> flag' is set. The existing CRN (as downstream NE of the CRN >> btw Path 1 and Path 3) between Path 1 and Path 2 can remove >> the old state on the Path 2 when it checks the CD flag >> included in NSIS signaling message from upstream NEs. In this >> case, the existing CRN needs to remove the old state through >> checking the CD flag. > > [SHIV] As mentioned above, for the CRN (between Path 1 and Path 2) to >remove/update the old state, it needs to know which path is the old > state (e.g. > whether it is Path 1 or Path 2). However, the CD Flag does not contain > this > information. Therefore, the CRN (between Path 1 and Path 2) would not be > able > to identify the correct path state to remove using the CD Flag alone. [SHL] NSLP_Br_ID (described in Section 4.2.2) enables CRN to identify which branch is old and new. The counter of NSLP_Br_ID is updated when a new branch is created or the old branch is removed. > Secondly, the discovered CRN has no way to know whether it is a CRN of > mobility > event (i.e. between Path 2 and Path 3) or a CRN of multiple paths (e.g. > between > Path 1 and Path 3). And, this is the root of the issue. Changing the CRN > behavior and using CD Flag does not solve it fundmentally, and may cause > further problems. For example, the CRN behavior described above > obviously does > not fit for non-multihoming cases. [SHL] Could you give me more clarifications on how the Path type ID classifies the paths required by multihoming functionalities from the paths created by mobility events? I guess the issues on removing the NSIS states at CRNs depend on how to put some identifiers in NSIS signaling messages. >> >> > The problem encountered in this case is that the discovered >> CRN would >> > have no information to decide its proper action (whether it is a >> > mobility event, or it's a multihoming case). There is a >> more thorough >> > analysis of this problem in section 4.1 of >> > draft-sanda-nsis-path-type-03 >> > [http://tools.ietf.org/wg/nsis/draft-sanda-nsis-path-type-03.txt] >> > >> > The above problem is an important issue to be considered in the >> > mobility draft as this scenario is very common and >> realistic. The text >> > sent earlier provides a brief description of this problem. >> If there >> > is a need for further clarification on this problem, we can provide >> > more/amended text for that. >> >> [SHL] I think this issue needs to further be discussed in the >> mobility draft. > > [SHIV] Correct, we need to discuss this issue/scenario further in the > mobility draft as it is a valid issue. If needed we can provide > relavent text for the draft, kindly let us know. > > >[SHL] What do you think differences between Path type and CD flag? > > > > [SHIV] The CD Flag and Path Type ID are actually introduced for > different > purposes. The CD Flag (as what we understand) is for CRN discovery > process, e.g. > to avoid unnecessary further CRN discovery process after a CRN is > already > identified. > > However CD Flag does not provide information about the relationship > between > different paths (whether they are old and new paths resulted from a > mobility > event, e.g. Path 2 & Path 3; or they are paths simultaneously used for a > session, > e.g. Path 1 and Path 3). This is where the Path Type ID could be used > for. We > don't think that the CD Flag and Path Type ID conflicts with each other > since > they are addressing different issues. [SHL] As I mentioned above, please give more clarifications on the "Path type ID." Warm regards, Sung-Hyuck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 01 13:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWWy-0004LM-Ng; Wed, 01 Mar 2006 13:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWWx-0004K6-RG for nsis@ietf.org; Wed, 01 Mar 2006 13:58:35 -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 1FEWWw-00031A-IO for nsis@ietf.org; Wed, 01 Mar 2006 13:58:35 -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; Wed, 01 Mar 2006 20:58:33 +0200 id 000701E5.4405EED9.0000336A Date: Wed, 1 Mar 2006 20:58:33 +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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [NSIS] A note to QOSM/QSPEC authors 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, Just a note to QOSM/QSPEC authors that there is the 8-bit QoS model-specific error subcode in the INFO_SPEC for you to use, e.g., to give more specific information about the event in question. Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 01 14:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWa3-00087j-G9; Wed, 01 Mar 2006 14:01:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWa1-00087e-P2 for nsis@ietf.org; Wed, 01 Mar 2006 14:01:45 -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 1FEWa0-00036c-FM for nsis@ietf.org; Wed, 01 Mar 2006 14:01:45 -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; Wed, 01 Mar 2006 21:01:43 +0200 id 0007023E.4405EF97.000057DE Date: Wed, 1 Mar 2006 21:01:43 +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: 2409bba43e9c8d580670fda8b695204a Subject: [NSIS] QoS NSLP updated 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, I have now updated the QoS NSLP draft. The changes are: - Edits based on two sets of comments from Jerry and Roland, most changes are in 5.2.4 and 5.3.6. - Re-named some of the references (I hated those loooooong ref names) ;) - Re-arranged the references - Removed the changelog - Re-wrote a bit the IANA considerations section I'm now running out of ideas of what to edit further. If I don't hear otherwise, I'm going to make a final sanity check during the weekend, and submit this version for consideration by the ADs and the IESG. As usual, a diff is available here: http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-09-10.html Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 01 14:38:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX9e-0001oc-68; Wed, 01 Mar 2006 14:38:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX9c-0001oW-3S for nsis@ietf.org; Wed, 01 Mar 2006 14:38:32 -0500 Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEX9a-0004lg-Ks for nsis@ietf.org; Wed, 01 Mar 2006 14:38:32 -0500 Received: from [192.67.198.2] (p5484A546.dip0.t-ipconnect.de [84.132.165.70]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k21JcOmO005765; Wed, 1 Mar 2006 20:38:25 +0100 (MET) Message-ID: <4405F7E7.5070601@cs.uni-goettingen.de> Date: Wed, 01 Mar 2006 20:37:11 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bo Gao Subject: Re: [NSIS] A question about timer References: <20060301100407.t8o58e8ulfwocswo@mail.encs.concordia.ca> In-Reply-To: <20060301100407.t8o58e8ulfwocswo@mail.encs.concordia.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Bo, I'm student at the University of Goettingen/Germany and we have made a GIST implementation. It's written in C/C++ and runs on Linux Platforms. You can have a look at the source code under http://user.informatik.uni-goettingen.de/~nsis/ I've written a short timer class which is based on double-linked lists. I use setitimer() to generate a signal. The signal handler searches the list for expired timers. The corresponding callback-function is then executed. With only one signal you can manage quite a lot of different timers. Using select() is the second possibility to manage timers. Here you have to distinguish first if select() returned because of a socket or a timer event. The rest would be the same. In our implementation you find the files Timer.cpp and Timer.h in the path nslp/nslp_api. In the path nslp/qos and nslp/natfw there are examples on how to use them. Bye, Bernd Bo Gao wrote: > Hello, > I am a student of a Canadian University and trying to implement GIST > right now. We are using Linux and C/C++. We know there are several > timers in GIST like state timer and refresh timer and retransmission > timer, which we must take care of. I checked our Linux(Fedora Core) > system in our university and found there is a timer_create system call > supported in our Linux. Also we know that when the timer expires, it can > send a signal. > We am planing to use only one Signal Handler for all of the timers. In > the Signal Handler, we are going to distinguish different signals and > write something to a local pipe or fifo. So we can treat the local pipe > or fifo as a member of a fdset, which should includes the RAW socket and > all other sockets associated with Message Associations. So we can use > select() in our main thread to detect all of messages(GIST message, > timers). Can anybody give some advices and suggestions as we are still > in design phase? > Also the problem right now is there seems to be only two kinds of > signals(USRSIG1, USRSIG2) we can use. But certainly,we have more than > two types of timers. Is it possible we can use something else rather > than signal number to distinguish different timers? > Any comment will be very helpful. > > Sincerely, > > Bo GaoE-mail: gao_b@cs.concordia.ca > Computer Science Dept, Concordia University, Montreal > > > _______________________________________________ > 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 02 03:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEjLa-0008GX-KB; Thu, 02 Mar 2006 03:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEjLY-0008BD-NK for nsis@ietf.org; Thu, 02 Mar 2006 03:39:40 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEjLY-00036X-3K for nsis@ietf.org; Thu, 02 Mar 2006 03:39:40 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id k228dWxT004426; Thu, 2 Mar 2006 17:39:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k228dXK01975; Thu, 2 Mar 2006 17:39:33 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k228dYG27861; Thu, 2 Mar 2006 17:39:34 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id k228dXr08837; Thu, 2 Mar 2006 17:39:33 +0900 (JST) Received: from [10.68.136.29] by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id k228dRY08646; Thu, 2 Mar 2006 17:39:27 +0900 (JST) Date: Thu, 02 Mar 2006 17:39:47 +0900 From: Takako Sanda To: Sung-Hyuck Lee Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft In-Reply-To: <001e01c63d41$79995ba0$f95b024b@LocalHost> References: <5F09D220B62F79418461A978CA0921BDB240F4@pslexc01.psl.local> <001e01c63d41$79995ba0$f95b024b@LocalHost> Message-Id: <20060302173709.0C0A.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Pek Yew Tan , 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 Sung-Hyuck, Thank you for your comment. Please see my comment below. BR, Takako On Thu, 02 Mar 2006 00:04:37 +0900 Sung-Hyuck Lee wrote: > [SHL] Could you give me more clarifications on how the Path type ID > classifies the paths required by multihoming functionalities from the paths > created by mobility events? I guess the issues on removing the NSIS states > at CRNs depend on how to put some identifiers in NSIS signaling messages. <\snip> Before discussion, let me clarify the issue again. The point here is, there are two types of CRNs in the case MN uses multiple (here we assume two) paths for same session. One is CRN between two on-going paths, and the other one is CRN between old and new paths caused by MN's handover. The former one (I temporally name it LB-CRN) will need to manage two on-going paths, while the latter one (I temporally name it HO-CRN) need to handle path update. These two CRNs need to be differentiated in order to avoid perform path update for wrong one. Path type ID is one way to differentiate these two. Again, I give an example to show why two types of CRN should be differentiated (with figures below):- MN uses path1 and path2 for the same session. According to an assumption in section 5.2.5 of the applicability draft, path1&2 uses the same SID but different FID. So, CRN between path1&2, LB-CRN has two FID information for the same SID. Then, MN's one interface performs handover and obtain nCoA, MN will try to establish new path with nCoA (i.e. new FID). The new path will crossover with path1 or path2 (let's assume the new path crossovers with path2). But the CRN between path2 and the new path cannot know if it is LB-CRN or HO-CRN because for both case, SID is the same but FID is different. And so it does not know if Path Update can be performed. Even if "CD_Flag" is set by this CRN, existing CRN (LB-CRN) still cannot differentiate which path should be updated. Path1 +--+ ********* +---+ +--+ | |** **|LB |***| | |MN| |CRN|***|CN| | |** **| | | | +--+ ********* +---+ +--+ Path2 | v +--+ ********* +---+ +--+ | |** **|LB |***| | |MN| |CRN|***|CN| | |** ? **| | | | +--+ *****CRN* +---+ +--+ * * ***** As one of solutions, we proposed the way to explicitly show "which path performs handover". If the new path include the information "I was path2 previously", the CRN in the example can know "OK, I am HO-CRN. So I should perform path update for path2". If the information says "I was path1 preciously", the CRN will say "OK, I am new LB-CRN, so path update should be done in different node" (in this case, previous LB-CRN should have a role of HO-CRN). For this explicit information, we proposed to use extra few bit for showing "path1" or "path2", and we call this path type ID. Of course, previous FID can be utilized for this information. But as FID has large space, we introduced to use small information. I am not sure if NSLP_BR_ID has similar sort of information. In current Applicability draft, NSLP_BR_ID contains (if my understanding is correct) NSLP_ID-flow (=NSLP ID?!), upstream or downstream, and mobility counter. And so it seems not containing the similar information. But I may misunderstand NSLP_Br_ID and CD_flag. If so, could you kindly show how the parameters could solve the issue? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 02 04:37:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkFO-0004BV-1O; Thu, 02 Mar 2006 04:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkFM-0004BQ-NY for nsis@ietf.org; Thu, 02 Mar 2006 04:37:20 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkFL-0005p6-5y for nsis@ietf.org; Thu, 02 Mar 2006 04:37:20 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k229bHs6018841 for ; Thu, 2 Mar 2006 18:37:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k229bI314903 for ; Thu, 2 Mar 2006 18:37:18 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k229bIG29228 for ; Thu, 2 Mar 2006 18:37:18 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id k229bH424215 for nsis@ietf.org; Thu, 2 Mar 2006 18:37:17 +0900 (JST) Received: from [10.68.136.29] by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id k229bGY24191 for ; Thu, 2 Mar 2006 18:37:16 +0900 (JST) Date: Thu, 02 Mar 2006 18:37:36 +0900 From: Takako Sanda To: nsis@ietf.org Message-Id: <20060302183456.0C17.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] minor comment on Applicability 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 Hi Applicability draft authors, I have a minor comment on the Applicability draft. Sub-section numbering in section 6 seems to be incorrect ;) The correct numbering should be:- 6.1.3 -> 6.2 6.1.3.1 -> 6.2.1 6.1.3.2 -> 6.2.2 6.1.4 -> 6.3 6.1.4.1 -> 6.3.1 6.1.4.2 -> 6.3.2 6.1.5 -> 6.4 6.1.6 -> 6.5 BR, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 02 07:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEmxD-0005If-Tu; Thu, 02 Mar 2006 07:30:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEmxC-0005IO-SK for nsis@ietf.org; Thu, 02 Mar 2006 07:30:46 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEmxA-0003x6-9v for nsis@ietf.org; Thu, 02 Mar 2006 07:30:46 -0500 Received: from [195.37.70.135] (unknown [195.37.70.135]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3C15C1BAC4D; Thu, 2 Mar 2006 13:31:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Thu, 2 Mar 2006 13:30:41 +0100 To: nsis X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [NSIS] NATFW Issue 63: Aggregation of NSLP signaling messages (was signaling session wildcarding) 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, The issue 63 (https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/ issue63) refers to the below section out of the 3GPP2 requirements draft (http://www.watersprings.org/pub/id/draft-bajko-nsis-fw-reqs-04.txt) 5.1.7 Efficient use of the air interface The protocol MUST allow an end point to create, modify or delete several firewall states with one protocol instance. NOTE: a Firewall Configuration Protocol should provide a solution for the above requirement in a single Firewall architecture. In a multihomed scenario, with multiple Firewalls on alternative paths, there should be a means for the Firewalls to keep themselves synchronized. This capability is useful in some wireless networks, where the access link resources are limited. This would reduce the overhead and the delay of the procedures. It MUST be possible to open a pinhole with a single protocol request/response pair of messages. This is required because: a) a wireless link is a scarce and expensive resource b) real-time applications are delay sensitive After further discussions with Gabor we have concluded that basically a function is needed to teardown multiple session belonging to a single NATFW NSLP node. For instance, if a mobile terminal is shutting down, it can send a single NATFW NSLP message and all session concerned will be terminated. The solution to this is similar to the NOTIFY storm avoidance. For NOTIFY the upcoming version of the draft contains: To avoid the need of generating per signaling session NOTIFY message in such a described or similar scenario, NFs SHOULD follow this procedure: The NF uses the NOTIFY message with the session ID in the NTLP set to zero, with the MRI completely wildcarded, and the 'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [1]. The upstream NF receiving this type of NOTIFY immediately regards all signaling sessions from that peer matching the MRI as void. (taken from here: http://www.stiemerling.org/ietf/nsis/snapshot/ snapshot.txt) The teardown of all session for a specific node could be done in this way - Set the MRI to source IP address of the node - wildcard all other parameter - Set SID to zero - Use 'explicit routing' in the NTLP - NSLP message with lifetime set to zero Any thoughts, comments, or objections about it? Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 02 08:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnU6-0003Dk-Nz; Thu, 02 Mar 2006 08:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnU4-000344-1K for nsis@ietf.org; Thu, 02 Mar 2006 08:04:44 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEnU3-00055I-92 for nsis@ietf.org; Thu, 02 Mar 2006 08:04:44 -0500 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IVI005UY481PY@mailout2.samsung.com> for nsis@ietf.org; Thu, 02 Mar 2006 22:02:25 +0900 (KST) Received: from LocalHost ([75.2.91.249]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IVI00LST48091@mmp1.samsung.com> for nsis@ietf.org; Thu, 02 Mar 2006 22:02:25 +0900 (KST) Date: Thu, 02 Mar 2006 22:02:24 +0900 From: Sung-Hyuck Lee Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft To: Takako Sanda Message-id: <00b501c63df9$8cedbee0$f95b024b@LocalHost> Organization: SAIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5F09D220B62F79418461A978CA0921BDB240F4@pslexc01.psl.local> <001e01c63d41$79995ba0$f95b024b@LocalHost> <20060302173709.0C0A.SANDA.TAKAKO@jp.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Pek Yew Tan , 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 Takako, ----- Original Message ----- From: "Takako Sanda" To: "Sung-Hyuck Lee" Cc: "Shivanajay Marwaha" ; ; "Pek Yew Tan" Sent: Thursday, March 02, 2006 5:39 PM Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft > Hi Sung-Hyuck, > > Thank you for your comment. Please see my comment below. > > BR, > Takako > > > On Thu, 02 Mar 2006 00:04:37 +0900 > Sung-Hyuck Lee wrote: > > > > [SHL] Could you give me more clarifications on how the Path type ID > > classifies the paths required by multihoming functionalities from the paths > > created by mobility events? I guess the issues on removing the NSIS states > > at CRNs depend on how to put some identifiers in NSIS signaling messages. > <\snip> > > Before discussion, let me clarify the issue again. > > The point here is, there are two types of CRNs in the case MN uses > multiple (here we assume two) paths for same session. One is CRN between > two on-going paths, and the other one is CRN between old and new paths > caused by MN's handover. The former one (I temporally name it LB-CRN) > will need to manage two on-going paths, while the latter one (I temporally > name it HO-CRN) need to handle path update. These two CRNs need to be > differentiated in order to avoid perform path update for wrong one. Path > type ID is one way to differentiate these two. > > Again, I give an example to show why two types of CRN should be > differentiated (with figures below):- > MN uses path1 and path2 for the same session. According to an assumption > in section 5.2.5 of the applicability draft, path1&2 uses the same SID > but different FID. So, CRN between path1&2, LB-CRN has two FID > information for the same SID. > Then, MN's one interface performs handover and obtain nCoA, MN will try > to establish new path with nCoA (i.e. new FID). > The new path will crossover with path1 or path2 (let's assume the new > path crossovers with path2). But the CRN between path2 and the new path > cannot know if it is LB-CRN or HO-CRN because for both case, SID is the > same but FID is different. And so it does not know if Path Update can be > performed. Even if "CD_Flag" is set by this CRN, existing CRN (LB-CRN) > still cannot differentiate which path should be updated. > > Path1 > +--+ ********* +---+ +--+ > | |** **|LB |***| | > |MN| |CRN|***|CN| > | |** **| | | | > +--+ ********* +---+ +--+ > Path2 > | > v > > +--+ ********* +---+ +--+ > | |** **|LB |***| | > |MN| |CRN|***|CN| > | |** ? **| | | | > +--+ *****CRN* +---+ +--+ > * * > ***** > > > As one of solutions, we proposed the way to explicitly show "which path > performs handover". If the new path include the information "I was path2 > previously", the CRN in the example can know "OK, I am HO-CRN. So I > should perform path update for path2". If the information says "I was > path1 preciously", the CRN will say "OK, I am new LB-CRN, so path update > should be done in different node" (in this case, previous LB-CRN should > have a role of HO-CRN). > For this explicit information, we proposed to use extra few bit for > showing "path1" or "path2", and we call this path type ID. Of course, previous > FID can be utilized for this information. But as FID has large space, we > introduced to use small information. > I am not sure if NSLP_BR_ID has similar sort of information. In current > Applicability draft, NSLP_BR_ID contains (if my understanding > is correct) NSLP_ID-flow (=NSLP ID?!), upstream or downstream, and > mobility counter. And so it seems not containing the similar > information. But I may misunderstand NSLP_Br_ID and CD_flag. If so, > could you kindly show how the parameters could solve the issue? [SHL] I also guess Path type ID seems to be necessary to distinguish paths created by mobility from paths established by load balancing. In this case, Path type ID just needs to identify whether a branch is additional for load balancing: For example, Path type ID can set as M (multiple path by multihoming ) or H (handover). And, NSLP_Br_ID can help classify which branch is old and new by its counter. In the first figure above, CRN also needs to identify which branch is additional for load balancing. In this case, Let's assume Path 2 is the additional branch for load balancing. When LB-CRN is discovered between Path 1 and Path 2, NSLP_Br_ID for Path 1 and Path 2 is set as 1-D-#1 and 1-D-#2 (additional path for load balancing), respectively . LB-CRN may perform aggregation for downstream flows, not State Update by checking Path type ID for Load Balancing. 'CD flag' can be set saying "LB-CRN is discovered." When a handover occurs, there are two scenarios on CRN created by Path 3. One is the case that CRN is created between Path 1 and Path 3 before Path 3 meets Path 2. The first case is same as the scenario shown in the first figure. NSLP_Br_IDs, for example, are set to 1-D-#1 and 1-D-#2 for Path 1 and Path 3, respectively. 'CD' flag is set to LB-CRN and just aggregation is performed for downstream flows. And afterwards, when Path 3 meets Path2, HO-CRN is discovered and 'CD' flag is set to 'CRN'. In this case, although Path 3 follows track of Path 1, NSLP_Br_ID (for Path 3 and Path 1) is again set to 1-D-#3 to classify which branch is old and thus remove the old path. Another is the case that CRN is created between Path 2 and Path 3 at first. This case is same as the case that Path 2 and Path 3 meet at the first scenario. Only, NSLP_Br_ID is differently set whether CRN is created where Path 1, Path 2, and Path 3 all meets or not. Once CRN is discovered, the aggregation for flow can be perfomed irregardless of whether it is LB-CARN or HO-CRN. Thanks, Sung-Hyuck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 02 12:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErx6-0001Wt-ND; Thu, 02 Mar 2006 12:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErx5-0001Wo-8D for nsis@ietf.org; Thu, 02 Mar 2006 12:50:59 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErwz-0000BP-Az for nsis@ietf.org; Thu, 02 Mar 2006 12:50:59 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k22HoFoW030282; Thu, 2 Mar 2006 17:50:15 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 17:50:14 +0000 Message-ID: <44073056.5020902@roke.co.uk> Date: Thu, 02 Mar 2006 17:50:14 +0000 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] QoS NSLP: rerouting issues References: <43CE14CD.9030604@roke.co.uk> <43E279FA.3040304@tm.uka.de> In-Reply-To: <43E279FA.3040304@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2006 17:50:14.0874 (UTC) FILETIME=[C2BE6BA0:01C63E21] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: Georgios Karagiannis , Jukka MJ Manner , 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 Roland, Thanks for looking at this. Sorry for the slow reply, this e-mail got half-written and I didn't get round to finishing it. Some replies/comments below. Roland Bless wrote: >>Proposed updates: >> >>##### section 3.2.10 ##### >> > > [previous text ok.] > >>Reservation on the new path happens when a refreshing RESERVE message >>arrives at the QNE where the old and the new path diverge. The >>refreshing RESERVE will be interpreted as a new RESERVE on the new >>path. Depending on the transfer mode, this may require installation > > > Hm, I'm a little bit confused about this statement. The incoming > refreshing RESERVE will usually _not_ trigger a transmission of > a new RESERVE along the new path. Refreshing state is independently > triggered at each node rather than a refreshing RESERVE traversing > the path downstream. The branching node (i.e. the QNE > where the old and the new path diverge) will send a refresh > to his downstream peer. If rerouting happens, there > are different cases to be considered: > - GIST will detect a new path by its own mechanism, i.e. while > sending an NTLP refresh. In this case a notification may be given > to the NSLP that a downstream SII has changed. This should > trigger immediate sending of a refreshing RESERVE (usually > with full QSPEC and RII, otherwise we'll get an error back first). > - NSLP has to send a refresh to its downstream peer, because the refresh > timer expired. GIST will find the new route then, notify NSLP of a > new SII and will also get back an error message from its downstream > peer, because he needs a full QSPEC. NSLP then should send the RESERVE > with RII and full QSPEC again. Yes, rereading this I'm a little bit confused too. :-) Most of the 3.2.10 text is unchanged from -08 (mostly deleted/reworded rather than added text), so we should probably have noticed this before. :-) I think we could say: Reservation on the new path happens when a RESERVE message arrives at the QNE beyond the point where the old and new paths diverge. A refreshing RESERVE (with no QSpec) will be identified as an error by a QNE on the new path. It will send back an error message which results in a full RESERVE message being sent. Depending on the transfer mode, this may require installation ... >>of a new messaging association. Rapid recovery at the NSLP layer >>therefore requires short refresh periods. Detection before the next >>RESERVE message arrives is only possible at the IP layer or through >>monitoring of GIST peering relations (e.g. by TTL counting the >>number of GIST hops between NSLP peers or the observing changes in >>the outgoing interface towards GIST peer). These mechanisms can >>provide implementation specific optimisations, and are outside the >>scope of this specification. > > > Yep. > > >>When the QoS NSLP is aware of the route change, it needs to set up >>the reservation on the new path. This is done by incrementing the >>RSN and then sending a new RESERVE message. On links that are common >>to the old and the new path, this RESERVE message is interpreted as a >>refreshing RESERVE. On new links, it creates the reservation. > > > Not quite correct. Incrementing the RSN is not necessary in this > case and contradicts to the statement that an increased RSN indicates > a changed session. Furthermore, remember that an RSN has only > local significance. > Because the RSN is different it will not directly > be considered as refresh by nodes that know this session. > Only if the QSPEC and MRI did not change, > then there is no need to send it further along the path. > I would suggest that we clarify text when to "forward" > a RESERVE (at end of sec. 5.4.1) or TEAR anyway. > Section 5.3.1. states > It MUST be incremented for each new RESERVE message where the > reservation for the session changes. > Strictly speaking the above statement does not infer that > a new RSN necessarily means that the session changes. But > in case nothing changed, the RSN must stay the same. > > Let's look what happens: the branching node should send > a full refreshing RESERVE (RSN not changed, added RII) along the new > link. If the next QNE is really a new peer that doesn't > know about the reservation, it will setup a new reservation > anyway. In this case this QNE will also emit a _new_ RESERVE > (include a new RSN, because the QNE is new). In case the > RESERVE hits the merging node again, the latter should > detect that: it knows the referenced session and that it > has a new upstream peer. But because neither MRI nor QSPEC > are changed, a new RESERVE along the unchanged path will > not be triggered (the normal refreshing RESERVE will be sent > when the refreshing timer fires). Yes, RSN does not need to be incremented since the same reservation is being requested. (I'd probably say 'changed reservation' or 'changed state' rather than 'changed session'). However, there is the issue of wanting to send a TEAR and not being 100% certain whether the next peer has changed (third paragraph of section 5.2.5.2). > The last two sentences are confusing, because > the RESERVE will not be forwarded (esp. not with the very same RSN). > Correct would be: The RESERVE may be sent along a new link but possibly > hits the same QNE as before (multi-homing scenario). In this case the > QNE will consider the RESERVE as refresh. If a new QNE is hit, it will > establish a new reservation (if possible) and send a new RESERVE downstream. Agreed. I think this is remnants of a time when we weren't so clear what service abstract-NTLP/GIMPS/GIST would provide. I suggest replacing this paragraph and removing the details which fit better into section 5. Suggested replacement: When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by sending a new RESERVE message. If the next QNE is, in fact, unchanged then this will be used to refresh/update the existing reservation. Otherwise it will lead to the reservation being installed on the new path. >>After the reservation on the new path is set up, the branching node >>or the merging node may want to tear down the reservation on the old >>path (faster than what would result from normal soft-state time-out). > > > As already written earlier > (http://www.ietf.org/mail-archive/web/nsis/current/msg05826.html): > I don't know how the merging node (i.e. the node where the paths > join again) should TEAR down the session. > Currently this is not possible because a RESERVE with TEAR can only > flow in the direction from QNI to QNR. Agreed. This paragraph also has some old 'requests GIST to provide' text. Suggested replacement: After the reservation on the new path is set up, the branching nodenode may want to tear down the reservation on the old path (sooner than would result from normal soft-state time-out). This functionality is supported by keeping track of the old SII-Handle provided over the GIST API. This handle can be used by the QoS NSLP to route messages explicitly to the next node. >>When the QoS NSLP is aware of the route change, it needs to set up >>the reservation on the new path. This is done by incrementing the >>RSN and sending a RESERVE message. On links that are common to the >>old and the new path, this RESERVE message is interpreted as a >>refreshing RESERVE. On new links, it creates the reservation. > > > This is the same text as above. I'm not really sure that we need > this redundancy. > > >>After the reservation on the new path is set up, the branching node or >>the merging node may want to tear down the reservation on the old path > > > Only the branching node... see above Would it be better to fold the remaining non-redundant parts of 4.8 into 3.2.10? >>downstream peer. A QNE that has detected the route change via the >>SII change sends a RESERVE message towards the QNR on the old path >>(using the old SII) with the TEAR flag set. Note that in case of > > > This TEAR would IMHO be too early. The TEAR should be triggered by the > RESPONSE to the RESERVE on the new path indicating that the reservation > is already installed. Yes. >>receiver-initiated reservations, this involves a QNE that is notified >>of the route change in another way and wants to tear down the old >>branch needs to send the RESERVE on the new path with an RII object. >>When it receives the RESPONSE message back, it can check whether its >>peer has effectively changed and send a RESERVE with the TEAR flag >>set if it has. Otherwise, teardown is not needed. A QNE that is >>unable to support an RII or does not receive a RESPONSE needs to rely >>on soft-state timeout on the old branch. > > > This is ok, but also applicable to the sender-initiated case. Yes. I find the last sentences of this paragraph unclear. I'm not sure that they're saying anything particularly useful (i.e. provides useful information beyond that in section 3.2.10). Generally 4.8 feels a bit repetitive of 3.2.10. There's possibly some new content in the last paragraph. Maybe that could be folded in to 3.2.10, and remove 4.8? >>QoS NSLP is notified by GIST when GIST believes that a rerouting event >>may have occurred. As part of the API, GIST provides an SII-Handle >>which can be used by the NSLP to direct a signalling message to a >>particular peer. The current SII-Handle will change if the signalling >>peer changes. However, it is not guaranteed to remain the same after a >>rerouting event where the peer does not change. Therefore, the QoS >>NSLP mechanism for reservation maintenance after a route change >>includes robustness mechanisms to avoid accidentally tearing down a >>reservation in situations where the peer QNE has remained the same >>after a 'route change' notification from GIST. >> >>When a QNE detects that its neighbour QNE in the direction of the QNR >>has changed, it SHOULD send a RESERVE message, including the full >>QSPEC. This RESERVE message MUST include an RII, to request a response >>from the QNR. When sending this message the RSN MUST be incremented by >>two (and this becomes the current RSN value). An SII MUST NOT be >>specified when passing this message over the API to GIST, so that it >>is correctly routed to the new peer QNE. >> >>When the QNE receives the RESPONSE message that relates to that the >>RESERVE message sent down the new path, it SHOULD send a RESERVE >>message with the TEAR flag sent down the old path, by specifying the >>SII relating to the old peer QNE. When sending this RESERVE message >>the RSN field MUST be set to one less than the current RSN value (and >>the current RSN value remains unchanged). This 'RSN-1' will cause the >>message to be reject by the next peer if the old and new next peers >>are actually the same. >> >>Depending on the particular route change, there may be a 'merge point' >>(or 'crossover node') where the old and new paths merge. Initially this >>has a reservation installed by the old peer QNE, identified by an old >>SII. When the new reservation is installed after the route change the >>new peer QNE will be identified by a new SII. At a later point the >>crossover node may receive a RESERVE message with the TEAR flag set >>from the QNE identified by the old SII. A node receiving a RESERVE >>message with the TEAR flag set which does not come from the current >>peer QNE, identified by its SII, MUST be ignored and MUST NOT be >>forwarded. > > > Yep. Therefore, we should exactly describe at the end of the > RESERVE section 5.4.1 that a RESERVE with a TEAR should > not be sent to the next peer in this case. I'd probably put this in after paragraph 4 of 5.4.1 (The one beginning "When the RESERVE is authorized..."), so it is with the other text discussing the TEAR flag. Suggested text: As discussed in section 5.2.5.2, to avoid incorrect removal of state after a rerouting event, a node receiving a RESERVE message with the TEAR flag set which does not come from the current peer QNE, identified by its SII, MUST be ignored and MUST NOT be forwarded. >>.sh 4 "Upstream route change notification" >> >>GIST may notify QoS NSLP that a possible upstream route change has >>occurred over the GIST API. On receiving such a notification, QoS NSLP >>SHOULD send a NOTIFY message with Informational code ????? for >>signalling sessions associated with the identified MRI. >> >>On receiving such a NOTIFY message, QoS NSLP SHOULD use the >>InvalidateRoutingState API call to inform GIST that routing state >>may be out of date. QoS NSLP SHOULD send a NOTIFY message upstream. > > > When should forwarding of NOTIFY stop? > I'm currently not sure how the branching node will detect this > case. Maybe if the NOTIFY arrives via an inactive/invalid routing > state. I'm not sure what we should do here. It is quite probable (if the possible route change indiciation from GIST is correct) that the node that the NOTIFY is initially sent to is no longer on the path. Some possible options: - don't forward it at all (but since the node receiving the NOTIFY might not be on the path, but would still have the node sending the NOTIFY as its next downstream hop for that flow, it is not clear that sending the NOTIFY message is useful) - let it go all the way back to the QNI/QNR - let it go all the way back to a QNE which determines that it's downstream peer has changed - something else Any thoughts on the best answer? ('best' rather than 'correct' since this is, at best, a hint) >>.sh 4 "Route change oscillation" >> >>In some circumstances a route change may occur, but the path than > > typo: then yes >>falls back to the original route. >> >>After a route change the routers on the old path will continue to >>refresh the reservation until soft state times out, or an explicit >>TEAR is received. >> >>After detecting an upstream route change a QNE SHOULD consider the new >>upstream peer as current and not fall back to the old upstream peer >>unless: >> >>- it stops receiving refreshes from the old upstream peer for at least >>the soft state timeout period > > ??? in this case it really makes no sense to fall back to the old > upstream peer ??? There is a vital bit missing from the end of this sentence: "and then starts receiving messages from the old upstream peer again" regards, Andrew -- Andrew McDonald, Senior Engineer Roke Manor Research Ltd, Romsey, Hants SO51 0ZN Phone +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 Thu Mar 02 13:20:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsQ6-0001Oi-BZ; Thu, 02 Mar 2006 13:20:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsQ5-0001Od-M5 for nsis@ietf.org; Thu, 02 Mar 2006 13:20:57 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEsQ1-0001IR-AV for nsis@ietf.org; Thu, 02 Mar 2006 13:20:57 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k22IKloW005226; Thu, 2 Mar 2006 18:20:47 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 18:20:47 +0000 Message-ID: <4407377E.1060305@roke.co.uk> Date: Thu, 02 Mar 2006 18:20:46 +0000 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] Problem in QoSNSLP/NSISNTLP draft References: <010701c62fc8$a691de60$1402a8c0@comm.ad.roke.co.uk> In-Reply-To: <010701c62fc8$a691de60$1402a8c0@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2006 18:20:47.0221 (UTC) FILETIME=[06E86250:01C63E26] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Robert Hancock wrote: > you are right that there is no traffic class carried in the GIST MRI. > however, the 6-bit DS-Field is there instead. the references are to rfc2474 > and rfc3260 which discuss the replacent of the 'traffic class' terminology > with 'ds-field' terminology. > > i don't know which document should fix this mainly terminological > inconsistency; however, the fact that the 'traffic class' terminology had > been replaced was pointed out to me by one of the QoS-NSLP authors :-) That'd be me then. :-) Comments below: >>-----Original Message----- >>From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>Behalf Of David Palma >>Sent: 10 February 2006 16:10 >>To: nsis@ietf.org >>Subject: [NSIS] Problem in QoSNSLP/NSISNTLP draft >> >> >>Hi all, >> >>I'm from the University of Coimbra and I'm currently >>implementing the QoS-NSLP. >> >>I started the tests between the QoS-NSLP and GIST but I found >>a problem. >> >>When creating the Packet Classifier, as described on section >>5.1.3.5 of the draft (draft-ietf-nsis-qos-nslp-08), it's >>assumed that we should get from the MRI the following flags: >> >> X - Source Address and Prefix >> Y - Destination Address and Prefix >> P - Protocol >> T - Traffic Class >> F - Flow Label >> S - SPI >> A - Source Port >> B - Destination Port "get from the MRI" probably isn't quite the right way to think about it - setting the flags in the PACKET_CLASSIFIER isn't necessarily a simple copy operation. A flag can only be set in the packet classifier if the field is present in the MRI. The opposite is not true. Part of the aim of the classifier is so that you can do things such as say "the packets for this reservation should be matched only using the DSCP" (as an example that RMD might use). That is, it allows you to use a subset of the information in the MRI as your packet classifier. >>Cross checking the MRI object format of the GIST draft in >>section A.3.1 >>(draft-ietf-nsis-ntlp-08) the only existing flags are: >> >> P - P=1 means that IP Protocol should be interpreted >> T - T=1 means that DS-Field should be interpreted; see [4] and [18] >> F - F=1 means that flow Label is present and should be interpreted >> S - S=1 means that SPI is present and should be >>interpreted; see [10] >> A/B - Source/Destination Port (see below) >> D - Direction of message relative to flow >> >>The Traffic Class field doesn't even exist! However in >>further searches I found that in an earlier version of GIMPS, >>like version 6, there was a Traffic Class field. Yes, it should be: T - DS-Field >>To resume my question is: >> >> - Where should I get the X, Y and T flag since they are not >>part of the MRI object has it is supposed to be in the GIST MRI? The MRI in GIST requires that both a source and destination address are provided. The X and Y flags were added to the packet classifier to allow some greater freedom by allowing you to say, for example, "match all packets (from whatever source address) going to this destination address". I think some extra words would probably help to clarify this. A suggested replacement for the paragraph after the list of flags: The flags indicate which fields from the MRI should be used by the packet classifier. This allows a subset of the information in the MRI to be used for identifying the set of packets which are part of the reservation. Flags MUST only be set if the data is present in the MRI (i.e. where there is a corresponding flag in the GIST MRI, the PACKET_CLASSIFIER flag can only be set if the corresponding GIST MRI flag is set). It should be noted that some flags in the PACKET_CLASSIFIER (X and Y) relate to data that is always present in the MRI, but are optional to use for QoS NSLP packet classification. The appropriate set of flags set may depend, to some extent, on the QoS model being used. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 02 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0q2-0003OK-I7; Thu, 02 Mar 2006 22:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0q2-0003N8-4W for nsis@ietf.org; Thu, 02 Mar 2006 22:20:18 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF0q1-0007h2-HH for nsis@ietf.org; Thu, 02 Mar 2006 22:20:18 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id k233KFQU026754; Fri, 3 Mar 2006 12:20:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k233KHR19654; Fri, 3 Mar 2006 12:20:17 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k233KGu24121; Fri, 3 Mar 2006 12:20:16 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml22) id k233KFn13758; Fri, 3 Mar 2006 12:20:15 +0900 (JST) Received: from [10.68.136.29] by soml22.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id k233KFA13742; Fri, 3 Mar 2006 12:20:15 +0900 (JST) Date: Fri, 03 Mar 2006 12:20:36 +0900 From: Takako Sanda To: Sung-Hyuck Lee Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft In-Reply-To: <00b501c63df9$8cedbee0$f95b024b@LocalHost> References: <20060302173709.0C0A.SANDA.TAKAKO@jp.panasonic.com> <00b501c63df9$8cedbee0$f95b024b@LocalHost> Message-Id: <20060303121944.6A3D.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Sung-Hyuck, Thank you for your comments. Please see my comments in line. Thanks, Takako On Thu, 02 Mar 2006 22:02:24 +0900 Sung-Hyuck Lee wrote: > [SHL] I also guess Path type ID seems to be necessary to distinguish > paths created by mobility from paths established by load balancing. <\snip> I guess the problem statement could be shared :) In this > case, Path type ID just needs to identify whether a branch is additional for > load balancing: For example, Path type ID can set as M (multiple path by > multihoming ) or H (handover). And, NSLP_Br_ID can help classify which > branch is old and new by its counter. > > In the first figure above, CRN also needs to identify which branch is additional > for load balancing. In this case, Let's assume Path 2 is the additional branch > for load balancing. When LB-CRN is discovered between Path 1 and Path 2, > NSLP_Br_ID for Path 1 and Path 2 is set as 1-D-#1 and 1-D-#2 (additional > path for load balancing), respectively . LB-CRN may perform aggregation for > downstream flows, not State Update by checking Path type ID for Load > Balancing. 'CD flag' can be set saying "LB-CRN is discovered." <\snip> Our original thinking of path type usage is a bit different. let me introduce the idea. Path type ID is different identifiers for on-going paths, e.g. path type "a" for path1 and path type "b" for path2 (see figure below). Path1 +--+ aaaaaaaaa +---+ +--+ | |aa aa|LB |aaa| | |MN| |CRN|bbb|CN| | |bb Path2 bb| | | | +--+ bbbbbbbbb +---+ +--+ And when one path change the route, the same ID is reused, e.g. if path2 is change to path3, "b" is used for path3.Therefore, when two paths meet, the CRN check the path type ID of the paths. if they are the same (case1), the CRN is HO-CRN, and if they are different (case2), the CRN is LB-CRN. NSLP_Br_ID, especially "mobility counter" parameter, is necessary for HO-CRN to know which path is old. (case1) +--+ aaaaaaaaa +---+ +--+ | |aa aa|LB |aaa| | |MN| +---+ |CRN|bbb|CN| | |bb |HO |bb| | | | +--+ bbbb|CRN| +---+ +--+ b b+---+ bbbb (case2) +--+ aaaaaaaaa +---+ +--+ | |aa aa|HO |aaa| | |MN| +---+ |CRN|bbb|CN| | |bb |LB |bb| | | | +--+ bbbb|CRN|aa+---+ +--+ a a+---+ aaaa > When a handover occurs, there are two scenarios on CRN created by Path 3. > One is the case that CRN is created between Path 1 and Path 3 before > Path 3 meets Path 2. The first case is same as the scenario shown in the > first figure. NSLP_Br_IDs, for example, are set to 1-D-#1 and 1-D-#2 for > Path 1 and Path 3, respectively. 'CD' flag is set to LB-CRN and just > aggregation is performed for downstream flows. And afterwards, when Path 3 > meets Path2, HO-CRN is discovered and 'CD' flag is set to 'CRN'. In this > case, although Path 3 follows track of Path 1, NSLP_Br_ID (for Path 3 and > Path 1) is again set to 1-D-#3 to classify which branch is old and thus > remove the old path. <\snip> In this case NSLP_Br_IDs can differentiate on-going paths. But it may be confused with mobility counter. Therefore, IMO, it would be better that NSLP_Br_ID and path type ID are co-existing (although this discussion would be too implementation specific :)). Thanks, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 02 23:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2IS-0000Xz-Ia; Thu, 02 Mar 2006 23:53:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2IR-0000RE-1Z for nsis@ietf.org; Thu, 02 Mar 2006 23:53:43 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF2IQ-0002Te-Gt for nsis@ietf.org; Thu, 02 Mar 2006 23:53:43 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IVJ00886C9HLE@mailout2.samsung.com> for nsis@ietf.org; Fri, 03 Mar 2006 13:53:41 +0900 (KST) Received: from LocalHost ([75.2.91.249]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IVJ0088UC9HHX@mmp2.samsung.com> for nsis@ietf.org; Fri, 03 Mar 2006 13:53:41 +0900 (KST) Date: Fri, 03 Mar 2006 13:53:40 +0900 From: Sung-Hyuck Lee Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft To: Takako Sanda Message-id: <008e01c63e7e$7114ae60$f95b024b@LocalHost> Organization: SAIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060302173709.0C0A.SANDA.TAKAKO@jp.panasonic.com> <00b501c63df9$8cedbee0$f95b024b@LocalHost> <20060303121944.6A3D.SANDA.TAKAKO@jp.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Takako, ----- Original Message ----- From: "Takako Sanda" To: "Sung-Hyuck Lee" Cc: Sent: Friday, March 03, 2006 12:20 PM Subject: Re: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft > Hi Sung-Hyuck, > > Thank you for your comments. Please see my comments in line. > > Thanks, > Takako > > > On Thu, 02 Mar 2006 22:02:24 +0900 > Sung-Hyuck Lee wrote: > > > > [SHL] I also guess Path type ID seems to be necessary to distinguish > > paths created by mobility from paths established by load balancing. > <\snip> > > I guess the problem statement could be shared :) > > > In this > > case, Path type ID just needs to identify whether a branch is additional for > > load balancing: For example, Path type ID can set as M (multiple path by > > multihoming ) or H (handover). And, NSLP_Br_ID can help classify which > > branch is old and new by its counter. > > > > In the first figure above, CRN also needs to identify which branch is additional > > for load balancing. In this case, Let's assume Path 2 is the additional branch > > for load balancing. When LB-CRN is discovered between Path 1 and Path 2, > > NSLP_Br_ID for Path 1 and Path 2 is set as 1-D-#1 and 1-D-#2 (additional > > path for load balancing), respectively . LB-CRN may perform aggregation for > > downstream flows, not State Update by checking Path type ID for Load > > Balancing. 'CD flag' can be set saying "LB-CRN is discovered." > <\snip> > > Our original thinking of path type usage is a bit different. let me > introduce the idea. > Path type ID is different identifiers for on-going paths, e.g. path type > "a" for path1 and path type "b" for path2 (see figure below). > > Path1 > +--+ aaaaaaaaa +---+ +--+ > | |aa aa|LB |aaa| | > |MN| |CRN|bbb|CN| > | |bb Path2 bb| | | | > +--+ bbbbbbbbb +---+ +--+ > > > And when one path change the route, the same ID is reused, e.g. if path2 > is change to path3, "b" is used for path3.Therefore, when two paths meet, > the CRN check the path type ID of the paths. if they are the same (case1), > the CRN is HO-CRN, and if they are different (case2), the CRN is LB-CRN. > NSLP_Br_ID, especially "mobility counter" parameter, is necessary for > HO-CRN to know which path is old. [SHL] I see. There seem to be just differences on how to use the Path type ID. > (case1) > +--+ aaaaaaaaa +---+ +--+ > | |aa aa|LB |aaa| | > |MN| +---+ |CRN|bbb|CN| > | |bb |HO |bb| | | | > +--+ bbbb|CRN| +---+ +--+ > b b+---+ > bbbb > > (case2) > +--+ aaaaaaaaa +---+ +--+ > | |aa aa|HO |aaa| | > |MN| +---+ |CRN|bbb|CN| > | |bb |LB |bb| | | | > +--+ bbbb|CRN|aa+---+ +--+ > a a+---+ > aaaa > > > > > When a handover occurs, there are two scenarios on CRN created by Path 3. > > One is the case that CRN is created between Path 1 and Path 3 before > > Path 3 meets Path 2. The first case is same as the scenario shown in the > > first figure. NSLP_Br_IDs, for example, are set to 1-D-#1 and 1-D-#2 for > > Path 1 and Path 3, respectively. 'CD' flag is set to LB-CRN and just > > aggregation is performed for downstream flows. And afterwards, when Path 3 > > meets Path2, HO-CRN is discovered and 'CD' flag is set to 'CRN'. In this > > case, although Path 3 follows track of Path 1, NSLP_Br_ID (for Path 3 and > > Path 1) is again set to 1-D-#3 to classify which branch is old and thus > > remove the old path. > <\snip> > > In this case NSLP_Br_IDs can differentiate on-going paths. But it may be > confused with mobility counter. Therefore, IMO, it would be better that > NSLP_Br_ID and path type ID are co-existing (although this discussion > would be too implementation specific :)). [SHL] I guess we say the same thing. :-) In the sentence above, I just mentioned the differences from the scenario shown in your first figure Thanks, Sung-Hyuck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 03 04:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6af-0002rP-EN; Fri, 03 Mar 2006 04:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6af-0002qn-0p for nsis@ietf.org; Fri, 03 Mar 2006 04:28:49 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6aa-0004Yh-LO for nsis@ietf.org; Fri, 03 Mar 2006 04:28:48 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k239SVoW028053; Fri, 3 Mar 2006 09:28:31 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 09:28:31 +0000 Message-ID: <44080C3F.5080906@roke.co.uk> Date: Fri, 03 Mar 2006 09:28:31 +0000 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] PACKET_CLASSIFIER in RESERVE adn QUERY References: <024b01c61854$0760ed30$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <024b01c61854$0760ed30$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 09:28:31.0723 (UTC) FILETIME=[D647DBB0:01C63EA4] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "Nsis \(E-mail\)" 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, A long time ago, Georgios Karagiannis wrote: > During some previous discussions have been emphasized that the > PACKET_CLASSIFIER is only usefull > if it is carried by RESERVE messages. > The other three QOS-NSLP messages, i.e., QUERY, NOTIFY and RESPONSE > messages do not need > to carry the PACKET_CLASSIFIER object. > I think that I would agree that the messages NOTIFY and RESPONSE do not > need to carry > the PACKET_CLASSIFIER > object, but I think that we should provide the > ability to future QoS models to use the PACKET_CLASSIFIER also in the > QUERY messages. > > Thus my proposal is: > > * Provide the possibility to use the PACKET_CLASSIFIER in RESERVE and > QUERY messages. I think this was addressed by adding the PACKET_CLASSIFIER in to the BNF for the QUERY. In draft -09, RESERVE is defined as: RESERVE = COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] [ POLICY_DATA ] [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] QUERY is: QUERY = COMMON_HEADER [ RII ][ n*BOUND_SESSION_ID ] [ POLICY_DATA ] PACKET_CLASSIFIER QSPEC [ QSPEC ] So, in RESERVE PACKET_CLASSIFIER is optional, whereas in QUERY it is compulsory. The optionality of PACKET_CLASSIFIER in RESERVE is linked in the text to reduced refreshes. But, the BNF says that you can have a QSPEC but not PACKET_CLASSIFIER. So, should the BNF be something more like: RESERVE = COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] [ POLICY_DATA ] [ PACKET_CLASSIFIER QSPEC [ QSPEC ] ] As an additional thought, in many cases the packet classifier will be the same as the MRI. So, could absence of a PACKET_CLASSIFIER object, when a QSPEC is provided, indicate that packet classification should be done using the whole MRI? The resulting BNF would be: RESERVE = COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] [ POLICY_DATA ] [ [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] ] QUERY = COMMON_HEADER [ RII ][ n*BOUND_SESSION_ID ] [ POLICY_DATA ] [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] Any opinions? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 03 04:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6cv-0006IO-Ix; Fri, 03 Mar 2006 04:31:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6cu-00068K-5a for nsis@ietf.org; Fri, 03 Mar 2006 04:31:08 -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 1FF6ct-0004fr-NO for nsis@ietf.org; Fri, 03 Mar 2006 04:31:08 -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; Fri, 03 Mar 2006 11:31:06 +0200 id 000702F0.44080CDA.0000737D Date: Fri, 3 Mar 2006 11:31:06 +0200 (EET) From: Jukka MJ Manner To: Andrew McDonald Subject: Re: [NSIS] PACKET_CLASSIFIER in RESERVE adn QUERY In-Reply-To: <44080C3F.5080906@roke.co.uk> Message-ID: References: <024b01c61854$0760ed30$4c0d5982@dynamic.ewi.utwente.nl> <44080C3F.5080906@roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Georgios Karagiannis , "Nsis \\\(E-mail\\\)" 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, fine with me. Jukka On Fri, 3 Mar 2006, Andrew McDonald wrote: > Hi Georgios, > > A long time ago, > Georgios Karagiannis wrote: > > During some previous discussions have been emphasized that the > > PACKET_CLASSIFIER is only usefull > > if it is carried by RESERVE messages. > > The other three QOS-NSLP messages, i.e., QUERY, NOTIFY and RESPONSE messages > > do not need > > to carry the PACKET_CLASSIFIER object. > > I think that I would agree that the messages NOTIFY and RESPONSE do not need > > to carry > > the PACKET_CLASSIFIER > > object, but I think that we should provide the > > ability to future QoS models to use the PACKET_CLASSIFIER also in the QUERY > > messages. > > Thus my proposal is: > > * Provide the possibility to use the PACKET_CLASSIFIER in RESERVE and QUERY > > messages. > > I think this was addressed by adding the PACKET_CLASSIFIER in to the BNF for > the QUERY. > > In draft -09, RESERVE is defined as: > RESERVE = COMMON_HEADER > RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] > [ POLICY_DATA ] [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] > > QUERY is: > QUERY = COMMON_HEADER > [ RII ][ n*BOUND_SESSION_ID ] > [ POLICY_DATA ] PACKET_CLASSIFIER QSPEC [ QSPEC ] > > So, in RESERVE PACKET_CLASSIFIER is optional, whereas in QUERY it is > compulsory. > > The optionality of PACKET_CLASSIFIER in RESERVE is linked in the text to > reduced refreshes. But, the BNF says that you can have a QSPEC but not > PACKET_CLASSIFIER. So, should the BNF be something more like: > RESERVE = COMMON_HEADER > RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] > [ POLICY_DATA ] [ PACKET_CLASSIFIER QSPEC [ QSPEC ] ] > > As an additional thought, in many cases the packet classifier will be the same > as the MRI. So, could absence of a PACKET_CLASSIFIER object, when a QSPEC is > provided, indicate that packet classification should be done using the whole > MRI? > > The resulting BNF would be: > RESERVE = COMMON_HEADER > RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] > [ POLICY_DATA ] [ [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] ] > QUERY = COMMON_HEADER > [ RII ][ n*BOUND_SESSION_ID ] > [ POLICY_DATA ] [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] > > Any opinions? > > 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 Fri Mar 03 04:34:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6ft-0000SB-CW; Fri, 03 Mar 2006 04:34:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6fs-0000S0-1G for nsis@ietf.org; Fri, 03 Mar 2006 04:34:12 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6fp-0004p8-BG for nsis@ietf.org; Fri, 03 Mar 2006 04:34:12 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k239XooW029367; Fri, 3 Mar 2006 09:33:50 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Mar 2006 09:33:50 +0000 Message-ID: <44080D7E.8080808@roke.co.uk> Date: Fri, 03 Mar 2006 09:33:50 +0000 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] PACKET_CLASSIFIER in RESERVE adn QUERY References: <024b01c61854$0760ed30$4c0d5982@dynamic.ewi.utwente.nl> <44080C3F.5080906@roke.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 09:33:50.0487 (UTC) FILETIME=[94476270:01C63EA5] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Georgios Karagiannis , "Nsis \\\(E-mail\\\)" 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: > fine with me. Which one? The basic fix to the RESERVE BNF, or the absence of PACKET_CLASSIFER means that you use the full MRI? :-) Andrew > On Fri, 3 Mar 2006, Andrew McDonald wrote: > > >>Hi Georgios, >> >>A long time ago, >>Georgios Karagiannis wrote: >> >>>During some previous discussions have been emphasized that the >>>PACKET_CLASSIFIER is only usefull >>>if it is carried by RESERVE messages. >>>The other three QOS-NSLP messages, i.e., QUERY, NOTIFY and RESPONSE messages >>>do not need >>>to carry the PACKET_CLASSIFIER object. >>>I think that I would agree that the messages NOTIFY and RESPONSE do not need >>>to carry >>>the PACKET_CLASSIFIER >>>object, but I think that we should provide the >>>ability to future QoS models to use the PACKET_CLASSIFIER also in the QUERY >>>messages. >>> Thus my proposal is: >>> * Provide the possibility to use the PACKET_CLASSIFIER in RESERVE and QUERY >>>messages. >> >>I think this was addressed by adding the PACKET_CLASSIFIER in to the BNF for >>the QUERY. >> >>In draft -09, RESERVE is defined as: >> RESERVE = COMMON_HEADER >> RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] >> [ POLICY_DATA ] [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] >> >>QUERY is: >> QUERY = COMMON_HEADER >> [ RII ][ n*BOUND_SESSION_ID ] >> [ POLICY_DATA ] PACKET_CLASSIFIER QSPEC [ QSPEC ] >> >>So, in RESERVE PACKET_CLASSIFIER is optional, whereas in QUERY it is >>compulsory. >> >>The optionality of PACKET_CLASSIFIER in RESERVE is linked in the text to >>reduced refreshes. But, the BNF says that you can have a QSPEC but not >>PACKET_CLASSIFIER. So, should the BNF be something more like: >> RESERVE = COMMON_HEADER >> RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] >> [ POLICY_DATA ] [ PACKET_CLASSIFIER QSPEC [ QSPEC ] ] >> >>As an additional thought, in many cases the packet classifier will be the same >>as the MRI. So, could absence of a PACKET_CLASSIFIER object, when a QSPEC is >>provided, indicate that packet classification should be done using the whole >>MRI? >> >>The resulting BNF would be: >> RESERVE = COMMON_HEADER >> RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] >> [ POLICY_DATA ] [ [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] ] >> QUERY = COMMON_HEADER >> [ RII ][ n*BOUND_SESSION_ID ] >> [ POLICY_DATA ] [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] >> >>Any opinions? >> >>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 -- Andrew McDonald, Senior Engineer Roke Manor Research Ltd, Romsey, Hants SO51 0ZN Phone +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 Fri Mar 03 04:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6sm-0005ML-Ev; Fri, 03 Mar 2006 04:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6sk-0005IW-BN for nsis@ietf.org; Fri, 03 Mar 2006 04:47:30 -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 1FF6sj-0005Bl-T9 for nsis@ietf.org; Fri, 03 Mar 2006 04:47:30 -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; Fri, 03 Mar 2006 11:47:29 +0200 id 000700C6.440810B1.00000F6B Date: Fri, 3 Mar 2006 11:47:29 +0200 (EET) From: Jukka MJ Manner To: Andrew McDonald Subject: Re: [NSIS] PACKET_CLASSIFIER in RESERVE adn QUERY In-Reply-To: <44080D7E.8080808@roke.co.uk> Message-ID: References: <024b01c61854$0760ed30$4c0d5982@dynamic.ewi.utwente.nl> <44080C3F.5080906@roke.co.uk> <44080D7E.8080808@roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Georgios Karagiannis , "Nsis \\\\\(E-mail\\\\\)" 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 meant the latter one. Jukka On Fri, 3 Mar 2006, Andrew McDonald wrote: > Jukka MJ Manner wrote: > > fine with me. > > Which one? The basic fix to the RESERVE BNF, or the absence of > PACKET_CLASSIFER means that you use the full MRI? > :-) > > Andrew > > > On Fri, 3 Mar 2006, Andrew McDonald wrote: > > > > > > > Hi Georgios, > > > > > > A long time ago, > > > Georgios Karagiannis wrote: > > > > > > > During some previous discussions have been emphasized that the > > > > PACKET_CLASSIFIER is only usefull > > > > if it is carried by RESERVE messages. > > > > The other three QOS-NSLP messages, i.e., QUERY, NOTIFY and RESPONSE > > > > messages > > > > do not need > > > > to carry the PACKET_CLASSIFIER object. > > > > I think that I would agree that the messages NOTIFY and RESPONSE do not > > > > need > > > > to carry > > > > the PACKET_CLASSIFIER > > > > object, but I think that we should provide the > > > > ability to future QoS models to use the PACKET_CLASSIFIER also in the > > > > QUERY > > > > messages. > > > > Thus my proposal is: > > > > * Provide the possibility to use the PACKET_CLASSIFIER in RESERVE and > > > > QUERY > > > > messages. > > > > > > I think this was addressed by adding the PACKET_CLASSIFIER in to the BNF > > > for > > > the QUERY. > > > > > > In draft -09, RESERVE is defined as: > > > RESERVE = COMMON_HEADER > > > RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] > > > [ POLICY_DATA ] [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] > > > > > > QUERY is: > > > QUERY = COMMON_HEADER > > > [ RII ][ n*BOUND_SESSION_ID ] > > > [ POLICY_DATA ] PACKET_CLASSIFIER QSPEC [ QSPEC ] > > > > > > So, in RESERVE PACKET_CLASSIFIER is optional, whereas in QUERY it is > > > compulsory. > > > > > > The optionality of PACKET_CLASSIFIER in RESERVE is linked in the text to > > > reduced refreshes. But, the BNF says that you can have a QSPEC but not > > > PACKET_CLASSIFIER. So, should the BNF be something more like: > > > RESERVE = COMMON_HEADER > > > RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] > > > [ POLICY_DATA ] [ PACKET_CLASSIFIER QSPEC [ QSPEC ] ] > > > > > > As an additional thought, in many cases the packet classifier will be the > > > same > > > as the MRI. So, could absence of a PACKET_CLASSIFIER object, when a QSPEC > > > is > > > provided, indicate that packet classification should be done using the > > > whole > > > MRI? > > > > > > The resulting BNF would be: > > > RESERVE = COMMON_HEADER > > > RSN [ RII ] [ REFRESH_PERIOD ] [ n*BOUND_SESSION_ID ] > > > [ POLICY_DATA ] [ [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] ] > > > QUERY = COMMON_HEADER > > > [ RII ][ n*BOUND_SESSION_ID ] > > > [ POLICY_DATA ] [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] > > > > > > Any opinions? > > > > > > 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 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 03 16:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHyC-0002a2-HP; Fri, 03 Mar 2006 16:37:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHyA-0002Zg-Ii for nsis@ietf.org; Fri, 03 Mar 2006 16:37:50 -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 1FFHy9-0005e5-83 for nsis@ietf.org; Fri, 03 Mar 2006 16:37:50 -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; Fri, 03 Mar 2006 23:37:47 +0200 id 000701D9.4408B72B.0000472B Date: Fri, 3 Mar 2006 23:37:47 +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 Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [NSIS] I-D ACTION:draft-manner-nsis-nslp-auth-00.txt (fwd) 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 submitted the following I-D about how to provide authorization information within NSLPs. The work is based on RFC3520, and adapted for use in NSIS. Any feedback, e.g., on whether people feel, as the three of us do, that this would be good to have are always welcome. There are some sections that we intend to fix once I-Ds can again be submitted after the Dallas meeting. Regards, Jukka ---------- Forwarded message ---------- Date: Wed, 01 Mar 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-manner-nsis-nslp-auth-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Authorization for NSIS Signaling Layer Protocols Author(s) : J. Manner, et al. Filename : draft-manner-nsis-nslp-auth-00.txt Pages : 24 Date : 2006-3-1 Signaling layer protocols in the NSIS working group may rely on GIST to handle authorization. Still, in certain cases, the signaling layer protocol may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-nsis-nslp-auth-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 03 19:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKIN-0008Hp-1v; Fri, 03 Mar 2006 19:06:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKD7-0002eB-3z for nsis@ietf.org; Fri, 03 Mar 2006 19:01:25 -0500 Received: from natsluvver.rzone.de ([81.169.145.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFKD1-0005wb-UY for nsis@ietf.org; Fri, 03 Mar 2006 19:01:24 -0500 Received: from [192.67.198.62] (p54848EF2.dip0.t-ipconnect.de [84.132.142.242]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k24011WS004022; Sat, 4 Mar 2006 01:01:02 +0100 (MET) Message-ID: <4408D872.9050003@cs.uni-goettingen.de> Date: Sat, 04 Mar 2006 00:59:46 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP updated References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Jukka, a few things are not quite clear to me: Who is responsible to trigger the Refresh Messages? Is it the QNI or the Client Application connected to the QNI? Who is allowed to tear down a session? Is it only the QNI or the QNR as well in both sender initiated and receiver initiated reservations? On page 41 the field 'Class' is the 4-bit error class. Is this the same as the severity class in the sentence below the diagram ("The first four bits of the error code indicates the severity class.")? If yes, that would mean that the 4 most significant bits of the error code represent the error class. But these are two independent objects. E.g. the bit representation for the error code 0x01 is: 0000 0000 0001. The error class would be 0x00. What is the reason to split up the objects in 4, 12 and 8 bits? This means we can have up to 16 error classes, 4096 error codes and 256 error subcodes. Do we need so many error codes? From programmer's view the 4-bit field is a possible source for bugs as you have to mask and shift bits. On page 61, in the first paragraph about the QUERY messages with set R-bit, is it possible that QNI and QNR are mixed up? Compared to the figure on page 22, the QUERY message travels from QNR to QNI and the QNI would create a RESERVE message. On page 63, IANA considerations the QoS NSLP Message Type is a 16 bit value. It's a 8 bit field on page 33. A bit further there are 7 objects listed (not 6). Thanks, Bernd Jukka MJ Manner wrote: > Dear all, > > I have now updated the QoS NSLP draft. The changes are: > > - Edits based on two sets of comments from Jerry and Roland, most changes > are in 5.2.4 and 5.3.6. > > - Re-named some of the references (I hated those loooooong ref names) ;) > > - Re-arranged the references > > - Removed the changelog > > - Re-wrote a bit the IANA considerations section > > > I'm now running out of ideas of what to edit further. If I don't hear > otherwise, I'm going to make a final sanity check during the weekend, and > submit this version for consideration by the ADs and the IESG. > > As usual, a diff is available here: > > http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-09-10.html > > 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 Sat Mar 04 08:50:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFX8x-0001FV-Fj; Sat, 04 Mar 2006 08:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFX8w-0001Cl-FL for nsis@ietf.org; Sat, 04 Mar 2006 08:49: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 1FFX8u-0000Ek-0W for nsis@ietf.org; Sat, 04 Mar 2006 08:49:58 -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, 04 Mar 2006 15:49:54 +0200 id 000701E6.44099B02.0000310F Date: Sat, 4 Mar 2006 15:49:54 +0200 (EET) From: Jukka MJ Manner To: Bernd Schloer Subject: Re: [NSIS] QoS NSLP updated In-Reply-To: <4408D872.9050003@cs.uni-goettingen.de> Message-ID: References: <4408D872.9050003@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, Some answers below: On Sat, 4 Mar 2006, Bernd Schloer wrote: > Hi Jukka, > > a few things are not quite clear to me: > > Who is responsible to trigger the Refresh Messages? Is it the QNI or the > Client Application connected to the QNI? Page 4: "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205], and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e. state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signalling path)." > > Who is allowed to tear down a session? Is it only the QNI or the QNR as well > in both sender initiated and receiver initiated reservations? An actual tearing RESERVE can only be sent towards the QNR. Any QNE can send a NOTIFY upstream, e.g., to indicate an error situation that should the same effect as a tear. A real tear can only be sent with a RESERVE. > > On page 41 the field 'Class' is the 4-bit error class. Is this the same > as the severity class in the sentence below the diagram ("The first four > bits of the error code indicates the severity class.")? If yes, that > would mean that the 4 most significant bits of the error code represent > the error class. But these are two independent objects. E.g. the bit > representation for the error code 0x01 is: 0000 0000 0001. The error > class would be 0x00. Yes, this should say "error class". There are six error classes, and within them 12-bits of error values, in each class. > > What is the reason to split up the objects in 4, 12 and 8 bits? This > means we can have up to 16 error classes, 4096 error codes and 256 error > subcodes. Do we need so many error codes? From programmer's view the > 4-bit field is a possible source for bugs as you have to mask and shift > bits. This has been deemed a usefull way to split 24 bits used for error reporting. Don't see a reason to change this. > > On page 61, in the first paragraph about the QUERY messages with set > R-bit, is it possible that QNI and QNR are mixed up? Compared to the > figure on page 22, the QUERY message travels from QNR to QNI and the QNI > would create a RESERVE message. This should be the QNI. > > On page 63, IANA considerations the QoS NSLP Message Type is a 16 bit value. > It's a 8 bit field on page 33. A bit further there are 7 objects listed (not > 6). This was fixed in my current editor's version, and appears in the diff. Thanks, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 04 09:36:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFXrU-0000Bc-Fy; Sat, 04 Mar 2006 09:36:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFXrT-0000BX-I3 for nsis@ietf.org; Sat, 04 Mar 2006 09:35:59 -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 1FFXrR-0001yw-8G for nsis@ietf.org; Sat, 04 Mar 2006 09:35:59 -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, 04 Mar 2006 16:35:55 +0200 id 00070210.4409A5CB.000007A0 Date: Sat, 4 Mar 2006 16:35:55 +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: d6b246023072368de71562c0ab503126 Subject: [NSIS] Qos NSLP updated, again 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've fixed some typos and mistakes (thanks, Bernd), and added a bit of text to the PACKET_CLASSIFIER discussions in three sections in the document, suggested by Andrew. I also changed the language to US english, which seems to be more commonly used in the IETF (and makes spell checking easier for me). I'll fix the formatting as the last step (e.g. pictures breaking accross pages) before submitting. A new diff is here: http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-09-10.html Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 04:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGCPJ-0004lb-SX; Mon, 06 Mar 2006 04:53:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGCPI-0004ku-Ir; Mon, 06 Mar 2006 04:53:36 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGAj5-0004RL-9D; Mon, 06 Mar 2006 03:05:55 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGATi-0004oo-5K; Mon, 06 Mar 2006 02:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k267o10e004166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGATh-0008La-P0; Mon, 06 Mar 2006 02:50:01 -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, 06 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-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 : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-01.txt Pages : 12 Date : 2006-3-5 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM control processing guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-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-y1541-qosm-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-y1541-qosm-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: <2006-3-5193212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-y1541-qosm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-5193212.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 Mon Mar 06 06:25:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDpo-0000yN-TM; Mon, 06 Mar 2006 06:25:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDpn-0000yI-RA for nsis@ietf.org; Mon, 06 Mar 2006 06:25:03 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDpm-0004vt-83 for nsis@ietf.org; Mon, 06 Mar 2006 06:25:03 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BOsn2028838; Mon, 6 Mar 2006 13:24:55 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:24:54 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:24:54 +0200 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 extensibility concern (IANA considerations) Date: Mon, 6 Mar 2006 13:24:53 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DC2@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST extensibility concern (IANA considerations) Thread-Index: AcYyPKywB7NeaKkCTVWntP1TtMeKggAmdBoAA446bEA= From: To: , X-OriginalArrivalTime: 06 Mar 2006 11:24:54.0100 (UTC) FILETIME=[97574940:01C64110] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 Catching up ... >a quick comment on the message type/protocol id/mrm aspects. > >i think there are actually two aspects here: >- whether GIST can cope (in some sense) with new protocol > numbers >- whether experimental numbers are useful > >we have to be able to do the first, whether the new protocol=20 >number comes because of an experiment or some other official=20 >assignment. In the three cases mentioned, I think the spec is >ok: >- unknown message types are rejected with an error (don't > change subsequent processing) >- unknown protocol IDs are ignored (when deciding what type > of MA to build) Agreed >the case of an unknown MRM is slightly more subtle; it was=20 >discussed in the thread starting here=20 >http://www1.ietf.org/mail-archive/web/nsis/current/msg05367.html >the upshot is that you should only get experimental MRMs with=20 >experimental NSLPs; and if you don't support the experimental=20 >NSLP you ignore the MRM.=20 > >so I think that experimental values for these are safe in the=20 >sense that unknown values are handled correctly. I agree. I think that experimental MRMs are needed for testing in a local environment. >of course, they are not safe if people adopt conflicting=20 >definitions of the unknown values. so the only environment in=20 >which valid experiments can be done is some sort of=20 >closed/private one (i.e. >one in which the experimenter knows all the experiments that=20 >are in progress). i think this is (implicitly) the type of=20 >experiment that rfc3692 is talking about. I still think it's=20 >useful to have an assignment range for that type of=20 >experiment, because it guarantees that some kind of software=20 >upgrade that brings in non- experimental new protocol numbers=20 >(e.g. because of some other standards work or expert review)=20 >will not suddenly cause a collision. it's a not very=20 >sophisticated mechanism for a not very ambitious goal. Agreed - that is the idea of 3692, or at least my reading of it. >it may be that the IANA section (whatever else we do with it)=20 >should be more explicit about what 'private/experimental'=20 >means, including possibly a reference to 3692. i'd like not to=20 >ban experiments, especially in the protocol ID and MRM cases,=20 >because actually I can think of some very interesting=20 >experiments to do there. Agreed. >cheers, > >r. > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: 15 February 2006 14:32 >> To: john.loughney@nokia.com >> Cc: Hancock, Robert; nsis@ietf.org >> Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) >>=20 >>=20 >> John, >>=20 >> Let me try to make some suggestions: >>=20 >> NSLP Identifier: >> Seems likely to need experiments and there's a=20 >pretty-well defined=20 >> mechanism for ignoring unknown NSLPs. I would suggest an escape code=20 >> and a new TLV field. One possibility that avoids registration is to=20 >> use a UUID, which is 128 bits. See RFC 4122 for the text version. An=20 >> alternative is to use the enterprise codes and an=20 >enterprise-specific=20 >> number (say, 16 bits). See >> http://www.iana.org/assignments/enterprise- >> numbers This would be a total of 48 bits, assuming 32 bits are long=20 >> enough for an enterprise number. >>=20 >> GIST Message Type: >> Seems less likely to need experiments and experiments seem more=20 >> dangerous, as it is unclear how well nodes that don't understand=20 >> message types can deal with them. I would suggest dropping private/=20 >> experimental use, given that there is an expert review space that=20 >> should make getting an identifier reasonably easy. >>=20 >> Object Types: >> Similar to NSLP identifier. Define an extension object=20 >that always=20 >> starts with a UUID or the enterprise code/type. >>=20 >> Message Routing Methods: >> Again, experiments seem likely to be disruptive. What do=20 >I do with=20 >> an unknown MRI? Thus, I'd suggest dropping the experimental range. >>=20 >> MA-Protocol-ID >> same >>=20 >> I think a basic issue is as to how well a system can deal=20 >with unknown=20 >> values. In some cases, it can, at best, generate an error and=20 >> terminate the flow of GIST messages. In others, such as the NSLP=20 >> identifier, it can ignore the value. >>=20 >> Is this a bit less vague? >>=20 >> Henning >>=20 >>=20 >> On Feb 15, 2006, at 2:42 AM, wrote: >>=20 >> > Hi Henning, >> > >> > Its unclear what kind of extensibility you'd like and the usage=20 >> > model of the extensiblity. If you had a more concrete=20 >proposal, it=20 >> > might be easier to follow. >> > >> > I'm basically following the extensibility model proposed=20 >in rfc3692. =20 >> > Also, I think that GIST will be a more 'standard' >> > transport protocol, where open extesibility is discouraged (as in=20 >> > TCP, SCTP, DCCP, etc). >> > >> > John >> >>> >>=20 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 06:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDsY-0005FB-5U; Mon, 06 Mar 2006 06:27:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDsX-0005E6-5H for nsis@ietf.org; Mon, 06 Mar 2006 06:27:53 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDsV-000519-Ni for nsis@ietf.org; Mon, 06 Mar 2006 06:27:53 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BQkL7029677; Mon, 6 Mar 2006 13:26:54 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:27:29 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:27:29 +0200 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: Mon, 6 Mar 2006 13:27:28 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DC3@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extended WGLC was: QoS NSLP going forward Thread-Index: AcY8thcFL4qXZydpSoWrU1VlLL1bTQEWqEzw From: To: , X-OriginalArrivalTime: 06 Mar 2006 11:27:29.0038 (UTC) FILETIME=[F3B0F2E0:01C64110] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [NSIS] Extended WGLC was: QoS NSLP going forward 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, A few people have commented that they may have a few points still to raise but have been caught up in the submission deadline rush, so I'll extend the comment period until this Friday March 10th. John >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 28 February, 2006 23:05 >To: nsis@ietf.org >Subject: [NSIS] QoS NSLP going forward > > >Dear all, > >There were no specific issues raised during the WG Last Call.=20 >I got one set of comments offline from Jerry, and Roland sent=20 >a few comments, too. =20 >I'll make those, and do an overall sanity check before=20 >submitting v. 10 by Monday morning. I won't be in Dallas due=20 >to family issues, but I guess there is not much to discuss=20 >about the QoS NSLP anyway. ;) > >Regards, >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 06 06:30:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDvI-0007AT-64; Mon, 06 Mar 2006 06:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDvG-0007AO-Qx for nsis@ietf.org; Mon, 06 Mar 2006 06:30:42 -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 1FGDvF-00054N-Fe for nsis@ietf.org; Mon, 06 Mar 2006 06:30:42 -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; Mon, 06 Mar 2006 13:30:40 +0200 id 00070239.440C1D60.00002524 Date: Mon, 6 Mar 2006 13:30:40 +0200 (EET) From: Jukka MJ Manner To: john.loughney@nokia.com In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DC3@esebe100.NOE.Nokia.com> Message-ID: References: <1AA39B75171A7144A73216AED1D7478D01869DC3@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nsis@ietf.org Subject: [NSIS] Re: Extended WGLC was: QoS NSLP going forward 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 So, will I be submitting a new I-D today in about two hours, or wait until we get all possible comments? Jukka On Mon, 6 Mar 2006 john.loughney@nokia.com wrote: > Jukka, > > A few people have commented that they may have a few points still > to raise but have been caught up in the submission deadline rush, > so I'll extend the comment period until this Friday March 10th. > > John > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 28 February, 2006 23:05 > >To: nsis@ietf.org > >Subject: [NSIS] QoS NSLP going forward > > > > > >Dear all, > > > >There were no specific issues raised during the WG Last Call. > >I got one set of comments offline from Jerry, and Roland sent > >a few comments, too. > >I'll make those, and do an overall sanity check before > >submitting v. 10 by Monday morning. I won't be in Dallas due > >to family issues, but I guess there is not much to discuss > >about the QoS NSLP anyway. ;) > > > >Regards, > >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 06 06:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDxE-0007tm-S1; Mon, 06 Mar 2006 06:32:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDxE-0007tg-2q for nsis@ietf.org; Mon, 06 Mar 2006 06:32:44 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDxD-00057s-L3 for nsis@ietf.org; Mon, 06 Mar 2006 06:32:44 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BWekq004766; Mon, 6 Mar 2006 13:32:42 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:32:26 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:32:27 +0200 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: Mon, 6 Mar 2006 13:32:25 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DC5@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extended WGLC was: QoS NSLP going forward Thread-Index: AcZBEW6DO3rooPHzQBi9gLXIpOA5fAAAChbQ From: To: X-OriginalArrivalTime: 06 Mar 2006 11:32:27.0035 (UTC) FILETIME=[A54FAEB0:01C64111] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nsis@ietf.org Subject: [NSIS] RE: Extended WGLC was: QoS NSLP going forward 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 Submit it, and if there are any major comments, we can take care of it later -=20 if there are no comments, then we are in good shape. john=20 >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 06 March, 2006 13:31 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org >Subject: Re: Extended WGLC was: QoS NSLP going forward > > >So, will I be submitting a new I-D today in about two hours,=20 >or wait until we get all possible comments? > >Jukka > >On Mon, 6 Mar 2006 john.loughney@nokia.com wrote: > >> Jukka, >>=20 >> A few people have commented that they may have a few points still to=20 >> raise but have been caught up in the submission deadline=20 >rush, so I'll=20 >> extend the comment period until this Friday March 10th. >>=20 >> John >>=20 >> >-----Original Message----- >> >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> >Sent: 28 February, 2006 23:05 >> >To: nsis@ietf.org >> >Subject: [NSIS] QoS NSLP going forward >> > >> > >> >Dear all, >> > >> >There were no specific issues raised during the WG Last Call.=20 >> >I got one set of comments offline from Jerry, and Roland sent a few=20 >> >comments, too. >> >I'll make those, and do an overall sanity check before=20 >submitting v.=20 >> >10 by Monday morning. I won't be in Dallas due to family=20 >issues, but=20 >> >I guess there is not much to discuss about the QoS NSLP anyway. ;) >> > >> >Regards, >> >Jukka >> > >> >_______________________________________________ >> >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 06 06:34:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDyW-00009a-E8; Mon, 06 Mar 2006 06:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDyV-00009V-GI for nsis@ietf.org; Mon, 06 Mar 2006 06:34:03 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDyV-000598-26 for nsis@ietf.org; Mon, 06 Mar 2006 06:34:03 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BY2RN005951; Mon, 6 Mar 2006 13:34:02 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:34:02 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:34:01 +0200 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] NATFW Issue 60: Signaling for ICMP policy rules Date: Mon, 6 Mar 2006 13:34:01 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DC6@esebe100.NOE.Nokia.com> In-Reply-To: <10352744-54AB-4468-A301-EF165654A16C@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW Issue 60: Signaling for ICMP policy rules Thread-Index: AcY5KO0CsKeGLa/cQS2HltrINEiVnwH6OvjQ From: To: , X-OriginalArrivalTime: 06 Mar 2006 11:34:01.0836 (UTC) FILETIME=[DDD12AC0:01C64111] X-Spam-Score: 0.2 (/) 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 This looks good to me. John=20 >-----Original Message----- >From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 >Sent: 24 February, 2006 11:55 >To: nsis >Subject: [NSIS] NATFW Issue 60: Signaling for ICMP policy rules > >Hi all, > >We have had the discussions about adding ICMP policy rules to=20 >the NATFW NSLP. A short summary of the topic: > >3GPP2 requested a feature to signal for ICMP policy rules,=20 >i.e., a NATFW node should be able to block a certain type of=20 >ICMP traffic, but not meaning ICMP traffic bound to an already=20 >configured flow (for instance, ICMP messages related to a TCP session). > >Elwyn propose this object to carry ICMP information within the NATFW >NSLP: > >4.2.10 ICMP Types Object > > The 'ICMP types' object contains additional information needed to > configure a NAT of firewall with rules to control ICMP=20 >traffic. The > object contains a number of values of the ICMP Type field=20 >for which a > filter action should be set up: > > Type: NATFW_ICMP_TYPES > > Length: Variable =3D ((Number of Types carried + 1) + 3) DIV 4 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Count | Type | Type | ........ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ................ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ........ | Type | (Padding) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 34: ICMP Types Object > > The fields MUST be interpreted according these rules: > > count: 8 bit integer specifying the number of 'Type' entries in > the object. > > type: 8 bit field specifying the ICMP Type values to which this > rule applies. > > padding: Sufficient 0 bits to pad out the last word so that the > total size of object is an even multiple of words. Ignored on > reception. > >_______________________________________________ >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 06 06:34:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDz4-0000rJ-SC; Mon, 06 Mar 2006 06:34:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDz3-0000rE-KM for nsis@ietf.org; Mon, 06 Mar 2006 06:34:37 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDz0-00059n-4K for nsis@ietf.org; Mon, 06 Mar 2006 06:34:37 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BYWfD018728; Mon, 6 Mar 2006 13:34:33 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:34:33 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:34:33 +0200 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] NATFW Issue 63: Aggregation of NSLP signaling messages (wassignaling session wildcarding) Date: Mon, 6 Mar 2006 13:34:32 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DC7@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW Issue 63: Aggregation of NSLP signaling messages (wassignaling session wildcarding) Thread-Index: AcY99V7vBBJeu1JPQ72rS7yomoBVlgDHIvFQ From: To: , X-OriginalArrivalTime: 06 Mar 2006 11:34:33.0005 (UTC) FILETIME=[F0652DD0:01C64111] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 This looks good to me.=20 >-----Original Message----- >From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 >Sent: 02 March, 2006 14:31 >To: nsis >Subject: [NSIS] NATFW Issue 63: Aggregation of NSLP signaling=20 >messages (wassignaling session wildcarding) > >Dear all, > >The issue 63 (https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/ >issue63) >refers to the below section out of the 3GPP2 requirements draft >(http://www.watersprings.org/pub/id/draft-bajko-nsis-fw-reqs-04.txt) > >5.1.7 Efficient use of the air interface > > The protocol MUST allow an end point to create, modify or delete > several firewall states with one protocol instance. > > NOTE: a Firewall Configuration Protocol should provide a solution > for the above requirement in a single Firewall architecture. In a > multihomed scenario, with multiple Firewalls on alternative paths, > there should be a means for the Firewalls to keep themselves > synchronized. > > This capability is useful in some wireless networks, where the > access link resources are limited. This would reduce the overhead > and the delay of the procedures. > > It MUST be possible to open a pinhole with a single protocol > request/response pair of messages. This is required because: > a) a wireless link is a scarce and expensive resource > b) real-time applications are delay sensitive > >After further discussions with Gabor we have concluded that=20 >basically a function is needed to teardown multiple session=20 >belonging to a single NATFW NSLP node. For instance, if a=20 >mobile terminal is shutting down, it can send a single NATFW=20 >NSLP message and all session concerned will be terminated. >The solution to this is similar to the NOTIFY storm avoidance.=20 >For NOTIFY the upcoming version of the draft contains: > > To avoid the need of generating per signaling session=20 >NOTIFY message > in such a described or similar scenario, NFs SHOULD follow this > procedure: The NF uses the NOTIFY message with the session=20 >ID in the > NTLP set to zero, with the MRI completely wildcarded, and the > 'explicit routing' as described in Sections 5.2.1 and=20 >7.1.4. in [1]. > The upstream NF receiving this type of NOTIFY immediately=20 >regards all > signaling sessions from that peer matching the MRI as void. > >(taken from here: http://www.stiemerling.org/ietf/nsis/snapshot/ >snapshot.txt) > >The teardown of all session for a specific node could be done=20 >in this way >- Set the MRI to source IP address of the node >- wildcard all other parameter >- Set SID to zero >- Use 'explicit routing' in the NTLP >- NSLP message with lifetime set to zero > >Any thoughts, comments, or objections about it? > > Martin > > >_______________________________________________ >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 06 07:51:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFBg-00036o-Ju; Mon, 06 Mar 2006 07:51:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFBe-00036e-SB for nsis@ietf.org; Mon, 06 Mar 2006 07:51:42 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFBe-00080N-Aw for nsis@ietf.org; Mon, 06 Mar 2006 07:51:42 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26CpaFH018137; Mon, 6 Mar 2006 14:51:39 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 14:51:39 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 14:51:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Mar 2006 14:51:37 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DDA@esebe100.NOE.Nokia.com> In-Reply-To: <391E6FBF5E786940B9E2F7CA6376C708DE469C@blns00fa.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Thread-Index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhg From: To: X-OriginalArrivalTime: 06 Mar 2006 12:51:38.0529 (UTC) FILETIME=[B56C2110:01C6411C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com Subject: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs 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="===============1361050774==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1361050774== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6411C.B502B678" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6411C.B502B678 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to be updated. It is too unprecise currently.=20 It says: "New QSPECs require IETF action which defines the elements within the QSPEC".=20 (i) it probably should be "QoS Models" rather than QSPECs. One could go on and say how new QSPEC parameters (elements???) are defined but this is detailed in the QSPEC ID so it should suffice to provide a pointer.=20 Fixed.=20 (ii) "IETF Action" what exactly is that? I've recently been studying the IANA RFC 2434 and this is not defined there. Or is this vague on purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were wondering what kind of IETF action is required for defining new QOSMs / QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification required" or "IETF Consensus" in IANA language !?) or standards track (=3D> "standards action" in IANA language)? We are currently assuming it is just "specification required" and updated the QSPEC ID accordingly. Note this implies that new _optional_ QSPEC parameters will receive this same IANA treatment because they can be defined by QOSMs. (New _mandatory_ QSPEC parameters would require standards action, because they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can be defined by providing a specification. A new QoS Model would define the QoS parameters to be carried in the QSPEC. For details see [QSPEC ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards Track RFC, Experimental RFC or an Information RFC.=20 Is this OK?=20 =20 ------_=_NextPart_001_01C6411C.B502B678 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable QOSM IANA Status / NSIS Extensibility Doc on = QOSMs
when studying the=20 NSIS Ext. ID I noticed the text in Sec. 5 needs to be updated. It is too = unprecise currently.

It says: "New QSPECs = require IETF=20 action which defines the elements within the QSPEC". =

(i) it probably should = be "QoS=20 Models" rather than QSPECs. One could go on and say how new QSPEC = parameters=20 (elements???) are defined but this is detailed in the QSPEC ID so it = should=20 suffice to provide a pointer.

Fixed. 

 (ii) "IETF Action" what = exactly is that?=20 I've recently been studying the IANA RFC 2434 and this is not defined = there.=20 Or is this vague on purpose / defined = elsewhere?

Along the same lines, = when updating=20 the QSPEC IANA section we were wondering what kind of IETF action is = required=20 for defining new QOSMs / QOSM IDs: Will the QOSM IDs be informational = RFCs=20 (=3D> "specification required" or "IETF Consensus" in IANA language = !?) or=20 standards track (=3D> "standards action" in IANA language)? We are = currently=20 assuming it is just "specification required" and updated the QSPEC ID=20 accordingly. Note this implies that new  _optional_ QSPEC = parameters will=20 receive this same IANA treatment because they can be defined by QOSMs. = (New=20 _mandatory_ QSPEC parameters would require standards action, because = they=20 "MUST be interpreted" by all QNEs)

My proposal for new = text in the NSIS=20 Ext ID is "New QoS Models can be defined by providing a specification. = A new=20 QoS Model would define the QoS parameters to be carried in the QSPEC. = For=20 details see [QSPEC ID]".

 IETF action=20 means: 

<t>Extensions=20 subject to "IETF Action" require either a Standards Track   RFC, Experimental RFC = or an=20 Information RFC.</t> 

Is this=20 OK? 

 

------_=_NextPart_001_01C6411C.B502B678-- --===============1361050774== 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 --===============1361050774==-- From nsis-bounces@ietf.org Mon Mar 06 07:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFJM-0000aS-Q7; Mon, 06 Mar 2006 07:59:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFJL-0000aN-B6 for nsis@ietf.org; Mon, 06 Mar 2006 07:59:39 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFJK-0000rF-LA for nsis@ietf.org; Mon, 06 Mar 2006 07:59:39 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k26CxZSg032402; Mon, 6 Mar 2006 13:59:35 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k26CxZFc001358; Mon, 6 Mar 2006 13:59:35 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:59:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Date: Mon, 6 Mar 2006 13:57:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs thread-index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgAAAVl4A= From: "Tschofenig, Hannes" To: , "Kappler, Cornelia" X-OriginalArrivalTime: 06 Mar 2006 12:59:35.0040 (UTC) FILETIME=[D171F000:01C6411D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============0860468886==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0860468886== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6411D.D122E312" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6411D.D122E312 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, =20 last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn = and myself.=20 We went through the NATFW NSLP and looked also at the QoS NSLP draft.=20 =20 Particuarly, the IANA consideration section in the QoS NSLP document = seems to require a major re-write.=20 =20 It might be interesting to take a look at the proposal we came up with. = See Section 7 of=20 = ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp = -natfw-10.txt We will send a more detailed mail (after the deadline) with a list of = questions. Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 6. M=E4rz 2006 13:52 An: Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs =09 =09 when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to be = updated. It is too unprecise currently.=20 It says: "New QSPECs require IETF action which defines the elements = within the QSPEC".=20 (i) it probably should be "QoS Models" rather than QSPECs. One could = go on and say how new QSPEC parameters (elements???) are defined but = this is detailed in the QSPEC ID so it should suffice to provide a = pointer.=20 Fixed.=20 (ii) "IETF Action" what exactly is that? I've recently been studying = the IANA RFC 2434 and this is not defined there. Or is this vague on = purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were = wondering what kind of IETF action is required for defining new QOSMs / = QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification = required" or "IETF Consensus" in IANA language !?) or standards track = (=3D> "standards action" in IANA language)? We are currently assuming it = is just "specification required" and updated the QSPEC ID accordingly. = Note this implies that new _optional_ QSPEC parameters will receive = this same IANA treatment because they can be defined by QOSMs. (New = _mandatory_ QSPEC parameters would require standards action, because = they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can be = defined by providing a specification. A new QoS Model would define the = QoS parameters to be carried in the QSPEC. For details see [QSPEC ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards = Track RFC, Experimental RFC or an Information RFC.=20 Is this OK?=20 =20 ------_=_NextPart_001_01C6411D.D122E312 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QOSM IANA Status / NSIS Extensibility Doc on = QOSMs
Hi John,
 
last weekend we had a face-to-face meeting with = Martin,=20 Cedric, Elwyn and myself.
We went through the NATFW NSLP and looked also = at the QoS=20 NSLP draft.
 
Particuarly, the IANA=20 consideration section in the QoS NSLP document seems to require a major=20 re-write.
 
It might be interesting to take a look = at the proposal=20 we came up with. See Section 7 of

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-ns= lp-natfw-10.txt

We will=20 send a more detailed mail  (after the deadline) with a list of = questions.

Ciao
Hannes
 


Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 6. = M=E4rz 2006=20 13:52
An: Kappler, Cornelia
Cc: gash@att.com;=20 nsis@ietf.org; Attila.Bader@ericsson.com
Betreff: [NSIS] RE: = QOSM=20 IANA Status / NSIS Extensibility Doc on QOSMs

when studying=20 the NSIS Ext. ID I noticed the text in Sec. 5 needs to be updated. It = is too=20 unprecise currently.

It says: "New QSPECs = require IETF=20 action which defines the elements within the QSPEC". =

(i) it probably = should be "QoS=20 Models" rather than QSPECs. One could go on and say how new QSPEC = parameters=20 (elements???) are defined but this is detailed in the QSPEC ID so it = should=20 suffice to provide a pointer.

Fixed. 

 (ii) "IETF Action" what = exactly is=20 that? I've recently been studying the IANA RFC 2434 and this is not = defined=20 there. Or is this vague on purpose / defined=20 elsewhere?

Along the same lines, = when updating=20 the QSPEC IANA section we were wondering what kind of IETF action is = required for defining new QOSMs / QOSM IDs: Will the QOSM IDs be=20 informational RFCs (=3D> "specification required" or "IETF = Consensus" in=20 IANA language !?) or standards track (=3D> "standards action" in = IANA=20 language)? We are currently assuming it is just "specification = required" and=20 updated the QSPEC ID accordingly. Note this implies that new =20 _optional_ QSPEC parameters will receive this same IANA treatment = because=20 they can be defined by QOSMs. (New _mandatory_ QSPEC parameters = would=20 require standards action, because they "MUST be interpreted" by all=20 QNEs)

My proposal for new = text in the=20 NSIS Ext ID is "New QoS Models can be defined by providing a = specification.=20 A new QoS Model would define the QoS parameters to be carried in the = QSPEC.=20 For details see [QSPEC ID]".

 IETF action=20 means: 

<t>Extensions=20 subject to "IETF Action" require either a Standards Track   RFC, Experimental RFC = or an=20 Information RFC.</t> 

Is this=20 OK? 

 

------_=_NextPart_001_01C6411D.D122E312-- --===============0860468886== 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 --===============0860468886==-- From nsis-bounces@ietf.org Mon Mar 06 08:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFMR-0002JN-2Y; Mon, 06 Mar 2006 08:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFMP-0002JH-Se for nsis@ietf.org; Mon, 06 Mar 2006 08:02:49 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFMP-0001N1-31 for nsis@ietf.org; Mon, 06 Mar 2006 08:02:49 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26D1Bq5013439; Mon, 6 Mar 2006 15:01:13 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:02:40 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:02:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Date: Mon, 6 Mar 2006 15:02:39 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DDE@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Thread-Index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgAAAVl4AAAEahcA== From: To: , X-OriginalArrivalTime: 06 Mar 2006 13:02:41.0174 (UTC) FILETIME=[4063BB60:01C6411E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============0384136619==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0384136619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6411E.3F80F1D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6411E.3F80F1D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The NATFW draft (& QoS draft) should actually detail the values for the = registries in the IANA section, that way IANA can just review the IANA = section - if they have to dig through the document, it'll be a mess. =20 I also was wondering if we should have a common registry for NSIS - or = seperate. Any thoughts? =20 John ________________________________ From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: 06 March, 2006 14:58 To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status / NSIS Extensibility Doc on QOSMs =09 =09 Hi John, =20 last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn = and myself.=20 We went through the NATFW NSLP and looked also at the QoS NSLP draft.=20 =20 Particuarly, the IANA consideration section in the QoS NSLP document = seems to require a major re-write.=20 =20 It might be interesting to take a look at the proposal we came up with. = See Section 7 of=20 = ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp = -natfw-10.txt We will send a more detailed mail (after the deadline) with a list of = questions. Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 6. M=E4rz 2006 13:52 An: Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs =09 =09 when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to = be updated. It is too unprecise currently.=20 It says: "New QSPECs require IETF action which defines the elements = within the QSPEC".=20 (i) it probably should be "QoS Models" rather than QSPECs. One could = go on and say how new QSPEC parameters (elements???) are defined but = this is detailed in the QSPEC ID so it should suffice to provide a = pointer.=20 Fixed.=20 (ii) "IETF Action" what exactly is that? I've recently been studying = the IANA RFC 2434 and this is not defined there. Or is this vague on = purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were = wondering what kind of IETF action is required for defining new QOSMs / = QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification = required" or "IETF Consensus" in IANA language !?) or standards track = (=3D> "standards action" in IANA language)? We are currently assuming it = is just "specification required" and updated the QSPEC ID accordingly. = Note this implies that new _optional_ QSPEC parameters will receive = this same IANA treatment because they can be defined by QOSMs. (New = _mandatory_ QSPEC parameters would require standards action, because = they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can be = defined by providing a specification. A new QoS Model would define the = QoS parameters to be carried in the QSPEC. For details see [QSPEC ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards = Track RFC, Experimental RFC or an Information RFC.=20 Is this OK?=20 =20 ------_=_NextPart_001_01C6411E.3F80F1D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QOSM IANA Status / NSIS Extensibility Doc on = QOSMs
The NATFW draft (& QoS draft) should = actually detail=20 the values for the registries in the IANA section, that way IANA can = just review=20 the IANA section - if they have to dig through the document, it'll be a=20 mess.
 
I also was wondering if we should have a common = registry=20 for NSIS - or seperate.  Any thoughts?
 
John


From: ext Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: 06 March, 2006 = 14:58
To: Loughney John (Nokia-NRC/Helsinki); Kappler,=20 Cornelia
Cc: gash@att.com; nsis@ietf.org;=20 Attila.Bader@ericsson.com
Subject: IANA Considerations for = QoS=20 workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on=20 QOSMs

Hi John,
 
last weekend we had a face-to-face meeting = with Martin,=20 Cedric, Elwyn and myself.
We went through the NATFW NSLP and looked = also at the QoS=20 NSLP draft.
 
Particuarly, the IANA=20 consideration section in the QoS NSLP document seems to require a = major=20 re-write.
 
It might be interesting to take a look = at the=20 proposal we came up with. See Section 7 of

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-ns= lp-natfw-10.txt

We=20 will send a more detailed mail  (after the deadline) with a = list of=20 questions.

Ciao
Hannes
 


Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 6. = M=E4rz 2006=20 13:52
An: Kappler, Cornelia
Cc: gash@att.com;=20 nsis@ietf.org; Attila.Bader@ericsson.com
Betreff: [NSIS] = RE: QOSM=20 IANA Status / NSIS Extensibility Doc on QOSMs

when studying=20 the NSIS Ext. ID I noticed the text in Sec. 5 needs to be updated. = It is too=20 unprecise currently.

It says: "New = QSPECs require IETF=20 action which defines the elements within the QSPEC". =

(i) it probably = should be "QoS=20 Models" rather than QSPECs. One could go on and say how new QSPEC=20 parameters (elements???) are defined but this is detailed in the = QSPEC ID=20 so it should suffice to provide a pointer.

Fixed. 

 (ii) "IETF Action" what = exactly is=20 that? I've recently been studying the IANA RFC 2434 and this is = not=20 defined there. Or is this vague on purpose / defined=20 elsewhere?

Along the same = lines, when=20 updating the QSPEC IANA section we were wondering what kind of = IETF action=20 is required for defining new QOSMs / QOSM IDs: Will the QOSM IDs = be=20 informational RFCs (=3D> "specification required" or "IETF = Consensus" in=20 IANA language !?) or standards track (=3D> "standards action" = in IANA=20 language)? We are currently assuming it is just "specification = required"=20 and updated the QSPEC ID accordingly. Note this implies that = new =20 _optional_ QSPEC parameters will receive this same IANA treatment = because=20 they can be defined by QOSMs. (New _mandatory_ QSPEC parameters = would=20 require standards action, because they "MUST be interpreted" by = all=20 QNEs)

My proposal for new = text in the=20 NSIS Ext ID is "New QoS Models can be defined by providing a=20 specification. A new QoS Model would define the QoS parameters to = be=20 carried in the QSPEC. For details see [QSPEC ID]". =

 IETF action=20 means: 

<t>Extensions=20 subject to "IETF Action" require either a Standards Track   RFC, Experimental = RFC or an=20 Information RFC.</t> 

Is this=20 OK? 

 

------_=_NextPart_001_01C6411E.3F80F1D8-- --===============0384136619== 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 --===============0384136619==-- From nsis-bounces@ietf.org Mon Mar 06 08:14:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFTy-0000mR-0p; Mon, 06 Mar 2006 08:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFTw-0000mF-OF for nsis@ietf.org; Mon, 06 Mar 2006 08:10:36 -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 1FGFTw-0001UI-9R for nsis@ietf.org; Mon, 06 Mar 2006 08:10:36 -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; Mon, 06 Mar 2006 15:10:35 +0200 id 00070209.440C34CB.00005AFC Date: Mon, 6 Mar 2006 15:10:35 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DC5@esebe100.NOE.Nokia.com> Message-ID: References: <1AA39B75171A7144A73216AED1D7478D01869DC5@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: John Loughney Subject: [NSIS] RE: Extended WGLC was: QoS NSLP going forward 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 do that. I'd like to ask people to see my diff at http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-09-10.html before you comment, just to make sure your comment has not yet been dealt with in v.10, which was submitted to the I-D Admin 10 minutes ago. Jukka On Mon, 6 Mar 2006 john.loughney@nokia.com wrote: > Submit it, and if there are any major comments, we can take care of it > later - > if there are no comments, then we are in good shape. > > john > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 06 March, 2006 13:31 > >To: Loughney John (Nokia-NRC/Helsinki) > >Cc: nsis@ietf.org > >Subject: Re: Extended WGLC was: QoS NSLP going forward > > > > > >So, will I be submitting a new I-D today in about two hours, > >or wait until we get all possible comments? > > > >Jukka > > > >On Mon, 6 Mar 2006 john.loughney@nokia.com wrote: > > > >> Jukka, > >> > >> A few people have commented that they may have a few points still to > >> raise but have been caught up in the submission deadline > >rush, so I'll > >> extend the comment period until this Friday March 10th. > >> > >> John > >> > >> >-----Original Message----- > >> >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >> >Sent: 28 February, 2006 23:05 > >> >To: nsis@ietf.org > >> >Subject: [NSIS] QoS NSLP going forward > >> > > >> > > >> >Dear all, > >> > > >> >There were no specific issues raised during the WG Last Call. > >> >I got one set of comments offline from Jerry, and Roland sent a few > >> >comments, too. > >> >I'll make those, and do an overall sanity check before > >submitting v. > >> >10 by Monday morning. I won't be in Dallas due to family > >issues, but > >> >I guess there is not much to discuss about the QoS NSLP anyway. ;) > >> > > >> >Regards, > >> >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 06 08:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFWC-0002oa-Fw; Mon, 06 Mar 2006 08:12:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFWB-0002oS-6q for nsis@ietf.org; Mon, 06 Mar 2006 08:12:55 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFW8-0001X3-MN for nsis@ietf.org; Mon, 06 Mar 2006 08:12:55 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k26DCNoW017652; Mon, 6 Mar 2006 13:12:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Date: Mon, 6 Mar 2006 13:12:23 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Thread-Index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgAAAVl4AAAEahcAAANA3Q From: "Hancock, Robert" To: , , X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============1014854387==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1014854387== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6411F.9B604B3A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6411F.9B604B3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I went through the GIST IANA section with the IANA people in Vancouver. = They seemed broadly happy with the format and content. The question did = come up of whether there was going to be a GIST registry or an NSIS = registry, and at the time I don't think I had a clear view one way or = the other (or even understand the significance of the question). =20 However, GIST creates 2 registries (NSLPID and MRMID) which are referred = to by all NSLPs. In addition, AFAIK the NSLP object type registry is = shared between all NSLPs, but GIST doesn't create it (its object types = are its own), so some other mechanism is needed for that.=20 =20 The above implies to me that a single NSIS registry is more sensible. =20 r. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: 06 March 2006 13:03 To: hannes.tschofenig@siemens.com; cornelia.kappler@siemens.com Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status /NSIS Extensibility Doc on QOSMs =09 =09 The NATFW draft (& QoS draft) should actually detail the values for the = registries in the IANA section, that way IANA can just review the IANA = section - if they have to dig through the document, it'll be a mess. =20 I also was wondering if we should have a common registry for NSIS - or = seperate. Any thoughts? =20 John ________________________________ From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: 06 March, 2006 14:58 To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status / NSIS Extensibility Doc on QOSMs =09 =09 Hi John, =20 last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn = and myself.=20 We went through the NATFW NSLP and looked also at the QoS NSLP draft.=20 =20 Particuarly, the IANA consideration section in the QoS NSLP document = seems to require a major re-write.=20 =20 It might be interesting to take a look at the proposal we came up = with. See Section 7 of=20 = ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp = -natfw-10.txt We will send a more detailed mail (after the deadline) with a list of = questions. Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 6. M=E4rz 2006 13:52 An: Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on = QOSMs =09 =09 when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to = be updated. It is too unprecise currently.=20 It says: "New QSPECs require IETF action which defines the elements = within the QSPEC".=20 (i) it probably should be "QoS Models" rather than QSPECs. One could = go on and say how new QSPEC parameters (elements???) are defined but = this is detailed in the QSPEC ID so it should suffice to provide a = pointer.=20 Fixed.=20 (ii) "IETF Action" what exactly is that? I've recently been = studying the IANA RFC 2434 and this is not defined there. Or is this = vague on purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were = wondering what kind of IETF action is required for defining new QOSMs / = QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification = required" or "IETF Consensus" in IANA language !?) or standards track = (=3D> "standards action" in IANA language)? We are currently assuming it = is just "specification required" and updated the QSPEC ID accordingly. = Note this implies that new _optional_ QSPEC parameters will receive = this same IANA treatment because they can be defined by QOSMs. (New = _mandatory_ QSPEC parameters would require standards action, because = they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can = be defined by providing a specification. A new QoS Model would define = the QoS parameters to be carried in the QSPEC. For details see [QSPEC = ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards = Track RFC, Experimental RFC or an Information RFC.=20 Is this OK?=20 =20 ------_=_NextPart_001_01C6411F.9B604B3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I went=20 through the GIST IANA section with the IANA people in Vancouver. They = seemed=20 broadly happy with the format and content. The question did come up of = whether=20 there was going to be a GIST registry or an NSIS registry, and at the = time I=20 don't think I had a clear view one way or the other (or even understand = the=20 significance of the question).
 
However, GIST creates 2 registries (NSLPID and MRMID) which are = referred=20 to by all NSLPs. In addition, AFAIK the NSLP object type registry is = shared=20 between all NSLPs, but GIST doesn't create it (its object types are its = own), so=20 some other mechanism is needed for that.
 
The=20 above implies to me that a single NSIS registry is more=20 sensible.
 
r.
-----Original Message-----
From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com] =
Sent: 06=20 March 2006 13:03
To: hannes.tschofenig@siemens.com;=20 cornelia.kappler@siemens.com
Cc: gash@att.com; = nsis@ietf.org;=20 Attila.Bader@ericsson.com
Subject: RE: IANA Considerations = for QoS=20 workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on=20 QOSMs

The NATFW draft (& QoS draft) should = actually detail=20 the values for the registries in the IANA section, that way IANA can = just=20 review the IANA section - if they have to dig through the document, = it'll be a=20 mess.
 
I also was wondering if we should have a = common registry=20 for NSIS - or seperate.  Any thoughts?
 
John


From: ext Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: 06 March, = 2006=20 14:58
To: Loughney John (Nokia-NRC/Helsinki); Kappler,=20 Cornelia
Cc: gash@att.com; nsis@ietf.org;=20 Attila.Bader@ericsson.com
Subject: IANA Considerations for = QoS=20 workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on=20 QOSMs

Hi John,
 
last weekend we had a face-to-face meeting = with Martin,=20 Cedric, Elwyn and myself.
We went through the NATFW NSLP and looked = also at the=20 QoS NSLP draft.
 
Particuarly, the IANA=20 consideration section in the QoS NSLP document seems to require a = major=20 re-write.
 
It might be interesting to take a look = at the=20 proposal we came up with. See Section 7 of

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-ns= lp-natfw-10.txt

We=20 will send a more detailed mail  (after the deadline) with = a list=20 of questions.

Ciao
Hannes
 


Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 6. = M=E4rz 2006=20 13:52
An: Kappler, Cornelia
Cc: gash@att.com;=20 nsis@ietf.org; Attila.Bader@ericsson.com
Betreff: [NSIS] = RE:=20 QOSM IANA Status / NSIS Extensibility Doc on = QOSMs

when=20 studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to be = updated. It is too unprecise currently.

It says: "New = QSPECs require=20 IETF action which defines the elements within the QSPEC".=20

(i) it probably = should be "QoS=20 Models" rather than QSPECs. One could go on and say how new = QSPEC=20 parameters (elements???) are defined but this is detailed in the = QSPEC=20 ID so it should suffice to provide a pointer.

Fixed. 

 (ii) "IETF Action" what = exactly is=20 that? I've recently been studying the IANA RFC 2434 and this is = not=20 defined there. Or is this vague on purpose / defined=20 elsewhere?

Along the same = lines, when=20 updating the QSPEC IANA section we were wondering what kind of = IETF=20 action is required for defining new QOSMs / QOSM IDs: Will the = QOSM IDs=20 be informational RFCs (=3D> "specification required" or "IETF = Consensus" in IANA language !?) or standards track (=3D> = "standards=20 action" in IANA language)? We are currently assuming it is just=20 "specification required" and updated the QSPEC ID accordingly. = Note this=20 implies that new  _optional_ QSPEC parameters will receive = this=20 same IANA treatment because they can be defined by QOSMs. (New=20 _mandatory_ QSPEC parameters would require standards action, = because=20 they "MUST be interpreted" by all QNEs)

My proposal for = new text in the=20 NSIS Ext ID is "New QoS Models can be defined by providing a=20 specification. A new QoS Model would define the QoS parameters = to be=20 carried in the QSPEC. For details see [QSPEC ID]". =

 IETF action=20 means: 

<t>Extensions=20 subject to "IETF Action" require either a Standards Track   RFC, Experimental = RFC or an=20 Information RFC.</t> 

Is this=20 OK? 

 

------_=_NextPart_001_01C6411F.9B604B3A-- --===============1014854387== 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 --===============1014854387==-- From nsis-bounces@ietf.org Mon Mar 06 08:14:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFY9-0004R6-8U; Mon, 06 Mar 2006 08:14:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFY7-0004Os-Dc for nsis@ietf.org; Mon, 06 Mar 2006 08:14:55 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFY6-0001Zk-IF for nsis@ietf.org; Mon, 06 Mar 2006 08:14:55 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26DEpPN008579; Mon, 6 Mar 2006 15:14:51 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:14:51 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:14:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS Extensibility Doc on QOSMs Date: Mon, 6 Mar 2006 15:14:50 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DDF@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS Extensibility Doc on QOSMs Thread-Index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgAAAVl4AAAEahcAAANA3QAABB0VA= From: To: , , X-OriginalArrivalTime: 06 Mar 2006 13:14:50.0879 (UTC) FILETIME=[F353E0F0:01C6411F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============0990832752==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0990832752== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6411F.F2EAE300" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6411F.F2EAE300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is what was thinking of as well, we can have a chat about that in = Dallas (during WG time), and then we'd be in good shape. =20 John ________________________________ From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 Sent: 06 March, 2006 15:12 To: Loughney John (Nokia-NRC/Helsinki); hannes.tschofenig@siemens.com; = cornelia.kappler@siemens.com Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status/NSIS Extensibility Doc on QOSMs =09 =09 I went through the GIST IANA section with the IANA people in Vancouver. = They seemed broadly happy with the format and content. The question did = come up of whether there was going to be a GIST registry or an NSIS = registry, and at the time I don't think I had a clear view one way or = the other (or even understand the significance of the question). =20 However, GIST creates 2 registries (NSLPID and MRMID) which are = referred to by all NSLPs. In addition, AFAIK the NSLP object type = registry is shared between all NSLPs, but GIST doesn't create it (its = object types are its own), so some other mechanism is needed for that.=20 =20 The above implies to me that a single NSIS registry is more sensible. =20 r. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: 06 March 2006 13:03 To: hannes.tschofenig@siemens.com; cornelia.kappler@siemens.com Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status /NSIS Extensibility Doc on QOSMs =09 =09 The NATFW draft (& QoS draft) should actually detail the values for = the registries in the IANA section, that way IANA can just review the = IANA section - if they have to dig through the document, it'll be a = mess. =20 I also was wondering if we should have a common registry for NSIS - or = seperate. Any thoughts? =20 John ________________________________ From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: 06 March, 2006 14:58 To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status / NSIS Extensibility Doc on QOSMs =09 =09 Hi John, =20 last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn = and myself.=20 We went through the NATFW NSLP and looked also at the QoS NSLP draft. = =20 Particuarly, the IANA consideration section in the QoS NSLP document = seems to require a major re-write.=20 =20 It might be interesting to take a look at the proposal we came up = with. See Section 7 of=20 = ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp = -natfw-10.txt We will send a more detailed mail (after the deadline) with a list = of questions. Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 6. M=E4rz 2006 13:52 An: Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on = QOSMs =09 =09 when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to = be updated. It is too unprecise currently.=20 It says: "New QSPECs require IETF action which defines the elements = within the QSPEC".=20 (i) it probably should be "QoS Models" rather than QSPECs. One = could go on and say how new QSPEC parameters (elements???) are defined = but this is detailed in the QSPEC ID so it should suffice to provide a = pointer.=20 Fixed.=20 (ii) "IETF Action" what exactly is that? I've recently been = studying the IANA RFC 2434 and this is not defined there. Or is this = vague on purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were = wondering what kind of IETF action is required for defining new QOSMs / = QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification = required" or "IETF Consensus" in IANA language !?) or standards track = (=3D> "standards action" in IANA language)? We are currently assuming it = is just "specification required" and updated the QSPEC ID accordingly. = Note this implies that new _optional_ QSPEC parameters will receive = this same IANA treatment because they can be defined by QOSMs. (New = _mandatory_ QSPEC parameters would require standards action, because = they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can = be defined by providing a specification. A new QoS Model would define = the QoS parameters to be carried in the QSPEC. For details see [QSPEC = ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards = Track RFC, Experimental RFC or an Information RFC.=20 Is this OK?=20 =20 ------_=_NextPart_001_01C6411F.F2EAE300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
This is what was thinking of as well, we can = have a=20 chat about that in Dallas (during WG time), and then we'd be in good=20 shape.
 
John


From: ext Hancock, Robert=20 [mailto:robert.hancock@roke.co.uk]
Sent: 06 March, 2006=20 15:12
To: Loughney John (Nokia-NRC/Helsinki);=20 hannes.tschofenig@siemens.com; = cornelia.kappler@siemens.com
Cc:=20 gash@att.com; nsis@ietf.org; = Attila.Bader@ericsson.com
Subject: RE:=20 IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS=20 Extensibility Doc on QOSMs

I=20 went through the GIST IANA section with the IANA people in Vancouver. = They=20 seemed broadly happy with the format and content. The question did = come up of=20 whether there was going to be a GIST registry or an NSIS registry, and = at the=20 time I don't think I had a clear view one way or the other (or even = understand=20 the significance of the question).
 
However, GIST creates 2 registries (NSLPID and MRMID) which = are=20 referred to by all NSLPs. In addition, AFAIK the NSLP object type = registry is=20 shared between all NSLPs, but GIST doesn't create it (its object types = are its=20 own), so some other mechanism is needed for that.
 
The=20 above implies to me that a single NSIS registry is more=20 sensible.
 
r.
-----Original Message-----
From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com] =
Sent: 06=20 March 2006 13:03
To: hannes.tschofenig@siemens.com;=20 cornelia.kappler@siemens.com
Cc: gash@att.com; = nsis@ietf.org;=20 Attila.Bader@ericsson.com
Subject: RE: IANA Considerations = for QoS=20 workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on=20 QOSMs

The NATFW draft (& QoS draft) should = actually=20 detail the values for the registries in the IANA section, that way = IANA can=20 just review the IANA section - if they have to dig through the = document,=20 it'll be a mess.
 
I also was wondering if we should have a = common=20 registry for NSIS - or seperate.  Any = thoughts?
 
John


From: ext Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: 06 March, = 2006=20 14:58
To: Loughney John (Nokia-NRC/Helsinki); Kappler,=20 Cornelia
Cc: gash@att.com; nsis@ietf.org;=20 Attila.Bader@ericsson.com
Subject: IANA Considerations = for QoS=20 workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on=20 QOSMs

Hi John,
 
last weekend we had a face-to-face = meeting with=20 Martin, Cedric, Elwyn and myself.
We went through the NATFW NSLP and looked = also at the=20 QoS NSLP draft.
 
Particuarly, the IANA=20 consideration section in the QoS NSLP document seems to require a = major=20 re-write.
 
It might be interesting to take a look = at the=20 proposal we came up with. See Section 7 of

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-ns= lp-natfw-10.txt

We=20 will send a more detailed mail  (after the = deadline) with a list=20 of questions.

Ciao
Hannes
 


Von: john.loughney@nokia.com = [mailto:john.loughney@nokia.com]
Gesendet: Montag, 6. = M=E4rz=20 2006 13:52
An: Kappler, Cornelia
Cc: = gash@att.com;=20 nsis@ietf.org; Attila.Bader@ericsson.com
Betreff: = [NSIS] RE:=20 QOSM IANA Status / NSIS Extensibility Doc on = QOSMs

when=20 studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to = be=20 updated. It is too unprecise currently.

It says: "New = QSPECs require=20 IETF action which defines the elements within the QSPEC".=20

(i) it probably = should be=20 "QoS Models" rather than QSPECs. One could go on and say how = new QSPEC=20 parameters (elements???) are defined but this is detailed in = the QSPEC=20 ID so it should suffice to provide a pointer. =

Fixed. 

 (ii) "IETF Action" = what exactly=20 is that? I've recently been studying the IANA RFC 2434 and = this is not=20 defined there. Or is this vague on purpose / defined=20 elsewhere?

Along the same = lines, when=20 updating the QSPEC IANA section we were wondering what kind of = IETF=20 action is required for defining new QOSMs / QOSM IDs: Will the = QOSM=20 IDs be informational RFCs (=3D> "specification required" or = "IETF=20 Consensus" in IANA language !?) or standards track (=3D> = "standards=20 action" in IANA language)? We are currently assuming it is = just=20 "specification required" and updated the QSPEC ID accordingly. = Note=20 this implies that new  _optional_ QSPEC parameters will = receive=20 this same IANA treatment because they can be defined by QOSMs. = (New=20 _mandatory_ QSPEC parameters would require standards action, = because=20 they "MUST be interpreted" by all QNEs)

My proposal for = new text in=20 the NSIS Ext ID is "New QoS Models can be defined by providing = a=20 specification. A new QoS Model would define the QoS parameters = to be=20 carried in the QSPEC. For details see [QSPEC ID]". =

 IETF action=20 means: 

<t>Extensions subject to "IETF Action" require = either a=20 Standards Track  =  RFC,=20 Experimental RFC or an Information RFC.</t> 

Is this=20 OK? 

 

------_=_NextPart_001_01C6411F.F2EAE300-- --===============0990832752== 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 --===============0990832752==-- From nsis-bounces@ietf.org Mon Mar 06 08:16:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFZw-0006Rk-2B; Mon, 06 Mar 2006 08:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFZu-0006QZ-Nz for nsis@ietf.org; Mon, 06 Mar 2006 08:16:46 -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 1FGFZu-0001cD-7x for nsis@ietf.org; Mon, 06 Mar 2006 08:16:46 -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; Mon, 06 Mar 2006 15:16:45 +0200 id 00070305.440C363D.00007765 Date: Mon, 6 Mar 2006 15:16:44 +0200 (EET) From: Jukka MJ Manner To: john.loughney@nokia.com Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DDE@esebe100.NOE.Nokia.com> Message-ID: References: <1AA39B75171A7144A73216AED1D7478D01869DDE@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.47 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: gash@att.com, cornelia.kappler@siemens.com, Attila.Bader@ericsson.com, nsis@ietf.org, hannes.tschofenig@siemens.com 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 Ack. I'll do that once all comments from this extended WGLC have been received, and we have a final spec to send to the ADs&IESG. A common registry would of course be nice, but is that possible? Jukka On Mon, 6 Mar 2006 john.loughney@nokia.com wrote: > The NATFW draft (& QoS draft) should actually detail the values for th= e registries in the IANA section, that way IANA can just review the IANA= section - if they have to dig through the document, it'll be a mess. > I also was wondering if we should have a common registry for NSIS - o= r > seperate. Any thoughts? > > John > > > ________________________________ > > =09From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]= > =09Sent: 06 March, 2006 14:58 > =09To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia > =09Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com > =09Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA S= tatus / NSIS Extensibility Doc on QOSMs > =09 > =09 > =09Hi John, > =09 > =09last weekend we had a face-to-face meeting with Martin, Cedric, Elw= yn and myself. > =09We went through the NATFW NSLP and looked also at the QoS NSLP draf= t. > =09 > =09Particuarly, the IANA consideration section in the QoS NSLP documen= t seems to require a major re-write. > =09 > =09It might be interesting to take a look at the proposal we came up w= ith. See Section 7 of > =09 ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp -natfw-10.txt > > =09We will send a more detailed mail (after the deadline) with a list= of questions. > > =09Ciao > =09Hannes > =09 > > > ________________________________ > > =09=09Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > =09=09Gesendet: Montag, 6. M=E4rz 2006 13:52 > =09=09An: Kappler, Cornelia > =09=09Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com > =09=09Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on= QOSMs > =09=09 > =09=09 > =09=09when studying the NSIS Ext. ID I noticed the text in Sec. 5 need= s to be updated. It is too unprecise currently. > > =09=09=09It says: "New QSPECs require IETF action which defines the el= ements within the QSPEC". > > =09=09=09(i) it probably should be "QoS Models" rather than QSPECs. On= e could go on and say how new QSPEC parameters (elements???) are defined= but this is detailed in the QSPEC ID so it should suffice to provide a = pointer. > > =09=09=09Fixed. > > =09=09=09 (ii) "IETF Action" what exactly is that? I've recently been = studying the IANA RFC 2434 and this is not defined there. Or is this vag= ue on purpose / defined elsewhere? > > =09=09=09Along the same lines, when updating the QSPEC IANA section we= were wondering what kind of IETF action is required for defining new QO= SMs / QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specifica= tion required" or "IETF Consensus" in IANA language !?) or standards tra= ck (=3D> "standards action" in IANA language)? We are currently assuming= it is just "specification required" and updated the QSPEC ID accordingl= y. Note this implies that new _optional_ QSPEC parameters will receive = this same IANA treatment because they can be defined by QOSMs. (New _man= datory_ QSPEC parameters would require standards action, because they "M= UST be interpreted" by all QNEs) > > =09=09=09My proposal for new text in the NSIS Ext ID is "New QoS Model= s can be defined by providing a specification. A new QoS Model would def= ine the QoS parameters to be carried in the QSPEC. For details see [QSPE= C ID]". > > =09=09=09 IETF action means: > > =09=09=09Extensions subject to "IETF Action" require either a Stand= ards Track RFC, Experimental RFC or an Information RFC. > > =09=09=09Is this OK? > > =09=09=09 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 08:17:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFaE-0006fS-Da; Mon, 06 Mar 2006 08:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFaC-0006bD-Nu for nsis@ietf.org; Mon, 06 Mar 2006 08:17:04 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFa6-0001cO-OB for nsis@ietf.org; Mon, 06 Mar 2006 08:17:04 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k26DGSoW018804; Mon, 6 Mar 2006 13:16:29 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 13:16:28 +0000 Message-ID: <440C362E.6030203@roke.co.uk> Date: Mon, 06 Mar 2006 13:16:30 +0000 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 13:16:28.0881 (UTC) FILETIME=[2DBDCC10:01C64120] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Tschofenig, Hannes wrote: > last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn > and myself. > We went through the NATFW NSLP and looked also at the QoS NSLP draft. > > Particuarly, the IANA consideration section in the QoS NSLP document > seems to require a major re-write. > > It might be interesting to take a look at the proposal we came up with. > See Section 7 of > > __ > _ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp > _-natfw-10.txt > > We will send a more detailed mail (after the deadline) with a list of > questions. I'd agree with that, I even created a QoS NSLP issue for it yesterday (issue #45) :-) http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue45 The GIST specification goes a bit further and splits up the registries, e.g. to allocate parts of the ranges to experimental use. I also noticed that the QoS NSLP fails to define the values for the objects that go in to messages, which surprises me since some people claim to have implemented it. :-) Logged as issue #46: http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue46 Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 08:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFoc-0000ta-8y; Mon, 06 Mar 2006 08:31:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFob-0000sZ-A6 for nsis@ietf.org; Mon, 06 Mar 2006 08:31:57 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGFoY-0001qz-Rl for nsis@ietf.org; Mon, 06 Mar 2006 08:31:57 -0500 Received: (qmail invoked by alias); 06 Mar 2006 13:31:53 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp019) with SMTP; 06 Mar 2006 14:31:53 +0100 X-Authenticated: #29516787 Message-ID: <440C39C3.3070404@gmx.net> Date: Mon, 06 Mar 2006 14:31:47 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew McDonald Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs References: <440C362E.6030203@roke.co.uk> In-Reply-To: <440C362E.6030203@roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nsis@ietf.org, "Tschofenig, Hannes" 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, we also wanted to allocate vendor specific and experimental regions for the registries we create. However, this depends a little bit on the decision whether we want to have a common registry for the NSLP object types, for example. Ciao Hannes Andrew McDonald wrote: > Tschofenig, Hannes wrote: > >> last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn >> and myself. >> We went through the NATFW NSLP and looked also at the QoS NSLP draft. >> >> Particuarly, the IANA consideration section in the QoS NSLP document >> seems to require a major re-write. >> >> It might be interesting to take a look at the proposal we came up >> with. See Section 7 of >> >> __ >> _ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp >> _-natfw-10.txt >> >> >> We will send a more detailed mail (after the deadline) with a list of >> questions. > > > I'd agree with that, I even created a QoS NSLP issue for it yesterday > (issue #45) :-) > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue45 > > The GIST specification goes a bit further and splits up the registries, > e.g. to allocate parts of the ranges to experimental use. > > I also noticed that the QoS NSLP fails to define the values for the > objects that go in to messages, which surprises me since some people > claim to have implemented it. :-) Logged as issue #46: > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue46 > > 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 Mon Mar 06 08:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFof-0000xc-Hp; Mon, 06 Mar 2006 08:32:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFoe-0000xW-JW for nsis@ietf.org; Mon, 06 Mar 2006 08:32:00 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFod-0001ra-PZ for nsis@ietf.org; Mon, 06 Mar 2006 08:32:00 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k26DVvW1003595; Mon, 6 Mar 2006 14:31:57 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k26DVu2O001810; Mon, 6 Mar 2006 14:31:56 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 14:31:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Date: Mon, 6 Mar 2006 14:31:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs thread-index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgAAAVl4AAAEahcAAAqJkw From: "Tschofenig, Hannes" To: , "Kappler, Cornelia" X-OriginalArrivalTime: 06 Mar 2006 13:31:55.0528 (UTC) FILETIME=[5610E880:01C64122] X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============1787849283==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1787849283== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64122.558B5A65" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64122.558B5A65 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John,=20 =20 I couldn't see a need for a common registry (e.g., Error Codes or NSLP = object type registry). =20 Ciao Hannes ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 6. M=E4rz 2006 14:03 An: Tschofenig, Hannes; Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Betreff: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status /NSIS Extensibility Doc on QOSMs =09 =09 The NATFW draft (& QoS draft) should actually detail the values for the = registries in the IANA section, that way IANA can just review the IANA = section - if they have to dig through the document, it'll be a mess. =20 I also was wondering if we should have a common registry for NSIS - or = seperate. Any thoughts? =20 John ________________________________ From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: 06 March, 2006 14:58 To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA = Status / NSIS Extensibility Doc on QOSMs =09 =09 Hi John, =20 last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn = and myself.=20 We went through the NATFW NSLP and looked also at the QoS NSLP draft.=20 =20 Particuarly, the IANA consideration section in the QoS NSLP document = seems to require a major re-write.=20 =20 It might be interesting to take a look at the proposal we came up = with. See Section 7 of=20 = ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp = -natfw-10.txt We will send a more detailed mail (after the deadline) with a list of = questions. Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 6. M=E4rz 2006 13:52 An: Kappler, Cornelia Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on = QOSMs =09 =09 when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to = be updated. It is too unprecise currently.=20 It says: "New QSPECs require IETF action which defines the elements = within the QSPEC".=20 (i) it probably should be "QoS Models" rather than QSPECs. One could = go on and say how new QSPEC parameters (elements???) are defined but = this is detailed in the QSPEC ID so it should suffice to provide a = pointer.=20 Fixed.=20 (ii) "IETF Action" what exactly is that? I've recently been = studying the IANA RFC 2434 and this is not defined there. Or is this = vague on purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were = wondering what kind of IETF action is required for defining new QOSMs / = QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification = required" or "IETF Consensus" in IANA language !?) or standards track = (=3D> "standards action" in IANA language)? We are currently assuming it = is just "specification required" and updated the QSPEC ID accordingly. = Note this implies that new _optional_ QSPEC parameters will receive = this same IANA treatment because they can be defined by QOSMs. (New = _mandatory_ QSPEC parameters would require standards action, because = they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can = be defined by providing a specification. A new QoS Model would define = the QoS parameters to be carried in the QSPEC. For details see [QSPEC = ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards = Track RFC, Experimental RFC or an Information RFC.=20 Is this OK?=20 =20 ------_=_NextPart_001_01C64122.558B5A65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QOSM IANA Status / NSIS Extensibility Doc on = QOSMs
Hi John,
 
I couldn't see a need for a common registry = (e.g., Error=20 Codes or  NSLP object type registry).
 
Ciao
Hannes


Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 6. = M=E4rz 2006=20 14:03
An: Tschofenig, Hannes; Kappler, = Cornelia
Cc:=20 gash@att.com; nsis@ietf.org; = Attila.Bader@ericsson.com
Betreff: RE:=20 IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS=20 Extensibility Doc on QOSMs

The NATFW draft (& QoS draft) should = actually detail=20 the values for the registries in the IANA section, that way IANA can = just=20 review the IANA section - if they have to dig through the document, = it'll be a=20 mess.
 
I also was wondering if we should have a = common registry=20 for NSIS - or seperate.  Any thoughts?
 
John


From: ext Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: 06 March, = 2006=20 14:58
To: Loughney John (Nokia-NRC/Helsinki); Kappler,=20 Cornelia
Cc: gash@att.com; nsis@ietf.org;=20 Attila.Bader@ericsson.com
Subject: IANA Considerations for = QoS=20 workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on=20 QOSMs

Hi John,
 
last weekend we had a face-to-face meeting = with Martin,=20 Cedric, Elwyn and myself.
We went through the NATFW NSLP and looked = also at the=20 QoS NSLP draft.
 
Particuarly, the IANA=20 consideration section in the QoS NSLP document seems to require a = major=20 re-write.
 
It might be interesting to take a look = at the=20 proposal we came up with. See Section 7 of

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-ns= lp-natfw-10.txt

We=20 will send a more detailed mail  (after the deadline) with = a list=20 of questions.

Ciao
Hannes
 


Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 6. = M=E4rz 2006=20 13:52
An: Kappler, Cornelia
Cc: gash@att.com;=20 nsis@ietf.org; Attila.Bader@ericsson.com
Betreff: [NSIS] = RE:=20 QOSM IANA Status / NSIS Extensibility Doc on = QOSMs

when=20 studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to be = updated. It is too unprecise currently.

It says: "New = QSPECs require=20 IETF action which defines the elements within the QSPEC".=20

(i) it probably = should be "QoS=20 Models" rather than QSPECs. One could go on and say how new = QSPEC=20 parameters (elements???) are defined but this is detailed in the = QSPEC=20 ID so it should suffice to provide a pointer.

Fixed. 

 (ii) "IETF Action" what = exactly is=20 that? I've recently been studying the IANA RFC 2434 and this is = not=20 defined there. Or is this vague on purpose / defined=20 elsewhere?

Along the same = lines, when=20 updating the QSPEC IANA section we were wondering what kind of = IETF=20 action is required for defining new QOSMs / QOSM IDs: Will the = QOSM IDs=20 be informational RFCs (=3D> "specification required" or "IETF = Consensus" in IANA language !?) or standards track (=3D> = "standards=20 action" in IANA language)? We are currently assuming it is just=20 "specification required" and updated the QSPEC ID accordingly. = Note this=20 implies that new  _optional_ QSPEC parameters will receive = this=20 same IANA treatment because they can be defined by QOSMs. (New=20 _mandatory_ QSPEC parameters would require standards action, = because=20 they "MUST be interpreted" by all QNEs)

My proposal for = new text in the=20 NSIS Ext ID is "New QoS Models can be defined by providing a=20 specification. A new QoS Model would define the QoS parameters = to be=20 carried in the QSPEC. For details see [QSPEC ID]". =

 IETF action=20 means: 

<t>Extensions=20 subject to "IETF Action" require either a Standards Track   RFC, Experimental = RFC or an=20 Information RFC.</t> 

Is this=20 OK? 

 

------_=_NextPart_001_01C64122.558B5A65-- --===============1787849283== 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 --===============1787849283==-- From nsis-bounces@ietf.org Mon Mar 06 08:35:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFsM-0003sR-Tw; Mon, 06 Mar 2006 08:35:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFsL-0003sL-Lr for nsis@ietf.org; Mon, 06 Mar 2006 08:35:49 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFsK-0001z1-88 for nsis@ietf.org; Mon, 06 Mar 2006 08:35:49 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26DYLVA012920; Mon, 6 Mar 2006 15:34:24 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:35:20 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 15:35:19 +0200 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: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Date: Mon, 6 Mar 2006 15:35:18 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DE0@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Thread-Index: AcZBID/xhA8BgxBFSFGncTaB5Yk4iwAAjO6A From: To: X-OriginalArrivalTime: 06 Mar 2006 13:35:19.0517 (UTC) FILETIME=[CFA728D0:01C64122] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: gash@att.com, cornelia.kappler@siemens.com, Attila.Bader@ericsson.com, nsis@ietf.org, hannes.tschofenig@siemens.com 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 >Ack. I'll do that once all comments from this extended WGLC=20 >have been received, and we have a final spec to send to the=20 >ADs&IESG. A common registry would of course be nice, but is=20 >that possible? One potential model: http://www.iana.org/assignments/aaa-parameters Another model: http://www.iana.org/numbers.html - under SIP. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 14:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKwg-0003JW-Gp; Mon, 06 Mar 2006 14:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKwf-0003IG-OD for nsis@ietf.org; Mon, 06 Mar 2006 14:00:37 -0500 Received: from smtp.ci.uc.pt ([193.136.200.57] helo=smtp-2-relay.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKwZ-0005mK-Kf for nsis@ietf.org; Mon, 06 Mar 2006 14:00:37 -0500 Received: from smtp-2.ci.uc.pt (localhost [127.0.0.1]) by smtp-2-relay.ci.uc.pt (Postfix) with ESMTP id 2E16C1926DB for ; Mon, 6 Mar 2006 19:00:30 +0000 (WET) Received: from teste-d.ci.uc.pt (teste-d.ci.uc.pt [193.136.200.37]) by smtp-2.ci.uc.pt (Postfix) with ESMTP id ED8292FD00C for ; Mon, 6 Mar 2006 19:00:29 +0000 (WET) Received: from promidius (unknown [193.136.207.4]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by teste-d.ci.uc.pt (Postfix) with ESMTP id ECA744A816D for ; Mon, 6 Mar 2006 19:00:23 +0000 (WET) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: Date: Mon, 6 Mar 2006 19:00:21 -0000 Message-ID: <005801c64150$3fbd7d90$04cf88c1@promidius> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZBTjPaMozUKKIpQEyyx8Z19exCUwAAe2Dg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c5809f82a2ef36c74d8c0ab21f70455 Subject: [NSIS] HyPath 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: , Content-Type: multipart/mixed; boundary="===============0761800055==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0761800055== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C64150.3FBD7D90" This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C64150.3FBD7D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 A new draft was submitted to the NSIS WG described has HyPath. =20 This proposal was developed by the University of Coimbra (http://www.dei.uc.pt) and LAAS (http://www.laas.fr) to try to solve the problem of signaling resource managers in heterogeneous networks with = NSIS. =20 Please provide me all your comments. =20 Best regards, Lu=EDs Cordeiro =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org] Sent: quarta-feira, 1 de Mar=E7o de 2006 15:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-cordeiro-nsis-hypath-00.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : Hybrid on-path off-path approach for end-to end signalling accross NSIS domains (HyPath) Author(s) : L. Cordeiro, et al. Filename : draft-cordeiro-nsis-hypath-00.txt Pages : 20 Date : 2006-3-1 =20 In a multi-domain Internet that offers QoS guaranties for=20 applications, there is the need of signalling among the domain=20 entities that are responsible for the management of QoS. Because=20 different domains have different network protocols and topologies,=20 the HyPath approach uses the NSIS protocol and interactions with=20 the local routing protocols to have an off path signalling in=20 hybrid environments.=20 =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-00.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. =20 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. =20 =20 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-00.txt". =20 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 =20 =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-cordeiro-nsis-hypath-00.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. =20 =20 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_000_0059_01C64150.3FBD7D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

A new draft was submitted to the NSIS WG = described has HyPath.

 

This proposal was developed by the University of Coimbra (http://www.dei.uc.pt) and LAAS (http://www.laas.fr) to try to solve the problem of signaling resource managers in heterogeneous networks with = NSIS.

 

Please provide me all your = comments.

 

Best regards,

Lu=EDs Cordeiro

 

 

-----Original Message-----

From: = Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]

Sent: quarta-feira, = 1 de Mar=E7o de 2006 15:50

To: i-d-announce@ietf.org

Subject: I-D ACTION:draft-cordeiro-nsis-hypath-00.txt

 

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

 

 

      Title       : Hybrid on-path off-path = approach for end-to end

signalling accross NSIS domains (HyPath)

      Author(s)   : L. Cordeiro, et = al.

      Filename    : draft-cordeiro-nsis-hypath-00.txt

      Pages       : = 20

      Date        : = 2006-3-1

     

   In a multi-domain Internet that offers QoS guaranties for =

   applications, there is the need of signalling among the domain =

   entities that are responsible for the management of QoS. Because =

   different domains have different network protocols and topologies, =

   the HyPath approach uses the NSIS protocol and interactions with =

   the local routing protocols to have an off path signalling in =

   hybrid environments.

 

 

A URL = for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypa= th-00.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-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<= /font>

 

 

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-00.txt".

     

NOTE: = The mail server at ietf.org can return the document = in

      MIME-encoded form by using the "mpack" utility.  To use = this

      feature, insert the command "ENCODING mime" before the "FILE"

      command.  To decode the response(s), you will need = "munpack" or

      a MIME-compliant mail reader.  Different MIME-compliant mail = readers

      exhibit different behavior, especially when dealing = with

      "multipart" MIME messages (i.e. documents which have been = split

      up into multiple messages), so check your local documentation = on

      how to manipulate these messages.

           

           

Below = is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

 

------=_NextPart_000_0059_01C64150.3FBD7D90-- --===============0761800055== 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 --===============0761800055==-- From nsis-bounces@ietf.org Mon Mar 06 15:15:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGM6k-0005KJ-Hu; Mon, 06 Mar 2006 15:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGM6k-0005KE-26 for nsis@ietf.org; Mon, 06 Mar 2006 15:15:06 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGM6j-0008JB-Lq for nsis@ietf.org; Mon, 06 Mar 2006 15:15:06 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26KF4JB018727 for ; Mon, 6 Mar 2006 22:15:04 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 22:15:00 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 22:15:00 +0200 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: Mon, 6 Mar 2006 22:15:00 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DFD@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated NSIS Extensibility Model draft Thread-Index: AcZBWqTsa1Bfd08GQGOqo58OD5FPAw== From: To: X-OriginalArrivalTime: 06 Mar 2006 20:15:00.0950 (UTC) FILETIME=[A5B36F60:01C6415A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [NSIS] Updated NSIS Extensibility Model 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 Hi all, Been embroiled in other work, but I updated the extensibility draft. If I get feedback on the draft, I promise to update it immediately, as my feeling is that this content should be nailed down shortly. The draft is available here while it is stuck in the queue (appologies for the geocities links, my other server is undergoing maintenance right now). http://www.geocities.com/j_loughney/ietf/draft-loughney-nsis-ext-02.txt http://www.geocities.com/j_loughney/ietf/draft-loughney-nsis-ext-02.htm thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 16:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNJi-000635-Ow; Mon, 06 Mar 2006 16:32:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNJh-00062v-Oe for nsis@ietf.org; Mon, 06 Mar 2006 16:32:33 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGNJh-00080A-Ds for nsis@ietf.org; Mon, 06 Mar 2006 16:32:33 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1141680614!9455807!35 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12892 invoked from network); 6 Mar 2006 21:32:32 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-120.messagelabs.com with SMTP; 6 Mar 2006 21:32:32 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4401E00700112E16 for nsis@ietf.org; Mon, 6 Mar 2006 16:32:32 -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: Mon, 6 Mar 2006 15:32:32 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9C1E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-nsis-qspec-09.txt Thread-Index: AcZBYa9KwKv+GD6ZTEamuZPIwv1XJgAARxRg From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-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, The updated 'QoS-NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt. The updates include a few comments that were made up through and including WGLC: 1. remove the DiffServ example in Section 6.2 (intent is use text as a basis for a separate DIFFSERV-QOSM I-D) 2. update wording in example in Section 4.3, to reflect use of default QOSM and QOSM selection by QNI 3. make minor changes to Section 7.2.7.2, per the exchange on the list 4. add comment on error codes, after the first paragraph in Section 4.5.1. There are no further outstanding changes/comments pending and no open issues currently identified. Thanks, Regards, Jerry -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, March 06, 2006 3:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: I-D ACTION:draft-ietf-nsis-qspec-09.txt=20 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-09.txt Pages : 46 Date : 2006-3-6 =09 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 draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, 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-09.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 06 16:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMrC-00028V-NI; Mon, 06 Mar 2006 16:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMea-0001vC-6G; Mon, 06 Mar 2006 15:50:04 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMeZ-0001MW-Ca; Mon, 06 Mar 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko3BX024410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeZ-00059o-02; Mon, 06 Mar 2006 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: Mon, 06 Mar 2006 15:50:03 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-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 : QoS-NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-09.txt Pages : 46 Date : 2006-3-6 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 draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, 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-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-qspec-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-qspec-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: <2006-3-6133817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6133817.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 07 02:41:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWok-0004jW-DD; Tue, 07 Mar 2006 02:41:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWnU-00042a-Tj for nsis@ietf.org; Tue, 07 Mar 2006 02:39:56 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGWbr-0004he-U0 for nsis@ietf.org; Tue, 07 Mar 2006 02:28:03 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k277QuG6013954 for ; Tue, 7 Mar 2006 09:26:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 09:27:49 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 09:27:49 +0200 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, 7 Mar 2006 09:27:49 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E0D@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Meeting Thread-Index: AcZBuKOHeJu6xxasQXyLp53Na4DZ3w== From: To: X-OriginalArrivalTime: 07 Mar 2006 07:27:49.0264 (UTC) FILETIME=[A3175100:01C641B8] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [NSIS] NSIS Meeting 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 am planning the meeting agenda. My rough plan is as follows: THURSDAY, March 23, 2006 0900-1130 Morning Session I=20 TSV nsis Next Steps in Signaling WG WG Status update GIST update - 5 minutes QoS work update - 15 minutes (QoS NSLP, various QoS model drafts) NATFW work update - 15 minutes Mobility discussion - 15 minutes mini off-path bof - 1 hour (note - many people have been asking about this topic, so some open=20 discussion for the WG is warrented). =09 1510-1610 Afternoon Session II TSV nsis Next Steps in Signaling WG New Work discussion - 1 hour - I'm lumping all non-WG drafts into this hour, to get a sense of what people=20 think should be done. =20 - Please review the non-working drafts before the meeting and post your opinions if the work is of interest or not. - http://tools.ietf.org/wg/nsis/ contains most of the drafts in question, IMO. thoughts, comments? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 05:18:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZGp-0004kc-5L; Tue, 07 Mar 2006 05:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZGn-0004bi-NM for nsis@ietf.org; Tue, 07 Mar 2006 05:18:21 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZGn-0005EJ-3a for nsis@ietf.org; Tue, 07 Mar 2006 05:18:21 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k27AI4oW007322; Tue, 7 Mar 2006 10:18:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Date: Tue, 7 Mar 2006 10:18:03 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Thread-Index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgACy/8wA= From: "Hancock, Robert" To: , X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============1584684926==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1584684926== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C641D0.6B8B665B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C641D0.6B8B665B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable a teeny question (also in fact a question on the extensibility draft): =09 (ii) "IETF Action" what exactly is that? I've recently been studying the IANA RFC 2434 and this is not defined there. Or is this vague on purpose / defined elsewhere? Along the same lines, when updating the QSPEC IANA section we were wondering what kind of IETF action is required for defining new QOSMs / QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> "specification required" or "IETF Consensus" in IANA language !?) = or standards track (=3D> "standards action" in IANA language)? We are currently assuming it is just "specification required" and updated the QSPEC ID accordingly. Note this implies that new _optional_ QSPEC parameters will receive this same IANA treatment because they can be defined by QOSMs. (New _mandatory_ QSPEC parameters would require standards action, because they "MUST be interpreted" by all QNEs) My proposal for new text in the NSIS Ext ID is "New QoS Models can be defined by providing a specification. A new QoS Model would define the QoS parameters to be carried in the QSPEC. For details see [QSPEC ID]".=20 IETF action means:=20 Extensions subject to "IETF Action" require either a Standards Track RFC, Experimental RFC or an Information RFC. =20 a teeny question: does that include an individual submission to the RFC-Editor (which is of course nothing to do with the IETF...) ? "IETF Consensus" [from 2434] seems a closer match to the intention. r. ------_=_NextPart_001_01C641D0.6B8B665B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
a=20 teeny question (also in fact a question on the extensibility=20 draft):

 (ii) "IETF Action" what exactly is = that? I've=20 recently been studying the IANA RFC 2434 and this is not defined = there. Or is=20 this vague on purpose / defined elsewhere?

Along the same lines, = when updating=20 the QSPEC IANA section we were wondering what kind of IETF action is = required for defining new QOSMs / QOSM IDs: Will the QOSM IDs be=20 informational RFCs (=3D> "specification required" or "IETF = Consensus" in=20 IANA language !?) or standards track (=3D> "standards action" in = IANA=20 language)? We are currently assuming it is just "specification = required" and=20 updated the QSPEC ID accordingly. Note this implies that new =20 _optional_ QSPEC parameters will receive this same IANA treatment = because=20 they can be defined by QOSMs. (New _mandatory_ QSPEC parameters = would=20 require standards action, because they "MUST be interpreted" by all=20 QNEs)

My proposal for new = text in the=20 NSIS Ext ID is "New QoS Models can be defined by providing a = specification.=20 A new QoS Model would define the QoS parameters to be carried in the = QSPEC.=20 For details see [QSPEC ID]".

 IETF action=20 means: 

<t>Extensions=20 subject to "IETF Action" require either a Standards Track   RFC, Experimental RFC = or an=20 Information RFC.</t>  

<= /BLOCKQUOTE>

a teeny question: does that include an = individual=20 submission to the RFC-Editor (which is of course nothing to do with the = IETF...)=20 ? "IETF Consensus" [from 2434] seems a closer match to the=20 intention.

r.

------_=_NextPart_001_01C641D0.6B8B665B-- --===============1584684926== 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 --===============1584684926==-- From nsis-bounces@ietf.org Tue Mar 07 05:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZJd-0007YA-M8; Tue, 07 Mar 2006 05:21:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZJc-0007Y5-5t for nsis@ietf.org; Tue, 07 Mar 2006 05:21:16 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZJa-0005In-O1 for nsis@ietf.org; Tue, 07 Mar 2006 05:21:16 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27AL94N010717; Tue, 7 Mar 2006 12:21:11 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:21:10 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:21:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Date: Tue, 7 Mar 2006 12:21:09 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E25@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs Thread-Index: AcYGGtu4bcmLfQvLSgugBRwOwZdaRQ7AbWhgACy/8wAAAEePwA== From: To: , X-OriginalArrivalTime: 07 Mar 2006 10:21:09.0946 (UTC) FILETIME=[DA6171A0:01C641D0] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: gash@att.com, nsis@ietf.org, Attila.Bader@ericsson.com 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="===============0592262409==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0592262409== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C641D0.DA2BC073" This is a multi-part message in MIME format. ------_=_NextPart_001_01C641D0.DA2BC073 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > a teeny question: does that include an individual submission to the RFC-Editor (which is of course nothing to do with the IETF...) ? =20 > "IETF Consensus" [from 2434] seems a closer match to the intention.=20 =20 I think that would be OK. The RFC editor always checks with the IESG before approving an RFC as an RFC Editor submission. =20 John ------_=_NextPart_001_01C641D0.DA2BC073 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
> =  a=20 teeny question: does that include an individual submission to the = RFC-Editor=20 (which is of course nothing to do with the IETF...) ?  
>  "IETF = Consensus" [from=20 2434] seems a closer match to the intention. 
 
I think that would be OK. The = RFC editor=20 always checks with the IESG before approving an RFC as an RFC Editor=20 submission.
 
John=
------_=_NextPart_001_01C641D0.DA2BC073-- --===============0592262409== 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 --===============0592262409==-- From nsis-bounces@ietf.org Tue Mar 07 05:55:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZr7-0002UP-1x; Tue, 07 Mar 2006 05:55:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZr6-0002UH-4U; Tue, 07 Mar 2006 05:55:52 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZr4-0006HZ-Mk; Tue, 07 Mar 2006 05:55:52 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27AsE3i001187; Tue, 7 Mar 2006 12:54:17 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:55:48 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:55:47 +0200 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, 7 Mar 2006 12:55:47 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E32@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Working Group Last call on Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Thread-Index: AcZB1bB4EMld5FdOQH6/ro2Pk+uBBA== From: To: X-OriginalArrivalTime: 07 Mar 2006 10:55:48.0052 (UTC) FILETIME=[B1074140:01C641D5] X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] NSIS Working Group Last call on Y.1541 QoS Model for Networks Using Y.1541 QoS Classes 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 seems that the remaining open issues on "Y.1541 QoS Model for Networks Using Y.1541 QoS Classes"=20 have been closed. I would like to start a 2 week WGLC on this draft, which will bring us to March 21st. Please submit issues and text recommendations for the draft. If you have read the draft, and you think it=20 is in good shape, then please let us know. You can find the draft at: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-01.txt John PS - BCC'ed to TSVWG WG, please reply on the NSIS mailing list. If you are not a subscriber, I will approve posting rights for you. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 05:57:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZsG-0003SY-PO; Tue, 07 Mar 2006 05:57:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZsF-0003SQ-Hw; Tue, 07 Mar 2006 05:57:03 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZsE-0006JC-3O; Tue, 07 Mar 2006 05:57:03 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27Au2wR012835; Tue, 7 Mar 2006 12:56:03 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:57:00 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 12:57:00 +0200 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, 7 Mar 2006 12:57:00 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E33@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869E32@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Working Group Last call on "RMD - The Resource Management in Diffserv QOS Model" Thread-Index: AcZB1bB4EMld5FdOQH6/ro2Pk+uBBAAAAtjA From: To: X-OriginalArrivalTime: 07 Mar 2006 10:57:00.0784 (UTC) FILETIME=[DC614700:01C641D5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [NSIS] NSIS Working Group Last call on "RMD - The Resource Management in Diffserv QOS Model" 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 seems that the remaining open issues on "RMD - The Resource Management in Diffserv QOS Model"=20 have been closed. I would like to start a 2 week WGLC on this draft, which will bring us to March 21st. Please submit issues and text recommendations for the draft. If you have read the draft, and you think it is in good shape, then please let us know. You can find the draft at: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-06.txt John PS - BCC'ed to TSVWG WG, please reply on the NSIS mailing list. If you are not a subscriber, I will approve posting rights for you. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 06:16:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaBD-0000It-TY; Tue, 07 Mar 2006 06:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaBB-0000Aw-PB for nsis@ietf.org; Tue, 07 Mar 2006 06:16:37 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGaBA-0006t7-Fz for nsis@ietf.org; Tue, 07 Mar 2006 06:16:37 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FGaAx-0001Nl-4m; Tue, 07 Mar 2006 12:16:25 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (i72vorta.tm.uni-karlsruhe.de [141.3.71.26]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id D65538696; Tue, 7 Mar 2006 12:16:22 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FGa9O-0007Jr-ER; Tue, 07 Mar 2006 12:14:46 +0100 Message-ID: <440D6B26.7020603@tm.uka.de> Date: Tue, 07 Mar 2006 12:14:46 +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: Andrew McDonald Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs References: <440C362E.6030203@roke.co.uk> In-Reply-To: <440C362E.6030203@roke.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: nsis@ietf.org, "Tschofenig, Hannes" 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 also noticed that the QoS NSLP fails to define the values for the > objects that go in to messages, which surprises me since some people > claim to have implemented it. :-) Logged as issue #46: :-) Yep, implementation is basically no problem if you pick some values, but interoperability might be an issue :-) So far we had no inter-op tests for QoS NSLP. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 06:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaib-0004nh-6M; Tue, 07 Mar 2006 06:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaia-0004jY-BJ for nsis@ietf.org; Tue, 07 Mar 2006 06:51:08 -0500 Received: from smtp6.libero.it ([193.70.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGaiZ-0007s5-1e for nsis@ietf.org; Tue, 07 Mar 2006 06:51:08 -0500 Received: from localhost (172.16.1.212) by smtp6.libero.it (7.0.027-DD01) id 43F225FD01ED48A1 for nsis@ietf.org; Tue, 7 Mar 2006 12:51:05 +0100 Received: from smtp0.libero.it ([172.16.1.204]) by localhost (asav6.libero.it [193.70.192.40]) (amavisd-new, port 10024) with ESMTP id 21552-02-3 for ; Tue, 7 Mar 2006 12:51:05 +0100 (CET) Received: from libero.it (192.168.17.1) by smtp0.libero.it (7.0.027-DD01) id 439064B400FCE364 for nsis@ietf.org; Tue, 7 Mar 2006 12:51:05 +0100 Date: Tue, 7 Mar 2006 12:50:57 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Elena Scialpi" To: "nsis" X-XaM3-API-Version: 4.3 (R1) (B3pl14) X-SenderIP: 212.189.140.2 X-Scanned: with antispam and antivirus automated system at libero.it X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [NSIS] Question on our 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 Hi all, 10 days ago we have submitted an a new draft "Semi-Proactive QoS Re-estab= lishment". It can be found at http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt I would want to know if someone has read the draft and if there are some = question on it. Thanks in advance, Elena Abstract Re-establishment of QoS after a Mobile Node handover must be done as quickly as possible in order to reduce degradation or interruption of QoS. It is specifically useful if real-time applications are used. We propose a Semi-Proactive procedure for QoS re-establisment that also avoids waste of resources. Moreover, we propose a new point of buffering for the packets destined to the Mobile Node during the handover. This is useful when QoS is required for these packets. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 07:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbJf-0002lR-TD; Tue, 07 Mar 2006 07:29:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbJe-0002l2-FL for nsis@ietf.org; Tue, 07 Mar 2006 07:29:26 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbJd-0000hj-3B for nsis@ietf.org; Tue, 07 Mar 2006 07:29:26 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FGbJY-000571-K6; Tue, 07 Mar 2006 13:29:22 +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 4A0BF8A24; Tue, 7 Mar 2006 13:29:20 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FGbJX-0007T0-RV; Tue, 07 Mar 2006 13:29:19 +0100 Message-ID: <440D7C9F.8090802@tm.uka.de> Date: Tue, 07 Mar 2006 13:29:19 +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: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: john.loughney@nokia.com, gash@att.com, nsis@ietf.org, hannes.tschofenig@siemens.com, Attila.Bader@ericsson.com, cornelia.kappler@siemens.com 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, > However, GIST creates 2 registries (NSLPID and MRMID) which are > referred to by all NSLPs. In addition, AFAIK the NSLP object type > registry is shared between all NSLPs, but GIST doesn't create it (its > object types are its own), so some other mechanism is needed for > that. Does it really make sense to have a shared NSLP object type registry? Do we have common objects? Any advantages compared to NSLP specific types? > The above implies to me that a single NSIS registry is more sensible. Sure, NSLPID and MRMID are related to NSLPs because they are used at the interface between GIST and NSLPs. However, one could also assign them to a GIST related registry. Moreover, if we decide that NSLP object type IDs are not shared between all NSLPs, I don't see a compelling reason for a single NSIS registry. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 08:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGcae-0002Ar-Mn; Tue, 07 Mar 2006 08:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGcae-0002Am-2h for nsis@ietf.org; Tue, 07 Mar 2006 08:51:04 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGcac-0002uv-MH for nsis@ietf.org; Tue, 07 Mar 2006 08:51:04 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k27DocoW002352; Tue, 7 Mar 2006 13:50:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Date: Tue, 7 Mar 2006 13:50:38 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Thread-Index: AcZB4tC4Br/21FWMSfWTX93A/J1vXQACxVqw From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: john.loughney@nokia.com, gash@att.com, nsis@ietf.org, hannes.tschofenig@siemens.com, Attila.Bader@ericsson.com, cornelia.kappler@siemens.com 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, > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 07 March 2006 12:29 > To: Hancock, Robert > Cc: john.loughney@nokia.com; hannes.tschofenig@siemens.com;=20 > cornelia.kappler@siemens.com; gash@att.com; nsis@ietf.org;=20 > Attila.Bader@ericsson.com > Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE:=20 > QOSM IANA Status /NSIS Extensibility Doc on QOSMs >=20 >=20 > Hi Robert, >=20 > > However, GIST creates 2 registries (NSLPID and MRMID) which are > > referred to by all NSLPs. In addition, AFAIK the NSLP object type > > registry is shared between all NSLPs, but GIST doesn't=20 > create it (its > > object types are its own), so some other mechanism is needed for > > that. >=20 > Does it really make sense to have a shared NSLP object type registry? > Do we have common objects? Any advantages compared to NSLP specific > types? it's an old discussion; see for example the thread starting here http://www1.ietf.org/mail-archive/web/nsis/current/msg03990.html (2004, how time flies...) i don't know whether it's possible or desirable to reopen it. >=20 > > The above implies to me that a single NSIS registry is more=20 > sensible. >=20 > Sure, NSLPID and MRMID are related to NSLPs because they are used > at the interface between GIST and NSLPs. However, one could also > assign them to a GIST related registry. > Moreover, if we decide that NSLP object type IDs are not shared > between all NSLPs, I don't see a compelling reason for a single NSIS > registry. the object type is the major issue rather than the other two, i agree. r. >=20 > Regards, > Roland >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 09:38:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdKh-0005eC-Hd; Tue, 07 Mar 2006 09:38:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdKg-0005e3-Fr for nsis@ietf.org; Tue, 07 Mar 2006 09:38:38 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdKf-0004vU-To for nsis@ietf.org; Tue, 07 Mar 2006 09:38:38 -0500 Received: from [195.37.70.137] (unknown [195.37.70.137]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 411241BAC4D; Tue, 7 Mar 2006 15:39:13 +0100 (CET) In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DC6@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01869DC6@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86B6B74B-E1BB-42F2-8952-0B9F01BF45BC@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW Issue 60: Signaling for ICMP policy rules Date: Tue, 7 Mar 2006 15:38:32 +0100 To: X-Mailer: Apple Mail (2.746.2) 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 Am 06.03.2006 um 12:34 schrieb : > This looks good to me. Great. It has been added to the draft which is going to show up on the I-D announce list within the next days. It is now in Section 4.2.10 "ICMP Types Object". Martin > > John > >> -----Original Message----- >> From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: 24 February, 2006 11:55 >> To: nsis >> Subject: [NSIS] NATFW Issue 60: Signaling for ICMP policy rules >> >> Hi all, >> >> We have had the discussions about adding ICMP policy rules to >> the NATFW NSLP. A short summary of the topic: >> >> 3GPP2 requested a feature to signal for ICMP policy rules, >> i.e., a NATFW node should be able to block a certain type of >> ICMP traffic, but not meaning ICMP traffic bound to an already >> configured flow (for instance, ICMP messages related to a TCP >> session). >> >> Elwyn propose this object to carry ICMP information within the NATFW >> NSLP: >> >> 4.2.10 ICMP Types Object >> >> The 'ICMP types' object contains additional information needed to >> configure a NAT of firewall with rules to control ICMP >> traffic. The >> object contains a number of values of the ICMP Type field >> for which a >> filter action should be set up: >> >> Type: NATFW_ICMP_TYPES >> >> Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | Count | Type | Type >> | ........ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> >> | ................ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | ........ | Type | >> (Padding) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> >> >> >> Figure 34: ICMP Types Object >> >> The fields MUST be interpreted according these rules: >> >> count: 8 bit integer specifying the number of 'Type' entries in >> the object. >> >> type: 8 bit field specifying the ICMP Type values to which this >> rule applies. >> >> padding: Sufficient 0 bits to pad out the last word so that the >> total size of object is an even multiple of words. Ignored on >> reception. >> >> _______________________________________________ >> 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 07 09:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdMm-00079N-P6; Tue, 07 Mar 2006 09:40:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdMk-00078M-UE for nsis@ietf.org; Tue, 07 Mar 2006 09:40:46 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdMh-00050H-DA for nsis@ietf.org; Tue, 07 Mar 2006 09:40:46 -0500 Received: from [195.37.70.137] (unknown [195.37.70.137]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C4CDE1BAC4D; Tue, 7 Mar 2006 15:41:18 +0100 (CET) In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DC7@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01869DC7@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW Issue 63: Aggregation of NSLP signaling messages (wassignaling session wildcarding) Date: Tue, 7 Mar 2006 15:40:41 +0100 To: X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Thanks and added to the upcoming -10 draft under 3.8.4 "Deleting Sessions" Martin Am 06.03.2006 um 12:34 schrieb : > This looks good to me. > >> -----Original Message----- >> From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: 02 March, 2006 14:31 >> To: nsis >> Subject: [NSIS] NATFW Issue 63: Aggregation of NSLP signaling >> messages (wassignaling session wildcarding) >> >> Dear all, >> >> The issue 63 (https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/ >> issue63) >> refers to the below section out of the 3GPP2 requirements draft >> (http://www.watersprings.org/pub/id/draft-bajko-nsis-fw-reqs-04.txt) >> >> 5.1.7 Efficient use of the air interface >> >> The protocol MUST allow an end point to create, modify or delete >> several firewall states with one protocol instance. >> >> NOTE: a Firewall Configuration Protocol should provide a solution >> for the above requirement in a single Firewall architecture. In a >> multihomed scenario, with multiple Firewalls on alternative paths, >> there should be a means for the Firewalls to keep themselves >> synchronized. >> >> This capability is useful in some wireless networks, where the >> access link resources are limited. This would reduce the overhead >> and the delay of the procedures. >> >> It MUST be possible to open a pinhole with a single protocol >> request/response pair of messages. This is required because: >> a) a wireless link is a scarce and expensive resource >> b) real-time applications are delay sensitive >> >> After further discussions with Gabor we have concluded that >> basically a function is needed to teardown multiple session >> belonging to a single NATFW NSLP node. For instance, if a >> mobile terminal is shutting down, it can send a single NATFW >> NSLP message and all session concerned will be terminated. >> The solution to this is similar to the NOTIFY storm avoidance. >> For NOTIFY the upcoming version of the draft contains: >> >> To avoid the need of generating per signaling session >> NOTIFY message >> in such a described or similar scenario, NFs SHOULD follow this >> procedure: The NF uses the NOTIFY message with the session >> ID in the >> NTLP set to zero, with the MRI completely wildcarded, and the >> 'explicit routing' as described in Sections 5.2.1 and >> 7.1.4. in [1]. >> The upstream NF receiving this type of NOTIFY immediately >> regards all >> signaling sessions from that peer matching the MRI as void. >> >> (taken from here: http://www.stiemerling.org/ietf/nsis/snapshot/ >> snapshot.txt) >> >> The teardown of all session for a specific node could be done >> in this way >> - Set the MRI to source IP address of the node >> - wildcard all other parameter >> - Set SID to zero >> - Use 'explicit routing' in the NTLP >> - NSLP message with lifetime set to zero >> >> Any thoughts, comments, or objections about it? >> >> Martin >> >> >> _______________________________________________ >> 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 07 10:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeNj-0003RS-4m; Tue, 07 Mar 2006 10:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeNi-0003RI-As for nsis@ietf.org; Tue, 07 Mar 2006 10:45:50 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGd59-0004SD-Rs for nsis@ietf.org; Tue, 07 Mar 2006 09:22:35 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGctW-0006Xw-V0 for nsis@ietf.org; Tue, 07 Mar 2006 09:10:36 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27E8uMo018749; Tue, 7 Mar 2006 16:08:57 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 16:09:36 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 16:09:35 +0200 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: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Date: Tue, 7 Mar 2006 16:09:35 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E47@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Thread-Index: AcZB4tC4Br/21FWMSfWTX93A/J1vXQACxVqwAAC0olA= From: To: , X-OriginalArrivalTime: 07 Mar 2006 14:09:35.0952 (UTC) FILETIME=[C3CBFD00:01C641F0] X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: gash@att.com, cornelia.kappler@siemens.com, Attila.Bader@ericsson.com, nsis@ietf.org, hannes.tschofenig@siemens.com 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 That is my memory as well, so I think we need to assume a single registry until proven otherwise. John=20 >-----Original Message----- >From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 >Sent: 07 March, 2006 15:51 >To: Roland Bless >Cc: Loughney John (Nokia-NRC/Helsinki);=20 >hannes.tschofenig@siemens.com; cornelia.kappler@siemens.com;=20 >gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com >Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE:=20 >QOSM IANA Status /NSIS Extensibility Doc on QOSMs > >hi, > >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: 07 March 2006 12:29 >> To: Hancock, Robert >> Cc: john.loughney@nokia.com; hannes.tschofenig@siemens.com;=20 >> cornelia.kappler@siemens.com; gash@att.com; nsis@ietf.org;=20 >> Attila.Bader@ericsson.com >> Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE:=20 >> QOSM IANA Status /NSIS Extensibility Doc on QOSMs >>=20 >>=20 >> Hi Robert, >>=20 >> > However, GIST creates 2 registries (NSLPID and MRMID) which are=20 >> > referred to by all NSLPs. In addition, AFAIK the NSLP object type=20 >> > registry is shared between all NSLPs, but GIST doesn't >> create it (its >> > object types are its own), so some other mechanism is needed for=20 >> > that. >>=20 >> Does it really make sense to have a shared NSLP object type registry? >> Do we have common objects? Any advantages compared to NSLP specific=20 >> types? > >it's an old discussion; see for example the thread starting=20 >here http://www1.ietf.org/mail-archive/web/nsis/current/msg03990.html >(2004, how time flies...) > >i don't know whether it's possible or desirable to reopen it. > >>=20 >> > The above implies to me that a single NSIS registry is more >> sensible. >>=20 >> Sure, NSLPID and MRMID are related to NSLPs because they are used at=20 >> the interface between GIST and NSLPs. However, one could also assign=20 >> them to a GIST related registry. >> Moreover, if we decide that NSLP object type IDs are not shared=20 >> between all NSLPs, I don't see a compelling reason for a single NSIS=20 >> registry. > >the object type is the major issue rather than the other two, i agree. > >r. > >>=20 >> Regards, >> Roland >>=20 >>=20 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 07 11:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGf1v-0001KC-Aj; Tue, 07 Mar 2006 11:27:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGf1u-0001JF-5O for nsis@ietf.org; Tue, 07 Mar 2006 11:27:22 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGf1r-0000t6-RM for nsis@ietf.org; Tue, 07 Mar 2006 11:27:22 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FGf1o-0001cU-K0; Tue, 07 Mar 2006 17:27:18 +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 E25DA8A2A; Tue, 7 Mar 2006 17:27:15 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FGf1n-0007hQ-Io; Tue, 07 Mar 2006 17:27:15 +0100 Message-ID: <440DB462.1000401@tm.uka.de> Date: Tue, 07 Mar 2006 17:27: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: "Hancock, Robert" Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: john.loughney@nokia.com, 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, > it's an old discussion; see for example the thread starting here > http://www1.ietf.org/mail-archive/web/nsis/current/msg03990.html > (2004, how time flies...) Thanks a lot for this pointer...I could remember only very vaguely a related discussion and wasn't able to locate it so quickly in my archive, and, yes, time flies :-( > i don't know whether it's possible or desirable to reopen it. I guess that I have to re-read the thread carefully, but I also understand that John doesn't want to make such late changes. ;-) Cheers, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 08 01:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGsQC-0002Bl-3M; Wed, 08 Mar 2006 01:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGd7v-0003wS-Pi for nsis@ietf.org; Tue, 07 Mar 2006 09:25:27 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGd7v-0004Xp-DJ for nsis@ietf.org; Tue, 07 Mar 2006 09:25:27 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 7 Mar 2006 09:25:17 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006030709251712359 ; Tue, 07 Mar 2006 09:25:17 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Mar 2006 09:25:17 -0500 Message-Id: From: "Roy, Radhika R." To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] NSIS Working Group Last call on Y.1541 QoS Model forNe tworks Using Y.1541 QoS Classes Date: Tue, 7 Mar 2006 09:25:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-Mailman-Approved-At: Wed, 08 Mar 2006 01:45:19 -0500 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: I provided some comments as included below. [My reply is bouncing back from the mailing list. I tried to subscribe again and again. It indicates me that I am already registered. I ma receiving all emails, but replies do not go through. My email address is Radhika.R.Roy@saic.com (sometimes Radhika.R.Roy@us.saic.com - this is NOT registered - if this is a problem, can someone help me to register this address).] I would appreciate your help. Best regards, Radhika ________________________________________ From: Roy, Radhika R. Sent: Monday, March 06, 2006 5:02 PM To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-09.txt There have been further comments as follows: 1. To clarify priority levels: What does it mean it mean? Is it for media? Is it for call (e.g., SIP)? Or, is it for something? 2. To remove the implementation specific extensions that do not belong to this "generic" draft * Y.xxx specific extensions of QSPEC (It will go where Y.xxx extensions of QSPEC draft is dealing). * DiffServ specific extensions of QSPEC parameters (need to do a separate draft like Y.xxxx as stated above) The above comments are yet to be taken care of. Best Regards, Radhika ________________________________________ From: nsis-bounces@ietf.org on behalf of Ash, Gerald R (Jerry), ALABS Sent: Mon 3/6/2006 4:32 PM To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-09.txt Hi All, The updated 'QoS-NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt . The updates include a few comments that were made up through and including WGLC: 1. remove the DiffServ example in Section 6.2 (intent is use text as a basis for a separate DIFFSERV-QOSM I-D) 2. update worFrom nsis-bounces@ietf.org Wed Mar 08 01:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGsQC-0002Bl-3M; Wed, 08 Mar 2006 01:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGd7v-0003wS-Pi for nsis@ietf.org; Tue, 07 Mar 2006 09:25:27 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGd7v-0004Xp-DJ for nsis@ietf.org; Tue, 07 Mar 2006 09:25:27 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 7 Mar 2006 09:25:17 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006030709251712359 ; Tue, 07 Mar 2006 09:25:17 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Mar 2006 09:25:17 -0500 Message-Id: From: "Roy, Radhika R." To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] NSIS Working Group Last call on Y.1541 QoS Model forNe tworks Using Y.1541 QoS Classes Date: Tue, 7 Mar 2006 09:25:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-Mailman-Approved-At: Wed, 08 Mar 2006 01:45:19 -0500 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: I provided some comments as included below. [My reply is bouncing back from the mailing list. I tried to subscribe again and again. It indicates me that I am already registered. I ma receiving all emails, but replies do not go through. My email address is Radhika.R.Roy@saic.com (sometimes Radhika.R.Roy@us.saic.com - this is NOT registered - if this is a problem, can someone help me to register this address).] I would appreciate your help. Best regards, Radhika ________________________________________ From: Roy, Radhika R. Sent: Monday, March 06, 2006 5:02 PM To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-09.txt There have been further comments as follows: 1. To clarify priority levels: What does it mean it mean? Is it for media? Is it for call (e.g., SIP)? Or, is it for something? 2. To remove the implementation specific extensions that do not belong to this "generic" draft * Y.xxx specific extensions of QSPEC (It will go where Y.xxx extensions of QSPEC draft is dealing). * DiffServ specific extensions of QSPEC parameters (need to do a separate draft like Y.xxxx as stated above) The above comments are yet to be taken care of. Best Regards, Radhika ________________________________________ From: nsis-bounces@ietf.org on behalf of Ash, Gerald R (Jerry), ALABS Sent: Mon 3/6/2006 4:32 PM To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-09.txt Hi All, The updated 'QoS-NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt . The updates include a few comments that were made up through and including WGLC: 1. remove the DiffServ example in Section 6.2 (intent is use text as a basis for a separate DIFFSERV-QOSM I-D) 2. update wording in example in Section 4.3, to reflect use of default QOSM and QOSM selection by QNI 3. make minor changes to Section 7.2.7.2, per the exchange on the list 4. add comment on error codes, after the first paragraph in Section 4.5.1. There are no further outstanding changes/comments pending and no open issues currently identified. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org ] On Behalf Of john.loughney@nokia.com Sent: Tuesday, March 07, 2006 5:56 AM To: nsis@ietf.org Subject: [NSIS] NSIS Working Group Last call on Y.1541 QoS Model forNetworks Using Y.1541 QoS Classes Hi all, It seems that the remaining open issues on "Y.1541 QoS Model for Networks Using Y.1541 QoS Classes" have been closed. I would like to start a 2 week WGLC on this draft, which will bring us to March 21st. Please submit issues and text recommendations for the draft. If you have read the draft, and you think it is in good shape, then please let us know. You can find the draft at: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-01.txt John PS - BCC'ed to TSVWG WG, please reply on the NSIS mailing list. If you are not a subscriber, I will approve posting rights for you. _______________________________________________ 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 08 01:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGsQC-0002Bq-Bs; Wed, 08 Mar 2006 01:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGddJ-0004zw-IE for nsis@ietf.org; Tue, 07 Mar 2006 09:57:53 -0500 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGddH-0005Tq-Ba for nsis@ietf.org; Tue, 07 Mar 2006 09:57:53 -0500 Received: from eden.dei.uc.pt (eden-out.dei.uc.pt [193.136.212.2]) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k27EluAx023175 for ; Tue, 7 Mar 2006 14:47:56 GMT Received: from eden.dei.uc.pt (localhost [127.0.0.1]) by eden.dei.uc.pt (8.13.5/8.13.5) with ESMTP id k27Eluwb032534 for ; Tue, 7 Mar 2006 14:47:56 GMT Received: from localhost (zhang@localhost) by eden.dei.uc.pt (8.13.5/8.13.1/Submit) with ESMTP id k27Elu2N032531 for ; Tue, 7 Mar 2006 14:47:56 GMT Date: Tue, 7 Mar 2006 14:47:56 +0000 (WET) From: Jian Zhang To: nsis@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="34210048-467410686-1141742876=:31649" X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.599, required 3, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: zhang@eden.dei.uc.pt X-Spam-Score: 0.0 (/) X-Scan-Signature: d7802e9da0b1d11bf32ba03c41071b61 X-Mailman-Approved-At: Wed, 08 Mar 2006 01:45:19 -0500 Subject: [NSIS] A new draft about the NSIS QOS Model for Inter-domain Signaling 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: -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org ] On Behalf Of john.loughney@nokia.com Sent: Tuesday, March 07, 2006 5:56 AM To: nsis@ietf.org Subject: [NSIS] NSIS Working Group Last call on Y.1541 QoS Model forNetworks Using Y.1541 QoS Classes Hi all, It seems that the remaining open issues on "Y.1541 QoS Model for Networks Using Y.1541 QoS Classes" have been closed. I would like to start a 2 week WGLC on this draft, which will bring us to March 21st. Please submit issues and text recommendations for the draft. If you have read the draft, and you think it is in good shape, then please let us know. You can find the draft at: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-01.txt John PS - BCC'ed to TSVWG WG, please reply on the NSIS mailing list. If you are not a subscriber, I will approve posting rights for you. _______________________________________________ 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 08 01:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGsQC-0002Bq-Bs; Wed, 08 Mar 2006 01:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGddJ-0004zw-IE for nsis@ietf.org; Tue, 07 Mar 2006 09:57:53 -0500 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGddH-0005Tq-Ba for nsis@ietf.org; Tue, 07 Mar 2006 09:57:53 -0500 Received: from eden.dei.uc.pt (eden-out.dei.uc.pt [193.136.212.2]) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k27EluAx023175 for ; Tue, 7 Mar 2006 14:47:56 GMT Received: from eden.dei.uc.pt (localhost [127.0.0.1]) by eden.dei.uc.pt (8.13.5/8.13.5) with ESMTP id k27Eluwb032534 for ; Tue, 7 Mar 2006 14:47:56 GMT Received: from localhost (zhang@localhost) by eden.dei.uc.pt (8.13.5/8.13.1/Submit) with ESMTP id k27Elu2N032531 for ; Tue, 7 Mar 2006 14:47:56 GMT Date: Tue, 7 Mar 2006 14:47:56 +0000 (WET) From: Jian Zhang To: nsis@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="34210048-467410686-1141742876=:31649" X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.599, required 3, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: zhang@eden.dei.uc.pt X-Spam-Score: 0.0 (/) X-Scan-Signature: d7802e9da0b1d11bf32ba03c41071b61 X-Mailman-Approved-At: Wed, 08 Mar 2006 01:45:19 -0500 Subject: [NSIS] A new draft about the NSIS QOS Model for Inter-domain Signaling 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --34210048-467410686-1141742876=:31649 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Dear all, A new draft about the NSIS QOS Model for Inter-domain Signaling has been submitted to the NSIS WG, which can be found at http://www.ietf.org/internet-drafts/draft-zhang-nsis-interdomain-qosm-00.txt. Now the 01 version of this draft is attached in this email. Any comments are welcome. Regards, Jian Zhang Univ. of Coimbra. Abstract This document describes a NSIS QoS Model for inter-domain signaling (InterDomain-QOSM) between adjacent domains to enable end-to-end QoS provisioning over heterogeneous network domains. Specifically, it assumes a distinct separation between the intra-domain control plane and the inter-domain control plane at each administrative domain and is intended to implement a common inter-domain interface that allows the QoS negotiation and setup of inter-domain traffic streams while hiding the heterogeneity of intra-domain control mechanisms in use in a chain of heterogeneous network domains. The InterDomain-QoSM in this document first describes its operation mode and then the additional QSPEC parameters for fulfilling the common inter-domain interface are specified, followed by the illustrations of how the InterDomain-QOSM interacts with some typical intra-domain QoS models to achieve the end-to-end QoS provisioning over heterogeneous domains in a standardized and dynamic way. ---------------------------------------------- --34210048-467410686-1141742876=:31649 Content-Type: TEXT/plain; charset=US-ASCII; name=draft-zhang-nsis-interdomain-qosm-01.txt Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename=draft-zhang-nsis-interdomain-qosm-01.txt DQpOU0lTIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBKLiBaaGFuZw0KSW50ZXJuZXQgRHJhZnQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RS4gTW9udGVpcm8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVW5pdmVyc2l0eSBvZiBDb2ltYnJhDQpFeHBp cmF0aW9uIERhdGU6IFNlcHRlbXBlciAwNiwgMjAwNiAgICAgICAgICAgICAg ICAgICAgICAgIE1hciAwNywgMjAwNg0KDQogICBJbnRlckRvbWFpbi1RT1NN OiBUaGUgTlNJUyBRT1MgTW9kZWwgZm9yIEludGVyLWRvbWFpbiBTaWduYWxp bmcgdG8NCiBFbmFibGUgRW5kLXRvLUVuZCBRb1MgUHJvdmlzaW9uaW5nIE92 ZXIgSGV0ZXJvZ2VuZW91cyBOZXR3b3JrIERvbWFpbnMNCiAgICAgICAgICAg ICAgICA8ZHJhZnQtemhhbmctbnNpcy1pbnRlcmRvbWFpbi1xb3NtLTAxLnR4 dD4NCiAgICAgICAgICAgICAgICAgICANClN0YXR1cyBvZiB0aGlzIE1lbW8N Cg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNo IGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBh dGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBp cyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBh bmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3 aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24g NiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAg IERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UN CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJ bnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8v d3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBj YW4gYmUgYWNjZXNzZWQgYXQNCiAgIGsis>, Errors-To: nsis-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --34210048-467410686-1141742876=:31649 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Dear all, A new draft about the NSIS QOS Model for Inter-domain Signaling has been submitted to the NSIS WG, which can be found at http://www.ietf.org/internet-drafts/draft-zhang-nsis-interdomain-qosm-00.txt. Now the 01 version of this draft is attached in this email. Any comments are welcome. Regards, Jian Zhang Univ. of Coimbra. Abstract This document describes a NSIS QoS Model for inter-domain signaling (InterDomain-QOSM) between adjacent domains to enable end-to-end QoS provisioning over heterogeneous network domains. Specifically, it assumes a distinct separation between the intra-domain control plane and the inter-domain control plane at each administrative domain and is intended to implement a common inter-domain interface that allows the QoS negotiation and setup of inter-domain traffic streams while hiding the heterogeneity of intra-domain control mechanisms in use in a chain of heterogeneous network domains. The InterDomain-QoSM in this document first describes its operation mode and then the additional QSPEC parameters for fulfilling the common inter-domain interface are specified, followed by the illustrations of how the InterDomain-QOSM interacts with some typical intra-domain QoS models to achieve the end-to-end QoS provisioning over heterogeneous domains in a standardized and dynamic way. ---------------------------------------------- --34210048-467410686-1141742876=:31649 Content-Type: TEXT/plain; charset=US-ASCII; name=draft-zhang-nsis-interdomain-qosm-01.txt Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename=draft-zhang-nsis-interdomain-qosm-01.txt DQpOU0lTIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBKLiBaaGFuZw0KSW50ZXJuZXQgRHJhZnQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RS4gTW9udGVpcm8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVW5pdmVyc2l0eSBvZiBDb2ltYnJhDQpFeHBp cmF0aW9uIERhdGU6IFNlcHRlbXBlciAwNiwgMjAwNiAgICAgICAgICAgICAg ICAgICAgICAgIE1hciAwNywgMjAwNg0KDQogICBJbnRlckRvbWFpbi1RT1NN OiBUaGUgTlNJUyBRT1MgTW9kZWwgZm9yIEludGVyLWRvbWFpbiBTaWduYWxp bmcgdG8NCiBFbmFibGUgRW5kLXRvLUVuZCBRb1MgUHJvdmlzaW9uaW5nIE92 ZXIgSGV0ZXJvZ2VuZW91cyBOZXR3b3JrIERvbWFpbnMNCiAgICAgICAgICAg ICAgICA8ZHJhZnQtemhhbmctbnNpcy1pbnRlcmRvbWFpbi1xb3NtLTAxLnR4 dD4NCiAgICAgICAgICAgICAgICAgICANClN0YXR1cyBvZiB0aGlzIE1lbW8N Cg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNo IGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBh dGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBp cyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBh bmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3 aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24g NiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAg IERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UN CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJ bnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8v d3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBj YW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gU2VwdGVtYmVyIDIwMDYuIA0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYp Lg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IE5TSVMgUW9TIE1vZGVsIGZvciBpbnRlci1kb21haW4gc2lnbmFsaW5nIA0K ICAgKEludGVyRG9tYWluLVFPU00pIGJldHdlZW4gYWRqYWNlbnQgZG9tYWlu cyB0byBlbmFibGUgZW5kLXRvLWVuZCBRb1MgDQogICBwcm92aXNpb25pbmcg b3ZlciBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgZG9tYWlucy4gU3BlY2lmaWNh bGx5LCBpdCANCiAgIGFzc3VtZXMgYSBkaXN0aW5jdCBzZXBhcmF0aW9uIGJl dHdlZW4gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIHBsYW5lDQogICBhbmQg dGhlIGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIGF0IGVhY2ggYWRtaW5p c3RyYXRpdmUgZG9tYWluIGFuZA0KICAgaXMgaW50ZW5kZWQgdG8gaW1wbGVt ZW50IGEgY29tbW9uIGludGVyLWRvbWFpbiBpbnRlcmZhY2UgdGhhdCBhbGxv d3MNCiAgIHRoZSBRb1MgbmVnb3RpYXRpb24gYW5kIHNldHVwIG9mIGludGVy LWRvbWFpbiB0cmFmZmljIHN0cmVhbXMgd2hpbGUNCiAgIGhpZGluZyB0aGUg aGV0ZXJvZ2VuZWl0eSBvZiBpbnRyYS1kb21haW4gY29udHJvbCBtZWNoYW5p c21zIGluIHVzZSBpbg0KICAgYSBjaGFpbiBvZiBoZXRlcm9nZW5lb3VzIG5l dHdvcmsgZG9tYWlucy4gVGhlIEludGVyRG9tYWluLVFvU00gDQogICBpbiB0 aGlzIGRvY3VtZW50IGZpcnN0IGRlc2NyaWJlcyBpdHMgb3BlcmF0aW9uIG1v ZGUgYW5kIHRoZW4gdGhlDQogICBhZGRpdGlvbmFsIFFTUEVDIHBhcmFtZXRl cnMgZm9yIGZ1bGZpbGxpbmcgdGhlIGNvbW1vbiBpbnRlci1kb21haW4NCiAg IGludGVyZmFjZSBhcmUgc3BlY2lmaWVkLCBmb2xsb3dlZCBieSB0aGUgaWxs dXN0cmF0aW9ucyBvZiBob3cgdGhlIA0KICAgSW50ZXJEb21haW4tUU9TTSBp bnRlcmFjdHMgd2l0aCBzb21lIHR5cGljYWwgaW50cmEtZG9tYWluIFFvUyBt b2RlbHMgICANCg0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWluLVFPU00gICAg ICAgICAgICAgICAgICBNYXJjaCAyMDA2DQogICANCiAgIHRvIGFjaGlldmUg dGhlIGVuZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZyBvdmVyIGhldGVyb2dl bmVvdXMgZG9tYWlucw0KICAgaW4gYSBzdGFuZGFyZGl6ZWQgYW5kIGR5bmFt aWMgd2F5Lg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuIEludHJv ZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzDQogICAyLiBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuNA0KICAgMy4g VGhlIERpc3RpbmN0IFNlcGVyYXRpb24gb2YgSW50cmEtZG9tYWluIENvbnRy b2wgUGxhbmUgYW5kDQogICAgICBJbnRlci1kb21haW4gQ29udHJvbCBQbGFu ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQ0KICAgICAg My4xIFRoZSBSZXF1aXJlbWVudHMgb2YgdGhlIEludGVyLWRvbWFpbiBDb250 cm9sIFBsYW5lLiAuIC4gLjYgICAgIA0KICAgNC4gVGhlIE92ZXJ2aWV3IG9m IHRoZSBOU0lTIEludGVyRG9tYWluLVFPU00uIC4gLiAuIC4gLiAuIC4gLiAu IDcNCiAgICAgIDQuMSBUaGUgb3BlcmF0aW9uIG1vZGVsIG9mIHRoZSBOU0lT IEludGVyRG9tYWluLVFPU00gLiAuIC4gLiA3DQogICAgICA0LjIgQmFzaWMg ZmVhdHVyZXMgb2YgSW50ZXJEb21haW4tUU9TTSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4xMA0KICAgNS4gSW50ZXJEb21haW4tUU9TTSwgRGV0YWlsZWQgRGVz Y3JpcHRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuMTANCiAgICAgIDUuMSBB ZGRpdGlvbmFsIFFTUEVDIFBhcmFtZXRlcnMgZm9yIEludGVyRG9tYWluLVFP U00gLiAuIC4gLjEwDQogICAgICAgICAgNS4xLjEgPEVncmVzcyBJRD4gcGFy YW1ldGVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KCSAgNS4x LjIgPEluZ3Jlc3MgSUQ+IHBhcmFtZXRlciAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4xMQ0KCSAgNS4xLjMgPEFic29sdXRlIFRpbWUgU3BlY2lmaWNh dGlvbj4gcGFyYW1ldGVyIC4gLiAuIC4gLiAxMQ0KICAgICAgICAgIDUuMS40 IDxSZWxhdGl2ZSBUaW1lIFNwZWNpZmljYXRpb24+IHBhcmFtZXRlciAuIC4g LiAuIC4gMTENCiAgICAgIDUuMiBJbGx1c3RyYXRpb25zIG9mIEludGVyLWRv bWFpbiBTaWduYWxpbmcgSW50ZXJhY3Rpb25zIC4gLjEyDQogICAgICAgICAg NS4yLjEgSW50ZXItZG9tYWluIHNpZ25hbGluZyBmb3IgdGhlIGNhc2UgdGhh dCBSTUQtUU9TTQ0KCSAgICAgICAgYXQgZG9tYWluIEEgYW5kIFkuMTU0MS1R T1NNIGF0IGRvbWFpbiBCIC4gLiAuIC4gLiAxMg0KCSAgNS4yLjIgSW50ZXIt ZG9tYWluIHNpZ25hbGluZyBmb3IgdGhlIGNhc2UgdGhhdA0KCSAgICAgICAg WS4xNTQxLVFPU00gYXQgZG9tYWluIEEgYW5kIFJNRC1RT1NNIGF0IGRvbWFp biBCLi4xMw0KCSAgNS4yLjMgSW50ZXItZG9tYWluIHNpZ25hbGluZyBmb3Ig dGhlIGNhc2UgdGhhdCBSTUQtUU9TTQ0KCSAgICAgICAgYXQgZG9tYWluIEEg YW5kIG5vbi1OU0lTIGJhc2VkIFFPU00gYXQgZG9tYWluIEIgLi4xMw0KCSAg NS4yLjQgSW50ZXItZG9tYWluIHNpZ25hbGluZyBmb3IgdGhlIGNhc2UgdGhh dCBub24tTlNJUw0KCSAgICAgICAgYmFzZWQgUU9TTSBhdCBkb21haW4gQSBh bmQgUk1ELVFPU00gYXQgZG9tYWluIEIgLi4xMw0KICAgICAgNS4zIFRoZSBE aXNjb3Zlcnkgb2YgUGVlciBJbnRlci1kb21haW4gQ29udHJvbCBBZ2VudCAu IC4gLiAuMTQNCiAgIDYuIFNlY3VyaXR5IENvbnNh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gU2VwdGVtYmVyIDIwMDYuIA0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYp Lg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IE5TSVMgUW9TIE1vZGVsIGZvciBpbnRlci1kb21haW4gc2lnbmFsaW5nIA0K ICAgKEludGVyRG9tYWluLVFPU00pIGJldHdlZW4gYWRqYWNlbnQgZG9tYWlu cyB0byBlbmFibGUgZW5kLXRvLWVuZCBRb1MgDQogICBwcm92aXNpb25pbmcg b3ZlciBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgZG9tYWlucy4gU3BlY2lmaWNh bGx5LCBpdCANCiAgIGFzc3VtZXMgYSBkaXN0aW5jdCBzZXBhcmF0aW9uIGJl dHdlZW4gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIHBsYW5lDQogICBhbmQg dGhlIGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIGF0IGVhY2ggYWRtaW5p c3RyYXRpdmUgZG9tYWluIGFuZA0KICAgaXMgaW50ZW5kZWQgdG8gaW1wbGVt ZW50IGEgY29tbW9uIGludGVyLWRvbWFpbiBpbnRlcmZhY2UgdGhhdCBhbGxv d3MNCiAgIHRoZSBRb1MgbmVnb3RpYXRpb24gYW5kIHNldHVwIG9mIGludGVy LWRvbWFpbiB0cmFmZmljIHN0cmVhbXMgd2hpbGUNCiAgIGhpZGluZyB0aGUg aGV0ZXJvZ2VuZWl0eSBvZiBpbnRyYS1kb21haW4gY29udHJvbCBtZWNoYW5p c21zIGluIHVzZSBpbg0KICAgYSBjaGFpbiBvZiBoZXRlcm9nZW5lb3VzIG5l dHdvcmsgZG9tYWlucy4gVGhlIEludGVyRG9tYWluLVFvU00gDQogICBpbiB0 aGlzIGRvY3VtZW50IGZpcnN0IGRlc2NyaWJlcyBpdHMgb3BlcmF0aW9uIG1v ZGUgYW5kIHRoZW4gdGhlDQogICBhZGRpdGlvbmFsIFFTUEVDIHBhcmFtZXRl cnMgZm9yIGZ1bGZpbGxpbmcgdGhlIGNvbW1vbiBpbnRlci1kb21haW4NCiAg IGludGVyZmFjZSBhcmUgc3BlY2lmaWVkLCBmb2xsb3dlZCBieSB0aGUgaWxs dXN0cmF0aW9ucyBvZiBob3cgdGhlIA0KICAgSW50ZXJEb21haW4tUU9TTSBp bnRlcmFjdHMgd2l0aCBzb21lIHR5cGljYWwgaW50cmEtZG9tYWluIFFvUyBt b2RlbHMgICANCg0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWluLVFPU00gICAg ICAgICAgICAgICAgICBNYXJjaCAyMDA2DQogICANCiAgIHRvIGFjaGlldmUg dGhlIGVuZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZyBvdmVyIGhldGVyb2dl bmVvdXMgZG9tYWlucw0KICAgaW4gYSBzdGFuZGFyZGl6ZWQgYW5kIGR5bmFt aWMgd2F5Lg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuIEludHJv ZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzDQogICAyLiBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuNA0KICAgMy4g VGhlIERpc3RpbmN0IFNlcGVyYXRpb24gb2YgSW50cmEtZG9tYWluIENvbnRy b2wgUGxhbmUgYW5kDQogICAgICBJbnRlci1kb21haW4gQ29udHJvbCBQbGFu ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQ0KICAgICAg My4xIFRoZSBSZXF1aXJlbWVudHMgb2YgdGhlIEludGVyLWRvbWFpbiBDb250 cm9sIFBsYW5lLiAuIC4gLjYgICAgIA0KICAgNC4gVGhlIE92ZXJ2aWV3IG9m IHRoZSBOU0lTIEludGVyRG9tYWluLVFPU00uIC4gLiAuIC4gLiAuIC4gLiAu IDcNCiAgICAgIDQuMSBUaGUgb3BlcmF0aW9uIG1vZGVsIG9mIHRoZSBOU0lT IEludGVyRG9tYWluLVFPU00gLiAuIC4gLiA3DQogICAgICA0LjIgQmFzaWMg ZmVhdHVyZXMgb2YgSW50ZXJEb21haW4tUU9TTSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4xMA0KICAgNS4gSW50ZXJEb21haW4tUU9TTSwgRGV0YWlsZWQgRGVz Y3JpcHRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuMTANCiAgICAgIDUuMSBB ZGRpdGlvbmFsIFFTUEVDIFBhcmFtZXRlcnMgZm9yIEludGVyRG9tYWluLVFP U00gLiAuIC4gLjEwDQogICAgICAgICAgNS4xLjEgPEVncmVzcyBJRD4gcGFy YW1ldGVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KCSAgNS4x LjIgPEluZ3Jlc3MgSUQ+IHBhcmFtZXRlciAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4xMQ0KCSAgNS4xLjMgPEFic29sdXRlIFRpbWUgU3BlY2lmaWNh dGlvbj4gcGFyYW1ldGVyIC4gLiAuIC4gLiAxMQ0KICAgICAgICAgIDUuMS40 IDxSZWxhdGl2ZSBUaW1lIFNwZWNpZmljYXRpb24+IHBhcmFtZXRlciAuIC4g LiAuIC4gMTENCiAgICAgIDUuMiBJbGx1c3RyYXRpb25zIG9mIEludGVyLWRv bWFpbiBTaWduYWxpbmcgSW50ZXJhY3Rpb25zIC4gLjEyDQogICAgICAgICAg NS4yLjEgSW50ZXItZG9tYWluIHNpZ25hbGluZyBmb3IgdGhlIGNhc2UgdGhh dCBSTUQtUU9TTQ0KCSAgICAgICAgYXQgZG9tYWluIEEgYW5kIFkuMTU0MS1R T1NNIGF0IGRvbWFpbiBCIC4gLiAuIC4gLiAxMg0KCSAgNS4yLjIgSW50ZXIt ZG9tYWluIHNpZ25hbGluZyBmb3IgdGhlIGNhc2UgdGhhdA0KCSAgICAgICAg WS4xNTQxLVFPU00gYXQgZG9tYWluIEEgYW5kIFJNRC1RT1NNIGF0IGRvbWFp biBCLi4xMw0KCSAgNS4yLjMgSW50ZXItZG9tYWluIHNpZ25hbGluZyBmb3Ig dGhlIGNhc2UgdGhhdCBSTUQtUU9TTQ0KCSAgICAgICAgYXQgZG9tYWluIEEg YW5kIG5vbi1OU0lTIGJhc2VkIFFPU00gYXQgZG9tYWluIEIgLi4xMw0KCSAg NS4yLjQgSW50ZXItZG9tYWluIHNpZ25hbGluZyBmb3IgdGhlIGNhc2UgdGhh dCBub24tTlNJUw0KCSAgICAgICAgYmFzZWQgUU9TTSBhdCBkb21haW4gQSBh bmQgUk1ELVFPU00gYXQgZG9tYWluIEIgLi4xMw0KICAgICAgNS4zIFRoZSBE aXNjb3Zlcnkgb2YgUGVlciBJbnRlci1kb21haW4gQ29udHJvbCBBZ2VudCAu IC4gLiAuMTQNCiAgIDYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb24uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICA3LiBJQU5B IENvbnNpZGVyYXRpb25zLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4xNA0KICAgOC4gT3BlbiBpc3N1ZXMuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuMTUNCiAgIDku IEFja25vd2xlZGdtZW50cy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLjE1ICAgDQogICAxMC4gTm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NQ0KICAgMTEuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAgIDEyLiBBdXRob3JzJyBB ZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE2DQogICAxMy4gSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVu dCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4xNg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNClpoYW5nLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMDYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJbnRlckRvbWFpbi1RT1NN ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNg0KDQoxLiBJbnRyb2R1Y3Rp b24NCg0KICAgQWx0aG91Z2ggYSBudW1iZXIgb2YgUW9TIChRdWFsaXR5IG9m IFNlcnZpY2UpIGFyY2hpdGVjdHVyZXMgKGUuZy4sDQogICBJbnRTZXJ2IFtS RkMyMjEwXSBhbmQgRGlmZnNlcnYgW1JGQzI0NzUsIFJGQzI2MzhdKSBoYXMg YmVlbiBwcm9wb3NlZA0KICAgYnkgdGhlIEludGVybmV0IGNvbW11bml0eSwg dGhlcmUgYXJlIHN0aWxsIHNvbWUgYmFycmllcnMgdG8gb3ZlcmNvbWUNCiAg IHRvIHJlYWxpemUgdGhlIGVuZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZyBv dmVyIGhldGVyb2dlbmVvdXMgbmV0d29yaw0KICAgZG9tYWlucy4gQW1vbmcg dGhlbSwgb25lIG1ham9yIGJhcnJpZXIgdG8gdGhlIGFjaGlldmVtZW50IG9m DQogICBlbmQtdG8tZW5kIFFvUyBvdmVyIGhldGVyb2dlbmVvdXMgZW52aXJv bm1lbnRzIGlzIHRoZSBsYWNrIG9mIGENCiAgIHN0YW5kYXJkaXplZCBhbmQg ZHluYW1pYyBhcHByb2FjaCB0byBwZXJmb3JtIGludGVyLWRvbWFpbiBRb1MN CiAgIGludGVyYWN0aW9ucyBiZXR3ZWVuIGFkamFjZW50IGRvbWFpbnMuIFRv IGFkZHJlc3MgdGhpcyBiYXJyaWVyLCBvbmUNCiAgIGNvbnNlbnN1cyBvZiB0 aGUgSW50ZXJuZXQgY29tbXVuaXR5IGlzIHRoYXQgYSBkaXN0aW5jdCBzZXBh cmF0aW9uIA0KICAgYmV0d2VlbiB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wg cGxhbmUgYW5kIHRoZSBpbnRlci1kb21haW4gY29udHJvbA0KICAgcGxhbmUg bXVzdCBiZSBtYWRlIGFuZCBhIGNvbW1vbiBpbnRlci1kb21haW4gY29udHJv bCBpbnRlcmZhY2UgbXVzdA0KICAgYmUgYXZhaWxhYmxlIGF0IGVhY2ggYWRt aW5pc3RyYXRpdmUgZG9tYWluIHRoYXQgYWxsb3dzIHRoZQ0KICAgaW50ZXIt ZG9tYWluIGludGVyYWN0aW9ucyBpbmRlcGVuZGVudCBmcm9tIHRoZSBpbnRy YS1kb21haW4gY29udHJvbA0KICAgbWVjaGFuaXNtcyBhbmQgdGhlIFFvUyBu ZWdvdGlhdGlvbiBhbmQgc2V0dXAgb2YgaW50ZXItZG9tYWluIHRyYWZmaWMN CiAgIHN0cmVhbXMgaW1wbGVtZW50ZWQgaW4gYSBzdGFuZGFyZGl6ZWQgYW5k IGR5bmFtaWMgd2F5Lg0KICAgDQogICBUaGUgUW9TIE5TSVMgU2lnbmFsaW5n IExheWVyIFByb3RvY29sIChRb1MtTlNMUCkgW1FvUy1OU0xQXSBkZWZpbmVz DQogICBtZXNzYWdlIHR5cGVzIGFuZCBnZW5lcmljIFFvUyBjb250cm9sIGlu Zm9ybWF0aW9uIGZvciBzdXBwb3J0aW5nIGENCiAgIGNsYXNzIG9mIFFPU01z IChRb1MgTW9kZWwpLiBBIFFPU00gaXMgYSBkZWZpbmVkIG1lY2hhbmlzbSBm b3INCiAgIGFjaGlldmluZyBRb1MtcmVsYXRlZCBvcGVyYXRpb25zIChlLmcu LCBuZWdvdGlhdGlvbiwgc2V0dXAsIHVwZGF0ZQ0KICAgYW5kIHJlbGVhc2Ug b2YgcmVxdWlyZWQgUW9TKSBpbiBhIG1hbm5lciB0aGF0IGlzIGNvbnNpc3Rl bnQgd2l0aA0KICAgZWl0aGVyIHRoZSB0ZWNobm9sb2d5IGluIHVzZSBpbiBh IG5ldHdvcmsgZG9tYWluIChpbnRyYS1kb21haW4gUU9TTSkNCiAgIG9yIHRo ZSBzcGVjaWZpY2F0aW9uIG9mIGludGVyLWRvbWFpbiBpbnRlcmFjdGlvbnMg aW4gdXNlIGJldHdlZW4NCiAgIGFkamFjZW50IGRvbWFpbnMgKGludGVyLWRv bWFpbiBRT1NNKS4gVGhlIFJNRC1RT1NNIFtSTUQtUU9TTV0gYW5kDQogICBZ LjE1NDEtUU9TTSBbWS4xNTQxLVFPU01dIGFyZSBleGFtcGxlcyBvZiB0aGUg TlNJUyBiYXNlZCBpbnRyYS1kb21haW4NCiAgIFFPU01zLg0KDQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIE5TSVMgYmFzZWQgaW50ZXItZG9tYWlu IFFPU00NCiAgIChJbnRlckRvbWFpbi1RT1NNKSB3aGljaCBhaW1zIHRvIGFz c3VtZSB0aGUgY29uY2VwdCBvZiBkaXN0aW5jdCANCiAgIHNlcGFyYXRpb24g YmV0d2VlbiB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgcGxhbmUgYW5kIHRo ZQ0KICAgaW50ZXItZG9tYWluIGNvbnRyb2wgcGxhbmUgYXQgZWFjaCBhZG1p bmlzdHJhdGl2ZSBkb21haW4gYW5kIHRvDQogICBpbXBsZW1lbnQgYSBjb21t b24gaW50ZXItZG9tYWluIGludGVyZmFjZSBiZXR3ZWVuIGFkamFjZW50IGRv bWFpbnMNCiAgIHNvIHRoYXQgdGhlIGludGVyLWRvbWFpbiBpbnRlcmFjdGlv bnMgd2lsbCBiZSBmdWxmaWxsZWQgaW4gYQ0KICAgc3RhbmRhcmRpemVkIGFu ZCBkeW5hbWljIHdheSB0byBmYWNpbGl0YXRlIHRoZSByZWFsaXphdGlvbiBv Zg0KICAgZW5kLXRvLWVuZCBRb1MgcHJvdmlzaW9uaW5nIG92ZXIgaGV0ZXJv Z2VuZW91cyBuZXR3b3JrIGRvbWFpbnMuDQogICBTcGVjaWZpY2FsbHksIHRo aXMgZG9jdW1lbnQgZmlyc3QgZGVzY3JpYmVzIHRoZSBjb25jpZGVyYXRpb24uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICA3LiBJQU5B IENvbnNpZGVyYXRpb25zLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4xNA0KICAgOC4gT3BlbiBpc3N1ZXMuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuMTUNCiAgIDku IEFja25vd2xlZGdtZW50cy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLjE1ICAgDQogICAxMC4gTm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NQ0KICAgMTEuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAgIDEyLiBBdXRob3JzJyBB ZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE2DQogICAxMy4gSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVu dCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4xNg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNClpoYW5nLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMDYsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJbnRlckRvbWFpbi1RT1NN ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNg0KDQoxLiBJbnRyb2R1Y3Rp b24NCg0KICAgQWx0aG91Z2ggYSBudW1iZXIgb2YgUW9TIChRdWFsaXR5IG9m IFNlcnZpY2UpIGFyY2hpdGVjdHVyZXMgKGUuZy4sDQogICBJbnRTZXJ2IFtS RkMyMjEwXSBhbmQgRGlmZnNlcnYgW1JGQzI0NzUsIFJGQzI2MzhdKSBoYXMg YmVlbiBwcm9wb3NlZA0KICAgYnkgdGhlIEludGVybmV0IGNvbW11bml0eSwg dGhlcmUgYXJlIHN0aWxsIHNvbWUgYmFycmllcnMgdG8gb3ZlcmNvbWUNCiAg IHRvIHJlYWxpemUgdGhlIGVuZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZyBv dmVyIGhldGVyb2dlbmVvdXMgbmV0d29yaw0KICAgZG9tYWlucy4gQW1vbmcg dGhlbSwgb25lIG1ham9yIGJhcnJpZXIgdG8gdGhlIGFjaGlldmVtZW50IG9m DQogICBlbmQtdG8tZW5kIFFvUyBvdmVyIGhldGVyb2dlbmVvdXMgZW52aXJv bm1lbnRzIGlzIHRoZSBsYWNrIG9mIGENCiAgIHN0YW5kYXJkaXplZCBhbmQg ZHluYW1pYyBhcHByb2FjaCB0byBwZXJmb3JtIGludGVyLWRvbWFpbiBRb1MN CiAgIGludGVyYWN0aW9ucyBiZXR3ZWVuIGFkamFjZW50IGRvbWFpbnMuIFRv IGFkZHJlc3MgdGhpcyBiYXJyaWVyLCBvbmUNCiAgIGNvbnNlbnN1cyBvZiB0 aGUgSW50ZXJuZXQgY29tbXVuaXR5IGlzIHRoYXQgYSBkaXN0aW5jdCBzZXBh cmF0aW9uIA0KICAgYmV0d2VlbiB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wg cGxhbmUgYW5kIHRoZSBpbnRlci1kb21haW4gY29udHJvbA0KICAgcGxhbmUg bXVzdCBiZSBtYWRlIGFuZCBhIGNvbW1vbiBpbnRlci1kb21haW4gY29udHJv bCBpbnRlcmZhY2UgbXVzdA0KICAgYmUgYXZhaWxhYmxlIGF0IGVhY2ggYWRt aW5pc3RyYXRpdmUgZG9tYWluIHRoYXQgYWxsb3dzIHRoZQ0KICAgaW50ZXIt ZG9tYWluIGludGVyYWN0aW9ucyBpbmRlcGVuZGVudCBmcm9tIHRoZSBpbnRy YS1kb21haW4gY29udHJvbA0KICAgbWVjaGFuaXNtcyBhbmQgdGhlIFFvUyBu ZWdvdGlhdGlvbiBhbmQgc2V0dXAgb2YgaW50ZXItZG9tYWluIHRyYWZmaWMN CiAgIHN0cmVhbXMgaW1wbGVtZW50ZWQgaW4gYSBzdGFuZGFyZGl6ZWQgYW5k IGR5bmFtaWMgd2F5Lg0KICAgDQogICBUaGUgUW9TIE5TSVMgU2lnbmFsaW5n IExheWVyIFByb3RvY29sIChRb1MtTlNMUCkgW1FvUy1OU0xQXSBkZWZpbmVz DQogICBtZXNzYWdlIHR5cGVzIGFuZCBnZW5lcmljIFFvUyBjb250cm9sIGlu Zm9ybWF0aW9uIGZvciBzdXBwb3J0aW5nIGENCiAgIGNsYXNzIG9mIFFPU01z IChRb1MgTW9kZWwpLiBBIFFPU00gaXMgYSBkZWZpbmVkIG1lY2hhbmlzbSBm b3INCiAgIGFjaGlldmluZyBRb1MtcmVsYXRlZCBvcGVyYXRpb25zIChlLmcu LCBuZWdvdGlhdGlvbiwgc2V0dXAsIHVwZGF0ZQ0KICAgYW5kIHJlbGVhc2Ug b2YgcmVxdWlyZWQgUW9TKSBpbiBhIG1hbm5lciB0aGF0IGlzIGNvbnNpc3Rl bnQgd2l0aA0KICAgZWl0aGVyIHRoZSB0ZWNobm9sb2d5IGluIHVzZSBpbiBh IG5ldHdvcmsgZG9tYWluIChpbnRyYS1kb21haW4gUU9TTSkNCiAgIG9yIHRo ZSBzcGVjaWZpY2F0aW9uIG9mIGludGVyLWRvbWFpbiBpbnRlcmFjdGlvbnMg aW4gdXNlIGJldHdlZW4NCiAgIGFkamFjZW50IGRvbWFpbnMgKGludGVyLWRv bWFpbiBRT1NNKS4gVGhlIFJNRC1RT1NNIFtSTUQtUU9TTV0gYW5kDQogICBZ LjE1NDEtUU9TTSBbWS4xNTQxLVFPU01dIGFyZSBleGFtcGxlcyBvZiB0aGUg TlNJUyBiYXNlZCBpbnRyYS1kb21haW4NCiAgIFFPU01zLg0KDQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIE5TSVMgYmFzZWQgaW50ZXItZG9tYWlu IFFPU00NCiAgIChJbnRlckRvbWFpbi1RT1NNKSB3aGljaCBhaW1zIHRvIGFz c3VtZSB0aGUgY29uY2VwdCBvZiBkaXN0aW5jdCANCiAgIHNlcGFyYXRpb24g YmV0d2VlbiB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgcGxhbmUgYW5kIHRo ZQ0KICAgaW50ZXItZG9tYWluIGNvbnRyb2wgcGxhbmUgYXQgZWFjaCBhZG1p bmlzdHJhdGl2ZSBkb21haW4gYW5kIHRvDQogICBpbXBsZW1lbnQgYSBjb21t b24gaW50ZXItZG9tYWluIGludGVyZmFjZSBiZXR3ZWVuIGFkamFjZW50IGRv bWFpbnMNCiAgIHNvIHRoYXQgdGhlIGludGVyLWRvbWFpbiBpbnRlcmFjdGlv bnMgd2lsbCBiZSBmdWxmaWxsZWQgaW4gYQ0KICAgc3RhbmRhcmRpemVkIGFu ZCBkeW5hbWljIHdheSB0byBmYWNpbGl0YXRlIHRoZSByZWFsaXphdGlvbiBv Zg0KICAgZW5kLXRvLWVuZCBRb1MgcHJvdmlzaW9uaW5nIG92ZXIgaGV0ZXJv Z2VuZW91cyBuZXR3b3JrIGRvbWFpbnMuDQogICBTcGVjaWZpY2FsbHksIHRo aXMgZG9jdW1lbnQgZmlyc3QgZGVzY3JpYmVzIHRoZSBjb25jZXB0IG9mIGRp c3RpbmNlDQogICBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIGludHJhLWRvbWFp biBjb250cm9sIHBsYW5lIGFuZCB0aGUNCiAgIGludGVyLWRvbWFpbiBjb250 cm9sIHBsYW5lIGF0IGVhY2ggYWRtaW5pc3RyYXRpdmUgZG9tYWluIGFuZCBw cmVzZW50cw0KICAgdGhlIG9wZXJhdGlvbiBtb2RlbCBvZiB0aGUgSW50ZXJE b21haW4tUU9TTSB3aGljaCBpcyB0byBlbmFibGUgYQ0KICAgY29tbW9uIGlu dGVyLWRvbWFpbiBjb250cm9sIGludGVyZmFjZSwgaW5kZXBlbmRlbnQgZnJv bSB0aGUNCiAgIGludHJhLWRvbWFpbiBjb250cm9sIGFsZ29yaXRobXMuIFRo ZSBhZGRpdGlvbmFsIFFTUEVDIHBhcmFtZXRlcnMgZm9yDQogICBpbXBsZW1l bnRpbmcgdGhlIGNvbW1vbiBpbnRlci1kb21haW4gaW50ZXJmYWNlIGFyZSB0 aGVuIHNwZWNpZmllZCwNCiAgIGZvbGxvd2VkIGJ5IHRoZSBpbGx1c3RyYXRp b25zIG9mIGhvdyB0aGUgSW50ZXJEb21haW4tUU9TTSB3aWxsDQogICBpbnRl cmFjdCB3aXRoIHNvbWUgdHlwaWNhbCBpbnRyYS1kb21haW4gUU9TTXMgdG8g cmVhbGl6ZSB0aGUNCiAgIGVuZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZyBv dmVyIGhldGVyb2dlbmVvdXMgZG9tYWlucy4NCg0KMi4gIFRlcm1pbm9sb2d5 DQogICANCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgDQogICBOT1QiLCAiU0hPVUxE LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9Q VElPTkFMIiANCiAgIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSANCiAgIFtSRkMyMTE5 XS4gICAgICANCiAgIA0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgM10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWluLVFPU00g ICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2IA0KDQogICBUaGUgdGVybWlu b2xvZ3kgZGVmaW5lZCBieSBHSVNUIFtHSVNUXSBhbmQgUW9TLU5TTFAgW1Fv Uy1OU0xQXSANCiAgIGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0KICAgSW4g YWRkaXRpb24sIHRoZSBmb2xsb3dpbmcgdGVybXMgYXJlIHVzZWQ6DQoNCiAg IEVkZ2Ugbm9kZTogYW4gbm9kZSBvbiB0aGUgYm91bmRhcnkgb2YgYW4gYWRt aW5pc3RyYXRpdmUgZG9tYWluLg0KDQogICBJbmdyZXNzIG5vZGU6IEFuIGVk Z2Ugbm9kZSB0aGF0IGhhbmRsZXMgdGhlIHRyYWZmaWMgYXMgaXQgZW50ZXJz IHRoZQ0KICAgZG9tYWluLg0KDQogICBFZ3Jlc3Mgbm9kZTogQW4gZWRnZSBu b2RlIHRoYXQgaGFuZGxlcyB0aGUgdHJhZmZpYyBhcyBpdCBsZWF2ZXMgdGhl DQogICBkb21haW4uDQogICANCiAgIEludGVyLWRvbWFpbiBjb250cm9sIGFn ZW50OiBBIGRvbWFpbi13aWRlIGNlbnRyYWxpemVkIGFnZW50IGF0IGFuDQog ICBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHdoaWNoIGltcGxlbWVudHMgYSBj b21tb24gaW50ZXItZG9tYWluIGNvbnRyb2wNCiAgIGludGVyZmFjZSBhbmQg aXMgcmVzcG9uc2libGUgZm9yIHRoZSBpbnRlci1kb21haW4gaW50ZXJhY3Rp b25zDQogICBiZXR3ZWVuIGFkamFjZW50IGRvbWFpbnMgdmlhIHRoZSBjb21t b24gaW50ZXItZG9tYWluIGludGVyZmFjZS4NCg0KICAgSW50cmEtZG9tYWlu IGNvbnRyb2wgYWdlbnQ6IEFuIGFic3RyYWN0IGVudGl0eSB3aGljaCBpcyBy ZXNwb25zaWJsZQ0KICAgZm9yIHBlcmZvcm1pbmcgYWxsIGludHJhLWRvbWFp biBjb250cm9sIG1lY2hhbmlzbXMgaW4gYSBtYW5uZXINCiAgIGFwcHJvcHJp YXRlIHRvIHRoZSBzcGVjaWZpYyBuZXR3b3JrIHRlY2hub2xvZ3kgaW4gdXNl IGF0IGFuDQogICBhZG1pbmlzdHJhdGl2ZSBkb21haW4uIE5vdGUgdGhhdCBp dCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYQ0KICAgY2VudHJhbGl6ZWQgb3Ig ZGlzdHJpYnV0ZWQgbW9kZSwgaS5lLiwgYSBzaW5nbGUgZG9tYWluLXdpZGUN CiAgIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IChjZW50cmFsaXplZCBt b2RlKSBvciBhIHNldCBvZiBsb2NhbA0KICAgaW50cmEtZG9tYWluIGNvbnRy b2wgYWdlbnRzIChkaXN0cmlidXRlZCBtb2RlKS4NCg0KICAgQ3VzdG9tZXI6 IGEgY3VzdG9tZXIgZGVub3RlcyBhbiBlbnRpdHkgd2hpY2ggaGFzIHRoZSBh YmlsaXR5IHRvDQogICBzdWJzY3JpYmUgdG8gdGhlIHNlcnZpY2VzIG9mZmVy ZWQgYnkgcHJvdmlkZXJzLg0KDQogICBQcm92aWRlcjogYSBwcm92aWRlciBk ZW5vdGVzIGEgYnVzaW5lc3MgZW50aXR5IHdoaWNoIG93bnMgYW4NCiAgIGFk bWluaXN0cmF0aXZlIGRvbWFpbiBhbmQgaXMgcmVzcG9uc2libGUgZm9yIGl0 cyBvcGVyYXRpb24gYW5kIHRoZQ0KICAgcHJvdmlzaW9uIG9mIEludGVybmV0 IGNvbm5lY3Rpdml0eSBhc3BlY3RzLg0KDQogICBTZXJ2aWNlIExldmVsIEFn cmVlbWVudCAoU0xBKTogYSBTTEEgaXMgY29uY2x1ZGVkIGJldHdlZW4gYSBj dXN0b21lcg0KICAgYW5kIGEgcHJvdmlkZXIsIHdoZXJlIHRoZSBjdXN0b21l ciBjYW4gYmUgYSBlbmQtdXNlciBvciBhIHBlZXINCiAgIHByb3ZpZGVyLiBB IFNMQSBwcm92aWRlcnMgYSBndWFyYW50ZWUgdGhhdCB0cmFmZmljIG9mZmVy ZWQgYnkgYQ0KICAgQ3VzdG9tZXIgdGhhdCBtZWV0cyBjZXJ0YWluIHN0YXRl ZCBjb25kaXRpb25zLCB3aWxsIHJlY2VpdmUgb25lIG9yDQogICBtb3JlIHBh cnRpY3VsYXIgc2VydmljZSBsZXZlbHMuIFRoZSBndWFyYW50ZWVzIG1heSBi ZSBoYXJkIG9yIHNvZnQsDQogICBtYXkgY2FycnkgY2VydGFpbiB0YXJpZmZz LCBhbmQgbWF5IGFsc28gY2FycnkgY2VydGFpbiBtb25ldGFyeSBvciANCiAg IGxlZ2FsIGNvbnNlcXVlbmNlcyBpZiB0aGV5IG5vdCBtZXQuDQoNCiAgIFNl cnZpY2UgTGV2ZWwgU3BlY2lmaWNhdGlvbiAoU0xTKTogYSBTTFMgY29udGFp bnMgdGhlIHRlY2huaWNhbA0KICAgZGV0YWlscyBvZiB0aGUgYWdyZWVtZZXB0IG9mIGRp c3RpbmNlDQogICBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIGludHJhLWRvbWFp biBjb250cm9sIHBsYW5lIGFuZCB0aGUNCiAgIGludGVyLWRvbWFpbiBjb250 cm9sIHBsYW5lIGF0IGVhY2ggYWRtaW5pc3RyYXRpdmUgZG9tYWluIGFuZCBw cmVzZW50cw0KICAgdGhlIG9wZXJhdGlvbiBtb2RlbCBvZiB0aGUgSW50ZXJE b21haW4tUU9TTSB3aGljaCBpcyB0byBlbmFibGUgYQ0KICAgY29tbW9uIGlu dGVyLWRvbWFpbiBjb250cm9sIGludGVyZmFjZSwgaW5kZXBlbmRlbnQgZnJv bSB0aGUNCiAgIGludHJhLWRvbWFpbiBjb250cm9sIGFsZ29yaXRobXMuIFRo ZSBhZGRpdGlvbmFsIFFTUEVDIHBhcmFtZXRlcnMgZm9yDQogICBpbXBsZW1l bnRpbmcgdGhlIGNvbW1vbiBpbnRlci1kb21haW4gaW50ZXJmYWNlIGFyZSB0 aGVuIHNwZWNpZmllZCwNCiAgIGZvbGxvd2VkIGJ5IHRoZSBpbGx1c3RyYXRp b25zIG9mIGhvdyB0aGUgSW50ZXJEb21haW4tUU9TTSB3aWxsDQogICBpbnRl cmFjdCB3aXRoIHNvbWUgdHlwaWNhbCBpbnRyYS1kb21haW4gUU9TTXMgdG8g cmVhbGl6ZSB0aGUNCiAgIGVuZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZyBv dmVyIGhldGVyb2dlbmVvdXMgZG9tYWlucy4NCg0KMi4gIFRlcm1pbm9sb2d5 DQogICANCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgDQogICBOT1QiLCAiU0hPVUxE LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9Q VElPTkFMIiANCiAgIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSANCiAgIFtSRkMyMTE5 XS4gICAgICANCiAgIA0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgM10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWluLVFPU00g ICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2IA0KDQogICBUaGUgdGVybWlu b2xvZ3kgZGVmaW5lZCBieSBHSVNUIFtHSVNUXSBhbmQgUW9TLU5TTFAgW1Fv Uy1OU0xQXSANCiAgIGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0KICAgSW4g YWRkaXRpb24sIHRoZSBmb2xsb3dpbmcgdGVybXMgYXJlIHVzZWQ6DQoNCiAg IEVkZ2Ugbm9kZTogYW4gbm9kZSBvbiB0aGUgYm91bmRhcnkgb2YgYW4gYWRt aW5pc3RyYXRpdmUgZG9tYWluLg0KDQogICBJbmdyZXNzIG5vZGU6IEFuIGVk Z2Ugbm9kZSB0aGF0IGhhbmRsZXMgdGhlIHRyYWZmaWMgYXMgaXQgZW50ZXJz IHRoZQ0KICAgZG9tYWluLg0KDQogICBFZ3Jlc3Mgbm9kZTogQW4gZWRnZSBu b2RlIHRoYXQgaGFuZGxlcyB0aGUgdHJhZmZpYyBhcyBpdCBsZWF2ZXMgdGhl DQogICBkb21haW4uDQogICANCiAgIEludGVyLWRvbWFpbiBjb250cm9sIGFn ZW50OiBBIGRvbWFpbi13aWRlIGNlbnRyYWxpemVkIGFnZW50IGF0IGFuDQog ICBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHdoaWNoIGltcGxlbWVudHMgYSBj b21tb24gaW50ZXItZG9tYWluIGNvbnRyb2wNCiAgIGludGVyZmFjZSBhbmQg aXMgcmVzcG9uc2libGUgZm9yIHRoZSBpbnRlci1kb21haW4gaW50ZXJhY3Rp b25zDQogICBiZXR3ZWVuIGFkamFjZW50IGRvbWFpbnMgdmlhIHRoZSBjb21t b24gaW50ZXItZG9tYWluIGludGVyZmFjZS4NCg0KICAgSW50cmEtZG9tYWlu IGNvbnRyb2wgYWdlbnQ6IEFuIGFic3RyYWN0IGVudGl0eSB3aGljaCBpcyBy ZXNwb25zaWJsZQ0KICAgZm9yIHBlcmZvcm1pbmcgYWxsIGludHJhLWRvbWFp biBjb250cm9sIG1lY2hhbmlzbXMgaW4gYSBtYW5uZXINCiAgIGFwcHJvcHJp YXRlIHRvIHRoZSBzcGVjaWZpYyBuZXR3b3JrIHRlY2hub2xvZ3kgaW4gdXNl IGF0IGFuDQogICBhZG1pbmlzdHJhdGl2ZSBkb21haW4uIE5vdGUgdGhhdCBp dCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYQ0KICAgY2VudHJhbGl6ZWQgb3Ig ZGlzdHJpYnV0ZWQgbW9kZSwgaS5lLiwgYSBzaW5nbGUgZG9tYWluLXdpZGUN CiAgIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IChjZW50cmFsaXplZCBt b2RlKSBvciBhIHNldCBvZiBsb2NhbA0KICAgaW50cmEtZG9tYWluIGNvbnRy b2wgYWdlbnRzIChkaXN0cmlidXRlZCBtb2RlKS4NCg0KICAgQ3VzdG9tZXI6 IGEgY3VzdG9tZXIgZGVub3RlcyBhbiBlbnRpdHkgd2hpY2ggaGFzIHRoZSBh YmlsaXR5IHRvDQogICBzdWJzY3JpYmUgdG8gdGhlIHNlcnZpY2VzIG9mZmVy ZWQgYnkgcHJvdmlkZXJzLg0KDQogICBQcm92aWRlcjogYSBwcm92aWRlciBk ZW5vdGVzIGEgYnVzaW5lc3MgZW50aXR5IHdoaWNoIG93bnMgYW4NCiAgIGFk bWluaXN0cmF0aXZlIGRvbWFpbiBhbmQgaXMgcmVzcG9uc2libGUgZm9yIGl0 cyBvcGVyYXRpb24gYW5kIHRoZQ0KICAgcHJvdmlzaW9uIG9mIEludGVybmV0 IGNvbm5lY3Rpdml0eSBhc3BlY3RzLg0KDQogICBTZXJ2aWNlIExldmVsIEFn cmVlbWVudCAoU0xBKTogYSBTTEEgaXMgY29uY2x1ZGVkIGJldHdlZW4gYSBj dXN0b21lcg0KICAgYW5kIGEgcHJvdmlkZXIsIHdoZXJlIHRoZSBjdXN0b21l ciBjYW4gYmUgYSBlbmQtdXNlciBvciBhIHBlZXINCiAgIHByb3ZpZGVyLiBB IFNMQSBwcm92aWRlcnMgYSBndWFyYW50ZWUgdGhhdCB0cmFmZmljIG9mZmVy ZWQgYnkgYQ0KICAgQ3VzdG9tZXIgdGhhdCBtZWV0cyBjZXJ0YWluIHN0YXRl ZCBjb25kaXRpb25zLCB3aWxsIHJlY2VpdmUgb25lIG9yDQogICBtb3JlIHBh cnRpY3VsYXIgc2VydmljZSBsZXZlbHMuIFRoZSBndWFyYW50ZWVzIG1heSBi ZSBoYXJkIG9yIHNvZnQsDQogICBtYXkgY2FycnkgY2VydGFpbiB0YXJpZmZz LCBhbmQgbWF5IGFsc28gY2FycnkgY2VydGFpbiBtb25ldGFyeSBvciANCiAg IGxlZ2FsIGNvbnNlcXVlbmNlcyBpZiB0aGV5IG5vdCBtZXQuDQoNCiAgIFNl cnZpY2UgTGV2ZWwgU3BlY2lmaWNhdGlvbiAoU0xTKTogYSBTTFMgY29udGFp bnMgdGhlIHRlY2huaWNhbA0KICAgZGV0YWlscyBvZiB0aGUgYWdyZWVtZW50 IHNwZWNpZmllZCBieSBhIFNMQS4gQSBTTFMgaGFzLCBhcyBpdHMgc2NvcGUs DQogICB0aGUgYWNjZXB0YW5jZSBhbmQgdHJlYXRtZW50IG9mIHRyYWZmaWMg bWVldGluZyBjZXJ0YWluIGNvbmRpdGlvbnMNCiAgIGFuZCBhcnJpdmluZyBm cm9tIGEgZW5kLXVzZXIgb3IgYSBwZWVyIHByb3ZpZGVyLg0KDQogICBDdXN0 b21lciBTTFMgKGNTTFMpOiB0aGUgdHlwZSBvZiBTTFMgZXN0YWJsaXNoZWQg YmV0d2VlbiBlbmQtdXNlcnMNCiAgIGFuZCBwcm92aWRlcnMuDQoNCiAgIFBl ZXIgU0xTIChwU0xTKTogdGhlIHR5cGUgb2YgU0xTIGVzdGFibGlzaGVkIGJl dHdlZW4gcGVlciBkb21haW5zLA0KICAgcHJlc3VtYWJseSAobG9naWNhbGx5 KSBhZGphY2VudCwgd2hlcmUgb25lIGRvbWFpbiBpcyB0aGUgc2VydmljZQ0K ICAgcHJvdmlkZXIgYW5kIHRoZSBvdGhlciBkb21haW4gaXMgdGhlIGN1c3Rv bWVyLg0KDQpaaGFuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDA2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgSW50ZXJEb21haW4tUU9TTSAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMDYNCg0KMy4gVGhlIERpc3RpbmN0IFNlcGVy YXRpb24gb2YgSW50cmEtZG9tYWluIENvbnRyb2wgUGxhbmUgYW5kDQogICBJ bnRlci1kb21haW4gQ29udHJvbCBQbGFuZQ0KDQogICBUbyBmYWNpbGl0YXRl IHRoZSByZWFsaXphdGlvbiBvZiBlbmQtdG8tZW5kIFFvUyBwcm92aXNpb25p bmcgb3Zlcg0KICAgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIGRvbWFpbnMsIG9u ZSBjb25zZW5zdXMgb2YgdGhlIEludGVybmV0DQogICBjb21tdW5pdHkgaXMg dGhhdCBhIGRpc3RpbmN0IHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgaW50cmEt ZG9tYWluDQogICBjb250cm9sIHBsYW5lIGFuZCB0aGUgaW50ZXItZG9tYWlu IGNvbnRyb2wgcGxhbmUgbXVzdCBiZSBtYWRlIGFuZCBhDQogICBjb21tb24g aW50ZXItZG9tYWluIGNvbnRyb2wgaW50ZXJmYWNlIG11c3QgYmUgYXZhaWxh YmxlIGF0IGVhY2gNCiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiB0aGF0IGFs bG93cyB0aGUgaW50ZXItZG9tYWluIGludGVyYWN0aW9ucyANCiAgIGluZGVw ZW5kZW50IGZyb20gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIG1lY2hhbmlz bXMgYW5kIHRoZSBRb1MNCiAgIG5lZ290aWF0aW9uIGFuZCBzZXR1cCBvZiBp bnRlci1kb21haW4gdHJhZmZpYyBzdHJlYW1zIGltcGxlbWVudGVkDQogICBp biBhIHN0YW5kYXJkaXplZCBhbmQgZHluYW1pYyB3YXkgW0RDUEVMLXJlcXVp cmVtZW50c10uIA0KICAgDQogICBGaWd1cmUgMSBzaG93cyBhIGhpZ2gtbGV2 ZWwgdmlldyBvZiBzdWNoIGRpc3RpbmN0IHNlcGVyYXRpb24gbWFkZSBhdA0K ICAgdHdvIGFkamFjZW50IGRvbWFpbnMuIE1vcmUgc2VwZWNpZmljLCBhdCBl YWNoIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwNCiAgIHRoZSBpbnRyYS1kb21h aW4gY29udHJvbCBhZ2VudCBpcyByZXNwb25zaWJsZSBmb3IgcGVyZm9ybWlu ZyBhbGwNCiAgIGludHJhLWRvbWFpbiBjb250cm9sIG1lY2hhbmlzbXMgaW4g YSBtYW5uZXIgYXBwcm9wcmlhdGUgdG8gdGhlIA0KICAgbmV0d29yayB0ZWNo bm9sb2d5IGluIHVzZSBhdCB0aGUgZG9tYWluIGFuZCB0aGUgaW50ZXItZG9t YWluIGNvbnRyb2wNCiAgIGFnZW50IGltcGxlbWVudHMgYSBjb21tb24gaW50 ZXItZG9tYWluIGNvbnRyb2wgaW50ZXJmYWNlIGFuZCBpcw0KICAgcmVzcG9u c2libGUgZm9yIHRoZSBpbnRlci1kb21haW4gaW50ZXJhY3Rpb25zIHdpdGgg aXRzIHBlZXIgdmlhIHRoZQ0KICAgY29tbW9uIGludGVyLWRvbWFpbiBpbnRl cmZhY2UuIE5vdGUgdGhhdCB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wNCiAg IGFnZW50IHNob3duIGluIEZpZ3VyZSAxIGlzIGFuIGFic3RyYWN0IGVudGl0 eSwgd2hpY2ggY2FuIGJlDQogICBpbXBsZW1lbnRlZCBpbiBhIGNlbnRyYWxp emVkIG9yIGRpc3RyaWJ1dGVkIG1vZGUsIGkuZS4sICB2aWEgYSBzaW5nbGUN CiAgIGRvbWFpbi13aWRlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IChj ZW50cmFsaXplZCBtb2RlKSBvciBhIHNldCBvZg0KICAgbG9jYWwgaW50cmEt ZG9tYWluIGNvbnRyb2wgYWdlbnRzIChkaXN0cmlidXRlZCBtb2RlKS4gV2hl cmVhcywgdGhlDQogICBpbnRlci1kb21haW4gY29udHJvbCBhZ2VudCBpcyBu b3JtYWxseSAob3IgYWx3YXlzKSBpbXBsZW1lbnRlZCBpbiBhDQogICBjZW50 cmFsaXplZCBtb2RlLCBpLmUuLCBhIG5ldHdvcmstd2lkZSBjZW50cmFsaXpl ZCBpbnRlci1kb21haW4NCiAgIGNvbnRyb2wgYWdlbnQgZXhpc3RzIGF0IGVh Y2ggZG9tYWluLCB3aGljaCBpcyB3ZWxsLWtub3duIHRvIHRoZSANCiAgIGlu dHJhLWRvbWFpbiBjb250cm9sIGFnZW50KHMpIGF0IGl0cyBkb21haW4uDQoN CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfERvbWFpbiBBICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgfERvbWFpbiBCICAgICAgICAg ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgIA0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8 ICstLS0tLS0tKyAgICAgICstLS0tLS0tKyAgIHwgICAgICAgICB8ICAgKy0t LS0tLS0rICAgICAgKy0tLS0tLS0rIHwNCiAgIHwgfEludHJhLSB8ICAgICAg fEludGVyLSB8ICAgfCAgICAgICAgIHwgICB8SW50ZXItIHwgICAgICB8SW50 cmEtIHwgfA0KICAgfCB8ZG9tYWluIHw8PDw+Pj58ZG9tYWluIHw8LS18LS0t LS0tLS0tfC0tPnxkb21haW4gfDw8PD4+Pnxkb21haW4gfCB8DQogICB8IHxj b250cm9sfCAgICAgIHxjb250cm9sfCAgIHxDb21tb24gICB8ICAgfGNvbnRy b2x8IW50 IHNwZWNpZmllZCBieSBhIFNMQS4gQSBTTFMgaGFzLCBhcyBpdHMgc2NvcGUs DQogICB0aGUgYWNjZXB0YW5jZSBhbmQgdHJlYXRtZW50IG9mIHRyYWZmaWMg bWVldGluZyBjZXJ0YWluIGNvbmRpdGlvbnMNCiAgIGFuZCBhcnJpdmluZyBm cm9tIGEgZW5kLXVzZXIgb3IgYSBwZWVyIHByb3ZpZGVyLg0KDQogICBDdXN0 b21lciBTTFMgKGNTTFMpOiB0aGUgdHlwZSBvZiBTTFMgZXN0YWJsaXNoZWQg YmV0d2VlbiBlbmQtdXNlcnMNCiAgIGFuZCBwcm92aWRlcnMuDQoNCiAgIFBl ZXIgU0xTIChwU0xTKTogdGhlIHR5cGUgb2YgU0xTIGVzdGFibGlzaGVkIGJl dHdlZW4gcGVlciBkb21haW5zLA0KICAgcHJlc3VtYWJseSAobG9naWNhbGx5 KSBhZGphY2VudCwgd2hlcmUgb25lIGRvbWFpbiBpcyB0aGUgc2VydmljZQ0K ICAgcHJvdmlkZXIgYW5kIHRoZSBvdGhlciBkb21haW4gaXMgdGhlIGN1c3Rv bWVyLg0KDQpaaGFuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDA2LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgSW50ZXJEb21haW4tUU9TTSAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMDYNCg0KMy4gVGhlIERpc3RpbmN0IFNlcGVy YXRpb24gb2YgSW50cmEtZG9tYWluIENvbnRyb2wgUGxhbmUgYW5kDQogICBJ bnRlci1kb21haW4gQ29udHJvbCBQbGFuZQ0KDQogICBUbyBmYWNpbGl0YXRl IHRoZSByZWFsaXphdGlvbiBvZiBlbmQtdG8tZW5kIFFvUyBwcm92aXNpb25p bmcgb3Zlcg0KICAgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIGRvbWFpbnMsIG9u ZSBjb25zZW5zdXMgb2YgdGhlIEludGVybmV0DQogICBjb21tdW5pdHkgaXMg dGhhdCBhIGRpc3RpbmN0IHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgaW50cmEt ZG9tYWluDQogICBjb250cm9sIHBsYW5lIGFuZCB0aGUgaW50ZXItZG9tYWlu IGNvbnRyb2wgcGxhbmUgbXVzdCBiZSBtYWRlIGFuZCBhDQogICBjb21tb24g aW50ZXItZG9tYWluIGNvbnRyb2wgaW50ZXJmYWNlIG11c3QgYmUgYXZhaWxh YmxlIGF0IGVhY2gNCiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiB0aGF0IGFs bG93cyB0aGUgaW50ZXItZG9tYWluIGludGVyYWN0aW9ucyANCiAgIGluZGVw ZW5kZW50IGZyb20gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIG1lY2hhbmlz bXMgYW5kIHRoZSBRb1MNCiAgIG5lZ290aWF0aW9uIGFuZCBzZXR1cCBvZiBp bnRlci1kb21haW4gdHJhZmZpYyBzdHJlYW1zIGltcGxlbWVudGVkDQogICBp biBhIHN0YW5kYXJkaXplZCBhbmQgZHluYW1pYyB3YXkgW0RDUEVMLXJlcXVp cmVtZW50c10uIA0KICAgDQogICBGaWd1cmUgMSBzaG93cyBhIGhpZ2gtbGV2 ZWwgdmlldyBvZiBzdWNoIGRpc3RpbmN0IHNlcGVyYXRpb24gbWFkZSBhdA0K ICAgdHdvIGFkamFjZW50IGRvbWFpbnMuIE1vcmUgc2VwZWNpZmljLCBhdCBl YWNoIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwNCiAgIHRoZSBpbnRyYS1kb21h aW4gY29udHJvbCBhZ2VudCBpcyByZXNwb25zaWJsZSBmb3IgcGVyZm9ybWlu ZyBhbGwNCiAgIGludHJhLWRvbWFpbiBjb250cm9sIG1lY2hhbmlzbXMgaW4g YSBtYW5uZXIgYXBwcm9wcmlhdGUgdG8gdGhlIA0KICAgbmV0d29yayB0ZWNo bm9sb2d5IGluIHVzZSBhdCB0aGUgZG9tYWluIGFuZCB0aGUgaW50ZXItZG9t YWluIGNvbnRyb2wNCiAgIGFnZW50IGltcGxlbWVudHMgYSBjb21tb24gaW50 ZXItZG9tYWluIGNvbnRyb2wgaW50ZXJmYWNlIGFuZCBpcw0KICAgcmVzcG9u c2libGUgZm9yIHRoZSBpbnRlci1kb21haW4gaW50ZXJhY3Rpb25zIHdpdGgg aXRzIHBlZXIgdmlhIHRoZQ0KICAgY29tbW9uIGludGVyLWRvbWFpbiBpbnRl cmZhY2UuIE5vdGUgdGhhdCB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wNCiAg IGFnZW50IHNob3duIGluIEZpZ3VyZSAxIGlzIGFuIGFic3RyYWN0IGVudGl0 eSwgd2hpY2ggY2FuIGJlDQogICBpbXBsZW1lbnRlZCBpbiBhIGNlbnRyYWxp emVkIG9yIGRpc3RyaWJ1dGVkIG1vZGUsIGkuZS4sICB2aWEgYSBzaW5nbGUN CiAgIGRvbWFpbi13aWRlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IChj ZW50cmFsaXplZCBtb2RlKSBvciBhIHNldCBvZg0KICAgbG9jYWwgaW50cmEt ZG9tYWluIGNvbnRyb2wgYWdlbnRzIChkaXN0cmlidXRlZCBtb2RlKS4gV2hl cmVhcywgdGhlDQogICBpbnRlci1kb21haW4gY29udHJvbCBhZ2VudCBpcyBu b3JtYWxseSAob3IgYWx3YXlzKSBpbXBsZW1lbnRlZCBpbiBhDQogICBjZW50 cmFsaXplZCBtb2RlLCBpLmUuLCBhIG5ldHdvcmstd2lkZSBjZW50cmFsaXpl ZCBpbnRlci1kb21haW4NCiAgIGNvbnRyb2wgYWdlbnQgZXhpc3RzIGF0IGVh Y2ggZG9tYWluLCB3aGljaCBpcyB3ZWxsLWtub3duIHRvIHRoZSANCiAgIGlu dHJhLWRvbWFpbiBjb250cm9sIGFnZW50KHMpIGF0IGl0cyBkb21haW4uDQoN CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfERvbWFpbiBBICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgfERvbWFpbiBCICAgICAgICAg ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgIA0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8 ICstLS0tLS0tKyAgICAgICstLS0tLS0tKyAgIHwgICAgICAgICB8ICAgKy0t LS0tLS0rICAgICAgKy0tLS0tLS0rIHwNCiAgIHwgfEludHJhLSB8ICAgICAg fEludGVyLSB8ICAgfCAgICAgICAgIHwgICB8SW50ZXItIHwgICAgICB8SW50 cmEtIHwgfA0KICAgfCB8ZG9tYWluIHw8PDw+Pj58ZG9tYWluIHw8LS18LS0t LS0tLS0tfC0tPnxkb21haW4gfDw8PD4+Pnxkb21haW4gfCB8DQogICB8IHxj b250cm9sfCAgICAgIHxjb250cm9sfCAgIHxDb21tb24gICB8ICAgfGNvbnRy b2x8ICAgICAgfGNvbnRyb2x8IHwNCiAgIHwgfGFnZW50ICB8ICAgICAgfGFn ZW50ICB8ICAgfGludGVyLSAgIHwgICB8YWdlbnQgIHwgICAgICB8YWdlbnQg IHwgfA0KICAgfCArLS0tLS0tLSsgICAgICArLS0tLS0tLSsgICB8ZG9tYWlu ICAgfCAgICstLS0tLS0tKyAgICAgICstLS0tLS0tKyB8DQogICB8IChjZW50 cmFsaXplZCAgKGNlbnRyYWxpemVkKXxjb250cm9sICB8IChjZW50cmFsaXpl ZCkgKGNlbnRyYWxpemVkIHwNCiAgIHwgIG9yICAgICAgICAgICAgICAgICAg ICAgICAgfGludGVyZmFjZXwgICAgICAgICAgICAgICAgb3IgICAgICAgICAg fA0KICAgfCAgZGlzdHJpYnV0ZWQpICAgICAgICAgICAgICB8ICAgICAgICAg fCAgICAgICAgICAgICAgICBkaXN0cmlidXRlZCl8DQogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCg0KICAgPDw8Pj4+ID0gaW50ZXJhY3Rpb25zIGJl dHdlZW4gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IGFuZA0KICAg ICAgICAgICAgdGhlIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGEg ZG9tYWluDQogICA8LS0tLT4gPSBjb21tb24gaW50ZXItZG9tYWluIGludGVy ZmFjZSBiZXR3ZWVuIHBlZXIgaW50ZXItZG9tYWluDQogICAgICAgICAgICBj b250cm9sIGFnZW50cyBhdCBhZGphY2VudCBkb21haW5zDQoNCiAgIEZpZ3Vy ZSAxOiBUaGUgaGlnaC1sZXZlbCB2aWV3IG9mIHRoZSBpbnRlci1kb21haW4g aW50ZXJhY3Rpb25zDQogICAgICAgICAgICAgYmV0d2VlbiB0d28gYWRqYWNl bnQgZG9tYWlucyB3aGVyZSB0aGUgZGlzdGluY3Qgc2VwZXJhdGlvbg0KCSAg ICAgYmV0d2VlbiB0aGUgaW50cmEtZG9tYWluIGFuZCBpbnRlci1kb21haW4g Y29udHJvbCBwbGFuZXMgaXMNCgkgICAgIG1hZGUgYW5kIGEgY29tbW9uIGlu dGVyLWRvbWFpbiBjb250cm9sIGludGVyZmFjZSBleGlzdHMuDQoNClpoYW5n LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMDYsIDIwMDYg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICBJbnRlckRvbWFpbi1RT1NNICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAwNg0KDQozLjEuIFRoZSBSZXF1aXJlbWVudHMgb2YgdGhlIEludGVy LWRvbWFpbiBDb250cm9sIFBsYW5lDQoNCiAgIFRoZSByZXF1aXJlbWVudHMg b2YgdGhlIGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIChpLmUuLCB0aGUN CiAgIGZ1bmN0aW9ucyBwcm92aWRlZCBieSB0aGUgaW50ZXItZG9tYWluIGNv bnRyb2wgYWdlbnQgaW4gRmlndXJlIDEpDQogICB3aGljaCBpcyByZXF1aXJl ZCB0byBpbXBsZW1lbnQgYSBjb21tb24gaW50ZXItZG9tYWluIGNvbnRyb2wN CiAgIGludGVyZmFjZSB0byBmYWNpbGl0YXRlIHRoZSBzdXBwb3J0IG9mIGVu ZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZw0KICAgb3ZlciBoZXRlcm9nZW5l b3VzIG5ldHdvcmsgZG9tYWlucyBhcmUgc3VtbWFyaXplZCBiZWxvdy4gTm90 ZSB0aGF0DQogICB0aGV5IGFyZSBkZXJpdmVkIGNsb3NlbHkgYmFzZWQgb24g dGhlIG9uZXMgb3V0bGluZWQgYnkgdGhlIHByb3Bvc2VkDQogICBEaWZmc2Vy diBDb250cm9sIFBsYW5lIEVsZW1lbnRzIChEQ1BFTCkgQk9GIGluIGl0cyBk b2N1bWVudA0KICAgW0RDUEVMLXJlcXVpcmVtZW50c10uDQoNCiAgIFRoZSBS ZXF1aXJlbWVudHMgb2YgdGhlIEludGVyLWRvbWFpbiBDb250cm9sIFBsYW5l Og0KDQogICBvICBBIGNvbW1vbiBpbnRlci1kb21haW4gY29udHJvbCBpbnRl cmZhY2UsIHdoaWNoIGFsbG93cyB0aGUgUW9TDQogICAgICBuZWdvdGlhdGlv biBhbmQgc2V0LXVwIG9mIGludGVyLWRvbWFpbiB0cmFmZmljIHN0cmVhbXMg d2hpbGUNCiAgICAgIGhpZGluZyBpbnRyYS1kb21haW4gY2hhcmFjdGVyaXN0 aWNzIGZyb20gaW50ZXItZG9tYWluDQogICAgICBpbnRlcmFjdGlvbnMgKGku ZS4sIGluZGVwZW5kZW50IGZyb20gdGhlIHNwZWNpZmljcyBvZiB0aGUNCiAg ICAgIGludHJhLWRvbWFpbiBjb250cm9sIHBsYW5lKSwgbXVzdCBiZSBpbXBs ZW1lbnRlZCBieSB0aGUNCiAgICAgIGludGVyLWRvbWFpbiBjb250cm9sIHBs YW5lLg0KDQogICBvICBTaWduYWxpbmcgQ29tbXVuaWNhdGlvbnMgb3ZlciB0 aGUgY29tbW9uIGludGVyLWRvbWFpbiBpbnRlcmZhY2UNCiAgICAgIG11c3Qg YmUgbWFkZSBiYXNlZCBvbiBhIHdlbGwtdW5kZXJzdG9vZCBpbmZvcm1hdGlv biBtb2RlbCBmb3INCiAgICAgIFNMU3MuIFRoaXMgbW9kZWwgc2hvdWxkIGFs bG93IHRoZSBkZWZpbml0aW9uIG9mIGRpZmZlcmVudCBkZWdyZWVzDQogICAg ICBvZiBTTFNzLCBmcm9tIHBlci1mbG93LCBtb3JlIHN1aXRhYmxlIGZvciBl bmQtaG9zdHMgb3Igc21hbGwNCiAgICAgIG5ldHdvcmtzLCB0byBwZXItYWdn cmVnYXRlLCBtb3JlIHN1aXRhYmxlIGZvciBsYXJnZSBuZXR3b3Jrcy4gSXQg DQogICAgICBzaG91bGQgYWxzbyBhbGxvdyB0aGUgaWRlbnRpZmljYXRpb24g b2YgdGhlIFNMUyB2YWxpZGl0eSBhbmQgYSBzZXQNCiAgICAgIG9mIHRpbWUg cGVyaW9kcyBvdmVyIGVhY2ggdGhlIFNMUyBtdXN0IGJlIGF2YWlsYWJsZSAo YWN0aXZhdGVkKSwgDQogICAgICBiZXNpZGVzIHRoZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUW9TIGNoYXJhY3RlcmlzdGljcy4NCg0KICAgbyAgVGhlIGlu dGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIGF0IGVhY2ggZG9tYWluIG11c3Qg YmUgYWJsZSB0byBrZWVwDQogICAgICBlc3RhYmxpc2hlZCBhbmQvb3IgYXZh aWxhYmxlL29mZmVyZWQgcFNMU3MuIFRoZSBwU0xTIGlzIGFzc29jaWF0ZWQN CiAgICAgIHdpdGggdGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGRvbWFp biBvZmZlcmluZyBvciByZXF1ZXN0aW5nIHRoZQ0KICAgICAgU0xTLg0KDQog ICBvICBUaGUgaW50ZXItZG9tYWluIGNvbnRyb2wgcGxhbmUgbXVzdCBhbGxv dyBuZXR3b3JrIGRvbWFpbnMNCiAgICAgIG5lZ290aWF0ZSBhbmQgc2V0IHVw IHBTTFNzIGJldHCAgICAgfGNvbnRyb2x8IHwNCiAgIHwgfGFnZW50ICB8ICAgICAgfGFn ZW50ICB8ICAgfGludGVyLSAgIHwgICB8YWdlbnQgIHwgICAgICB8YWdlbnQg IHwgfA0KICAgfCArLS0tLS0tLSsgICAgICArLS0tLS0tLSsgICB8ZG9tYWlu ICAgfCAgICstLS0tLS0tKyAgICAgICstLS0tLS0tKyB8DQogICB8IChjZW50 cmFsaXplZCAgKGNlbnRyYWxpemVkKXxjb250cm9sICB8IChjZW50cmFsaXpl ZCkgKGNlbnRyYWxpemVkIHwNCiAgIHwgIG9yICAgICAgICAgICAgICAgICAg ICAgICAgfGludGVyZmFjZXwgICAgICAgICAgICAgICAgb3IgICAgICAgICAg fA0KICAgfCAgZGlzdHJpYnV0ZWQpICAgICAgICAgICAgICB8ICAgICAgICAg fCAgICAgICAgICAgICAgICBkaXN0cmlidXRlZCl8DQogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCg0KICAgPDw8Pj4+ID0gaW50ZXJhY3Rpb25zIGJl dHdlZW4gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IGFuZA0KICAg ICAgICAgICAgdGhlIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGEg ZG9tYWluDQogICA8LS0tLT4gPSBjb21tb24gaW50ZXItZG9tYWluIGludGVy ZmFjZSBiZXR3ZWVuIHBlZXIgaW50ZXItZG9tYWluDQogICAgICAgICAgICBj b250cm9sIGFnZW50cyBhdCBhZGphY2VudCBkb21haW5zDQoNCiAgIEZpZ3Vy ZSAxOiBUaGUgaGlnaC1sZXZlbCB2aWV3IG9mIHRoZSBpbnRlci1kb21haW4g aW50ZXJhY3Rpb25zDQogICAgICAgICAgICAgYmV0d2VlbiB0d28gYWRqYWNl bnQgZG9tYWlucyB3aGVyZSB0aGUgZGlzdGluY3Qgc2VwZXJhdGlvbg0KCSAg ICAgYmV0d2VlbiB0aGUgaW50cmEtZG9tYWluIGFuZCBpbnRlci1kb21haW4g Y29udHJvbCBwbGFuZXMgaXMNCgkgICAgIG1hZGUgYW5kIGEgY29tbW9uIGlu dGVyLWRvbWFpbiBjb250cm9sIGludGVyZmFjZSBleGlzdHMuDQoNClpoYW5n LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMDYsIDIwMDYg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICBJbnRlckRvbWFpbi1RT1NNICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAwNg0KDQozLjEuIFRoZSBSZXF1aXJlbWVudHMgb2YgdGhlIEludGVy LWRvbWFpbiBDb250cm9sIFBsYW5lDQoNCiAgIFRoZSByZXF1aXJlbWVudHMg b2YgdGhlIGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIChpLmUuLCB0aGUN CiAgIGZ1bmN0aW9ucyBwcm92aWRlZCBieSB0aGUgaW50ZXItZG9tYWluIGNv bnRyb2wgYWdlbnQgaW4gRmlndXJlIDEpDQogICB3aGljaCBpcyByZXF1aXJl ZCB0byBpbXBsZW1lbnQgYSBjb21tb24gaW50ZXItZG9tYWluIGNvbnRyb2wN CiAgIGludGVyZmFjZSB0byBmYWNpbGl0YXRlIHRoZSBzdXBwb3J0IG9mIGVu ZC10by1lbmQgUW9TIHByb3Zpc2lvbmluZw0KICAgb3ZlciBoZXRlcm9nZW5l b3VzIG5ldHdvcmsgZG9tYWlucyBhcmUgc3VtbWFyaXplZCBiZWxvdy4gTm90 ZSB0aGF0DQogICB0aGV5IGFyZSBkZXJpdmVkIGNsb3NlbHkgYmFzZWQgb24g dGhlIG9uZXMgb3V0bGluZWQgYnkgdGhlIHByb3Bvc2VkDQogICBEaWZmc2Vy diBDb250cm9sIFBsYW5lIEVsZW1lbnRzIChEQ1BFTCkgQk9GIGluIGl0cyBk b2N1bWVudA0KICAgW0RDUEVMLXJlcXVpcmVtZW50c10uDQoNCiAgIFRoZSBS ZXF1aXJlbWVudHMgb2YgdGhlIEludGVyLWRvbWFpbiBDb250cm9sIFBsYW5l Og0KDQogICBvICBBIGNvbW1vbiBpbnRlci1kb21haW4gY29udHJvbCBpbnRl cmZhY2UsIHdoaWNoIGFsbG93cyB0aGUgUW9TDQogICAgICBuZWdvdGlhdGlv biBhbmQgc2V0LXVwIG9mIGludGVyLWRvbWFpbiB0cmFmZmljIHN0cmVhbXMg d2hpbGUNCiAgICAgIGhpZGluZyBpbnRyYS1kb21haW4gY2hhcmFjdGVyaXN0 aWNzIGZyb20gaW50ZXItZG9tYWluDQogICAgICBpbnRlcmFjdGlvbnMgKGku ZS4sIGluZGVwZW5kZW50IGZyb20gdGhlIHNwZWNpZmljcyBvZiB0aGUNCiAg ICAgIGludHJhLWRvbWFpbiBjb250cm9sIHBsYW5lKSwgbXVzdCBiZSBpbXBs ZW1lbnRlZCBieSB0aGUNCiAgICAgIGludGVyLWRvbWFpbiBjb250cm9sIHBs YW5lLg0KDQogICBvICBTaWduYWxpbmcgQ29tbXVuaWNhdGlvbnMgb3ZlciB0 aGUgY29tbW9uIGludGVyLWRvbWFpbiBpbnRlcmZhY2UNCiAgICAgIG11c3Qg YmUgbWFkZSBiYXNlZCBvbiBhIHdlbGwtdW5kZXJzdG9vZCBpbmZvcm1hdGlv biBtb2RlbCBmb3INCiAgICAgIFNMU3MuIFRoaXMgbW9kZWwgc2hvdWxkIGFs bG93IHRoZSBkZWZpbml0aW9uIG9mIGRpZmZlcmVudCBkZWdyZWVzDQogICAg ICBvZiBTTFNzLCBmcm9tIHBlci1mbG93LCBtb3JlIHN1aXRhYmxlIGZvciBl bmQtaG9zdHMgb3Igc21hbGwNCiAgICAgIG5ldHdvcmtzLCB0byBwZXItYWdn cmVnYXRlLCBtb3JlIHN1aXRhYmxlIGZvciBsYXJnZSBuZXR3b3Jrcy4gSXQg DQogICAgICBzaG91bGQgYWxzbyBhbGxvdyB0aGUgaWRlbnRpZmljYXRpb24g b2YgdGhlIFNMUyB2YWxpZGl0eSBhbmQgYSBzZXQNCiAgICAgIG9mIHRpbWUg cGVyaW9kcyBvdmVyIGVhY2ggdGhlIFNMUyBtdXN0IGJlIGF2YWlsYWJsZSAo YWN0aXZhdGVkKSwgDQogICAgICBiZXNpZGVzIHRoZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUW9TIGNoYXJhY3RlcmlzdGljcy4NCg0KICAgbyAgVGhlIGlu dGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIGF0IGVhY2ggZG9tYWluIG11c3Qg YmUgYWJsZSB0byBrZWVwDQogICAgICBlc3RhYmxpc2hlZCBhbmQvb3IgYXZh aWxhYmxlL29mZmVyZWQgcFNMU3MuIFRoZSBwU0xTIGlzIGFzc29jaWF0ZWQN CiAgICAgIHdpdGggdGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIGRvbWFp biBvZmZlcmluZyBvciByZXF1ZXN0aW5nIHRoZQ0KICAgICAgU0xTLg0KDQog ICBvICBUaGUgaW50ZXItZG9tYWluIGNvbnRyb2wgcGxhbmUgbXVzdCBhbGxv dyBuZXR3b3JrIGRvbWFpbnMNCiAgICAgIG5lZ290aWF0ZSBhbmQgc2V0IHVw IHBTTFNzIGJldHdlZW4gYWRqYWNlbnQgZG9tYWlucy4gUG9saWN5DQogICAg ICBpbmZvcm1hdGlvbiBzcGVjaWZpYyB0byB0aGUgcmVxdWVzdGVyLCBvciBv dGhlciBnZW5lcmFsIHBvbGljaWVzDQogICAgICBtdXN0IGJlIGNoZWNrZWQg dG8gZGV0ZXJtaW5lIGlmIHRoZSByZXF1ZXN0ZWQgU0xTIGNhbiB0aGUNCiAg ICAgIGFjY2VwdGVkLg0KDQogICBvICBUaGUgaW50ZXItZG9tYWluIGNvbnRy b2wgcGxhbmUgYXQgZWFjaCBkb21haW4gbXVzdCBiZSBhYmxlIHRvDQogICAg ICBlbnN1cmUgdGhhdCB0aGUgdHJhZmZpYyBzdHJlYW1zIGl0cyBkb21haW4g c2VuZHMgYXJlIGluIGNvbmZvcm1pdHkNCiAgICAgIHdpdGggdGhlIGVzdGFi bGlzaGVkIGFncmVlbWVudC4gUGFja2V0cyBtaWdodCBuZWVkIHRvIGJlIHJl LW1hcmtlZA0KICAgICAgZnJvbSBvbmUgaW50ZXJuYWwgdHJhZmZpYyBjbGFz cyBpZGVudGlmaWVyIHRvIHRoZSBpbnRlci1kb21haW4gU0xTDQogICAgICBp ZGVudGlmaWVyLCB3aGljaCB0aGVuIG1pZ2h0IG5lZWQgdG8gYmUgcmUtbWFy a2VkIGZyb20gdGhlDQogICAgICBpbnRlci1kb21haW4gU0xTIGlkZW50aWZp ZXIgdG8gYW5vdGhlciBpbnRlcm5hbCB0cmFmZmljIGNsYXNzDQogICAgICBp ZGVudGlmaWVyIHVzZWQgYXQgaXRzIGFkamFjZW50IGRvbWFpbi4NCg0KICAg byAgVGhlIGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIHNob3VsZCBiZSBh YmxlIHRvIHN1cHBvcnQgdGhlIFFvUw0KICAgICAgcXVlcnksIHJlcXVlc3Qs IHJlc3BvbnNlIGFuZCBtb25pdG9yIG9wZXJhdGlvbnMgaW4gYSBjaGFpbiBv ZiANCiAgICAgIGhldGVyb2dlbmVvdXMgbmV0d29yayBkb21haW5zIG9uIGEg cGVyLWZsb3cgb3IgcGVyLWFnZ3JlZ2F0ZQ0KICAgICAgYmFzaXMgdmlhIHRo ZSBjb21tb24gaW50ZXItZG9tYWluIGNvbnRyb2wgaW50ZXJmYWNlLg0KDQpa aGFuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDA2LCAy MDA2ICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgSW50ZXJEb21haW4tUU9TTSAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMDYNCg0KICAgbyAgVGhlIGludGVyLWRvbWFpbiBjb250cm9s IHBsYW5lIHNob3VsZCBiZSBhYmxlIHRvIHN1cHBvcnQgdGhlDQogICAgICBh dXRvbWF0aWMgaW50ZXItZG9tYWluIGFkanVzdG1lbnQgaW4gdGhlIHNjZW5h cmlvIG9mIG1vYmlsZSBlbmQNCiAgICAgIGN1c3RvbWVycy4NCg0KNC4gVGhl IE92ZXJ2aWV3IG9mIHRoZSBOU0lTIEludGVyRG9tYWluLVFPU00NCg0KICAg VGhlIEludGVyRG9tYWluLVFPU00gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQgYXNzdW1lcyB0aGUgZGlzdGluY3QgDQogICBzZXBhcmF0aW9uIGJldHdl ZW4gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIHBsYW5lIGFuZCB0aGUNCiAg IGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIGF0IGVhY2ggYWRtaW5pc3Ry YXRpdmUgZG9tYWluIGFuZCB0aGVuDQogICB0cmllcyB0byBmdWxmaWxsIHRo ZSBhYm92ZSByZXF1aXJlbWVudHMgb2YgdGhlIGludGVyLWRvbWFpbiBjb250 cm9sDQogICBwbGFuZSBieSBpbXBsZW1lbnRpbmcgdGhlIGludGVyLWRvbWFp biBjb250cm9sIGFnZW50IChzZWUgRmlndXJlDQogICAxKSB0aHJvdWdoIHNw ZWNpZnlpbmcgYSBOU0lTIFFPU00uIFRoZSBvcGVyYXRpb24gbW9kZWwgYW5k IHRoZSBiYXNpYw0KICAgZmVhdHVyZXMgb2YgdGhlIEludGVyRG9tYWluLVFP U00gYXJlIHByZXNlbnRlZCBiZWxvdywgcmVzcGVjdGl2ZWx5Lg0KDQo0LjEg VGhlIG9wZXJhdGlvbiBtb2RlbCBvZiB0aGUgTlNJUyBJbnRlckRvbWFpbi1R T1NNDQoNCiAgIFRoZSBvcGVyYXRpb24gbW9kZWwgb2YgdGhlIEludGVyRG9t YWluLVFPU00gaXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlDQogICAyLCB3aGVy ZSBhdCBlYWNoIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgdGhlIGRvbWFpbi13 aWRlIGNlbnRyYWxpemVkDQogICBpbnRlci1kb21haW4gY29udHJvbCBhZ2Vu dCBpbXBsZW1lbnRzIHRoZSBOU0lTIEludGVyRG9tYWluLVFPU00gYW5kDQog ICB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgYWdlbnQgaXMgYW4gYWJzdHJh Y3QgZW50aXR5IHdoaWNoIGNhbiBkZXBsb3kNCiAgIGFueSBpbnRyYS1kb21h aW4gUW9TIG1vZGVsIChlLmcuLCBjZW50cmFsaXplZCBvciBkaXN0cmlidXRl ZCwgTlNJUw0KICAgYmFzZWQgb3Igbm9uLU5TSVMgYmFzZWQpLiBNb3Jlb3Zl ciwgdGhlIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50IGlzDQogICBsb2Nh dGVkIGF0IGEgd2VsbC1rbm93biBRTkUgYXQgaXRzIGRvbWFpbiB3aGVyZSB0 aGUgUW9TLU5TTFAgaXMNCiAgIHN0YXRlZnVsIGFuZCB0aGUgcGF0aC1jb3Vw bGVkIG9yIHBhdGgtZGVjb3VwbGVkIE5UTFAgYXJlIGJvdGgNCiAgIHBvc3Np YmxlIHRvIGJlIHVzZWQgdG8gZGlzY292ZXIgaXRzIHBlZXJzIGF0IHRoZSBh ZGphY2VudCBkb21haW5zLg0KICAgVGhlIGV4cGFuYXRpb24gb2YgdGhlIG9w ZXJhdGlvbiBtb2RlbCBpcyBwcmVzZW50ZWQgYmVsb3cuIE5vdGUgdGhhdA0K ICAgdGhlIEludGVyRG9tYWluLVFPU00gYXNzdW1lcyB0aGF0IHRoZSBwU0xT cyBiZXR3ZWVuIHRoZSBhZGphY2VudA0KICAgZG9tYWlucyBoYXZlIGJlZW4g ZXN0YWJsaXNoZWQgb3IgZGlzY292ZXJlZCBieSBzb21lIG90aGVyIHByb3Rv Y29scw0KICAgKGUuZy4sIFFvUy1hd2FyZSBCR1AgcHJvdG9jb2wpIGFuZCB0 aG9zZSBwU0xTcyBhcmUgbWFpbnRhaW5lZCBhdCB0aGUNCiAgIGludGVyLWRv bWFpbiBjb250cm9sIGFnZW50Lg0KICAgDQogICAgICBTb3VyY2UgRG9tYWlu ICAgICB8ICAgICBUcmFuc2l0IERvbWFpbiAgICB8ICAgICAgU2luayBEb21h aW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICAgICAgIEludGVyLSAgIHwgICBJbnRlci0g ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIGRvbWFpbiAgIHwgICBk b21haW4gICAgICAgICAgICAdlZW4gYWRqYWNlbnQgZG9tYWlucy4gUG9saWN5DQogICAg ICBpbmZvcm1hdGlvbiBzcGVjaWZpYyB0byB0aGUgcmVxdWVzdGVyLCBvciBv dGhlciBnZW5lcmFsIHBvbGljaWVzDQogICAgICBtdXN0IGJlIGNoZWNrZWQg dG8gZGV0ZXJtaW5lIGlmIHRoZSByZXF1ZXN0ZWQgU0xTIGNhbiB0aGUNCiAg ICAgIGFjY2VwdGVkLg0KDQogICBvICBUaGUgaW50ZXItZG9tYWluIGNvbnRy b2wgcGxhbmUgYXQgZWFjaCBkb21haW4gbXVzdCBiZSBhYmxlIHRvDQogICAg ICBlbnN1cmUgdGhhdCB0aGUgdHJhZmZpYyBzdHJlYW1zIGl0cyBkb21haW4g c2VuZHMgYXJlIGluIGNvbmZvcm1pdHkNCiAgICAgIHdpdGggdGhlIGVzdGFi bGlzaGVkIGFncmVlbWVudC4gUGFja2V0cyBtaWdodCBuZWVkIHRvIGJlIHJl LW1hcmtlZA0KICAgICAgZnJvbSBvbmUgaW50ZXJuYWwgdHJhZmZpYyBjbGFz cyBpZGVudGlmaWVyIHRvIHRoZSBpbnRlci1kb21haW4gU0xTDQogICAgICBp ZGVudGlmaWVyLCB3aGljaCB0aGVuIG1pZ2h0IG5lZWQgdG8gYmUgcmUtbWFy a2VkIGZyb20gdGhlDQogICAgICBpbnRlci1kb21haW4gU0xTIGlkZW50aWZp ZXIgdG8gYW5vdGhlciBpbnRlcm5hbCB0cmFmZmljIGNsYXNzDQogICAgICBp ZGVudGlmaWVyIHVzZWQgYXQgaXRzIGFkamFjZW50IGRvbWFpbi4NCg0KICAg byAgVGhlIGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIHNob3VsZCBiZSBh YmxlIHRvIHN1cHBvcnQgdGhlIFFvUw0KICAgICAgcXVlcnksIHJlcXVlc3Qs IHJlc3BvbnNlIGFuZCBtb25pdG9yIG9wZXJhdGlvbnMgaW4gYSBjaGFpbiBv ZiANCiAgICAgIGhldGVyb2dlbmVvdXMgbmV0d29yayBkb21haW5zIG9uIGEg cGVyLWZsb3cgb3IgcGVyLWFnZ3JlZ2F0ZQ0KICAgICAgYmFzaXMgdmlhIHRo ZSBjb21tb24gaW50ZXItZG9tYWluIGNvbnRyb2wgaW50ZXJmYWNlLg0KDQpa aGFuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDA2LCAy MDA2ICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgSW50ZXJEb21haW4tUU9TTSAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMDYNCg0KICAgbyAgVGhlIGludGVyLWRvbWFpbiBjb250cm9s IHBsYW5lIHNob3VsZCBiZSBhYmxlIHRvIHN1cHBvcnQgdGhlDQogICAgICBh dXRvbWF0aWMgaW50ZXItZG9tYWluIGFkanVzdG1lbnQgaW4gdGhlIHNjZW5h cmlvIG9mIG1vYmlsZSBlbmQNCiAgICAgIGN1c3RvbWVycy4NCg0KNC4gVGhl IE92ZXJ2aWV3IG9mIHRoZSBOU0lTIEludGVyRG9tYWluLVFPU00NCg0KICAg VGhlIEludGVyRG9tYWluLVFPU00gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQgYXNzdW1lcyB0aGUgZGlzdGluY3QgDQogICBzZXBhcmF0aW9uIGJldHdl ZW4gdGhlIGludHJhLWRvbWFpbiBjb250cm9sIHBsYW5lIGFuZCB0aGUNCiAg IGludGVyLWRvbWFpbiBjb250cm9sIHBsYW5lIGF0IGVhY2ggYWRtaW5pc3Ry YXRpdmUgZG9tYWluIGFuZCB0aGVuDQogICB0cmllcyB0byBmdWxmaWxsIHRo ZSBhYm92ZSByZXF1aXJlbWVudHMgb2YgdGhlIGludGVyLWRvbWFpbiBjb250 cm9sDQogICBwbGFuZSBieSBpbXBsZW1lbnRpbmcgdGhlIGludGVyLWRvbWFp biBjb250cm9sIGFnZW50IChzZWUgRmlndXJlDQogICAxKSB0aHJvdWdoIHNw ZWNpZnlpbmcgYSBOU0lTIFFPU00uIFRoZSBvcGVyYXRpb24gbW9kZWwgYW5k IHRoZSBiYXNpYw0KICAgZmVhdHVyZXMgb2YgdGhlIEludGVyRG9tYWluLVFP U00gYXJlIHByZXNlbnRlZCBiZWxvdywgcmVzcGVjdGl2ZWx5Lg0KDQo0LjEg VGhlIG9wZXJhdGlvbiBtb2RlbCBvZiB0aGUgTlNJUyBJbnRlckRvbWFpbi1R T1NNDQoNCiAgIFRoZSBvcGVyYXRpb24gbW9kZWwgb2YgdGhlIEludGVyRG9t YWluLVFPU00gaXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlDQogICAyLCB3aGVy ZSBhdCBlYWNoIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgdGhlIGRvbWFpbi13 aWRlIGNlbnRyYWxpemVkDQogICBpbnRlci1kb21haW4gY29udHJvbCBhZ2Vu dCBpbXBsZW1lbnRzIHRoZSBOU0lTIEludGVyRG9tYWluLVFPU00gYW5kDQog ICB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgYWdlbnQgaXMgYW4gYWJzdHJh Y3QgZW50aXR5IHdoaWNoIGNhbiBkZXBsb3kNCiAgIGFueSBpbnRyYS1kb21h aW4gUW9TIG1vZGVsIChlLmcuLCBjZW50cmFsaXplZCBvciBkaXN0cmlidXRl ZCwgTlNJUw0KICAgYmFzZWQgb3Igbm9uLU5TSVMgYmFzZWQpLiBNb3Jlb3Zl ciwgdGhlIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50IGlzDQogICBsb2Nh dGVkIGF0IGEgd2VsbC1rbm93biBRTkUgYXQgaXRzIGRvbWFpbiB3aGVyZSB0 aGUgUW9TLU5TTFAgaXMNCiAgIHN0YXRlZnVsIGFuZCB0aGUgcGF0aC1jb3Vw bGVkIG9yIHBhdGgtZGVjb3VwbGVkIE5UTFAgYXJlIGJvdGgNCiAgIHBvc3Np YmxlIHRvIGJlIHVzZWQgdG8gZGlzY292ZXIgaXRzIHBlZXJzIGF0IHRoZSBh ZGphY2VudCBkb21haW5zLg0KICAgVGhlIGV4cGFuYXRpb24gb2YgdGhlIG9w ZXJhdGlvbiBtb2RlbCBpcyBwcmVzZW50ZWQgYmVsb3cuIE5vdGUgdGhhdA0K ICAgdGhlIEludGVyRG9tYWluLVFPU00gYXNzdW1lcyB0aGF0IHRoZSBwU0xT cyBiZXR3ZWVuIHRoZSBhZGphY2VudA0KICAgZG9tYWlucyBoYXZlIGJlZW4g ZXN0YWJsaXNoZWQgb3IgZGlzY292ZXJlZCBieSBzb21lIG90aGVyIHByb3Rv Y29scw0KICAgKGUuZy4sIFFvUy1hd2FyZSBCR1AgcHJvdG9jb2wpIGFuZCB0 aG9zZSBwU0xTcyBhcmUgbWFpbnRhaW5lZCBhdCB0aGUNCiAgIGludGVyLWRv bWFpbiBjb250cm9sIGFnZW50Lg0KICAgDQogICAgICBTb3VyY2UgRG9tYWlu ICAgICB8ICAgICBUcmFuc2l0IERvbWFpbiAgICB8ICAgICAgU2luayBEb21h aW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICAgICAgIEludGVyLSAgIHwgICBJbnRlci0g ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIGRvbWFpbiAgIHwgICBk b21haW4gICAgICAgICAgICAgIHwgIA0KICAgICAgICAgICAgICAgY29udHJv bCAgfCAgIGNvbnRyb2wgICAgICAgICAgICAgfCAgDQogICAgICAgICAgICAg ICBhZ2VudCAgICB8ICAgYWdlbnQgICAgICAgICAgICAgICB8ICANCiAgUW9T IFRyaWdnZXIgKy0tLS0tLSsgM3wgICstLS0tLS0rICAgICAgICA2ICAgIHwg ICstLS0tLS0rIA0KICAgICB8ICBeICAgICB8ICAgICAgfC0tfC0+fCAgICAg IHwtLS0tLS0tLS0tLS0tfC0+fCAgICAgIHwNCiAgICAxfCAgfDEyICAgfElu dGVyIHwxMHwgIHxJbnRlciB8ICAgICAgICA5ICAgIHwgIHxJbnRlciB8DQog ICAgIFYgIHwgICAgIHxEb21haW58PC18LS18RG9tYWlufDwtLS0tLS0tLS0t LS18LS18RG9tYWlufCAgIA0KICArLS0tLS0tLSsgMiB8UU9TTSAgfCAgfCAg fFFPU00gIHwgNCArLS0tLS0tLSsgfCAgfFFPU00gIHwgNyArLS0tLS0tLSsg DQogIHxpbnRyYS0gfC0tPnwgICAgICB8ICB8ICB8ICAgICAgfC0tPnxpbnRy YS0gfCB8ICB8ICAgICAgfC0tPnxpbnRyYS0gfA0KICB8ZG9tYWluIHwgMTF8 ICAgICAgfCAgfCAgfCAgICAgIHwgNSB8ZG9tYWluIHwgfCAgfCAgICAgIHwg OCB8ZG9tYWluIHwNCiAgfFFPU00xICB8PC0tfCAgICAgIHwgIHwgIHwgICAg ICB8PC0tfFFPU00yICB8IHwgIHwgICAgICB8PC0tfFFPU00zICB8DQogIHwg ICAgICAgfCAgIHwtLS0tLS18ICB8ICB8LS0tLS0tfCAgIHwgICAgICAgfCB8 ICB8LS0tLS0tfCAgIHwgICAgICAgfA0KICB8SW50cmEtIHwgICB8IFFvUy0g fCAgfCAgfCBRb1MtIHwgICB8SW50cmEtIHwgfCAgfCBRb1MtIHwgICB8SW50 cmEtIHwNCiAgfGRvbWFpbiB8ICAgfCBOU0xQIHwgIHwgIHwgTlNMUCB8ICAg fGRvbWFpbiB8IHwgIHwgTlNMUCB8ICAgfGRvbWFpbiB8DQogIHxjb250cm9s fCAgIHwtLS0tLS18ICB8ICB8LS0tLS0tfCAgIHxjb250cm9sfCB8ICB8LS0t LS0tfCAgIHxjb250cm9sfA0KICB8YWdlbnQgIHwgICB8IE5UTFAqfCAgfCAg fCBOVExQKnwgICB8YWdlbnQgIHwgfCAgfCBOVExQKnwgICB8YWdlbnQgIHwN CiAgKy0tLS0tLS0rICAgKy0tLS0tLSsgIHwgICstLS0tLS0rICAgKy0tLS0t LS0rIHwgICstLS0tLS0rICAgKy0tLS0tLS0rICAgICAgICANCiAgICAgICAg ICAgDQogICBOVExQKjogcGF0aC1jb3VwbGVkIG9yIHBhdGgtZGVjb3VwbGVk IE5UTFANCiAgIA0KICAgRmlndXJlIDI6IFRoZSBvcGVyYXRpb24gbW9kZWwg b2YgdGhlIEludGVyRG9tYWluLVFPU00NCg0KWmhhbmcsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVy RG9tYWluLVFPU00gICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2DQoNCiAg IFdoZW4gYSBRb1MgcmVxdWVzdCBvciBxdWVyeSB3aXRoIGl0cyBTTFMgcGFy YW1ldGVycyBpcyByZWNlaXZlZCBieSANCiAgIHRoZSBpbnRyYS1kb21haW4g Y29udHJvbCBhZ2VudCBhdCB0aGUgc291cmNlIGRvbWFpbiAoc3RlcCAxKSwg dGhlDQogICBpbnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBmaXJzdCBuZWVk IHRvIGF1dGhlbnRpY2F0ZSB0aGUgcmVxdWVzdCBvcg0KICAgcXVlcnkgaXMg ZnJvbSBhbiBhdXRob3JpemVkIFFvUyB0cmlnZ2VyIGFuZCB0aGVuIG1ha2Ug dGhlIA0KICAgaW50cmEtZG9tYWluIFFvUyBvcGVyYXRpb25zIHRvIGRldGVy bWluZSB0aGUgcmVzdWx0IG9mIHRoZSBRb1MNCiAgIHJlcXVlc3Qgb3IgcXVl cnkgYXQgdGhlIHNvdXJjZSBkb21haW4uIEluIGNhc2Ugb2YgcG9zaXRpdmUg ZGVjaXNpb25zLA0KICAgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50 IHdpbGwgZm9yd2FyZCB0byB0aGUgd2VsbC1rbm93bg0KICAgaW50ZXItZG9t YWluIGNvbnRyb2wgYWdlbnQgYXQgaXRzIGRvbWFpbiB0aGUgUW9TIHJlcXVl c3Qgb3IgcXVlcnkNCiAgIHdpdGggdGhlIFNMUyBwYXJhbWV0ZXJzIGFzIHdl bGwgYXMgdGhlIGVncmVzcyBub2RlIG9mIHRoZSBzb3VyY2UNCiAgIGRvbWFp biB0byB3aGljaCB0aGUgcmVxdWVzdCBvciBxdWVyeSBpcyBhc3NpZ25lZCBh bmQgdGhlIGluZ3Jlc3Mgbm9kZQ0KICAgb2YgdGhlIHRyYW5zaXQgZG9tYWlu IGZyb20gd2hpY2ggdGhlIHJlcXVlc3Qgb3IgcXVlcnkgd2lsbCBiZQ0KICAg YWNjZXB0ZWQgKHN0ZXAgMikuDQogICANCiAgIFRoZSBpbnRlci1kb21haW4g Y29udHJvbCBhZ2VudCBhdCB0aGUgc291cmNlIGRvbWFpbiB0aGVuIG5lZWQg dG8NCiAgIGNoZWNrIHdoZXRoZXIgdGhlIHJlY2VpdmVkIFNMUyBwYXJhbWV0 ZXJzIGZpdCBpbiB0aGUgcFNMUyBlc3RhYmxpc2hlZA0KICAgYmV0d2VlbiB0 aGUgZWdyZXNzIG5vZGUgb2YgdGhlIHNvdXJjZSBkb21haW4gYW5kIHRoZSBp bmdyZXNzIG5vZGUgb2YNCiAgIHRoZSB0cmFuc21pdCBkb21haW4gYXNzaWdu ZWQgdG8gdGhlIHJlcXVlc3Qgb3IgcXVlcnkuIElmIHRoZXJlIGlzIHRoZQ0K ICAgcG9zaXRpdmUgb3V0Y29tZSBvZiB0aGUgYWJvdmUgY2hlY2ssIHRoZSBp bnRlci1kb21haW4gY29udHJvbCBhZ2VudA0KICAgd2lsbCBtYWludGFpbiB0 aGUgSVAgaW50ZXJmYWNlcyBvZiB0aGUgZWdyZXNzIGFuZCBpbmdyZXNzIG5v ZGVzIGZvcg0KICAgdGhlIFFvUyByZXF1ZXN0IG9yIHF1ZXJ5LCBjb250cnVj dCBhIG5ldyBRb1MtTlNMUCBSRVNFUlZFIG9yIFFVRVJZDQogICBtZXNzYWdl IHdpdGggdGhlIFFTUEVDIG9iamVjdCBjb250YWluaW5nIGFsbCByZWNlaXZl ZCBTTFMsIGVncmVzcyBhbmQNCiAgIGluZ3Jlc3Mgbm9kZSBwYXJhbWV0ZXJz IGFzIHdlbGwgYXMgdGhlIFBPTElDWV9EQVRBIG9iamVjdCBjb250YWluaW5n DQogICBpdHMgSUQgYW5kIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uLCBh bmQgc2VuZCB0aGUgbWVzc2FnZSB0byBpdHMNCiAgIHBlZXIgYXQgdGhlIHRy YW5zaXQgZG9tYWluIChzdGVwIDMpLg0KDQogICBXaGVuIHRoZSBpbnRlci1k b21haW4gY29udHJvbCBhZ2VudCBhdCB0aGUgdHJhbnNpdCBkb21haW4gcmVj ZWl2ZXMgYQ0KICAgUW9TLU5TTFAgUkVTgIHwgIA0KICAgICAgICAgICAgICAgY29udHJv bCAgfCAgIGNvbnRyb2wgICAgICAgICAgICAgfCAgDQogICAgICAgICAgICAg ICBhZ2VudCAgICB8ICAgYWdlbnQgICAgICAgICAgICAgICB8ICANCiAgUW9T IFRyaWdnZXIgKy0tLS0tLSsgM3wgICstLS0tLS0rICAgICAgICA2ICAgIHwg ICstLS0tLS0rIA0KICAgICB8ICBeICAgICB8ICAgICAgfC0tfC0+fCAgICAg IHwtLS0tLS0tLS0tLS0tfC0+fCAgICAgIHwNCiAgICAxfCAgfDEyICAgfElu dGVyIHwxMHwgIHxJbnRlciB8ICAgICAgICA5ICAgIHwgIHxJbnRlciB8DQog ICAgIFYgIHwgICAgIHxEb21haW58PC18LS18RG9tYWlufDwtLS0tLS0tLS0t LS18LS18RG9tYWlufCAgIA0KICArLS0tLS0tLSsgMiB8UU9TTSAgfCAgfCAg fFFPU00gIHwgNCArLS0tLS0tLSsgfCAgfFFPU00gIHwgNyArLS0tLS0tLSsg DQogIHxpbnRyYS0gfC0tPnwgICAgICB8ICB8ICB8ICAgICAgfC0tPnxpbnRy YS0gfCB8ICB8ICAgICAgfC0tPnxpbnRyYS0gfA0KICB8ZG9tYWluIHwgMTF8 ICAgICAgfCAgfCAgfCAgICAgIHwgNSB8ZG9tYWluIHwgfCAgfCAgICAgIHwg OCB8ZG9tYWluIHwNCiAgfFFPU00xICB8PC0tfCAgICAgIHwgIHwgIHwgICAg ICB8PC0tfFFPU00yICB8IHwgIHwgICAgICB8PC0tfFFPU00zICB8DQogIHwg ICAgICAgfCAgIHwtLS0tLS18ICB8ICB8LS0tLS0tfCAgIHwgICAgICAgfCB8 ICB8LS0tLS0tfCAgIHwgICAgICAgfA0KICB8SW50cmEtIHwgICB8IFFvUy0g fCAgfCAgfCBRb1MtIHwgICB8SW50cmEtIHwgfCAgfCBRb1MtIHwgICB8SW50 cmEtIHwNCiAgfGRvbWFpbiB8ICAgfCBOU0xQIHwgIHwgIHwgTlNMUCB8ICAg fGRvbWFpbiB8IHwgIHwgTlNMUCB8ICAgfGRvbWFpbiB8DQogIHxjb250cm9s fCAgIHwtLS0tLS18ICB8ICB8LS0tLS0tfCAgIHxjb250cm9sfCB8ICB8LS0t LS0tfCAgIHxjb250cm9sfA0KICB8YWdlbnQgIHwgICB8IE5UTFAqfCAgfCAg fCBOVExQKnwgICB8YWdlbnQgIHwgfCAgfCBOVExQKnwgICB8YWdlbnQgIHwN CiAgKy0tLS0tLS0rICAgKy0tLS0tLSsgIHwgICstLS0tLS0rICAgKy0tLS0t LS0rIHwgICstLS0tLS0rICAgKy0tLS0tLS0rICAgICAgICANCiAgICAgICAg ICAgDQogICBOVExQKjogcGF0aC1jb3VwbGVkIG9yIHBhdGgtZGVjb3VwbGVk IE5UTFANCiAgIA0KICAgRmlndXJlIDI6IFRoZSBvcGVyYXRpb24gbW9kZWwg b2YgdGhlIEludGVyRG9tYWluLVFPU00NCg0KWmhhbmcsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVy RG9tYWluLVFPU00gICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2DQoNCiAg IFdoZW4gYSBRb1MgcmVxdWVzdCBvciBxdWVyeSB3aXRoIGl0cyBTTFMgcGFy YW1ldGVycyBpcyByZWNlaXZlZCBieSANCiAgIHRoZSBpbnRyYS1kb21haW4g Y29udHJvbCBhZ2VudCBhdCB0aGUgc291cmNlIGRvbWFpbiAoc3RlcCAxKSwg dGhlDQogICBpbnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBmaXJzdCBuZWVk IHRvIGF1dGhlbnRpY2F0ZSB0aGUgcmVxdWVzdCBvcg0KICAgcXVlcnkgaXMg ZnJvbSBhbiBhdXRob3JpemVkIFFvUyB0cmlnZ2VyIGFuZCB0aGVuIG1ha2Ug dGhlIA0KICAgaW50cmEtZG9tYWluIFFvUyBvcGVyYXRpb25zIHRvIGRldGVy bWluZSB0aGUgcmVzdWx0IG9mIHRoZSBRb1MNCiAgIHJlcXVlc3Qgb3IgcXVl cnkgYXQgdGhlIHNvdXJjZSBkb21haW4uIEluIGNhc2Ugb2YgcG9zaXRpdmUg ZGVjaXNpb25zLA0KICAgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50 IHdpbGwgZm9yd2FyZCB0byB0aGUgd2VsbC1rbm93bg0KICAgaW50ZXItZG9t YWluIGNvbnRyb2wgYWdlbnQgYXQgaXRzIGRvbWFpbiB0aGUgUW9TIHJlcXVl c3Qgb3IgcXVlcnkNCiAgIHdpdGggdGhlIFNMUyBwYXJhbWV0ZXJzIGFzIHdl bGwgYXMgdGhlIGVncmVzcyBub2RlIG9mIHRoZSBzb3VyY2UNCiAgIGRvbWFp biB0byB3aGljaCB0aGUgcmVxdWVzdCBvciBxdWVyeSBpcyBhc3NpZ25lZCBh bmQgdGhlIGluZ3Jlc3Mgbm9kZQ0KICAgb2YgdGhlIHRyYW5zaXQgZG9tYWlu IGZyb20gd2hpY2ggdGhlIHJlcXVlc3Qgb3IgcXVlcnkgd2lsbCBiZQ0KICAg YWNjZXB0ZWQgKHN0ZXAgMikuDQogICANCiAgIFRoZSBpbnRlci1kb21haW4g Y29udHJvbCBhZ2VudCBhdCB0aGUgc291cmNlIGRvbWFpbiB0aGVuIG5lZWQg dG8NCiAgIGNoZWNrIHdoZXRoZXIgdGhlIHJlY2VpdmVkIFNMUyBwYXJhbWV0 ZXJzIGZpdCBpbiB0aGUgcFNMUyBlc3RhYmxpc2hlZA0KICAgYmV0d2VlbiB0 aGUgZWdyZXNzIG5vZGUgb2YgdGhlIHNvdXJjZSBkb21haW4gYW5kIHRoZSBp bmdyZXNzIG5vZGUgb2YNCiAgIHRoZSB0cmFuc21pdCBkb21haW4gYXNzaWdu ZWQgdG8gdGhlIHJlcXVlc3Qgb3IgcXVlcnkuIElmIHRoZXJlIGlzIHRoZQ0K ICAgcG9zaXRpdmUgb3V0Y29tZSBvZiB0aGUgYWJvdmUgY2hlY2ssIHRoZSBp bnRlci1kb21haW4gY29udHJvbCBhZ2VudA0KICAgd2lsbCBtYWludGFpbiB0 aGUgSVAgaW50ZXJmYWNlcyBvZiB0aGUgZWdyZXNzIGFuZCBpbmdyZXNzIG5v ZGVzIGZvcg0KICAgdGhlIFFvUyByZXF1ZXN0IG9yIHF1ZXJ5LCBjb250cnVj dCBhIG5ldyBRb1MtTlNMUCBSRVNFUlZFIG9yIFFVRVJZDQogICBtZXNzYWdl IHdpdGggdGhlIFFTUEVDIG9iamVjdCBjb250YWluaW5nIGFsbCByZWNlaXZl ZCBTTFMsIGVncmVzcyBhbmQNCiAgIGluZ3Jlc3Mgbm9kZSBwYXJhbWV0ZXJz IGFzIHdlbGwgYXMgdGhlIFBPTElDWV9EQVRBIG9iamVjdCBjb250YWluaW5n DQogICBpdHMgSUQgYW5kIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uLCBh bmQgc2VuZCB0aGUgbWVzc2FnZSB0byBpdHMNCiAgIHBlZXIgYXQgdGhlIHRy YW5zaXQgZG9tYWluIChzdGVwIDMpLg0KDQogICBXaGVuIHRoZSBpbnRlci1k b21haW4gY29udHJvbCBhZ2VudCBhdCB0aGUgdHJhbnNpdCBkb21haW4gcmVj ZWl2ZXMgYQ0KICAgUW9TLU5TTFAgUkVTRVJWRSBvciBRVUVSWSBtZXNzYWdl IGZyb20gaXRzIHBlZXIsIGl0IHdpbGwgdGFrZSB0aGUNCiAgIGZvbGxvd2lu ZyBhY3Rpb25zOg0KDQogICBhLiBBdXRoZW50aWNhdGUgdGhhdCB0aGUgUkVT RVJWRSBvciBRVUVSWSBtZXNzYWdlIGlzIGluZGVlZCBmcm9tIGENCiAgICAg IHBlZXIgYnkgdXNpbmcgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5pbmcgaW4g dGhlIFBPTElDWV9EQVRBIG9iamVjdA0KICAgICAgb2YgdGhlIHJlY2VpdmVk IG1lc3NhZ2UuDQogICBiLiBDaGVjayB0aGF0IHRoZSBTTFMgcGFyYW1ldGVy cyBjb250YWluaW5nIGluIHRoZSBRU1BFQyBvYmplY3Qgb2YNCiAgICAgIHRo ZSByZWNlaXZlZCBtZXNzYWdlIGZhbGwgd2l0aGluIHRoZSBwU0xTIGVzdGFi bGlzaGVkIGJldHdlZW4gdGhlDQogICAgICBlZ3Jlc3MgYW5kIGluZ3Jlc3Mg bm9kZXMgaW4gdGhlIFFTUEVDIG9iamVjdC4NCiAgIGMuIERldGVybWluZSB3 aGV0aGVyIHRoZSBRb1MgcmVxdWVzdCBvciBxdWVyeSBtYXkgYmUgYWNjZXB0 ZWQgDQogICAgICBhY2NvcmRpbmcgdG8gdGhlIHBvbGljaWVzIG9mIHRoZSBk b21haW4uDQoNCiAgIEluIGNhc2UgdGhhdCBhbGwgdGhlIGRlY2lzaW9ucyBo YXZlIHBvc2l0aXZlIG91dHB1dHMsIHRoZQ0KICAgaW50ZXItZG9tYWluIGNv bnRyb2wgYWdlbnQgYXQgdGhlIHRyYW5zaXQgZG9tYWluIHdpbGwgYWxzbyBt YWludGFpbg0KICAgdGhlIElQIGludGVyZmFjZXMgb2YgdGhlIGVncmVzcyBh bmQgaW5ncmVzcyBub2RlcyBmb3IgdGhlIFFvUyByZXF1ZXN0DQogICBvciBx dWVyeSwgYW5kIHRoZW4gc2VuZCB0aGUgU0xTIHBhcmFtZXRlcnMgYW5kIHRo ZSBJUCBpbnRlcmZhY2Ugb2YNCiAgIHRoZSBpbmdyZXNzIG5vZGUgZnJvbSB3 aGljaCB0aGUgcmVxdWVzdCBvciBxdWVyeSB3aWxsIGJlIGFkbWl0dGVkDQog ICBpbnRvIHRoZSB0cmFuc2l0IGRvbWFpbiB0byB0aGUgaW50cmEtZG9tYWlu IGNvbnRyb2wgYWdlbnQgb2YgaXRzDQogICBkb21haW4gKHN0ZXAgNCkuIEFm dGVyIHRoZSBpbnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBjb25maXJtcyB0 aGF0DQogICB0aGUgcmVxdWVzdCBvciBxdWVyeSBpcyBmcm9tIGFuIGF1dGhv cml6ZWQgUW9TIHRyaWdnZXIgKGluIHRoaXMgY2FzZSwNCiAgIHRoZSBpbnRl ci1kb21haW4gY29udHJvbCBhZ2VudCksIGl0IHdpbGwgYXBwbHkgaXRzIGlu dHJhLWRvbWFpbg0KICAgY29udHJvbCBtZWNoYW5pc21zIHRvIHRoZSBRb1Mg cmVxdWVzdCBvciBxdWVyeS4gSW4gY2FzZSBvZiBwb3NpdGl2ZQ0KICAgb3V0 Y29tZSwgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IHNob3VsZCBz ZW5kIHRoZSBTTFMNCiAgIHBhcmFtZXRlcnMsIHRoZSBJUCBpbnRlcmZhY2Ug b2YgdGhlIGVncmVzcyBub2RlIG9mIHRoZSB0cmFuc2l0IGRvbWFpbg0KICAg dG8gd2hpY2ggdGhlIFFvUyByZXF1ZXN0IG9yIHF1ZXJ5IGlzIGFzc2lnbmVk IGFuZCB0aGUgSVAgaW50ZXJmYWNlIG9mDQogICB0aGUgaW5ncmVzcyBub2Rl IG9mIHRoZSBzaW5rIGRvbWFpbiBmcm9tIHdoaWNoIHRoZSBRb1MgcmVxdWVz dCBvcg0KICAgcXVlcnkgd2lsbCBiZSBhY2NlcHRlZCB0byB0aGUgaW50ZXIt ZG9tYWluIGNvbnRyb2wgYWdlbnQgKHN0ZXAgNSksDQogICB3aGljaCB3aWxs IGZpcnN0IGRldGVybWluZSBpZiB0aGUgU0xTIHBhcmFtZXRlcnMgZmFsbCB3 aXRoaW4gdGhlIHBTTFMNCiAgIGVzdGFibGlzaGVkIGJldHdlZW4gdGhlIGFz c2lnbmVkIGVncmVzcyBub2RlIG9mIHRoZSB0cmFuc2l0IGRvbWFpbg0KICAg YW5kIHRoZSBhc3NpZ25lZCBpbmdyZXNzIG5vZGUgb2YgdGhlIHNpbmsgZG9t YWluLiANCiAgIA0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWluLVFPU00gICAg ICAgICAgICAgICAgICBNYXJjaCAyMDA2DQogICANCiAgIEluIGNhc2Ugb2Yg cG9zaXRpdmUgZGVjaXNpb24sIHRoZSBpbnRlci1kb21haW4gY29udHJvbCBh Z2VudCBhdCB0aGUNCiAgIHRyYW5zaXQgZG9tYWluIG5lZWQgdG8gbWFpbnRh aW4gdGhlIElQIGFkZHJlc3NlcyBvZiB0aGUgYWJvdmUgdHdvDQogICBlZ3Jl c3MgYW5kIGluZ3Jlc3Mgbm9kZXMgKHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgSVAgaW50ZXJmYWNlcw0KICAgbWFpbnRhaW5lZCBhdCBlYWNoIGludGVy LWRvbWFpbiBjb250cm9sIGFnZW50IGlzIHN1bW1hcml6ZWQgaW4gVGFibGUN CiAgIDEpLCB0aGVuIHRvIGNvbnN0cnVjdCBhIG5ldyBRb1MtTlNMUCBSRVNF UlZFIG9yIFFVRVJZIG1lc3NhZ2Ugd2l0aA0KICAgdGhlIFFTUEVDIG9iamVj dCBjb250YWluaW5nIHRoZSBTTFMgcGFyYW1ldGVycyBhbmQgdGhlIElQIGFk ZHJlc3Nlcw0KICAgb2YgdGhlIGFib3ZlIGVncmVzcyBhbmQgaW5ncmVzcyBu b2RlcyBhcyB3ZWxsIGFzIHRoZSBQT0xJQ1lfREFUQQ0KICAgb2JqZWN0IGNv bnRhaW5pbmcgaXRzIElEIGFuZCBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlv biwgYW5kIHNlbmQgdGhlDQogICBtZXNzYWdlIHRvIHRoZSBpdHMgcGVlciBh dCB0aGUgc2luayBkb21haW4gKHN0ZXAgNikuDQogICANCiAgIC0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICB8LSBJUCBpbnRl cmZhY2Ugb2YgaXRzIGVncmVzcyBub2RlIGFzc2lnbmVkIHRvIHRoZSBRb1MN CiAgIFNvdXJjZSBEb21haW4gfCAgcmVxdWVzdCBvciBxdWVyeQ0KCQkgfC0g SVAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNzIG5vZGUgZnJvbSB3aGljaCB0 aGUgUW9TDQoJCSB8ICByZXF1ZXN0IG9yIHF1ZXJ5IGlzIGFkbWl0dGVkIGlu dG8gdGhlIHRyYW5zaXQgZG9tYWluDQogICAtLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICAgICAgICAgICAgICAgfC0gSVAgaRVJWRSBvciBRVUVSWSBtZXNzYWdl IGZyb20gaXRzIHBlZXIsIGl0IHdpbGwgdGFrZSB0aGUNCiAgIGZvbGxvd2lu ZyBhY3Rpb25zOg0KDQogICBhLiBBdXRoZW50aWNhdGUgdGhhdCB0aGUgUkVT RVJWRSBvciBRVUVSWSBtZXNzYWdlIGlzIGluZGVlZCBmcm9tIGENCiAgICAg IHBlZXIgYnkgdXNpbmcgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5pbmcgaW4g dGhlIFBPTElDWV9EQVRBIG9iamVjdA0KICAgICAgb2YgdGhlIHJlY2VpdmVk IG1lc3NhZ2UuDQogICBiLiBDaGVjayB0aGF0IHRoZSBTTFMgcGFyYW1ldGVy cyBjb250YWluaW5nIGluIHRoZSBRU1BFQyBvYmplY3Qgb2YNCiAgICAgIHRo ZSByZWNlaXZlZCBtZXNzYWdlIGZhbGwgd2l0aGluIHRoZSBwU0xTIGVzdGFi bGlzaGVkIGJldHdlZW4gdGhlDQogICAgICBlZ3Jlc3MgYW5kIGluZ3Jlc3Mg bm9kZXMgaW4gdGhlIFFTUEVDIG9iamVjdC4NCiAgIGMuIERldGVybWluZSB3 aGV0aGVyIHRoZSBRb1MgcmVxdWVzdCBvciBxdWVyeSBtYXkgYmUgYWNjZXB0 ZWQgDQogICAgICBhY2NvcmRpbmcgdG8gdGhlIHBvbGljaWVzIG9mIHRoZSBk b21haW4uDQoNCiAgIEluIGNhc2UgdGhhdCBhbGwgdGhlIGRlY2lzaW9ucyBo YXZlIHBvc2l0aXZlIG91dHB1dHMsIHRoZQ0KICAgaW50ZXItZG9tYWluIGNv bnRyb2wgYWdlbnQgYXQgdGhlIHRyYW5zaXQgZG9tYWluIHdpbGwgYWxzbyBt YWludGFpbg0KICAgdGhlIElQIGludGVyZmFjZXMgb2YgdGhlIGVncmVzcyBh bmQgaW5ncmVzcyBub2RlcyBmb3IgdGhlIFFvUyByZXF1ZXN0DQogICBvciBx dWVyeSwgYW5kIHRoZW4gc2VuZCB0aGUgU0xTIHBhcmFtZXRlcnMgYW5kIHRo ZSBJUCBpbnRlcmZhY2Ugb2YNCiAgIHRoZSBpbmdyZXNzIG5vZGUgZnJvbSB3 aGljaCB0aGUgcmVxdWVzdCBvciBxdWVyeSB3aWxsIGJlIGFkbWl0dGVkDQog ICBpbnRvIHRoZSB0cmFuc2l0IGRvbWFpbiB0byB0aGUgaW50cmEtZG9tYWlu IGNvbnRyb2wgYWdlbnQgb2YgaXRzDQogICBkb21haW4gKHN0ZXAgNCkuIEFm dGVyIHRoZSBpbnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBjb25maXJtcyB0 aGF0DQogICB0aGUgcmVxdWVzdCBvciBxdWVyeSBpcyBmcm9tIGFuIGF1dGhv cml6ZWQgUW9TIHRyaWdnZXIgKGluIHRoaXMgY2FzZSwNCiAgIHRoZSBpbnRl ci1kb21haW4gY29udHJvbCBhZ2VudCksIGl0IHdpbGwgYXBwbHkgaXRzIGlu dHJhLWRvbWFpbg0KICAgY29udHJvbCBtZWNoYW5pc21zIHRvIHRoZSBRb1Mg cmVxdWVzdCBvciBxdWVyeS4gSW4gY2FzZSBvZiBwb3NpdGl2ZQ0KICAgb3V0 Y29tZSwgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IHNob3VsZCBz ZW5kIHRoZSBTTFMNCiAgIHBhcmFtZXRlcnMsIHRoZSBJUCBpbnRlcmZhY2Ug b2YgdGhlIGVncmVzcyBub2RlIG9mIHRoZSB0cmFuc2l0IGRvbWFpbg0KICAg dG8gd2hpY2ggdGhlIFFvUyByZXF1ZXN0IG9yIHF1ZXJ5IGlzIGFzc2lnbmVk IGFuZCB0aGUgSVAgaW50ZXJmYWNlIG9mDQogICB0aGUgaW5ncmVzcyBub2Rl IG9mIHRoZSBzaW5rIGRvbWFpbiBmcm9tIHdoaWNoIHRoZSBRb1MgcmVxdWVz dCBvcg0KICAgcXVlcnkgd2lsbCBiZSBhY2NlcHRlZCB0byB0aGUgaW50ZXIt ZG9tYWluIGNvbnRyb2wgYWdlbnQgKHN0ZXAgNSksDQogICB3aGljaCB3aWxs IGZpcnN0IGRldGVybWluZSBpZiB0aGUgU0xTIHBhcmFtZXRlcnMgZmFsbCB3 aXRoaW4gdGhlIHBTTFMNCiAgIGVzdGFibGlzaGVkIGJldHdlZW4gdGhlIGFz c2lnbmVkIGVncmVzcyBub2RlIG9mIHRoZSB0cmFuc2l0IGRvbWFpbg0KICAg YW5kIHRoZSBhc3NpZ25lZCBpbmdyZXNzIG5vZGUgb2YgdGhlIHNpbmsgZG9t YWluLiANCiAgIA0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWluLVFPU00gICAg ICAgICAgICAgICAgICBNYXJjaCAyMDA2DQogICANCiAgIEluIGNhc2Ugb2Yg cG9zaXRpdmUgZGVjaXNpb24sIHRoZSBpbnRlci1kb21haW4gY29udHJvbCBh Z2VudCBhdCB0aGUNCiAgIHRyYW5zaXQgZG9tYWluIG5lZWQgdG8gbWFpbnRh aW4gdGhlIElQIGFkZHJlc3NlcyBvZiB0aGUgYWJvdmUgdHdvDQogICBlZ3Jl c3MgYW5kIGluZ3Jlc3Mgbm9kZXMgKHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgSVAgaW50ZXJmYWNlcw0KICAgbWFpbnRhaW5lZCBhdCBlYWNoIGludGVy LWRvbWFpbiBjb250cm9sIGFnZW50IGlzIHN1bW1hcml6ZWQgaW4gVGFibGUN CiAgIDEpLCB0aGVuIHRvIGNvbnN0cnVjdCBhIG5ldyBRb1MtTlNMUCBSRVNF UlZFIG9yIFFVRVJZIG1lc3NhZ2Ugd2l0aA0KICAgdGhlIFFTUEVDIG9iamVj dCBjb250YWluaW5nIHRoZSBTTFMgcGFyYW1ldGVycyBhbmQgdGhlIElQIGFk ZHJlc3Nlcw0KICAgb2YgdGhlIGFib3ZlIGVncmVzcyBhbmQgaW5ncmVzcyBu b2RlcyBhcyB3ZWxsIGFzIHRoZSBQT0xJQ1lfREFUQQ0KICAgb2JqZWN0IGNv bnRhaW5pbmcgaXRzIElEIGFuZCBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlv biwgYW5kIHNlbmQgdGhlDQogICBtZXNzYWdlIHRvIHRoZSBpdHMgcGVlciBh dCB0aGUgc2luayBkb21haW4gKHN0ZXAgNikuDQogICANCiAgIC0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICB8LSBJUCBpbnRl cmZhY2Ugb2YgaXRzIGVncmVzcyBub2RlIGFzc2lnbmVkIHRvIHRoZSBRb1MN CiAgIFNvdXJjZSBEb21haW4gfCAgcmVxdWVzdCBvciBxdWVyeQ0KCQkgfC0g SVAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNzIG5vZGUgZnJvbSB3aGljaCB0 aGUgUW9TDQoJCSB8ICByZXF1ZXN0IG9yIHF1ZXJ5IGlzIGFkbWl0dGVkIGlu dG8gdGhlIHRyYW5zaXQgZG9tYWluDQogICAtLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50ZXJmYWNlIG9mIHRo ZSBlZ3Jlc3Mgbm9kZSBvZiB0aGUgc291cmNlIGRvbWFpbg0KICAgVHJhbnNp dCBEb21haW58ICBhc3NpZ25lZCB0byB0aGUgUW9TIHJlcXVlc3Qgb3IgcXVl cnkNCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50ZXJmYWNlIG9mIGl0cyBp bmdyZXNzIG5vZGUgZnJvbSB3aGljaCB0aGUgUW9TDQoJCSB8ICByZXF1ZXN0 IG9yIHF1ZXJ5IGlzIGFkbWl0dGVkIGludG8gdGhlIHRyYW5zaXQgZG9tYWlu DQoJCSB8LSBJUCBpbnRlcmZhY2Ugb2YgaXRzIGVncmVzcyBub2RlIGFzc2ln bmVkIHRvIHRoZSBRb1MNCgkJIHwgIHJlcXVlc3Qgb3IgcXVlcnkNCiAgICAg ICAgICAgICAgICAgfC0gSVAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNzIG5v ZGUgZnJvbSB3aGljaCB0aGUgUW9TDQoJCSB8ICByZXF1ZXN0IG9yIHF1ZXJ5 IGlzIGFkbWl0dGVkIGludG8gdGhlIHNpbmsgZG9tYWluDQogICAtLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50 ZXJmYWNlIG9mIHRoZSBlZ3Jlc3Mgbm9kZSBvZiB0aGUgdHJhbnNpdCAgDQog ICBTaW5rIERvbWFpbiAgIHwgIGRvbWFpbiBhc3NpZ25lZCB0byB0aGUgUW9T IHJlcXVlc3Qgb3IgcXVlcnkNCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50 ZXJmYWNlIG9mIGl0cyBpbmdyZXNzIG5vZGUgZnJvbSB3aGljaCB0aGUgUW9T DQoJCSB8ICByZXF1ZXN0IG9yIHF1ZXJ5IGlzIGFkbWl0dGVkIGludG8gdGhl IHNpbmsgZG9tYWluDQogICAtLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICAgVGFibGUgMTogVGhlIElQIGludGVyZmFjZXMgb2YgdGhlIGVncmVzcyBh bmQgaW5ncmVzcyBub2RlcyBtYWludGFpbmVkDQogICAgICAgICAgICBhdCBl YWNoIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50Lg0KDQogICBUaGUgaW50 ZXItZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQgdGhlIHNpbmsgZG9tYWluIHdp bGwgYWxzbyBuZWVkIHRvDQogICBjaGVjayBpZiB0aGUgU0xTIHBhcmFtZXRl cnMgaW4gdGhlIFJFU0VSVkUgb3IgUVVFUlkgbWVzc2FnZSBmYWxsIA0KICAg d2l0aGluIHRoZSBwU0xTIGJldHdlZW4gdGhlIGVncmVzcyBub2RlIG9mIHRo ZSB0cmFuc2l0IGRvbWFpbiBhbmQgaXRzDQogICBpbmdyZXNzIG5vZGUgY29u dGFpbmVkIGluIHRoZSBJbnRlckRvbWFpbi1RT1NNIFFTUEVDIG9mIHRoZSBS RVNFUlZFIA0KICAgb3IgUVVFUlkgbWVzc2FnZSBhbmQgbWFpbnRhaW4gdGhl aXIgSVAgaW50ZXJmYWNlcyAoc2VlIFRhYmxlIDEpIHdoZW4NCiAgIHRoZSBj aGVjayByZXN1bHQgaXMgcG9zaXRpdmUuIFRoZW4sIHRoZSBTTFMgcGFyYW1l dGVycyBhbmQgdGhlIElQIA0KICAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNz IG5vZGUgd2lsbCBiZSBzZW50IHRvIHRoZSBpbnRyYS1kb21haW4NCiAgIGNv bnRyb2wgYWdlbnQgYXQgdGhlIHNpbmsgZG9tYWluIChzdGVwIDcpLCB3aGlj aCB0YWtlcyBjYXJlIG9mIHRoZSANCiAgIGludHJhLWRvbWFpbiB0cmVhdG1l bnQgb2YgdGhlIFFvUyByZXF1ZXN0IG9yIHF1ZXJ5IGFuZCB0aGVuIHNlbmQg YmFjaw0KICAgaXRzIHJlc3BvbnNlIChzdGVwIDgpLiBJbiBjYXNlIG9mIHBv c2l0aXZlIHJlc3BvbnNlLCBpdCB3aWxsIGJlDQogICBwcm9wYWdhdGVkIGRp cmVjdGx5IGJldHdlZW4gdGhlIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50 cyB2aWEgdGhlDQogICBRb1MtTlNMUCBSRVNQT05TRSBtZXNzYWdlIChzdGVw cyA5IGFuZCAxMCkuIEluIGNhc2Ugb2YgbmVnYXRpdmUgDQogICByZXN1bHQg b2YgUW9TIHJlcXVlc3QgZnJvbSBhZGphY2VudCBkb21haW4sIHRoZSBpbnRl ci1kb21haW4gY29udHJvbA0KICAgYWdlbnQgc2hvdWxkIGFsc28gaW5mb3Jt IGl0IHRvIGl0cyBpbnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBzbyB0aGF0 DQogICB0aGUgcmVzZXJ2ZWQgcmVzb3VyY2VzIGF0IHRoaXMgZG9tYWluIGNh biBiZSB0ZWFyZWQgZG93biAodGhpcyBzdGVwDQogICBpcyBub3QgcmVmbGVj dGVkIGluIEZpZ3VyZSAyIGR1ZSB0byBsaW1pdGVkIHNwYWNlKS4gV2hlbiB0 aGUgUkVTUE9OU0UNCiAgIG1lc3NhZ2UgcmVhY2hlcyB0aGUgaW50ZXItZG9t YWluIGNvbnRyb2wgYWdlbnQgYXQgc291cmNlIGRvbWFpbiwgaXRzDQogICBj b250ZW50IHdpbGwgYmUgc2VudCB0byB0aGUgaW50cmEtZG9tYWluIGNvbnRy b2wgYWdlbnQgYXQgdGhlIGRvbWFpbg0KICAgKHN0ZXAgMTEpLCB3aGljaCB3 aWxsIGZ1cnRoZXIgZm9yd2FyZCBpdCB0byB0aGUgaW5pdGlhbCBRb1MgdHJp Z2dlciAoDQogICBzdGVwIDEyKS4NCg0KWmhhbmcsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1Bh Z2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9t YWluLVFPU00gICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2DQoNCjQuMiBC YXNpYyBmZWF0dXJlcyBvZiBJbnRlckRvbWFpbi1RT1NNDQoNCiAgIFRoZSBi YXNpYyBmZWF0dXJlcyBvZiB0aGUgSW50ZXJEb21haW4tUU9TTSBkZXNjcmli ZWQgaW4gdGhpcyBkb2N1bWVudA0KICAgaW5jbHVkZToNCg0KICAgbyAgVGhl IFNMUyBwYXJhbWV0ZXJzIGFuZCBRb1MgY29udHJvbCBpbmZvcm1hdGlvbiBy ZXF1aXJlZCBmb3IgdGhlDQogICAgICBpbnRlci1kb21haW4gUW9TIGludGVy YWN0aW9ucyBhcmUgc3BlY2lmaWVkIGJ5IHVzaW5nL2V4dGVuZGluZyB0aGUg DQogICAgICBRU1BFQyB0ZW1wbGF0ZSBpbiBbTlNJUy1RU1BFQ10uDQoNCiAg IG8gIFRoZSBJbnRlckRvbWFpbi1RT1NNIHJlc2lkZXMgb24gdG9wIG9mIHRo ZSBRb1MtTlNMUCBbUW9TLU5TTFBdIGFuZA0KICAgICAgTlRMUCwgd2hpY2gg bWVhbnMgdGhhdCBpdCB1c2VzIHRoZSBtZXNzYWdlcywgb2JqZWN0cyBhbmQN CiAgICAgIHByb2NlZHVyZXMgZGVmaW5lZCBieSB0aGUgUW9TLUW50ZXJmYWNlIG9mIHRo ZSBlZ3Jlc3Mgbm9kZSBvZiB0aGUgc291cmNlIGRvbWFpbg0KICAgVHJhbnNp dCBEb21haW58ICBhc3NpZ25lZCB0byB0aGUgUW9TIHJlcXVlc3Qgb3IgcXVl cnkNCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50ZXJmYWNlIG9mIGl0cyBp bmdyZXNzIG5vZGUgZnJvbSB3aGljaCB0aGUgUW9TDQoJCSB8ICByZXF1ZXN0 IG9yIHF1ZXJ5IGlzIGFkbWl0dGVkIGludG8gdGhlIHRyYW5zaXQgZG9tYWlu DQoJCSB8LSBJUCBpbnRlcmZhY2Ugb2YgaXRzIGVncmVzcyBub2RlIGFzc2ln bmVkIHRvIHRoZSBRb1MNCgkJIHwgIHJlcXVlc3Qgb3IgcXVlcnkNCiAgICAg ICAgICAgICAgICAgfC0gSVAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNzIG5v ZGUgZnJvbSB3aGljaCB0aGUgUW9TDQoJCSB8ICByZXF1ZXN0IG9yIHF1ZXJ5 IGlzIGFkbWl0dGVkIGludG8gdGhlIHNpbmsgZG9tYWluDQogICAtLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50 ZXJmYWNlIG9mIHRoZSBlZ3Jlc3Mgbm9kZSBvZiB0aGUgdHJhbnNpdCAgDQog ICBTaW5rIERvbWFpbiAgIHwgIGRvbWFpbiBhc3NpZ25lZCB0byB0aGUgUW9T IHJlcXVlc3Qgb3IgcXVlcnkNCiAgICAgICAgICAgICAgICAgfC0gSVAgaW50 ZXJmYWNlIG9mIGl0cyBpbmdyZXNzIG5vZGUgZnJvbSB3aGljaCB0aGUgUW9T DQoJCSB8ICByZXF1ZXN0IG9yIHF1ZXJ5IGlzIGFkbWl0dGVkIGludG8gdGhl IHNpbmsgZG9tYWluDQogICAtLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICAgVGFibGUgMTogVGhlIElQIGludGVyZmFjZXMgb2YgdGhlIGVncmVzcyBh bmQgaW5ncmVzcyBub2RlcyBtYWludGFpbmVkDQogICAgICAgICAgICBhdCBl YWNoIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50Lg0KDQogICBUaGUgaW50 ZXItZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQgdGhlIHNpbmsgZG9tYWluIHdp bGwgYWxzbyBuZWVkIHRvDQogICBjaGVjayBpZiB0aGUgU0xTIHBhcmFtZXRl cnMgaW4gdGhlIFJFU0VSVkUgb3IgUVVFUlkgbWVzc2FnZSBmYWxsIA0KICAg d2l0aGluIHRoZSBwU0xTIGJldHdlZW4gdGhlIGVncmVzcyBub2RlIG9mIHRo ZSB0cmFuc2l0IGRvbWFpbiBhbmQgaXRzDQogICBpbmdyZXNzIG5vZGUgY29u dGFpbmVkIGluIHRoZSBJbnRlckRvbWFpbi1RT1NNIFFTUEVDIG9mIHRoZSBS RVNFUlZFIA0KICAgb3IgUVVFUlkgbWVzc2FnZSBhbmQgbWFpbnRhaW4gdGhl aXIgSVAgaW50ZXJmYWNlcyAoc2VlIFRhYmxlIDEpIHdoZW4NCiAgIHRoZSBj aGVjayByZXN1bHQgaXMgcG9zaXRpdmUuIFRoZW4sIHRoZSBTTFMgcGFyYW1l dGVycyBhbmQgdGhlIElQIA0KICAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNz IG5vZGUgd2lsbCBiZSBzZW50IHRvIHRoZSBpbnRyYS1kb21haW4NCiAgIGNv bnRyb2wgYWdlbnQgYXQgdGhlIHNpbmsgZG9tYWluIChzdGVwIDcpLCB3aGlj aCB0YWtlcyBjYXJlIG9mIHRoZSANCiAgIGludHJhLWRvbWFpbiB0cmVhdG1l bnQgb2YgdGhlIFFvUyByZXF1ZXN0IG9yIHF1ZXJ5IGFuZCB0aGVuIHNlbmQg YmFjaw0KICAgaXRzIHJlc3BvbnNlIChzdGVwIDgpLiBJbiBjYXNlIG9mIHBv c2l0aXZlIHJlc3BvbnNlLCBpdCB3aWxsIGJlDQogICBwcm9wYWdhdGVkIGRp cmVjdGx5IGJldHdlZW4gdGhlIGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50 cyB2aWEgdGhlDQogICBRb1MtTlNMUCBSRVNQT05TRSBtZXNzYWdlIChzdGVw cyA5IGFuZCAxMCkuIEluIGNhc2Ugb2YgbmVnYXRpdmUgDQogICByZXN1bHQg b2YgUW9TIHJlcXVlc3QgZnJvbSBhZGphY2VudCBkb21haW4sIHRoZSBpbnRl ci1kb21haW4gY29udHJvbA0KICAgYWdlbnQgc2hvdWxkIGFsc28gaW5mb3Jt IGl0IHRvIGl0cyBpbnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBzbyB0aGF0 DQogICB0aGUgcmVzZXJ2ZWQgcmVzb3VyY2VzIGF0IHRoaXMgZG9tYWluIGNh biBiZSB0ZWFyZWQgZG93biAodGhpcyBzdGVwDQogICBpcyBub3QgcmVmbGVj dGVkIGluIEZpZ3VyZSAyIGR1ZSB0byBsaW1pdGVkIHNwYWNlKS4gV2hlbiB0 aGUgUkVTUE9OU0UNCiAgIG1lc3NhZ2UgcmVhY2hlcyB0aGUgaW50ZXItZG9t YWluIGNvbnRyb2wgYWdlbnQgYXQgc291cmNlIGRvbWFpbiwgaXRzDQogICBj b250ZW50IHdpbGwgYmUgc2VudCB0byB0aGUgaW50cmEtZG9tYWluIGNvbnRy b2wgYWdlbnQgYXQgdGhlIGRvbWFpbg0KICAgKHN0ZXAgMTEpLCB3aGljaCB3 aWxsIGZ1cnRoZXIgZm9yd2FyZCBpdCB0byB0aGUgaW5pdGlhbCBRb1MgdHJp Z2dlciAoDQogICBzdGVwIDEyKS4NCg0KWmhhbmcsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICAgW1Bh Z2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9t YWluLVFPU00gICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2DQoNCjQuMiBC YXNpYyBmZWF0dXJlcyBvZiBJbnRlckRvbWFpbi1RT1NNDQoNCiAgIFRoZSBi YXNpYyBmZWF0dXJlcyBvZiB0aGUgSW50ZXJEb21haW4tUU9TTSBkZXNjcmli ZWQgaW4gdGhpcyBkb2N1bWVudA0KICAgaW5jbHVkZToNCg0KICAgbyAgVGhl IFNMUyBwYXJhbWV0ZXJzIGFuZCBRb1MgY29udHJvbCBpbmZvcm1hdGlvbiBy ZXF1aXJlZCBmb3IgdGhlDQogICAgICBpbnRlci1kb21haW4gUW9TIGludGVy YWN0aW9ucyBhcmUgc3BlY2lmaWVkIGJ5IHVzaW5nL2V4dGVuZGluZyB0aGUg DQogICAgICBRU1BFQyB0ZW1wbGF0ZSBpbiBbTlNJUy1RU1BFQ10uDQoNCiAg IG8gIFRoZSBJbnRlckRvbWFpbi1RT1NNIHJlc2lkZXMgb24gdG9wIG9mIHRo ZSBRb1MtTlNMUCBbUW9TLU5TTFBdIGFuZA0KICAgICAgTlRMUCwgd2hpY2gg bWVhbnMgdGhhdCBpdCB1c2VzIHRoZSBtZXNzYWdlcywgb2JqZWN0cyBhbmQN CiAgICAgIHByb2NlZHVyZXMgZGVmaW5lZCBieSB0aGUgUW9TLU5TTFAgZm9y IHNpZ25hbGluZyBleGNoYW5nZXMgd2l0aA0KICAgICAgb3RoZXIgUU5FcyBh bmQgZGVwZW5kcyBvbiB0aGUgTlRMUCB0byBkaXNjb3ZlciB0aGUgcGVlcg0K ICAgICAgaW50ZXItZG9tYWluIGNvbnRyb2wgYWdlbnRzIGF0IHRoZSBhZGph Y2VudCBkb21haW5zLg0KICAgDQogICBvICBUaGUgSW50ZXJEb21haW4tUU9T TSBtYWtlcyBubyBhc3N1bXB0aW9ucyBhYm91dCB0aGUgaW1wbGVtZW50YXRp b24NCiAgICAgIG1lY2hhbmlzbXMgb2YgaW50cmEtZG9tYWluIGNvbnRyb2wg YWdlbnQuIFRoYXQgaXMgdG8gc2F5IHRoYXQgdGhlDQogICAgICBpbnRyYS1k b21haW4gY29udHJvbCBhZ2VudCBtaWdodCBiZSBjZW50cmFsaXplZCBvciBk aXN0cmlidXRlZCwgDQogICAgICBOU0lTIGJhc2VkIG9yIG5vbi1OU0lTIGJh c2VkLg0KDQogICBvICBUaGUgSW50ZXJEb21haW4tUU9TTSBtYWtlcyBubyBh c3N1bXB0aW9uIGFib3V0IHRoZSBtZXRob2QgdGhhdCB0aGUNCiAgICAgIHVu ZGVybHlpbmcgTlRMUCBtaWdodCB1c2UgdG8gZGlzY292ZXIgdGhlIHBlZXIg aW50ZXItZG9tYWluDQogICAgICBjb250cm9sIGFnZW50cyBhdCBhZGphY2Vu dCBkb21haW5zLg0KDQo1LiBJbnRlckRvbWFpbi1RT1NNLCBEZXRhaWxlZCBE ZXNjcmlwdGlvbg0KDQo1LjEgQWRkaXRpb25hbCBRU1BFQyBQYXJhbWV0ZXJz IGZvciBJbnRlckRvbWFpbi1RT1NNDQoNCiAgIEZpcnN0IG9mIGFsbCwgdHdv IG5ldyBRb1MgY29udHJvbCBwYXJhbWV0ZXJzIDxFZ3Jlc3MgSUQ+IGFuZCAN CiAgIDxJbmdyZXNzIElEPiBuZWVkIHRvIGJlIGFkZGVkIHRvIHRoZSBRU1BF QyBDb250cm9sIEluZm9ybWF0aW9uIG9mDQogICB0aGUgSW50ZXJEb21haW4t UU9TTSwgd2hpY2ggZGVzY3JpYmVzIHRoZSBJUCBpbnRlcmZhY2VzIG9mIHRo ZSANCiAgIGVncmVzcyBhbmQgaW5ncmVzcyBub2RlcyB0byB3aGljaCB0aGUg c2lnbmFsZWQgdHJhZmZpYyBzdHJlYW0gaXMNCiAgIGFzc2lnbmVkIHJlc3Bl Y3RpdmVseS4NCiAgIA0KICAgU2Vjb25kbHksIHRvIGRlc2NyaWJlIHRoZSB0 aW1lIHBlcmlvZHMgb3ZlciB3aGljaCBhIFNMUyB3aWxsIGJlDQogICBhdmFp bGFibGUgb3IgcmVxdWVzdGVkLCB0aGUgZm9sbG93aW5nIDxUaW1lIFNwZWNp ZmljYXRpb24+IHBhcmFtZXRlcnMNCiAgIGFyZSBhZGRlZCB0byB0aGUgPFFv UyBEZXNpcmVkPiwgPFFvUyBBdmFpbGFibGU+LCA8UW9TIFJlc2VydmVkPg0K ICAgYW5kIDxNaW5pbXVtIFFvUz4gUVNQRUMgb2JqZWN0cyBvZiB0aGUgSW50 ZXJEb21haW4tUU9TTToNCg0KICAgPFRpbWUgU3BlY2lmaWNhdGlvbj4gPSA8 QWJzb2x1dGUgVGltZSBTcGVjaWZpY2F0aW9uPiB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgIDxSZWxhdGl2ZSBUaW1lIFNwZWNpZmljYXRpb24+DQoN CiAgIHdoZXJlIHRoZSA8QWJzb2x1dGUgVGltZSBTcGVjaWZpY2F0aW9uPiBk ZWZpbmVzIGEgdGltZSBwZXJpb2QgYnkNCiAgIGJ5IHNwZWNpZnlpbmcgaXRz IHN0YXJ0aW5nIGFuZCBlbmRpbmcgdGltZSBwb2ludHMgd2hlcmVhcyB0aGUN CiAgIDxSZWxhdGl2ZSBUaW1lIFNwZWNpZmljYXRpb24+IHNwZWNpZmllcyBv bmx5IHRoZSBsZW5ndGggb2YgYSB0aW1lDQogICBwZXJpb2QuIE5vdGUgdGhh dCB0aGUgZm9ybWF0IG9mIGFsbCB0aGUgYWRkaXRpb25hbCBwYXJhbWV0ZXJz DQogICBmb2xsb3dzIHRoZSBvbmUgZGVmaW5lZCBpbiBbTlNJUy1RU1BFQ10u DQoNCjUuMS4xIDxFZ3Jlc3MgSUQ+IHBhcmFtZXRlcg0KICAgDQogICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgIHwwfEV8TnxUfCAgICAgIFBhcmFtZXRl ciBJRCAgICAgfCBJUC1WZXJ8ICAgICAgICBMZW5ndGggICAgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgLy8gICAgICAgICAgICAgICAg ICAgICBJbnRlcmZhY2UgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAg Ly8NCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNClpoYW5nLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMDYsIDIwMDYgICAgICAgICAg ICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJ bnRlckRvbWFpbi1RT1NNICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNg0K DQogICBUaGUgZmllbGQgSW50ZXJmYWNlIEFkZHJlc3Mgc3BlY2lmaWVzIHRo ZSBJUCBpbnRlcmZhY2Ugb2YgdGhlIGVncmVzcw0KICAgbm9kZSB0byB3aGlj aCB0aGUgc2lnbmFsZWQgdHJhZmZpYyBzdHJlYW0gaXMgYXNzaWduZWQuIEFs bCBvdGhlcg0KICAgZmllbGRzIHRoYW4gdGhlIEludGVyZmFjZSBBZGRyZXNz IHJlbWFpbiB0aGUgc2FtZSBtZWFuaW5ncyBhcw0KICAgZGVmaW5lZCBpbiBb TlNJUy1RU1BFQ10uIA0KDQo1LjEuMiA8SW5ncmVzcyBJRD4gcGFyYW1ldGVy DQogICANCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfDB8RXxOfFR8 ICAgICAgUGFyYW1ldGVyIElEICAgICB8IElQLVZlcnwgICAgICAgIExlbmd0 aCAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAvLyA5TTFAgZm9y IHNpZ25hbGluZyBleGNoYW5nZXMgd2l0aA0KICAgICAgb3RoZXIgUU5FcyBh bmQgZGVwZW5kcyBvbiB0aGUgTlRMUCB0byBkaXNjb3ZlciB0aGUgcGVlcg0K ICAgICAgaW50ZXItZG9tYWluIGNvbnRyb2wgYWdlbnRzIGF0IHRoZSBhZGph Y2VudCBkb21haW5zLg0KICAgDQogICBvICBUaGUgSW50ZXJEb21haW4tUU9T TSBtYWtlcyBubyBhc3N1bXB0aW9ucyBhYm91dCB0aGUgaW1wbGVtZW50YXRp b24NCiAgICAgIG1lY2hhbmlzbXMgb2YgaW50cmEtZG9tYWluIGNvbnRyb2wg YWdlbnQuIFRoYXQgaXMgdG8gc2F5IHRoYXQgdGhlDQogICAgICBpbnRyYS1k b21haW4gY29udHJvbCBhZ2VudCBtaWdodCBiZSBjZW50cmFsaXplZCBvciBk aXN0cmlidXRlZCwgDQogICAgICBOU0lTIGJhc2VkIG9yIG5vbi1OU0lTIGJh c2VkLg0KDQogICBvICBUaGUgSW50ZXJEb21haW4tUU9TTSBtYWtlcyBubyBh c3N1bXB0aW9uIGFib3V0IHRoZSBtZXRob2QgdGhhdCB0aGUNCiAgICAgIHVu ZGVybHlpbmcgTlRMUCBtaWdodCB1c2UgdG8gZGlzY292ZXIgdGhlIHBlZXIg aW50ZXItZG9tYWluDQogICAgICBjb250cm9sIGFnZW50cyBhdCBhZGphY2Vu dCBkb21haW5zLg0KDQo1LiBJbnRlckRvbWFpbi1RT1NNLCBEZXRhaWxlZCBE ZXNjcmlwdGlvbg0KDQo1LjEgQWRkaXRpb25hbCBRU1BFQyBQYXJhbWV0ZXJz IGZvciBJbnRlckRvbWFpbi1RT1NNDQoNCiAgIEZpcnN0IG9mIGFsbCwgdHdv IG5ldyBRb1MgY29udHJvbCBwYXJhbWV0ZXJzIDxFZ3Jlc3MgSUQ+IGFuZCAN CiAgIDxJbmdyZXNzIElEPiBuZWVkIHRvIGJlIGFkZGVkIHRvIHRoZSBRU1BF QyBDb250cm9sIEluZm9ybWF0aW9uIG9mDQogICB0aGUgSW50ZXJEb21haW4t UU9TTSwgd2hpY2ggZGVzY3JpYmVzIHRoZSBJUCBpbnRlcmZhY2VzIG9mIHRo ZSANCiAgIGVncmVzcyBhbmQgaW5ncmVzcyBub2RlcyB0byB3aGljaCB0aGUg c2lnbmFsZWQgdHJhZmZpYyBzdHJlYW0gaXMNCiAgIGFzc2lnbmVkIHJlc3Bl Y3RpdmVseS4NCiAgIA0KICAgU2Vjb25kbHksIHRvIGRlc2NyaWJlIHRoZSB0 aW1lIHBlcmlvZHMgb3ZlciB3aGljaCBhIFNMUyB3aWxsIGJlDQogICBhdmFp bGFibGUgb3IgcmVxdWVzdGVkLCB0aGUgZm9sbG93aW5nIDxUaW1lIFNwZWNp ZmljYXRpb24+IHBhcmFtZXRlcnMNCiAgIGFyZSBhZGRlZCB0byB0aGUgPFFv UyBEZXNpcmVkPiwgPFFvUyBBdmFpbGFibGU+LCA8UW9TIFJlc2VydmVkPg0K ICAgYW5kIDxNaW5pbXVtIFFvUz4gUVNQRUMgb2JqZWN0cyBvZiB0aGUgSW50 ZXJEb21haW4tUU9TTToNCg0KICAgPFRpbWUgU3BlY2lmaWNhdGlvbj4gPSA8 QWJzb2x1dGUgVGltZSBTcGVjaWZpY2F0aW9uPiB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgIDxSZWxhdGl2ZSBUaW1lIFNwZWNpZmljYXRpb24+DQoN CiAgIHdoZXJlIHRoZSA8QWJzb2x1dGUgVGltZSBTcGVjaWZpY2F0aW9uPiBk ZWZpbmVzIGEgdGltZSBwZXJpb2QgYnkNCiAgIGJ5IHNwZWNpZnlpbmcgaXRz IHN0YXJ0aW5nIGFuZCBlbmRpbmcgdGltZSBwb2ludHMgd2hlcmVhcyB0aGUN CiAgIDxSZWxhdGl2ZSBUaW1lIFNwZWNpZmljYXRpb24+IHNwZWNpZmllcyBv bmx5IHRoZSBsZW5ndGggb2YgYSB0aW1lDQogICBwZXJpb2QuIE5vdGUgdGhh dCB0aGUgZm9ybWF0IG9mIGFsbCB0aGUgYWRkaXRpb25hbCBwYXJhbWV0ZXJz DQogICBmb2xsb3dzIHRoZSBvbmUgZGVmaW5lZCBpbiBbTlNJUy1RU1BFQ10u DQoNCjUuMS4xIDxFZ3Jlc3MgSUQ+IHBhcmFtZXRlcg0KICAgDQogICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgIHwwfEV8TnxUfCAgICAgIFBhcmFtZXRl ciBJRCAgICAgfCBJUC1WZXJ8ICAgICAgICBMZW5ndGggICAgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgLy8gICAgICAgICAgICAgICAg ICAgICBJbnRlcmZhY2UgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAg Ly8NCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNClpoYW5nLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMDYsIDIwMDYgICAgICAgICAg ICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJ bnRlckRvbWFpbi1RT1NNICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNg0K DQogICBUaGUgZmllbGQgSW50ZXJmYWNlIEFkZHJlc3Mgc3BlY2lmaWVzIHRo ZSBJUCBpbnRlcmZhY2Ugb2YgdGhlIGVncmVzcw0KICAgbm9kZSB0byB3aGlj aCB0aGUgc2lnbmFsZWQgdHJhZmZpYyBzdHJlYW0gaXMgYXNzaWduZWQuIEFs bCBvdGhlcg0KICAgZmllbGRzIHRoYW4gdGhlIEludGVyZmFjZSBBZGRyZXNz IHJlbWFpbiB0aGUgc2FtZSBtZWFuaW5ncyBhcw0KICAgZGVmaW5lZCBpbiBb TlNJUy1RU1BFQ10uIA0KDQo1LjEuMiA8SW5ncmVzcyBJRD4gcGFyYW1ldGVy DQogICANCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfDB8RXxOfFR8 ICAgICAgUGFyYW1ldGVyIElEICAgICB8IElQLVZlcnwgICAgICAgIExlbmd0 aCAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAvLyAg ICAgICAgICAgICAgICAgICAgIEludGVyZmFjZSBBZGRyZXNzICAgICAgICAg ICAgICAgICAgICAgICAvLw0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0K ICAgVGhlIGZpZWxkIEludGVyZmFjZSBBZGRyZXNzIHNwZWNpZmllcyB0aGUg SVAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNzDQogICBub2RlIHRvIHdoaWNo IHRoZSBzaWduYWxlZCB0cmFmZmljIHN0cmVhbSBpcyBhc3NpZ25lZC4gQWxs IG90aGVyDQogICBmaWVsZHMgdGhhbiB0aGUgSW50ZXJmYWNlIEFkZHJlc3Mg cmVtYWluIHRoZSBzYW1lIG1lYW5pbmdzIGFzDQogICBkZWZpbmVkIGluIFtO U0lTLVFTUEVDXS4NCg0KNS4xLjMgPEFic29sdXRlIFRpbWUgU3BlY2lmaWNh dGlvbj4gcGFyYW1ldGVyDQoNCiAgICAwICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgfDB8RXxOfFR8ICAgICBQYXJhbWV0ZXIgSUQgICAgICB8cnxyfHJ8cnwg ICAgICAgICAgMiAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8ICBTdGFydGluZyBQb2ludCAgKDMyLWJpdCBpbnRlZ2VyKSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgIHwgIEVuZGluZyBQb2ludCAgICgzMi1iaXQgaW50ZWdl cikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICBUaGUgZmllbGRzIFN0YXJ0aW5nIFBvaW50 IGFuZCBFbmRpbmcgUG9pbnQgc3BlY2lmeSB0aGUgYWJzb2x1dGUgdGltZQ0K ICAgdmFsdWVzIG9mIHRoZSBzdGFydGluZyBhbmQgZW5kaW5nIHBvaW50cyBv ZiBhIHRpbWUgcGVyaW9kDQogICByZXNwZWN0aXZlbHkuIFRoZSBmb3JtYXQg b2YgdGhlIGFic29sdXRlIHRpbWUgdmFsdWVzIGZvbGxvdyB0aGUgb25lDQog ICBkZWZpbmVkIGJ5IHRoZSBJRVRGIE5ldHdvcmsgVGltZSBQcm90b2NvbC4g Qm90aCBvZiB0aGVtIG11c3QgYmUgDQogICBub25uZWdhdGl2ZSBhbmQgYXJl IG1lYXN1cmVkIGluIG1pY3Jvc2Vjb25kcy4gTm93IHRoZXkgYXJlDQogICBy ZXByZXNlbnRlZCBhcyBhIDMyLWJpdCBpbnRlZ2VyIGFuZCBjYW4gYmUgY2hh bmdlZCBhZnRlcndhcmRzIGlmDQogICBuZWNlc3NhcnkuIEFsbCBvdGhlciBm aWVsZHMgdGhhbiB0aGUgU3RhcnRpbmcgUG9pbnQgYW5kIEVuZGluZyBQb2lu dA0KICAgcmVtYWluIHRoZSBzYW1lIG1lYW5pbmdzIGFzIGRlZmluZWQgaW4g W05TSVMtUVNQRUNdLg0KDQo1LjEuNCA8UmVsYXRpdmUgVGltZSBTcGVjaWZp Y2F0aW9uPiBwYXJhbWV0ZXINCg0KICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICB8MHxFfE58VHwgICAgIFBhcmFtZXRlciBJRCAgICAgIHxyfHJ8cnxy fCAgICAgICAgICAxICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHwgIEFjdGl2ZSBEdXJhdGlvbiAgKDMyLWJpdCBpbnRlZ2Vy KSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgDQpaaGFuZywgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDA2LCAyMDA2ICAgICAgICAgICAgIFtQYWdlIDEx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgSW50ZXJEb21haW4t UU9TTSAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDYNCiAgICANCiAgIFRo ZSBmaWVsZCBBY3RpdmUgRHVyYXRpb24gc3BlY2lmaWVzIHRoZSBsZW5ndGgg b2YgYSB0aW1lIHBlcmlvZA0KICAgZHVyaW5nIHdoaWNoIGEgU0xTIGRlc2Ny aWJlZCBieSBvdGhlciBRU1BFQyBwYXJhbWV0ZXJzIHdpbGwgYmUgDQogICBh dmFpbGFibGUgb3IgbmVlZCB0byBiZSBhY3RpdmF0ZWQuIEl0IG11c3QgYWxz byBiZSBub25uZWdhdGl2ZSBhbmQNCiAgIGlzIG1lYXN1cmVkIGluIG1pY3Jv c2Vjb25kcy4gTm93IGl0IGlzIHJlcHJlc2VudGVkIGFzIGEgMzItYml0DQog ICBpbnRlZ2VyIGFuZCBjYW4gYmUgY2hhbmdlZCBhZnRlcndhcmRzIGlmIG5l Y2Vzc2FyeS4gQWxsIG90aGVyIGZpZWxkcw0KICAgdGhhbiB0aGUgQWN0aXZl IER1cmF0aW9uIHJlbWFpbiB0aGUgc2FtZSBtZWFuaW5ncyBhcyBkZWZpbmVk IGluDQogICBbTlNJUy1RU1BFQ10uDQoNCjUuMiBJbGx1c3RyYXRpb25zIG9m IEludGVyLWRvbWFpbiBTaWduYWxpbmcgSW50ZXJhY3Rpb25zDQoNCiAgIFNl dmVyYWwgaW50ZXItZG9tYWluIGludGVyYWN0aW9uIHNjZW5hcmlvcyBhcmUg aWxsdXN0cmF0ZWQgaGVyZSB0bw0KICAgc2hvdyBob3cgdGhlIEludGVyRG9t YWluLVFPU00gb3BlcmF0ZXMgYXQgdHlwaWNhbCBpbnRlci1kb21haW4gDQog ICBpbnRlcmFjdGlvbiBzY2VuYXJpb3MuIE5vdGUgdGhhdCB0aGUgcHVycG9z ZSBvZiB0aGlzIGlsbHVzdHJhdGlvbnMgaXMNCiAgIG5vdCB0aGUgZW51bWVy YXRpb24g ICAgICAgICAgICAgICAgICAgIEludGVyZmFjZSBBZGRyZXNzICAgICAgICAg ICAgICAgICAgICAgICAvLw0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0K ICAgVGhlIGZpZWxkIEludGVyZmFjZSBBZGRyZXNzIHNwZWNpZmllcyB0aGUg SVAgaW50ZXJmYWNlIG9mIHRoZSBpbmdyZXNzDQogICBub2RlIHRvIHdoaWNo IHRoZSBzaWduYWxlZCB0cmFmZmljIHN0cmVhbSBpcyBhc3NpZ25lZC4gQWxs IG90aGVyDQogICBmaWVsZHMgdGhhbiB0aGUgSW50ZXJmYWNlIEFkZHJlc3Mg cmVtYWluIHRoZSBzYW1lIG1lYW5pbmdzIGFzDQogICBkZWZpbmVkIGluIFtO U0lTLVFTUEVDXS4NCg0KNS4xLjMgPEFic29sdXRlIFRpbWUgU3BlY2lmaWNh dGlvbj4gcGFyYW1ldGVyDQoNCiAgICAwICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgfDB8RXxOfFR8ICAgICBQYXJhbWV0ZXIgSUQgICAgICB8cnxyfHJ8cnwg ICAgICAgICAgMiAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8ICBTdGFydGluZyBQb2ludCAgKDMyLWJpdCBpbnRlZ2VyKSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgIHwgIEVuZGluZyBQb2ludCAgICgzMi1iaXQgaW50ZWdl cikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICBUaGUgZmllbGRzIFN0YXJ0aW5nIFBvaW50 IGFuZCBFbmRpbmcgUG9pbnQgc3BlY2lmeSB0aGUgYWJzb2x1dGUgdGltZQ0K ICAgdmFsdWVzIG9mIHRoZSBzdGFydGluZyBhbmQgZW5kaW5nIHBvaW50cyBv ZiBhIHRpbWUgcGVyaW9kDQogICByZXNwZWN0aXZlbHkuIFRoZSBmb3JtYXQg b2YgdGhlIGFic29sdXRlIHRpbWUgdmFsdWVzIGZvbGxvdyB0aGUgb25lDQog ICBkZWZpbmVkIGJ5IHRoZSBJRVRGIE5ldHdvcmsgVGltZSBQcm90b2NvbC4g Qm90aCBvZiB0aGVtIG11c3QgYmUgDQogICBub25uZWdhdGl2ZSBhbmQgYXJl IG1lYXN1cmVkIGluIG1pY3Jvc2Vjb25kcy4gTm93IHRoZXkgYXJlDQogICBy ZXByZXNlbnRlZCBhcyBhIDMyLWJpdCBpbnRlZ2VyIGFuZCBjYW4gYmUgY2hh bmdlZCBhZnRlcndhcmRzIGlmDQogICBuZWNlc3NhcnkuIEFsbCBvdGhlciBm aWVsZHMgdGhhbiB0aGUgU3RhcnRpbmcgUG9pbnQgYW5kIEVuZGluZyBQb2lu dA0KICAgcmVtYWluIHRoZSBzYW1lIG1lYW5pbmdzIGFzIGRlZmluZWQgaW4g W05TSVMtUVNQRUNdLg0KDQo1LjEuNCA8UmVsYXRpdmUgVGltZSBTcGVjaWZp Y2F0aW9uPiBwYXJhbWV0ZXINCg0KICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICB8MHxFfE58VHwgICAgIFBhcmFtZXRlciBJRCAgICAgIHxyfHJ8cnxy fCAgICAgICAgICAxICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHwgIEFjdGl2ZSBEdXJhdGlvbiAgKDMyLWJpdCBpbnRlZ2Vy KSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgDQpaaGFuZywgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDA2LCAyMDA2ICAgICAgICAgICAgIFtQYWdlIDEx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgSW50ZXJEb21haW4t UU9TTSAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDYNCiAgICANCiAgIFRo ZSBmaWVsZCBBY3RpdmUgRHVyYXRpb24gc3BlY2lmaWVzIHRoZSBsZW5ndGgg b2YgYSB0aW1lIHBlcmlvZA0KICAgZHVyaW5nIHdoaWNoIGEgU0xTIGRlc2Ny aWJlZCBieSBvdGhlciBRU1BFQyBwYXJhbWV0ZXJzIHdpbGwgYmUgDQogICBh dmFpbGFibGUgb3IgbmVlZCB0byBiZSBhY3RpdmF0ZWQuIEl0IG11c3QgYWxz byBiZSBub25uZWdhdGl2ZSBhbmQNCiAgIGlzIG1lYXN1cmVkIGluIG1pY3Jv c2Vjb25kcy4gTm93IGl0IGlzIHJlcHJlc2VudGVkIGFzIGEgMzItYml0DQog ICBpbnRlZ2VyIGFuZCBjYW4gYmUgY2hhbmdlZCBhZnRlcndhcmRzIGlmIG5l Y2Vzc2FyeS4gQWxsIG90aGVyIGZpZWxkcw0KICAgdGhhbiB0aGUgQWN0aXZl IER1cmF0aW9uIHJlbWFpbiB0aGUgc2FtZSBtZWFuaW5ncyBhcyBkZWZpbmVk IGluDQogICBbTlNJUy1RU1BFQ10uDQoNCjUuMiBJbGx1c3RyYXRpb25zIG9m IEludGVyLWRvbWFpbiBTaWduYWxpbmcgSW50ZXJhY3Rpb25zDQoNCiAgIFNl dmVyYWwgaW50ZXItZG9tYWluIGludGVyYWN0aW9uIHNjZW5hcmlvcyBhcmUg aWxsdXN0cmF0ZWQgaGVyZSB0bw0KICAgc2hvdyBob3cgdGhlIEludGVyRG9t YWluLVFPU00gb3BlcmF0ZXMgYXQgdHlwaWNhbCBpbnRlci1kb21haW4gDQog ICBpbnRlcmFjdGlvbiBzY2VuYXJpb3MuIE5vdGUgdGhhdCB0aGUgcHVycG9z ZSBvZiB0aGlzIGlsbHVzdHJhdGlvbnMgaXMNCiAgIG5vdCB0aGUgZW51bWVy YXRpb24gb2YgYWxsIHBvc3NpYmxlIHNjZW5hcmlvcywgaW5zdGVhZCBpdCBh aW1zIGF0DQogICBkZW1vbnN0cmF0aW5nIHRoZSBvcGVyYXRpb24gbW9kZWwg b2YgdGhlIEludGVyRG9tYWluLVFPU00gaW4gc2VjdGlvbg0KICAgNC4xIGJ5 IHVzaW5nIHNvbWUgdHlwaWNhbCBpbnRyYS1kb21haW4gUU9TTXMgYXQgYWRq YWNlbnQgZG9tYWlucy4NCiAgIE5vdGUgdGhhdCB0aHJvdWdob3V0IHRoaXMg c2VjdGlvbiwgd2UgYXNzdW1lIHRoYXQgZG9tYWluIEIgaXMgdGhlDQogICBu ZXh0IGRvbWFpbiBvZiBkb21haW4gQSBhbG9uZyB0aGUgZGlyZWN0aW9uIHRv d2FyZHMgdGhlIGZsb3cNCiAgIGRlc3RpbmF0aW9uIGFuZCBmb3IgdGhlIGNh c2UgdGhhdCB0aGUgbm9uLU5TSVMgYmFzZWQgUU9TTSBpcyBkZXBsb3llZA0K ICAgYXQgYSBkb21haW4sIHdlIGN1cnJlbnRseSBhc3N1bWUgdGhhdCBhIGRv bWFpbi13aWRlIGNlbnRyYWxpemVkIA0KICAgaW50cmEtZG9tYWluIGNvbnRy b2wgYWdlbnQgZXhpc3QgYXQgdGhlIGRvbWFpbiBhbmQgdGhlIGludGVyLWRv bWFpbg0KICAgYW5kIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50cyBhdCBk b21haW4gQiB3aWxsIHJlc2lkZSB0b2dldGhlciBhbmQNCiAgIGludGVyYWN0 IHdpdGggZWFjaCBvdGhlciB2aWEgYSBzZXQgb2Ygc3RhbmRhcmRpemVkIEFQ SXMgKHRoZSBBUElzDQogICB3aWxsIGJlIGRlZmluZWQgYmFzZWQgb24gZnVy dGhlciBkaXNjdXNzaW9ucykuDQoNCjUuMi4xIEludGVyLWRvbWFpbiBzaWdu YWxpbmcgZm9yIHRoZSBjYXNlIHRoYXQgUk1ELVFPU00gYXQgZG9tYWluIEEg YW5kDQogICAgICBZLjE1NDEtUU9TTSBhdCBkb21haW4gQg0KICAgIA0KICAg V2hlbiBhbiBlZ3Jlc3Mgbm9kZSBhdCBkb21haW4gQSByZWNlaXZlIGEgbG9j YWwgUkVTRVJWRSBtZXNzYWdlIHdoaWNoDQogICBpbmRpY2F0ZXMgdGhlIHN1 Y2Nlc3NmdWwgcmVzZXJ2YXRpb24gYXQgdGhpcyBkb21haW4sIGl0IHNob3Vs ZA0KICAgY29uc3RydWN0IGEgSW50ZXJEb21haW4tUU9TTSBRU1BFQyBiYXNl ZCBvbiB0aGUgSW5pdGlhdG9yIFFTUEVDLiANCiAgIFNwZWNpZmljYWxseSwg dGhlIEludGVyRG9tYWluLVFPU00gUVNQRUMgY29udGFpbnMgYWxsIHRoZSBR U1BFQw0KICAgcGFyYW1ldGVycyBhdCB0aGUgSW5pdGlhdG9yIFFTUEVDIGFz IHdlbGwgYXMgdGhlIG5ldyBwYXJhbWV0ZXINCiAgIDxFZ3Jlc3MgSUQ+IHRo YXQgY29udGFpbnMgdGhlIElQIGludGVyZmFjZSBvZiB0aGUgZWdyZXNzIG5v ZGUgYW5kIHRoZQ0KICAgbmV3IHBhcmFtZXRlciA8SW5ncmVzcyBJRD4gdGhh dCBjb250YWlucyB0aGUgSVAgaW50ZXJmYWNlIG9mIHRoZSANCiAgIGluZ3Jl c3Mgbm9kZSBvZiBkb21haW4gQiB0byB3aGljaCB0aGUgc2lnbmFsZWQgdHJh ZmZpYyBmbG93IGlzIA0KICAgYXNzaWduZWQuIFRoZW4sIHRoZSBlZ3Jlc3Mg bm9kZSBzZW5kcyBhIG5ldyBSRVNFUlZFIG1lc3NhZ2Ugd2l0aCB0aGlzDQog ICBJbnRlckRvbWFpbi1RT1NNIFFTUEVDIHRvIHRoZSB3ZWxsLWtub3duIGlu dGVyLWRvbWFpbiBjb250cm9sIGFnZW50IA0KICAgYXQgaXRzIGRvbWFpbiwg d2hpY2ggd2lsbCBjaGVjayB0aGUgcmVxdWVzdGVkIFNMUyBwYXJhbWV0ZXJz IGFnYWluc3QNCiAgIHRoZSBwU0xTIGJldHdlZW4gdGhlIGVncmVzcyBub2Rl IG9mIGRvbWFpbiBBIGFuZCB0aGUgaW5ncmVzcyBub2RlIG9mDQogICBkb21h aW4gQi4gSW4gY2FzZSBvZiBwb3NpdGl2ZSBkZWNpc2lvbiwgaXQgd2lsbCBt YWludGFpbiB0aGUgSVANCiAgIGludGVyZmFjZXMgb2YgdGhlIGVncmVzcyBh bmQgaW5ncmVzcyBub2RlcyBhc3NpZ25lZCB0byB0aGlzIGZsb3cgYW5kDQog ICB0aGVuIGZvcndhcmQgdGhlIFJFU0VSVkUgbWVzc2FnZSB0byBpdHMgcGVl ciBhdCBkb21haW4gQi4NCiAgDQogICBXaGVuIHRoZSBpbnRlci1kb21haW4g Y29udHJvbCBhZ2VudCBhdCBkb21haW4gQiByZWNlaXZlcyBhIFJFU0VSVkUN CiAgIG1lc3NhZ2UgZnJvbSBpdHMgcGVlciwgaXQgd2lsbCB0YWtlIHRoZSBz YW1lIGFjdGlvbnMgZGVmaW5lZCBieSB0aGUgDQogICBvcGVyYXRpb24gbW9k ZWwgb2YgSW50ZXJEb21haW4tUU9TTSBpbiBzZWN0aW9uIDQuMS4gSW4gY2Fz ZSB0aGF0IGFsbA0KICAgdGhlIGRlY2lzaW9ucyBoYXZlIHBvc2l0aXZlIG91 dHB1dHMsIHRoZSBpbnRlci1kb21haW4gY29udHJvbCBhZ2VudA0KICAgbmVl ZCBhbHNvIG1haW50YWluIHRoZSBJUCBpbnRlcmZhY2VzIG9mIHRoZSBlZ3Jl c3MgYW5kIGluZ3Jlc3Mgbm9kZXMNCiAgIGFzc2lnbmVkIHRvIHRoZSBRb1Mg cmVxdWVzdCwgdGhlbiBtb2RpZmllcyB0aGUgcmVjZWl2ZWQgUkVTRVJWRQ0K ICAgbWVzc2FnZSAocmVtb3ZlIHRoZSA8ZWdyZXNzIElEPiBhbmQgPGluZ3Jl c3MgSUQ+IHBhcmFtZXRlcnMpIGFuZCBzZW5kDQogICB0aGUgbW9kaWZpZWQg UkVTRVJWRSBtZXNzYWdlIHRvIHRoZSBleHRyYWN0ZWQgaW5ncmVzcyBub2Rl IGF0IGRvbWFpbg0KICAgQi4NCg0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICBbUGFnZSAx Ml0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWlu LVFPU00gICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2DQoNCiAgIE5leHQs IHRoZSBRb1Mgc2lnbmFsaW5nIG9wZXJhdGlvbnMgYXQgZG9tYWluIEIgd2ls bCBiZSBwcm9jZWVkZWQgaW4gDQogICB0aGUgc2FtZSB3YXkgYXMgZGVzY3Jp YmVkIGluIFtZLjE1NDEtUU9TTV0uIEZvciB0aGUgY2FzZSB0aGF0IGRvbWFp bg0KICAgQiBpcyB0aGUgc2luayBkb21haW4sIHRoZW4gb25lIFFOUiBhdCBk b21haW4gQiB3aWxsIGNyZWF0ZSBhIFJFU1BPTlNFDQogICBtZXNzYWdlIHRv IGluZGljYXRlIHRoZSByZXNlcnZhdGlvbiByZXN1bHQuIFdoZW4gdGhlIFJF U1BPTlNFIG1lc3NhZ2UNCiAgIHJlYWNoZXMgdGhlIGFib3ZlIGluZ3Jlc3Mg bm9kZSwgaXQgd2lsbCBiZSBmb3J3YXJkZWQgdG8gdGhlIA0KICAgaW50ZXIt ZG9tYWluIGNvbnRygb2YgYWxsIHBvc3NpYmxlIHNjZW5hcmlvcywgaW5zdGVhZCBpdCBh aW1zIGF0DQogICBkZW1vbnN0cmF0aW5nIHRoZSBvcGVyYXRpb24gbW9kZWwg b2YgdGhlIEludGVyRG9tYWluLVFPU00gaW4gc2VjdGlvbg0KICAgNC4xIGJ5 IHVzaW5nIHNvbWUgdHlwaWNhbCBpbnRyYS1kb21haW4gUU9TTXMgYXQgYWRq YWNlbnQgZG9tYWlucy4NCiAgIE5vdGUgdGhhdCB0aHJvdWdob3V0IHRoaXMg c2VjdGlvbiwgd2UgYXNzdW1lIHRoYXQgZG9tYWluIEIgaXMgdGhlDQogICBu ZXh0IGRvbWFpbiBvZiBkb21haW4gQSBhbG9uZyB0aGUgZGlyZWN0aW9uIHRv d2FyZHMgdGhlIGZsb3cNCiAgIGRlc3RpbmF0aW9uIGFuZCBmb3IgdGhlIGNh c2UgdGhhdCB0aGUgbm9uLU5TSVMgYmFzZWQgUU9TTSBpcyBkZXBsb3llZA0K ICAgYXQgYSBkb21haW4sIHdlIGN1cnJlbnRseSBhc3N1bWUgdGhhdCBhIGRv bWFpbi13aWRlIGNlbnRyYWxpemVkIA0KICAgaW50cmEtZG9tYWluIGNvbnRy b2wgYWdlbnQgZXhpc3QgYXQgdGhlIGRvbWFpbiBhbmQgdGhlIGludGVyLWRv bWFpbg0KICAgYW5kIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50cyBhdCBk b21haW4gQiB3aWxsIHJlc2lkZSB0b2dldGhlciBhbmQNCiAgIGludGVyYWN0 IHdpdGggZWFjaCBvdGhlciB2aWEgYSBzZXQgb2Ygc3RhbmRhcmRpemVkIEFQ SXMgKHRoZSBBUElzDQogICB3aWxsIGJlIGRlZmluZWQgYmFzZWQgb24gZnVy dGhlciBkaXNjdXNzaW9ucykuDQoNCjUuMi4xIEludGVyLWRvbWFpbiBzaWdu YWxpbmcgZm9yIHRoZSBjYXNlIHRoYXQgUk1ELVFPU00gYXQgZG9tYWluIEEg YW5kDQogICAgICBZLjE1NDEtUU9TTSBhdCBkb21haW4gQg0KICAgIA0KICAg V2hlbiBhbiBlZ3Jlc3Mgbm9kZSBhdCBkb21haW4gQSByZWNlaXZlIGEgbG9j YWwgUkVTRVJWRSBtZXNzYWdlIHdoaWNoDQogICBpbmRpY2F0ZXMgdGhlIHN1 Y2Nlc3NmdWwgcmVzZXJ2YXRpb24gYXQgdGhpcyBkb21haW4sIGl0IHNob3Vs ZA0KICAgY29uc3RydWN0IGEgSW50ZXJEb21haW4tUU9TTSBRU1BFQyBiYXNl ZCBvbiB0aGUgSW5pdGlhdG9yIFFTUEVDLiANCiAgIFNwZWNpZmljYWxseSwg dGhlIEludGVyRG9tYWluLVFPU00gUVNQRUMgY29udGFpbnMgYWxsIHRoZSBR U1BFQw0KICAgcGFyYW1ldGVycyBhdCB0aGUgSW5pdGlhdG9yIFFTUEVDIGFz IHdlbGwgYXMgdGhlIG5ldyBwYXJhbWV0ZXINCiAgIDxFZ3Jlc3MgSUQ+IHRo YXQgY29udGFpbnMgdGhlIElQIGludGVyZmFjZSBvZiB0aGUgZWdyZXNzIG5v ZGUgYW5kIHRoZQ0KICAgbmV3IHBhcmFtZXRlciA8SW5ncmVzcyBJRD4gdGhh dCBjb250YWlucyB0aGUgSVAgaW50ZXJmYWNlIG9mIHRoZSANCiAgIGluZ3Jl c3Mgbm9kZSBvZiBkb21haW4gQiB0byB3aGljaCB0aGUgc2lnbmFsZWQgdHJh ZmZpYyBmbG93IGlzIA0KICAgYXNzaWduZWQuIFRoZW4sIHRoZSBlZ3Jlc3Mg bm9kZSBzZW5kcyBhIG5ldyBSRVNFUlZFIG1lc3NhZ2Ugd2l0aCB0aGlzDQog ICBJbnRlckRvbWFpbi1RT1NNIFFTUEVDIHRvIHRoZSB3ZWxsLWtub3duIGlu dGVyLWRvbWFpbiBjb250cm9sIGFnZW50IA0KICAgYXQgaXRzIGRvbWFpbiwg d2hpY2ggd2lsbCBjaGVjayB0aGUgcmVxdWVzdGVkIFNMUyBwYXJhbWV0ZXJz IGFnYWluc3QNCiAgIHRoZSBwU0xTIGJldHdlZW4gdGhlIGVncmVzcyBub2Rl IG9mIGRvbWFpbiBBIGFuZCB0aGUgaW5ncmVzcyBub2RlIG9mDQogICBkb21h aW4gQi4gSW4gY2FzZSBvZiBwb3NpdGl2ZSBkZWNpc2lvbiwgaXQgd2lsbCBt YWludGFpbiB0aGUgSVANCiAgIGludGVyZmFjZXMgb2YgdGhlIGVncmVzcyBh bmQgaW5ncmVzcyBub2RlcyBhc3NpZ25lZCB0byB0aGlzIGZsb3cgYW5kDQog ICB0aGVuIGZvcndhcmQgdGhlIFJFU0VSVkUgbWVzc2FnZSB0byBpdHMgcGVl ciBhdCBkb21haW4gQi4NCiAgDQogICBXaGVuIHRoZSBpbnRlci1kb21haW4g Y29udHJvbCBhZ2VudCBhdCBkb21haW4gQiByZWNlaXZlcyBhIFJFU0VSVkUN CiAgIG1lc3NhZ2UgZnJvbSBpdHMgcGVlciwgaXQgd2lsbCB0YWtlIHRoZSBz YW1lIGFjdGlvbnMgZGVmaW5lZCBieSB0aGUgDQogICBvcGVyYXRpb24gbW9k ZWwgb2YgSW50ZXJEb21haW4tUU9TTSBpbiBzZWN0aW9uIDQuMS4gSW4gY2Fz ZSB0aGF0IGFsbA0KICAgdGhlIGRlY2lzaW9ucyBoYXZlIHBvc2l0aXZlIG91 dHB1dHMsIHRoZSBpbnRlci1kb21haW4gY29udHJvbCBhZ2VudA0KICAgbmVl ZCBhbHNvIG1haW50YWluIHRoZSBJUCBpbnRlcmZhY2VzIG9mIHRoZSBlZ3Jl c3MgYW5kIGluZ3Jlc3Mgbm9kZXMNCiAgIGFzc2lnbmVkIHRvIHRoZSBRb1Mg cmVxdWVzdCwgdGhlbiBtb2RpZmllcyB0aGUgcmVjZWl2ZWQgUkVTRVJWRQ0K ICAgbWVzc2FnZSAocmVtb3ZlIHRoZSA8ZWdyZXNzIElEPiBhbmQgPGluZ3Jl c3MgSUQ+IHBhcmFtZXRlcnMpIGFuZCBzZW5kDQogICB0aGUgbW9kaWZpZWQg UkVTRVJWRSBtZXNzYWdlIHRvIHRoZSBleHRyYWN0ZWQgaW5ncmVzcyBub2Rl IGF0IGRvbWFpbg0KICAgQi4NCg0KWmhhbmcsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAgICAgICAgICAgICBbUGFnZSAx Ml0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEludGVyRG9tYWlu LVFPU00gICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2DQoNCiAgIE5leHQs IHRoZSBRb1Mgc2lnbmFsaW5nIG9wZXJhdGlvbnMgYXQgZG9tYWluIEIgd2ls bCBiZSBwcm9jZWVkZWQgaW4gDQogICB0aGUgc2FtZSB3YXkgYXMgZGVzY3Jp YmVkIGluIFtZLjE1NDEtUU9TTV0uIEZvciB0aGUgY2FzZSB0aGF0IGRvbWFp bg0KICAgQiBpcyB0aGUgc2luayBkb21haW4sIHRoZW4gb25lIFFOUiBhdCBk b21haW4gQiB3aWxsIGNyZWF0ZSBhIFJFU1BPTlNFDQogICBtZXNzYWdlIHRv IGluZGljYXRlIHRoZSByZXNlcnZhdGlvbiByZXN1bHQuIFdoZW4gdGhlIFJF U1BPTlNFIG1lc3NhZ2UNCiAgIHJlYWNoZXMgdGhlIGFib3ZlIGluZ3Jlc3Mg bm9kZSwgaXQgd2lsbCBiZSBmb3J3YXJkZWQgdG8gdGhlIA0KICAgaW50ZXIt ZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQgZG9tYWluIEIsIHdoaWNoIGNvbnRp bnVlcyBmb3J3YXJkaW5nDQogICB0aGUgUkVTUE9OU0UgdG8gaXRzIHBlZXIg YXQgZG9tYWluIEEuIFRoZW4sIHRoZSBpbnRlci1kb21haW4gY29udHJvbA0K ICAgYWdlbnQgYXQgZG9tYWluIEEgd2lsbCBzZW5kIHRoaXMgUkVTUE9OU0Ug bWVzc2FnZSB0byB0aGUgZWdyZXNzIG5vZGUNCiAgIGl0IGhhcyBtYWludGFp bmVkIGZvciB0aGUgc2lnbmFsZWQgZmxvdy4gQWZ0ZXIgdGhhdCwgdGhlIHBy b3BhZ2F0aW9uDQogICBvZiB0aGUgUkVTUE9OU0UgbWVzc2FnZSBhdCBkb21h aW4gQSB3aWxsIGZvbGxvdyB0aGUgc2FtZSBydWxlcyBhcyANCiAgIGRlZmlu ZWQgaW4gW1JNRC1RT1NNXS4NCg0KNS4yLjIgSW50ZXItZG9tYWluIHNpZ25h bGluZyBmb3IgdGhlIGNhc2UgdGhhdCBZLjE1NDEtUU9TTSBhdCBkb21haW4g QQ0KICAgICAgYW5kIFJNRC1RT1NNIGF0IGRvbWFpbiBCDQoNCiAgIFRoZSBz aWduYWxpbmcgZXhjaGFuZ2VzIHRha2VuIGZvciB0aGlzIGNhc2UgYXJlIHRo ZSBzYW1lIGFzIHRoZSBvbmVzDQogICBkZXNjcmliZWQgaW4gc2VjdGlvbiA1 LjIuMSBleGNlcHQgdGhhdCB0aGUgaW50cmEtZG9tYWluIHNpZ25hbGluZyAN CiAgIG9wZXJhdGlvbnMgZm9sbG93IGRpZmZlcmVudCBydWxlcyBhdCBkb21h aW4gQSBhbmQgQi4NCg0KNS4yLjMgSW50ZXItZG9tYWluIHNpZ25hbGluZyBm b3IgdGhlIGNhc2UgdGhhdCBSTUQtUU9TTSBhdCBkb21haW4gQSANCiAgICAg IGFuZCBub24tTlNJUyBiYXNlZCBRT1NNIGF0IGRvbWFpbiBCDQogICANCiAg IFRoZSBzaWduYWxpbmcgb3BlcmF0aW9ucyBhdCBkb21haW4gQSBhbmQgdGhl IGludGVyLWRvbWFpbiBzaWduYWxpbmcNCiAgIGludGVyYWN0aW9ucyBiZXR3 ZWVuIGRvbWFpbiBBIGFuZCBkb21haW4gQiB3aWxsIGJlIHRoZSBzYW1lIGFz DQogICBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjIuMS4gV2hlbiB0aGUgaW50 ZXItZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQNCiAgIGRvbWFpbiBCIHJlY2Vp dmVzIGEgUkVTRVJWRSBtZXNzYWdlIGZyb20gaXRzIHBlZXIsIGl0IHdpbGwg Y2Fycnkgb3V0DQogICB0aGUgc2FtZSBhY3Rpb25zIGRlZmluZWQgYnkgdGhl IG9wZXJhdGlvbiBtb2RlbCBvZiBJbnRlckRvbWFpbi1RT1NNDQogICBpbiBz ZWN0aW9uIDQuMS4gSW4gY2FzZSB0aGF0IGFsbCB0aGUgZGVjaXNpb25zIGhh dmUgcG9zaXRpdmUgb3V0cHV0cywNCiAgIHRoZSBpbnRlci1kb21haW4gY29u dHJvbCBhZ2VudCBuZWVkIGFsc28gbWFpbnRhaW4gdGhlIElQIGludGVyZmFj ZXMNCiAgIG9mIHRoZSBlZ3Jlc3MgYW5kIGluZ3Jlc3Mgbm9kZXMgYXNzaWdu ZWQgdG8gdGhlIFFvUyByZXF1ZXN0IGFuZCB0aGVuDQogICBzZW5kIHRoZSBl eHRyYWN0ZWQgU0xTIHBhcmFtZXRlcnMgYW5kIHRoZSBJUCBpbnRlcmZhY2Ug b2YgdGhlIGluZ3Jlc3MNCiAgIG5vZGUgdG8gdGhlIGludHJhLWRvbWFpbiBj b250cm9sIGFnZW50IHZpYSB0aGUgc3RhbmRhcmRpemVkIEFQSXMuDQogICBO ZXh0LCB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQgZG9tYWlu IEIgd2lsbCBhcHBseSBpdHMNCiAgIGludHJhLWRvbWFpbiBjb250cm9sIG1l Y2hhbmlzbXMgdG8gdGhlIFFvUyByZXF1ZXN0IGFuZCBtYWtlIHRoZSBRb1MN CiAgIHJlc2VydmF0aW9ucyBhY2NvcmRpbmdseS4NCiAgICANCiAgIEZvciB0 aGUgY2FzZSB0aGF0IGRvbWFpbiBCIGlzIHRoZSBzaW5rIGRvbWFpbiwgdGhl IGludHJhLWRvbWFpbg0KICAgY29udHJvbCBhZ2VudCB3aWxsIHNlbmQgaXRz IHJlc3BvbnNlIHRvIHRoZSBpbnRlci1kb21haW4gY29udHJvbCBhZ2VudA0K ICAgYWxzbyB2aWEgdGhlIHN0YW5kYXJkaXplZCBBUElzLiBUaGVuIHRoZSBp bnRlci1kb21haW4gY29udHJvbCBhZ2VudA0KICAgd2lsbCBjb25zdHJ1Y3Qg YSBSRVNQT05TRSBtZXNzYWdlIGJhc2VkIG9uIHRoZSByZWNlaXZlZCByZXNw b25zZSBhbmQNCiAgIHNlbmQgaXQgdG8gdGhlIGludGVyLWRvbWFpbiBjb250 cm9sIGFnZW50IGF0IGRvbWFpbiBBLCB3aGljaCB3aWxsDQogICBmb3J3YXJk IHRoaXMgUkVTUE9OU0UgbWVzc2FnZSB0byB0aGUgZWdyZXNzIG5vZGUgb2Yg ZG9tYWluIEEgaXQgaGFzDQogICBtYWludGFpbmVkIGZvciB0aGlzIGZsb3cu IEZyb20gdGhlbiBvbiwgdGhlIHByb3BhZ2F0aW9uIG9mIHRoZQ0KICAgUkVT UE9OU0UgbWVzc2FnZSBhdCBkb21haW4gQSB3aWxsIGZvbGxvdyB0aGUgcnVs ZXMgYXMgZGVmaW5lZCBpbiANCiAgIFtSTUQtUU9TTV0uDQoNCjUuMi40IElu dGVyLWRvbWFpbiBzaWduYWxpbmcgZm9yIHRoZSBjYXNlIHRoYXQgbm9uLU5T SVMgYmFzZWQgUU9TTSBhdA0KICAgICAgZG9tYWluIEEgYW5kIFJNRC1RT1NN IGF0IGRvbWFpbiBCDQoNClpoYW5nLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMDYsIDIwMDYgICAgICAgICAgICAgW1BhZ2UgMTNdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJbnRlckRvbWFpbi1RT1NN ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNg0KDQogICBXaGVuIHRoZSBp bnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBhdCBkb21haW4gQSBzdWNjZXNz ZnVsbHkgbWFrZXMNCiAgIHRoZSByZXNlcnZhdGlvbiBmb3IgYSB0cmFmZmlj IGZsb3csIGl0IHdpbGwgc2VuZCB0aGUgaW50ZXItZG9tYWluDQogICBjb250 cm9sIGFnZW50IHRoZSBTTFMgcGFyYW1ldGVycyBkZXNjcmliaW5nIHRoZSBR b1MgcmVxdWlyZW1lbnRzIG9mDQogICB0aGUgZmxvdyBhbmQgdGhlIElQIGlu dGVyZmFjZXMgb2YgdGhlIGVncmVzcyBub2RlIG9mIGRvbWFpbiBBIGFuZCB0 aGUNCiAgIGluZ3Jlc3Mgbm9kZSBvZiBkb21haW4gQiBhc3NpZ25lZCB0byB0 aGUgZmxvdyBieSBpbnZva2luZyB0aGUgDQogICBzdGFuZGFyZGl6ZWQgQVBJ cy4gTm90ZSB0aGF0IHdlIG1ha2Ugbm8gYXNzdW1wdGlvbnMgYWJvdXQgaG93 IHRoZSANCiAgIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGRvbWFp biBBIGNhbiBkaXNjb3ZlciB0ab2wgYWdlbnQgYXQgZG9tYWluIEIsIHdoaWNoIGNvbnRp bnVlcyBmb3J3YXJkaW5nDQogICB0aGUgUkVTUE9OU0UgdG8gaXRzIHBlZXIg YXQgZG9tYWluIEEuIFRoZW4sIHRoZSBpbnRlci1kb21haW4gY29udHJvbA0K ICAgYWdlbnQgYXQgZG9tYWluIEEgd2lsbCBzZW5kIHRoaXMgUkVTUE9OU0Ug bWVzc2FnZSB0byB0aGUgZWdyZXNzIG5vZGUNCiAgIGl0IGhhcyBtYWludGFp bmVkIGZvciB0aGUgc2lnbmFsZWQgZmxvdy4gQWZ0ZXIgdGhhdCwgdGhlIHBy b3BhZ2F0aW9uDQogICBvZiB0aGUgUkVTUE9OU0UgbWVzc2FnZSBhdCBkb21h aW4gQSB3aWxsIGZvbGxvdyB0aGUgc2FtZSBydWxlcyBhcyANCiAgIGRlZmlu ZWQgaW4gW1JNRC1RT1NNXS4NCg0KNS4yLjIgSW50ZXItZG9tYWluIHNpZ25h bGluZyBmb3IgdGhlIGNhc2UgdGhhdCBZLjE1NDEtUU9TTSBhdCBkb21haW4g QQ0KICAgICAgYW5kIFJNRC1RT1NNIGF0IGRvbWFpbiBCDQoNCiAgIFRoZSBz aWduYWxpbmcgZXhjaGFuZ2VzIHRha2VuIGZvciB0aGlzIGNhc2UgYXJlIHRo ZSBzYW1lIGFzIHRoZSBvbmVzDQogICBkZXNjcmliZWQgaW4gc2VjdGlvbiA1 LjIuMSBleGNlcHQgdGhhdCB0aGUgaW50cmEtZG9tYWluIHNpZ25hbGluZyAN CiAgIG9wZXJhdGlvbnMgZm9sbG93IGRpZmZlcmVudCBydWxlcyBhdCBkb21h aW4gQSBhbmQgQi4NCg0KNS4yLjMgSW50ZXItZG9tYWluIHNpZ25hbGluZyBm b3IgdGhlIGNhc2UgdGhhdCBSTUQtUU9TTSBhdCBkb21haW4gQSANCiAgICAg IGFuZCBub24tTlNJUyBiYXNlZCBRT1NNIGF0IGRvbWFpbiBCDQogICANCiAg IFRoZSBzaWduYWxpbmcgb3BlcmF0aW9ucyBhdCBkb21haW4gQSBhbmQgdGhl IGludGVyLWRvbWFpbiBzaWduYWxpbmcNCiAgIGludGVyYWN0aW9ucyBiZXR3 ZWVuIGRvbWFpbiBBIGFuZCBkb21haW4gQiB3aWxsIGJlIHRoZSBzYW1lIGFz DQogICBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjIuMS4gV2hlbiB0aGUgaW50 ZXItZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQNCiAgIGRvbWFpbiBCIHJlY2Vp dmVzIGEgUkVTRVJWRSBtZXNzYWdlIGZyb20gaXRzIHBlZXIsIGl0IHdpbGwg Y2Fycnkgb3V0DQogICB0aGUgc2FtZSBhY3Rpb25zIGRlZmluZWQgYnkgdGhl IG9wZXJhdGlvbiBtb2RlbCBvZiBJbnRlckRvbWFpbi1RT1NNDQogICBpbiBz ZWN0aW9uIDQuMS4gSW4gY2FzZSB0aGF0IGFsbCB0aGUgZGVjaXNpb25zIGhh dmUgcG9zaXRpdmUgb3V0cHV0cywNCiAgIHRoZSBpbnRlci1kb21haW4gY29u dHJvbCBhZ2VudCBuZWVkIGFsc28gbWFpbnRhaW4gdGhlIElQIGludGVyZmFj ZXMNCiAgIG9mIHRoZSBlZ3Jlc3MgYW5kIGluZ3Jlc3Mgbm9kZXMgYXNzaWdu ZWQgdG8gdGhlIFFvUyByZXF1ZXN0IGFuZCB0aGVuDQogICBzZW5kIHRoZSBl eHRyYWN0ZWQgU0xTIHBhcmFtZXRlcnMgYW5kIHRoZSBJUCBpbnRlcmZhY2Ug b2YgdGhlIGluZ3Jlc3MNCiAgIG5vZGUgdG8gdGhlIGludHJhLWRvbWFpbiBj b250cm9sIGFnZW50IHZpYSB0aGUgc3RhbmRhcmRpemVkIEFQSXMuDQogICBO ZXh0LCB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgYWdlbnQgYXQgZG9tYWlu IEIgd2lsbCBhcHBseSBpdHMNCiAgIGludHJhLWRvbWFpbiBjb250cm9sIG1l Y2hhbmlzbXMgdG8gdGhlIFFvUyByZXF1ZXN0IGFuZCBtYWtlIHRoZSBRb1MN CiAgIHJlc2VydmF0aW9ucyBhY2NvcmRpbmdseS4NCiAgICANCiAgIEZvciB0 aGUgY2FzZSB0aGF0IGRvbWFpbiBCIGlzIHRoZSBzaW5rIGRvbWFpbiwgdGhl IGludHJhLWRvbWFpbg0KICAgY29udHJvbCBhZ2VudCB3aWxsIHNlbmQgaXRz IHJlc3BvbnNlIHRvIHRoZSBpbnRlci1kb21haW4gY29udHJvbCBhZ2VudA0K ICAgYWxzbyB2aWEgdGhlIHN0YW5kYXJkaXplZCBBUElzLiBUaGVuIHRoZSBp bnRlci1kb21haW4gY29udHJvbCBhZ2VudA0KICAgd2lsbCBjb25zdHJ1Y3Qg YSBSRVNQT05TRSBtZXNzYWdlIGJhc2VkIG9uIHRoZSByZWNlaXZlZCByZXNw b25zZSBhbmQNCiAgIHNlbmQgaXQgdG8gdGhlIGludGVyLWRvbWFpbiBjb250 cm9sIGFnZW50IGF0IGRvbWFpbiBBLCB3aGljaCB3aWxsDQogICBmb3J3YXJk IHRoaXMgUkVTUE9OU0UgbWVzc2FnZSB0byB0aGUgZWdyZXNzIG5vZGUgb2Yg ZG9tYWluIEEgaXQgaGFzDQogICBtYWludGFpbmVkIGZvciB0aGlzIGZsb3cu IEZyb20gdGhlbiBvbiwgdGhlIHByb3BhZ2F0aW9uIG9mIHRoZQ0KICAgUkVT UE9OU0UgbWVzc2FnZSBhdCBkb21haW4gQSB3aWxsIGZvbGxvdyB0aGUgcnVs ZXMgYXMgZGVmaW5lZCBpbiANCiAgIFtSTUQtUU9TTV0uDQoNCjUuMi40IElu dGVyLWRvbWFpbiBzaWduYWxpbmcgZm9yIHRoZSBjYXNlIHRoYXQgbm9uLU5T SVMgYmFzZWQgUU9TTSBhdA0KICAgICAgZG9tYWluIEEgYW5kIFJNRC1RT1NN IGF0IGRvbWFpbiBCDQoNClpoYW5nLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMDYsIDIwMDYgICAgICAgICAgICAgW1BhZ2UgMTNdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBJbnRlckRvbWFpbi1RT1NN ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNg0KDQogICBXaGVuIHRoZSBp bnRyYS1kb21haW4gY29udHJvbCBhZ2VudCBhdCBkb21haW4gQSBzdWNjZXNz ZnVsbHkgbWFrZXMNCiAgIHRoZSByZXNlcnZhdGlvbiBmb3IgYSB0cmFmZmlj IGZsb3csIGl0IHdpbGwgc2VuZCB0aGUgaW50ZXItZG9tYWluDQogICBjb250 cm9sIGFnZW50IHRoZSBTTFMgcGFyYW1ldGVycyBkZXNjcmliaW5nIHRoZSBR b1MgcmVxdWlyZW1lbnRzIG9mDQogICB0aGUgZmxvdyBhbmQgdGhlIElQIGlu dGVyZmFjZXMgb2YgdGhlIGVncmVzcyBub2RlIG9mIGRvbWFpbiBBIGFuZCB0 aGUNCiAgIGluZ3Jlc3Mgbm9kZSBvZiBkb21haW4gQiBhc3NpZ25lZCB0byB0 aGUgZmxvdyBieSBpbnZva2luZyB0aGUgDQogICBzdGFuZGFyZGl6ZWQgQVBJ cy4gTm90ZSB0aGF0IHdlIG1ha2Ugbm8gYXNzdW1wdGlvbnMgYWJvdXQgaG93 IHRoZSANCiAgIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGRvbWFp biBBIGNhbiBkaXNjb3ZlciB0aGUgSVAgaW50ZXJmYWNlDQogICBvZiB0aGUg aW5ncmVzcyBub2RlIHRocm91Z2ggd2hpY2ggdGhlIHNpZ25hbGVkIGZsb3cg d2lsbCBiZSBhY2NlcHRlZA0KICAgaW50byBkb21haW4gQiBhbmQgc2V2ZXJh bCBtZWNoYW5pc21zIGNvdWxkIGJlIHVzZWQuDQogICANCiAgIFdoZW4gdGhl IGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGRvbWFpbiBBIHJlY2Vp dmVzIHRoZSBBUEkNCiAgIGNhbGwsIGl0IHdpbGwgY29uc3RydWN0IGEgSW50 ZXJEb21haW4tUU9TTSBRU1BFQyBiYXNlZCBvbiB0aGUNCiAgIHJlY2VpdmVk IFNMUyBwYXJhbWV0ZXJzIGFuZCB0aGUgSVAgaW50ZXJmYWNlcyBvZiB0aGUg ZWdyZXNzIGFuZA0KICAgaW5ncmVzcyBub2RlcyBhbmQgc2VuZCBhIG5ldyBS RVNFUlZFIG1lc3NhZ2Ugd2l0aCB0aGUgDQogICBJbnRlckRvbWFpbi1RT1NN IFFTUEVDIHRvIGl0cyBwZWVyIGF0IGRvbWFpbiBCLg0KICAgDQogICBOZXh0 LCB0aGUgc2lnbmFsaW5nIGV4Y2hhbmdlcyBpbiBkb21haW4gQiBhcmUgdGhl IHNpbWlsYXIgYXMNCiAgIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDUuMi4xLiBG b3IgdGhlIGNhc2UgdGhhdCBkb21haW4gQiBpcyB0aGUgc2luaw0KICAgZG9t YWluLCBvbmUgUU5SIGF0IGRvbWFpbiBCIHdpbGwgY3JlYXRlIGEgUkVTUE9O U0UgbWVzc2FnZSB0byANCiAgIGluZGljYXRlIHRoZSByZXNlcnZhdGlvbiBy ZXN1bHQuIFdoZW4gdGhlIFJFU1BPTlNFIG1lc3NhZ2UgcmVhY2hlcw0KICAg dGhlIGFib3ZlIGluZ3Jlc3Mgbm9kZSwgaXQgd2lsbCBiZSBmb3J3YXJkZWQg dG8gdGhlIGludGVyLWRvbWFpbg0KICAgY29udHJvbCBhZ2VudCBhdCBkb21h aW4gQiwgd2hpY2ggY29udGludWVzIGZvcndhcmRpbmcgdGhlIFJFU1BPTlNF IHRvDQogICBpdHMgcGVlciBhdCBkb21haW4gQS4gVGhlbiwgdGhlIGludGVy LWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGRvbWFpbg0KICAgQSB3aWxsIHBy b2Nlc3MgdGhlIHJlY2VpdmVkIFJFU1BPTlNFIG1lc3NhZ2UgYW5kIHRoZW4g c2VuZCB0aGUNCiAgIHJlbGV2YW50IHJlc3BvbnNlIHRvIHRoZSBpbnRyYS1k b21haW4gY29udHJvbCBhZ2VudCB2aWEgYSBBUEkgYmV0d2Vlbg0KICAgdGhl bS4gQWZ0ZXIgdGhhdCwgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50 IGNhbiBpbmZvcm0gdGhlIFFvUw0KICAgdHJpZ2dlciB0aGUgcmVzdWx0IG9m IGl0cyByZXNlcnZhdGlvbiByZXF1ZXN0IGJ5IHVzaW5nIGl0cyANCiAgIGlu dHJhLWRvbWFpbiBzaWduYWxpbmcgbWVjaGFuaXNtcy4NCg0KNS4zIFRoZSBE aXNjb3Zlcnkgb2YgUGVlciBJbnRlci1kb21haW4gQ29udHJvbCBBZ2VudA0K DQogICBNYWlubHksIHRoZSBkaXNjb3Zlcnkgb2YgcGVlciBpbnRlci1kb21h aW4gY29udHJvbCBhZ2VudCBjYW4gYmUgDQogICBwZXJmb3JtZWQgZWl0aGVy IGJ5IHVzaW5nIHRoZSBkaXNjb3ZlcnkgbWV0aG9kIHdoaWNoIHdpbGwgYmUg cmVwb3J0ZWQNCiAgIGF0IGEgc2VwZXJhdGUgTlNJUyBkcmFmdCBvciBtYW51 YWwgY29uZmlndXJhdGlvbiBvciBhbnkgb3RoZXINCiAgIGRpc2NvdmVyeSB0 ZWNobmlxdWUuIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gYXNzdW1wdGlvbnMg YWJvdXQgdGhhdC4NCg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0K ICAgVGhlIG9wZXJhdGlvbiBtb2RlIG9mIHRoZSBJbnRlckRvbWFpbi1RT1NN IG1pZ2h0IHByb2R1Y2Ugc29tZQ0KICAgc2VjdXJpdHkgY29uY2VybnMgYW5k IHRoaXMgd2lsbCBiZSBkaXNjdXNzZWQgYW5kIGNsYXJpZmllZCBsYXRlci4N CiAgIA0KNy4gSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIHNlY3Rp b24gcHJvdmlkZXMgZ3VpZGFuY2UgdG8gdGhlIEludGVybmV0IEFzc2lnbmVk IE51bWJlcnMNCiAgIEF1dGhvcml0eSAoSUFOQSkgcmVnYXJkaW5nIHJlZ2lz dHJhdGlvbiBvZiB2YWx1ZXMgcmVsYXRlZCB0byB0aGUNCiAgIFFTUEVDIHRl bXBsYXRlLCBpbiBhY2NvcmRhbmNlIHdpdGggQkNQIDI2IFJGQyAyNDM0IFtS RkMyNDM0XS4NCg0KICAgSW50ZXJEb21haW4tUU9TTSByZXF1aXJlcyBhIG5l dyBJQU5BIHJlZ2lzdHJ5LiBJbiBhZGRpdGlvbiwgdGhpcw0KICAgZG9jdW1l bnQgYWxzbyBkZWZpbmVzIDMgbmV3IFFTUEVDIHBhcmFtZXRlcnMgZm9yIHRo ZSBRU1BFQyBUZW1wbGF0ZSwgDQogICBhcyBkZXRhaWxlZCBpbiBTZWN0aW9u IDQuIFZhbHVlcyBhcmUgdG8gYmUgYXNzaWduZWQgZm9yIHRoZW0gZnJvbSB0 aGUNCiAgIFFTUEVDIFBhcmFtZXRlciBJRCByZWdpc3RyeS4NCg0KWmhhbmcs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAg ICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIEludGVyRG9tYWluLVFPU00gICAgICAgICAgICAgICAgICBNYXJj aCAyMDA2DQoNCjguIE9wZW4gaXNzdWVzDQoNCiAgIFRoaXMgc2VjdGlvbiBk ZXNjcmliZXMgdGhlIG9wZW4gaXNzdWVzIHJlbGF0ZWQgdG8gdGhlDQogICBJ bnRlckRvbWFpbi1RT1NNLiBDdXJyZW50bHksIHRoZSBmb2xsb3dpbmcgb3Bl biBpc3N1ZXMgd2lsbCBwb3NzaWJseQ0KICAgbmVlZCB0byBiZSBkaXNjdXNz ZWQgYW5kIGFkZHJlc3NlZCBsYXRlciBvbi4NCg0KICAgbyAgVGhlIGludGVy YWN0aW9ucyBiZXR3ZWVuIHRoZSBpbnRyYS1kb21haW4gY29udHJvbCBhZ2Vu dCBhbmQgdGhlIA0KICAgICAgaW50ZXItZG9tYWluIGNvbnRyb2wgYWdlbnQg d2hlbiB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgYWdlbnQgaXMNCiAgICAg IG5vdCBOU0lTLWNhcGFibGUuIFRoZSBjdXJyZW50IHNvbHV0aW9uIGlzIHRo YXQgd2UgYXNzdW1lIHRoZSANCiAgICAgIGludGVyLWRvbWFpbiBhbmQgaW50 cmEtZG9tYWluIGNvbnRyb2wgYWdlbnRzIHdpbGwgcmVzaWRlIHRvZ2V0aGVy DQogICAgICBhbmQgdGhleSBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIgdmlh IGEgc2V0IG9mIHN0YW5kYXJkaXplZCBBUElzLg0KICAgICAgRm9yIHRoZSBj YXNlIHRoYXQgdGhlIGludHJhLWRvbWFpbiGUgSVAgaW50ZXJmYWNlDQogICBvZiB0aGUg aW5ncmVzcyBub2RlIHRocm91Z2ggd2hpY2ggdGhlIHNpZ25hbGVkIGZsb3cg d2lsbCBiZSBhY2NlcHRlZA0KICAgaW50byBkb21haW4gQiBhbmQgc2V2ZXJh bCBtZWNoYW5pc21zIGNvdWxkIGJlIHVzZWQuDQogICANCiAgIFdoZW4gdGhl IGludGVyLWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGRvbWFpbiBBIHJlY2Vp dmVzIHRoZSBBUEkNCiAgIGNhbGwsIGl0IHdpbGwgY29uc3RydWN0IGEgSW50 ZXJEb21haW4tUU9TTSBRU1BFQyBiYXNlZCBvbiB0aGUNCiAgIHJlY2VpdmVk IFNMUyBwYXJhbWV0ZXJzIGFuZCB0aGUgSVAgaW50ZXJmYWNlcyBvZiB0aGUg ZWdyZXNzIGFuZA0KICAgaW5ncmVzcyBub2RlcyBhbmQgc2VuZCBhIG5ldyBS RVNFUlZFIG1lc3NhZ2Ugd2l0aCB0aGUgDQogICBJbnRlckRvbWFpbi1RT1NN IFFTUEVDIHRvIGl0cyBwZWVyIGF0IGRvbWFpbiBCLg0KICAgDQogICBOZXh0 LCB0aGUgc2lnbmFsaW5nIGV4Y2hhbmdlcyBpbiBkb21haW4gQiBhcmUgdGhl IHNpbWlsYXIgYXMNCiAgIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDUuMi4xLiBG b3IgdGhlIGNhc2UgdGhhdCBkb21haW4gQiBpcyB0aGUgc2luaw0KICAgZG9t YWluLCBvbmUgUU5SIGF0IGRvbWFpbiBCIHdpbGwgY3JlYXRlIGEgUkVTUE9O U0UgbWVzc2FnZSB0byANCiAgIGluZGljYXRlIHRoZSByZXNlcnZhdGlvbiBy ZXN1bHQuIFdoZW4gdGhlIFJFU1BPTlNFIG1lc3NhZ2UgcmVhY2hlcw0KICAg dGhlIGFib3ZlIGluZ3Jlc3Mgbm9kZSwgaXQgd2lsbCBiZSBmb3J3YXJkZWQg dG8gdGhlIGludGVyLWRvbWFpbg0KICAgY29udHJvbCBhZ2VudCBhdCBkb21h aW4gQiwgd2hpY2ggY29udGludWVzIGZvcndhcmRpbmcgdGhlIFJFU1BPTlNF IHRvDQogICBpdHMgcGVlciBhdCBkb21haW4gQS4gVGhlbiwgdGhlIGludGVy LWRvbWFpbiBjb250cm9sIGFnZW50IGF0IGRvbWFpbg0KICAgQSB3aWxsIHBy b2Nlc3MgdGhlIHJlY2VpdmVkIFJFU1BPTlNFIG1lc3NhZ2UgYW5kIHRoZW4g c2VuZCB0aGUNCiAgIHJlbGV2YW50IHJlc3BvbnNlIHRvIHRoZSBpbnRyYS1k b21haW4gY29udHJvbCBhZ2VudCB2aWEgYSBBUEkgYmV0d2Vlbg0KICAgdGhl bS4gQWZ0ZXIgdGhhdCwgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGFnZW50 IGNhbiBpbmZvcm0gdGhlIFFvUw0KICAgdHJpZ2dlciB0aGUgcmVzdWx0IG9m IGl0cyByZXNlcnZhdGlvbiByZXF1ZXN0IGJ5IHVzaW5nIGl0cyANCiAgIGlu dHJhLWRvbWFpbiBzaWduYWxpbmcgbWVjaGFuaXNtcy4NCg0KNS4zIFRoZSBE aXNjb3Zlcnkgb2YgUGVlciBJbnRlci1kb21haW4gQ29udHJvbCBBZ2VudA0K DQogICBNYWlubHksIHRoZSBkaXNjb3Zlcnkgb2YgcGVlciBpbnRlci1kb21h aW4gY29udHJvbCBhZ2VudCBjYW4gYmUgDQogICBwZXJmb3JtZWQgZWl0aGVy IGJ5IHVzaW5nIHRoZSBkaXNjb3ZlcnkgbWV0aG9kIHdoaWNoIHdpbGwgYmUg cmVwb3J0ZWQNCiAgIGF0IGEgc2VwZXJhdGUgTlNJUyBkcmFmdCBvciBtYW51 YWwgY29uZmlndXJhdGlvbiBvciBhbnkgb3RoZXINCiAgIGRpc2NvdmVyeSB0 ZWNobmlxdWUuIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gYXNzdW1wdGlvbnMg YWJvdXQgdGhhdC4NCg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0K ICAgVGhlIG9wZXJhdGlvbiBtb2RlIG9mIHRoZSBJbnRlckRvbWFpbi1RT1NN IG1pZ2h0IHByb2R1Y2Ugc29tZQ0KICAgc2VjdXJpdHkgY29uY2VybnMgYW5k IHRoaXMgd2lsbCBiZSBkaXNjdXNzZWQgYW5kIGNsYXJpZmllZCBsYXRlci4N CiAgIA0KNy4gSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIHNlY3Rp b24gcHJvdmlkZXMgZ3VpZGFuY2UgdG8gdGhlIEludGVybmV0IEFzc2lnbmVk IE51bWJlcnMNCiAgIEF1dGhvcml0eSAoSUFOQSkgcmVnYXJkaW5nIHJlZ2lz dHJhdGlvbiBvZiB2YWx1ZXMgcmVsYXRlZCB0byB0aGUNCiAgIFFTUEVDIHRl bXBsYXRlLCBpbiBhY2NvcmRhbmNlIHdpdGggQkNQIDI2IFJGQyAyNDM0IFtS RkMyNDM0XS4NCg0KICAgSW50ZXJEb21haW4tUU9TTSByZXF1aXJlcyBhIG5l dyBJQU5BIHJlZ2lzdHJ5LiBJbiBhZGRpdGlvbiwgdGhpcw0KICAgZG9jdW1l bnQgYWxzbyBkZWZpbmVzIDMgbmV3IFFTUEVDIHBhcmFtZXRlcnMgZm9yIHRo ZSBRU1BFQyBUZW1wbGF0ZSwgDQogICBhcyBkZXRhaWxlZCBpbiBTZWN0aW9u IDQuIFZhbHVlcyBhcmUgdG8gYmUgYXNzaWduZWQgZm9yIHRoZW0gZnJvbSB0 aGUNCiAgIFFTUEVDIFBhcmFtZXRlciBJRCByZWdpc3RyeS4NCg0KWmhhbmcs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAwNiwgMjAwNiAg ICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIEludGVyRG9tYWluLVFPU00gICAgICAgICAgICAgICAgICBNYXJj aCAyMDA2DQoNCjguIE9wZW4gaXNzdWVzDQoNCiAgIFRoaXMgc2VjdGlvbiBk ZXNjcmliZXMgdGhlIG9wZW4gaXNzdWVzIHJlbGF0ZWQgdG8gdGhlDQogICBJ bnRlckRvbWFpbi1RT1NNLiBDdXJyZW50bHksIHRoZSBmb2xsb3dpbmcgb3Bl biBpc3N1ZXMgd2lsbCBwb3NzaWJseQ0KICAgbmVlZCB0byBiZSBkaXNjdXNz ZWQgYW5kIGFkZHJlc3NlZCBsYXRlciBvbi4NCg0KICAgbyAgVGhlIGludGVy YWN0aW9ucyBiZXR3ZWVuIHRoZSBpbnRyYS1kb21haW4gY29udHJvbCBhZ2Vu dCBhbmQgdGhlIA0KICAgICAgaW50ZXItZG9tYWluIGNvbnRyb2wgYWdlbnQg d2hlbiB0aGUgaW50cmEtZG9tYWluIGNvbnRyb2wgYWdlbnQgaXMNCiAgICAg IG5vdCBOU0lTLWNhcGFibGUuIFRoZSBjdXJyZW50IHNvbHV0aW9uIGlzIHRo YXQgd2UgYXNzdW1lIHRoZSANCiAgICAgIGludGVyLWRvbWFpbiBhbmQgaW50 cmEtZG9tYWluIGNvbnRyb2wgYWdlbnRzIHdpbGwgcmVzaWRlIHRvZ2V0aGVy DQogICAgICBhbmQgdGhleSBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIgdmlh IGEgc2V0IG9mIHN0YW5kYXJkaXplZCBBUElzLg0KICAgICAgRm9yIHRoZSBj YXNlIHRoYXQgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGZ1bmN0aW9uIGlz IGRpc3RyaWJ1dGVkDQogICAgICB0byBhIHNldCBvZiBsb2NhbCBhZ2VudHMs IHRoZSBhZGRpdGlvbmFsIHNvbHV0aW9ucyB3aWxsIGJlDQogICAgICBzdHVk aWVkLg0KDQogICBvICBNb3JlIFFTUEVDIHBhcmFtZXRlcnMgbWF5IGJlIG5l ZWRlZCBmb3IgdGhlIEludGVyRG9tYWluLVFPU00uDQogICAgICANCiAgIG8g IFRoZSBzdXBwb3J0IG9mIHRoZSBhdXRvbWF0aWMgaW50ZXItZG9tYWluIGFk anVzdG1lbnQgaW4gdGhlDQogICAgICBzY2VuYXJpbyBvZiBtb2JpbGUgZW5k IGN1c3RvbWVycy4NCg0KOS4gIEFja25vd2xlZGdtZW50cw0KDQogICAgVGhl IGF1dGhvcnMgd291bGQgbGlrZSBnaXZlIHRoZSB0aGFua3MgdG8gdGhlIEVV IElTVCBGUDYgRXVRb1MNCiAgICBwcm9qZWN0IGZvciB0aGVpciBmdW5kaW5n Lg0KDQoxMC4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW05TSVMtUVNQ RUNdIEFzaCwgSi4sIGV0LiBhbC4sICJRb1MtTlNMUCBRU1BFQyBUZW1wbGF0 ZSwiIHdvcmsgaW4NCiAgIHByb2dyZXNzLg0KDQogICBbUW9TLU5TTFBdIE1h bm5lciwgSi4sIEthcmFnaWFubmlzLCBHLiwgTWNEb25hbGQsIEEuIGFuZCBC b3NjaCwgUy4sIA0KICAgIk5TTFAgZm9yIFF1YWxpdHktb2YtU2VydmljZSBz aWduYWxpbmciLCBkcmFmdC1pZXRmLW5zaXMtcW9zLW5zbHAtMDgNCiAgICh3 b3JrIGluIHByb2dyZXNzKSwgQXByaWwgMjAwNi4NCg0KICAgW1JGQzIxMTld IFMuIEJyYWRuZXIsICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIA0KICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTksIE1h cmNoIDE5OTcuICAgDQoNCjExLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoN CiAgIFtEQ1BFTC1yZXF1aXJlbWVudHNdIE1lbmRlcywgUC4sIGFuZCBOaWNo b2xzLCBLLiwgIlJlcXVpcmVtZW50cyBmb3INCiAgIERpZmZTZXJ2IENvbnRy b2wgUGxhbmUgRWxlbWVudHMiLCBkcmFmdC1tZW5kZXMtZGNwZWwtcmVxdWly ZW1lbnRzLTAwDQogICAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAwNi4N Cg0KICAgW0dJU1RdIFNjaHVsenJpbm5lLCBILiwgYW5kIEhhbmNvY2ssIFIu LCAiR0lTVDogIEdlbmVyYWwgSW50ZXJuZXQNCiAgIFNpZ25hbGluZyBUcmFu c3BvcnQiLCBkcmFmdC1pZXRmLW5zaXMtbnRscC0wOCAod29yayBpbiBwcm9n cmVzcyksDQogICBNYXJjaCAyMDA2Lg0KDQogICBbUkZDMjIxMF0gV3JvY2xh d3NraSwgSi4sICJUaGUgVXNlIG9mIFJTVlAgd2l0aCBJRVRGIEludGVncmF0 ZWQNCiAgIFNlcnZpY2VzLCIgUkZDIDIyMTAsIFNlcHRlbWJlciAxOTk3Lg0K DQogICBbUkZDMjQ3NV0gQmxha2UsIFMuLCBCbGFjaywgRC4sIENhcmxzb24s IE0uLCBEYXZpZXMsIEUuLCBXYW5nLCBaLg0KICAgYW5kIFcuICBXZWlzcywg IkFuIEFyY2hpdGVjdHVyZSBmb3IgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMi LCBSRkMgDQogICAyNDc1LCBEZWNlbWJlciAxOTk4Lg0KDQpaaGFuZywgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDA2LCAyMDA2ICAgICAg ICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgSW50ZXJEb21haW4tUU9TTSAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MDYNCg0KICAgW1JGQzI2MzhdIE5pY2hvbHMgSy4sIEphY29ic29uIFYuLCBa aGFuZyBMLiAgIkEgVHdvLWJpdCANCiAgIERpZmZlcmVudGlhdGVkIFNlcnZp Y2VzIEFyY2hpdGVjdHVyZSBmb3IgdGhlIEludGVybmV0IiwgUkZDIDI2Mzgs DQogICBKdWx5IDE5OTkuDQoNCiAgIFtSTUQtUU9TTV0gQmFkZXIsIEEuLCBl dC4gYWwuLCAiUk1ELVFPU00gLSBUaGUgUmVzb3VyY2UgTWFuYWdlbWVudA0K ICAgaW4gRGlmZnNlcnYgUU9TIE1vZGVsLCIgd29yayBpbiBwcm9ncmVzcy4N Cg0KICAgW1kuMTU0MS1RT1NNXSBBc2gsIEouLCBldC4gYWwuLCAiWS4xNTQx LVFPU00gLS0gWS4xNTQxIFFvUyBNb2RlbCBmb3INCiAgIE5ldHdvcmtzIFVz aW5nIFkuMTU0MSBRb1MgQ2xhc3NlcywiIHdvcmsgaW4gcHJvZ3Jlc3MuDQoN CjEyLiBBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgSmlhbiBaaGFuZw0KICAg RGVwdC4gb2YgSW5mb3JtYXRpY3MgRW5naW5lZXJpbmcNCiAgIFVuaXYuIG9m IENvaW1icmENCiAgIFBvbG8gSUkgLSBQaW5oYWwgZGUgTWFycm9jb3MNCiAg IDMwMzAtMjkwIENvaW1icmEsIFBvcnR1Z2FsDQogICBFbWFpbDogemhhbmdA ZGVpLnVjLnB0DQoNCiAgIEVkbXVuZG8gTW9udGVpcm8NCiAgIERlcHQuIG9m IEluZm9ybWF0aWNzIEVuZ2luZWVyaW5nDQogICBVbml2LiBvZiBDb2ltYnJh DQogICBQb2xvIElJIC0gUGluaGFsIGRlIE1hcnJvY29zDQogICAzMDMwLTI5 MCBDb2ltYnJhLCBQb3J0dWdhbA0KICAgRW1haWw6IGVkbXVuZG9AZGVpLnVj LnB0DQoNCjEzLiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQog ICANCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0 aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwg UHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJl IGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9u IG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRo aXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5z ZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJl IGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz DQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkg YW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9j ZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50 cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQog ICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUBjb250cm9sIGZ1bmN0aW9uIGlz IGRpc3RyaWJ1dGVkDQogICAgICB0byBhIHNldCBvZiBsb2NhbCBhZ2VudHMs IHRoZSBhZGRpdGlvbmFsIHNvbHV0aW9ucyB3aWxsIGJlDQogICAgICBzdHVk aWVkLg0KDQogICBvICBNb3JlIFFTUEVDIHBhcmFtZXRlcnMgbWF5IGJlIG5l ZWRlZCBmb3IgdGhlIEludGVyRG9tYWluLVFPU00uDQogICAgICANCiAgIG8g IFRoZSBzdXBwb3J0IG9mIHRoZSBhdXRvbWF0aWMgaW50ZXItZG9tYWluIGFk anVzdG1lbnQgaW4gdGhlDQogICAgICBzY2VuYXJpbyBvZiBtb2JpbGUgZW5k IGN1c3RvbWVycy4NCg0KOS4gIEFja25vd2xlZGdtZW50cw0KDQogICAgVGhl IGF1dGhvcnMgd291bGQgbGlrZSBnaXZlIHRoZSB0aGFua3MgdG8gdGhlIEVV IElTVCBGUDYgRXVRb1MNCiAgICBwcm9qZWN0IGZvciB0aGVpciBmdW5kaW5n Lg0KDQoxMC4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW05TSVMtUVNQ RUNdIEFzaCwgSi4sIGV0LiBhbC4sICJRb1MtTlNMUCBRU1BFQyBUZW1wbGF0 ZSwiIHdvcmsgaW4NCiAgIHByb2dyZXNzLg0KDQogICBbUW9TLU5TTFBdIE1h bm5lciwgSi4sIEthcmFnaWFubmlzLCBHLiwgTWNEb25hbGQsIEEuIGFuZCBC b3NjaCwgUy4sIA0KICAgIk5TTFAgZm9yIFF1YWxpdHktb2YtU2VydmljZSBz aWduYWxpbmciLCBkcmFmdC1pZXRmLW5zaXMtcW9zLW5zbHAtMDgNCiAgICh3 b3JrIGluIHByb2dyZXNzKSwgQXByaWwgMjAwNi4NCg0KICAgW1JGQzIxMTld IFMuIEJyYWRuZXIsICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIA0KICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTksIE1h cmNoIDE5OTcuICAgDQoNCjExLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoN CiAgIFtEQ1BFTC1yZXF1aXJlbWVudHNdIE1lbmRlcywgUC4sIGFuZCBOaWNo b2xzLCBLLiwgIlJlcXVpcmVtZW50cyBmb3INCiAgIERpZmZTZXJ2IENvbnRy b2wgUGxhbmUgRWxlbWVudHMiLCBkcmFmdC1tZW5kZXMtZGNwZWwtcmVxdWly ZW1lbnRzLTAwDQogICAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAwNi4N Cg0KICAgW0dJU1RdIFNjaHVsenJpbm5lLCBILiwgYW5kIEhhbmNvY2ssIFIu LCAiR0lTVDogIEdlbmVyYWwgSW50ZXJuZXQNCiAgIFNpZ25hbGluZyBUcmFu c3BvcnQiLCBkcmFmdC1pZXRmLW5zaXMtbnRscC0wOCAod29yayBpbiBwcm9n cmVzcyksDQogICBNYXJjaCAyMDA2Lg0KDQogICBbUkZDMjIxMF0gV3JvY2xh d3NraSwgSi4sICJUaGUgVXNlIG9mIFJTVlAgd2l0aCBJRVRGIEludGVncmF0 ZWQNCiAgIFNlcnZpY2VzLCIgUkZDIDIyMTAsIFNlcHRlbWJlciAxOTk3Lg0K DQogICBbUkZDMjQ3NV0gQmxha2UsIFMuLCBCbGFjaywgRC4sIENhcmxzb24s IE0uLCBEYXZpZXMsIEUuLCBXYW5nLCBaLg0KICAgYW5kIFcuICBXZWlzcywg IkFuIEFyY2hpdGVjdHVyZSBmb3IgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMi LCBSRkMgDQogICAyNDc1LCBEZWNlbWJlciAxOTk4Lg0KDQpaaGFuZywgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDA2LCAyMDA2ICAgICAg ICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgSW50ZXJEb21haW4tUU9TTSAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MDYNCg0KICAgW1JGQzI2MzhdIE5pY2hvbHMgSy4sIEphY29ic29uIFYuLCBa aGFuZyBMLiAgIkEgVHdvLWJpdCANCiAgIERpZmZlcmVudGlhdGVkIFNlcnZp Y2VzIEFyY2hpdGVjdHVyZSBmb3IgdGhlIEludGVybmV0IiwgUkZDIDI2Mzgs DQogICBKdWx5IDE5OTkuDQoNCiAgIFtSTUQtUU9TTV0gQmFkZXIsIEEuLCBl dC4gYWwuLCAiUk1ELVFPU00gLSBUaGUgUmVzb3VyY2UgTWFuYWdlbWVudA0K ICAgaW4gRGlmZnNlcnYgUU9TIE1vZGVsLCIgd29yayBpbiBwcm9ncmVzcy4N Cg0KICAgW1kuMTU0MS1RT1NNXSBBc2gsIEouLCBldC4gYWwuLCAiWS4xNTQx LVFPU00gLS0gWS4xNTQxIFFvUyBNb2RlbCBmb3INCiAgIE5ldHdvcmtzIFVz aW5nIFkuMTU0MSBRb1MgQ2xhc3NlcywiIHdvcmsgaW4gcHJvZ3Jlc3MuDQoN CjEyLiBBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgSmlhbiBaaGFuZw0KICAg RGVwdC4gb2YgSW5mb3JtYXRpY3MgRW5naW5lZXJpbmcNCiAgIFVuaXYuIG9m IENvaW1icmENCiAgIFBvbG8gSUkgLSBQaW5oYWwgZGUgTWFycm9jb3MNCiAg IDMwMzAtMjkwIENvaW1icmEsIFBvcnR1Z2FsDQogICBFbWFpbDogemhhbmdA ZGVpLnVjLnB0DQoNCiAgIEVkbXVuZG8gTW9udGVpcm8NCiAgIERlcHQuIG9m IEluZm9ybWF0aWNzIEVuZ2luZWVyaW5nDQogICBVbml2LiBvZiBDb2ltYnJh DQogICBQb2xvIElJIC0gUGluaGFsIGRlIE1hcnJvY29zDQogICAzMDMwLTI5 MCBDb2ltYnJhLCBQb3J0dWdhbA0KICAgRW1haWw6IGVkbXVuZG9AZGVpLnVj LnB0DQoNCjEzLiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQog ICANCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0 aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwg UHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJl IGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9u IG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRo aXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5z ZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJl IGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz DQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkg YW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9j ZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50 cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQog ICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYg U2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNl cyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0K ICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBv ciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0 YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0K ICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVU RiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJl c3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAg Y29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBv ciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVy IHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50 DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9y bWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4N Cg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50 IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJv dmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklC VVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJ RUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElF RA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCkNvcHlyaWdodCBTdGF0 ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0 eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRo ZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVk IGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJl aW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQpa aGFuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDA2LCAy MDA2ICAgICAgICAgICAgIFtQYWdlIDE2XQ== --34210048-467410686-1141742876=:31649 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 --34210048-467410686-1141742876=:31649-- gdG8gdGhlIElFVEYg U2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNl cyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0K ICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBv ciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0 YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0K ICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVU RiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJl c3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAg Y29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBv ciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVy IHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50 DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9y bWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4N Cg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50 IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJv dmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklC VVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJ RUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElF RA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCkNvcHlyaWdodCBTdGF0 ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0 eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRo ZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVk IGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJl aW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQpa aGFuZywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDA2LCAy MDA2ICAgICAgICAgICAgIFtQYWdlIDE2XQ== --34210048-467410686-1141742876=:31649 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 --34210048-467410686-1141742876=:31649-- From nsis-bounces@ietf.org Wed Mar 08 03:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuPv-0001QG-6z; Wed, 08 Mar 2006 03:53:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuPt-0001Oj-CX for nsis@ietf.org; Wed, 08 Mar 2006 03:53:09 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGuPr-0007jC-D0 for nsis@ietf.org; Wed, 08 Mar 2006 03:53:09 -0500 Received: from [195.37.70.137] (unknown [195.37.70.137]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4ABBD1BAC4D; Wed, 8 Mar 2006 09:53:37 +0100 (CET) In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DDF@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01869DDF@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <9E07FCB9-78C0-4A7E-9D69-D198B84096B5@netlab.nec.de> From: Martin Stiemerling Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS Extensibility Doc on QOSMs Date: Wed, 8 Mar 2006 09:53:03 +0100 To: "john.loughney@nokia.com> X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: gash@att.com, nsis@ietf.org, hannes.tschofenig@siemens.com, robert.hancock@roke.co.uk, Attila.Bader@ericsson.com, cornelia.kappler@siemens.com 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="===============1422573211==" Errors-To: nsis-bounces@ietf.org --===============1422573211== Content-Type: multipart/alternative; boundary=Apple-Mail-5-292026423 --Apple-Mail-5-292026423 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed hi all, I would in favour of discussing this during the WG time in Dallas, =20 since it involves (probably) GIST, QoS NSLP, and the NATFW NSLP. Martin Am 06.03.2006 um 14:14 schrieb =20 : > This is what was thinking of as well, we can have a chat about that =20= > in Dallas (during WG time), and then we'd be in good shape. > > John > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 06 March, 2006 15:12 > To: Loughney John (Nokia-NRC/Helsinki); =20 > hannes.tschofenig@siemens.com; cornelia.kappler@siemens.com > Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com > Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM =20 > IANA Status/NSIS Extensibility Doc on QOSMs > > I went through the GIST IANA section with the IANA people in =20 > Vancouver. They seemed broadly happy with the format and content. =20 > The question did come up of whether there was going to be a GIST =20 > registry or an NSIS registry, and at the time I don't think I had a =20= > clear view one way or the other (or even understand the =20 > significance of the question). > > However, GIST creates 2 registries (NSLPID and MRMID) which are =20 > referred to by all NSLPs. In addition, AFAIK the NSLP object type =20 > registry is shared between all NSLPs, but GIST doesn't create it =20 > (its object types are its own), so some other mechanism is needed =20 > for that. > > The above implies to me that a single NSIS registry is more sensible. > > r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 06 March 2006 13:03 > To: hannes.tschofenig@siemens.com; cornelia.kappler@siemens.com > Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com > Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM =20 > IANA Status /NSIS Extensibility Doc on QOSMs > > The NATFW draft (& QoS draft) should actually detail the values for =20= > the registries in the IANA section, that way IANA can just review =20 > the IANA section - if they have to dig through the document, it'll =20 > be a mess. > > I also was wondering if we should have a common registry for NSIS - =20= > or seperate. Any thoughts? > > John > > From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 06 March, 2006 14:58 > To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia > Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com > Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA =20 > Status / NSIS Extensibility Doc on QOSMs > > Hi John, > > last weekend we had a face-to-face meeting with Martin, Cedric, =20 > Elwyn and myself. > We went through the NATFW NSLP and looked also at the QoS NSLP draft. > > Particuarly, the IANA consideration section in the QoS NSLP =20 > document seems to require a major re-write. > > It might be interesting to take a look at the proposal we came up =20 > with. See Section 7 of > ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp-=20 > natfw-10.txt > > We will send a more detailed mail (after the deadline) with a list =20= > of questions. > > Ciao > Hannes > > > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Gesendet: Montag, 6. M=E4rz 2006 13:52 > An: Kappler, Cornelia > Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.com > Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs > > when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs =20 > to be updated. It is too unprecise currently. > It says: "New QSPECs require IETF action which defines the elements =20= > within the QSPEC". > > (i) it probably should be "QoS Models" rather than QSPECs. One =20 > could go on and say how new QSPEC parameters (elements???) are =20 > defined but this is detailed in the QSPEC ID so it should suffice =20 > to provide a pointer. > > Fixed. > > (ii) "IETF Action" what exactly is that? I've recently been =20 > studying the IANA RFC 2434 and this is not defined there. Or is =20 > this vague on purpose / defined elsewhere? > > Along the same lines, when updating the QSPEC IANA section we were =20 > wondering what kind of IETF action is required for defining new =20 > QOSMs / QOSM IDs: Will the QOSM IDs be informational RFCs (=3D> =20 > "specification required" or "IETF Consensus" in IANA language !?) =20 > or standards track (=3D> "standards action" in IANA language)? We are =20= > currently assuming it is just "specification required" and updated =20 > the QSPEC ID accordingly. Note this implies that new _optional_ =20 > QSPEC parameters will receive this same IANA treatment because they =20= > can be defined by QOSMs. (New _mandatory_ QSPEC parameters would =20 > require standards action, because they "MUST be interpreted" by all =20= > QNEs) > > My proposal for new text in the NSIS Ext ID is "New QoS Models can =20 > be defined by providing a specification. A new QoS Model would =20 > define the QoS parameters to be carried in the QSPEC. For details =20 > see [QSPEC ID]". > > IETF action means: > > Extensions subject to "IETF Action" require either a Standards =20 > Track RFC, Experimental RFC or an Information RFC. > > Is this OK? > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-5-292026423 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi all,

I would in favour of = discussing this during the WG time in Dallas, since it involves = (probably) GIST, QoS NSLP, and the NATFW NSLP.

=A0 Martin

=A0
Am = 06.03.2006 um 14:14 schrieb <john.loughney@nokia.com> = <john.loughney@nokia.com>:
=
This is what was thinking = of as well, we can have a chat about that in Dallas (during WG time), = and then we'd be in good shape.
=A0
John


From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk= ]
Sent: 06 March, 2006 15:12
To: Loughney = John (Nokia-NRC/Helsinki); hannes.tschofenig@siemens.co= m; cornelia.kappler@siemens.com<= /A>
Cc:
gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.comSubject: RE: IANA Considerations for QoS workAW: [NSIS] RE: = QOSM IANA Status/NSIS Extensibility Doc on QOSMs

=
I went through the GIST IANA section with = the IANA people in Vancouver. They seemed broadly happy with the = format and content. The question did come up of whether there was = going to be a GIST registry or an NSIS registry, and at the time I = don't think I had a clear view one way or the other (or even understand = the significance of the question).
=A0
However, GIST creates 2 registries (NSLPID and MRMID) which = are referred to by all NSLPs. In addition, AFAIK the NSLP object type = registry is shared between all NSLPs, but GIST doesn't create it (its = object types are its own), so some other mechanism is needed for that. =
=A0
=
The above implies to me that a single = NSIS registry is more sensible.
=A0
r.
-----Original = Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com= ]
Sent: 06 March 2006 13:03
To: hannes.tschofenig@siemens.co= m; cornelia.kappler@siemens.com<= /A>
Cc:
gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.comSubject: RE: IANA Considerations for QoS workAW: [NSIS] RE: = QOSM IANA Status /NSIS Extensibility Doc on = QOSMs

The NATFW draft (& QoS draft) should actually detail = the values for the registries in the IANA section, that way IANA can = just review the IANA section - if they have to dig through the document, = it'll be a mess.
=A0
I also was wondering if we should have a = common registry for NSIS - or seperate.=A0 Any = thoughts?
=A0
John

=
From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@sie= mens.com]
Sent: 06 March, 2006 14:58
To: = Loughney John (Nokia-NRC/Helsinki); Kappler, = Cornelia
Cc: gash@att.com; = nsis@ietf.org; Attila.Bader@ericsson.comSubject: IANA Considerations for QoS workAW: [NSIS] RE: = QOSM IANA Status / NSIS Extensibility Doc on = QOSMs

Hi John,
=A0
=
last weekend we had a = face-to-face meeting with Martin, Cedric, Elwyn and myself. =
We went through the NATFW NSLP and looked also at the = QoS NSLP draft.
=A0
Particuarly, the IANA consideration section in the QoS NSLP document = seems to require a major re-write.
=A0
=
It might be interesting to = take a look at=A0the proposal we came up with. See Section 7 of =

ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-n= slp-natfw-10.txt

We will send a more detailed mail=A0 = (after the deadline)=A0with a list of = questions.

Ciao
Hannes
=
=A0


= Von: john.loughney@nokia.com = [mailto:john.loughney@nokia.com= ]
Gesendet: Montag, 6. M=E4rz 2006 = 13:52
An: Kappler, Cornelia
Cc: gash@att.com; nsis@ietf.org; Attila.Bader@ericsson.comBetreff: [NSIS] RE: QOSM IANA Status / NSIS = Extensibility Doc on QOSMs

=
when studying the NSIS Ext. ID I noticed the text in = Sec. 5 needs to be updated. It is too unprecise currently. =

It says: "New = QSPECs require IETF action which defines the elements within = the QSPEC".

(i) it probably should be "QoS = Models" rather than QSPECs. One could go on and say how new QSPEC = parameters (elements???) are defined but this is detailed in the = QSPEC ID so it should suffice to provide a pointer. =

Fixed.=A0

=A0(ii) "IETF Action" what exactly = is that? I've recently been studying the IANA RFC 2434 and this = is not defined there. Or is this vague on purpose / defined = elsewhere?

Along the same lines, when updating = the QSPEC IANA section we were wondering what kind of IETF = action is required for defining new QOSMs / QOSM IDs: Will the QOSM = IDs be informational RFCs (=3D> "specification required" or = "IETF Consensus" in IANA language !?) or standards track = (=3D> "standards action" in IANA language)? We are = currently assuming it is just "specification required" and = updated the QSPEC ID accordingly. Note this implies that new=A0 = _optional_ QSPEC parameters will receive this same IANA = treatment because they can be defined by QOSMs. (New = _mandatory_ QSPEC parameters would require standards action, because = they "MUST be interpreted" by all QNEs)

My proposal for new text in = the NSIS Ext ID is "New QoS Models can be defined by providing = a specification. A new QoS Model would define the QoS = parameters to be carried in the QSPEC. For details see [QSPEC = ID]".

=A0IETF = action means:=A0

<t>Extensions subject to "IETF Action" require either a = Standards Track=A0 = =A0RFC, Experimental RFC or an Information = RFC.</t>=A0

Is this = OK?=A0

=A0
nsis mailing list
=

= --Apple-Mail-5-292026423-- --===============1422573211== 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 --===============1422573211==-- From nsis-bounces@ietf.org Wed Mar 08 03:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuSE-000459-Hr; Wed, 08 Mar 2006 03:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuSC-00044p-J9 for nsis@ietf.org; Wed, 08 Mar 2006 03:55:32 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGuSC-0007s1-5u for nsis@ietf.org; Wed, 08 Mar 2006 03:55:32 -0500 Received: from [195.37.70.137] (unknown [195.37.70.137]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 484B31BAC99; Wed, 8 Mar 2006 09:56:02 +0100 (CET) In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869E0D@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01869E0D@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NSIS Meeting Date: Wed, 8 Mar 2006 09:55:27 +0100 To: X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Fine with me when you add the IANA topic for GIST and the NSLPs. Thanks, Martin Am 07.03.2006 um 08:27 schrieb : > Hi all, > > I am planning the meeting agenda. My rough plan is as follows: > > THURSDAY, March 23, 2006 > 0900-1130 Morning Session I > TSV nsis Next Steps in Signaling WG > > WG Status update > GIST update - 5 minutes > QoS work update - 15 minutes (QoS NSLP, various QoS model drafts) > NATFW work update - 15 minutes > Mobility discussion - 15 minutes > > mini off-path bof - 1 hour > (note - many people have been asking about this topic, so some open > discussion for the WG is warrented). > > 1510-1610 Afternoon Session II > TSV nsis Next Steps in Signaling WG > > New Work discussion - 1 hour > - I'm lumping all non-WG drafts into this hour, to get a sense of > what > people > think should be done. > - Please review the non-working drafts before the meeting and post > your > opinions if the work is of interest or not. > - http://tools.ietf.org/wg/nsis/ contains most of the drafts in > question, IMO. > > thoughts, comments? > > 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 Wed Mar 08 04:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuaW-0007B0-Ls; Wed, 08 Mar 2006 04:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuaU-00075S-Oj for nsis@ietf.org; Wed, 08 Mar 2006 04:04:06 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGuaU-0008Rg-Bj for nsis@ietf.org; Wed, 08 Mar 2006 04:04:06 -0500 Received: from [195.37.70.137] (unknown [195.37.70.137]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 547FB1BAC9E; Wed, 8 Mar 2006 10:04:36 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs Date: Wed, 8 Mar 2006 10:03:59 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: john.loughney@nokia.com, gash@att.com, nsis@ietf.org, hannes.tschofenig@siemens.com, Attila.Bader@ericsson.com, Roland Bless , cornelia.kappler@siemens.com 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 07.03.2006 um 14:50 schrieb Hancock, Robert: [...] >> >> >> Hi Robert, >> >>> However, GIST creates 2 registries (NSLPID and MRMID) which are >>> referred to by all NSLPs. In addition, AFAIK the NSLP object type >>> registry is shared between all NSLPs, but GIST doesn't >> create it (its >>> object types are its own), so some other mechanism is needed for >>> that. >> >> Does it really make sense to have a shared NSLP object type registry? >> Do we have common objects? Any advantages compared to NSLP specific >> types? > > it's an old discussion; see for example the thread starting here > http://www1.ietf.org/mail-archive/web/nsis/current/msg03990.html > (2004, how time flies...) > > i don't know whether it's possible or desirable to reopen it. I wouldn't like to reopen it but at the point when discussing it in the past, we haven't had the NSLPs we have now. I would prefer a short status check whether the assumptions of the 2004 discussions still hold. There is also another issue: The error code registry. I think this is going to separated between the different NSLPs, since the severity classes of the QoS and NATFW NSLP differ quite much as the response codes do as well. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 08 09:45:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzvE-0003B1-K0; Wed, 08 Mar 2006 09:45:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzvD-00036s-0i for nsis@ietf.org; Wed, 08 Mar 2006 09:45:51 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzvC-0003qj-Iw for nsis@ietf.org; Wed, 08 Mar 2006 09:45:50 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k28Ejmk1003657 for ; Wed, 8 Mar 2006 16:45:49 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 16:45:16 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 16:45:16 +0200 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 Working Group Last call on "RMD - The ResourceManagement in Diffserv QOS Model" Date: Wed, 8 Mar 2006 16:45:16 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869E93@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: [NSIS] NSIS Working Group Last call on "RMD - The ResourceManagement in Diffserv QOS Model" Thread-Index: AcZB1bB4EMld5FdOQH6/ro2Pk+uBBAAAAtjAADnOqOAAAHgpcA== From: To: X-OriginalArrivalTime: 08 Mar 2006 14:45:16.0631 (UTC) FILETIME=[EA276E70:01C642BE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 to let you all know, the planned status is that this would be an Information document. John >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: 07 March 2006 10:57 >To: nsis@ietf.org >Subject: [NSIS] NSIS Working Group Last call on "RMD - The=20 >ResourceManagement in Diffserv QOS Model" > >Hi all, > >It seems that the remaining open issues on "RMD - The Resource=20 >Management in Diffserv QOS Model"=20 >have been closed. I would like to start a 2 week WGLC on this=20 >draft, which will bring us to March 21st. > >Please submit issues and text recommendations for the draft. =20 >If you have read the draft, and you think it is in good shape,=20 >then please let us know. > >You can find the draft at: >http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-06.txt > >John > >PS - BCC'ed to TSVWG WG, please reply on the NSIS mailing=20 >list. If you are not a subscriber, I will approve posting=20 >rights for you. > >_______________________________________________ >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 09 05:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHI6A-0004ix-NV; Thu, 09 Mar 2006 05:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHI69-0004g5-4m for nsis@ietf.org; Thu, 09 Mar 2006 05:10:21 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHI67-0003x7-R7 for nsis@ietf.org; Thu, 09 Mar 2006 05:10:21 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FHI5s-0005sF-OJ; Thu, 09 Mar 2006 11:10:08 +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 73AB48A35; Thu, 9 Mar 2006 11:10:04 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FHI5s-0002Hc-4k; Thu, 09 Mar 2006 11:10:04 +0100 Message-ID: <440FFEFB.5090306@tm.uka.de> Date: Thu, 09 Mar 2006 11:10:03 +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] QoS NSLP updated References: <4408D872.9050003@cs.uni-goettingen.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Jukka, > On Sat, 4 Mar 2006, Bernd Schloer wrote: > >> Hi Jukka, >> >> a few things are not quite clear to me: >> >> Who is responsible to trigger the Refresh Messages? Is it the QNI or the >> Client Application connected to the QNI? > > Page 4: > "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 > [RFC2205], and uses soft-state peer-to-peer refresh messages as the > primary state management mechanism (i.e. state installation/refresh > is performed between pairs of adjacent NSLP nodes, rather than in an > end-to-end fashion along the complete signalling path)." The latter is, however, possible in case one uses a refreshing RESERVE with an RII object included: 5.1.2.1. RESERVE ... A refresh right along the path can be forced by requesting a RESPONSE from the far end (i.e. (i.e., by including an RII object in the RESERVE message). I still don't know what it's good for... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 09 06:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJXI-0000iv-Vz; Thu, 09 Mar 2006 06:42:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJXH-0000iq-Ub for nsis@ietf.org; Thu, 09 Mar 2006 06:42:27 -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 1FHJXG-0006wC-Kp for nsis@ietf.org; Thu, 09 Mar 2006 06:42:27 -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; Thu, 09 Mar 2006 13:42:25 +0200 id 000702DF.441014A1.00005857 Date: Thu, 9 Mar 2006 13:42:25 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP updated In-Reply-To: <440FFEFB.5090306@tm.uka.de> Message-ID: References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@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: 4adaf050708fb13be3316a9eee889caa 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, The "forced" refresh is useful to have, and makes it possible for any node to force a refresh operation to be carried. For example, a mobility anchor point may get to know that an MN has moved, and can force a refresh towards the MN. A similar indication and a subsequent refresh can happen with Mobile IP, when the HA, or CN receive a binding update, and know that the path near the MN has changed. Regards, Jukka On Thu, 9 Mar 2006, Roland Bless wrote: > Hi Jukka, > > > On Sat, 4 Mar 2006, Bernd Schloer wrote: > > > >> Hi Jukka, > >> > >> a few things are not quite clear to me: > >> > >> Who is responsible to trigger the Refresh Messages? Is it the QNI or the > >> Client Application connected to the QNI? > > > > Page 4: > > "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 > > [RFC2205], and uses soft-state peer-to-peer refresh messages as the > > primary state management mechanism (i.e. state installation/refresh > > is performed between pairs of adjacent NSLP nodes, rather than in an > > end-to-end fashion along the complete signalling path)." > > The latter is, however, possible in case one uses a refreshing RESERVE > with an RII object included: > 5.1.2.1. RESERVE > ... > A refresh right along the path can be forced by requesting a RESPONSE > from the far end (i.e. (i.e., by including an RII object in the RESERVE > message). > > I still don't know what it's good for... > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 09 08:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKpD-0000fF-2U; Thu, 09 Mar 2006 08:05:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKpB-0000ck-Mx for nsis@ietf.org; Thu, 09 Mar 2006 08:05:01 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKpB-0000r9-9F for nsis@ietf.org; Thu, 09 Mar 2006 08:05:01 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FHKp6-0006Dk-R7; Thu, 09 Mar 2006 14:04:59 +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 6CBAB853C; Thu, 9 Mar 2006 14:04:56 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FHKp5-0002Ut-Sq; Thu, 09 Mar 2006 14:04:55 +0100 Message-ID: <441027F7.4040006@tm.uka.de> Date: Thu, 09 Mar 2006 14:04: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: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP updated References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Jukka, > The "forced" refresh is useful to have, and makes it possible for any node ^^^^^^^^^ Yes, I'm interested in examples that show its usefulness (they should possibly mentioned in the draft section 4). > to force a refresh operation to be carried. For example, a mobility anchor > point may get to know that an MN has moved, and can force a refresh > towards the MN. A similar indication and a subsequent refresh can happen Hm, I don't quite get it. In case the MN has moved he also changed his CoA and thus the MRI, and, in this case, the MAP will usually send a new RESERVE with a different MRI. > with Mobile IP, when the HA, or CN receive a binding update, and know that > the path near the MN has changed. I don't see why a forced refresh will help much in mobility scenarios. Basically what you achieve with a forced refresh is that the state along the whole path doesn't expire, but states will not expire using the normal peer refreshes in case nothing else changed. So in case the routing in the network didn't change, the refreshing RESERVE will take exactly the same path as before. If the MN has changed its CoA, you will usually end up sending a RESERVE with a different MRI which then may traverse along a new path. Then states along the unchanged path are refreshed anyway. The only benefit would be IMHO to force a refresh before a handover so that the time period for performing the handover is long enough to keep the reservation while the QNI moves. But this could be achieved by an ordinary refresh, too. Regards, Roland > On Thu, 9 Mar 2006, Roland Bless wrote: > >> Hi Jukka, >> >>> On Sat, 4 Mar 2006, Bernd Schloer wrote: >>> >>>> Hi Jukka, >>>> >>>> a few things are not quite clear to me: >>>> >>>> Who is responsible to trigger the Refresh Messages? Is it the QNI or the >>>> Client Application connected to the QNI? >>> Page 4: >>> "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 >>> [RFC2205], and uses soft-state peer-to-peer refresh messages as the >>> primary state management mechanism (i.e. state installation/refresh >>> is performed between pairs of adjacent NSLP nodes, rather than in an >>> end-to-end fashion along the complete signalling path)." >> The latter is, however, possible in case one uses a refreshing RESERVE >> with an RII object included: >> 5.1.2.1. RESERVE >> ... >> A refresh right along the path can be forced by requesting a RESPONSE >> from the far end (i.e. (i.e., by including an RII object in the RESERVE >> message). >> >> I still don't know what it's good for... >> >> Regards, >> Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 09 12:23:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOrU-0003nV-9R; Thu, 09 Mar 2006 12:23:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOrS-0003nQ-TI for nsis@ietf.org; Thu, 09 Mar 2006 12:23:38 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOrP-0000mL-Gm for nsis@ietf.org; Thu, 09 Mar 2006 12:23:38 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k29HN1oW026733; Thu, 9 Mar 2006 17:23:01 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:23:00 +0000 Message-ID: <44106474.9020004@roke.co.uk> Date: Thu, 09 Mar 2006 17:23:00 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jukka MJ Manner , Georgios Karagiannis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 17:23:00.0995 (UTC) FILETIME=[1DC48530:01C6439E] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nsis@ietf.org Subject: [NSIS] QoS NSLP INFO_SPEC and error codes 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 A few comments in the area of the INFO_SPEC object and error codes. Draft -10 doesn't seem to have appeared yet, but these comments apply equally to -09 and -10. Protocol errors include: * 0x08 - Unknown QSPEC type: the QoS Model ID refers to a QoS Model which is not known by this QNE. It's not clear to me that is a protocol error. Firstly, QoS Model ID is inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly, my understanding from the QSPEC template is that, in the case of an unknown QoS Model ID, the RMF should continue to process mandatory QSPEC parameters. Transient failure codes include: * 0x01 - Requested resources not available * 0x02 - Insufficient bandwidth available * 0x03 - Delay requirement cannot be met Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since they directly relate to information in the QSPEC rather than the main QoS NSLP data? There are two transient error codes: * 0x05 - Resources pre-empted * 0x09 - Reservation pre-empted but I don't see how these differ. Similarly, the difference between these two is unclear to me: * 0x06 - No GIST reverse-path forwarding state * 0x08 - No path state for RESERVE, when doing a receiver- oriented reservation The Information/Success/ProtocolError codes have a sentence of explanation as well as the 'error name'. Would it be useful to add something for the other codes too? I eventually found what "RII conflict" was, but I'm still not sure about "Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE". It is not totally clear which errors the optional error specific information is appropriate for. I think it would be useful to list them explicitly (otherwise there is some ambiguity about whether you are decoding an 'Object Value Info' or 'Object Type Info'. Section 5.3.5 on the INFO_SPEC object seemed overly long (it is the longest description of any QoS NSLP object, though I would have thought it was one of the least complicated). Most of the text in the sections 5.3.5.x is repeated. Can we try to trim this text down a bit? I'd rather see some text saying what the usual processing of an INFO_SPEC is, and then identify any differences that occur due to the different error classes. Also, a sizeable amount of the text in 5.3.5.x is a repeat of the error code lists from 5.1.3.6 - it's probably better to keep these in one place (either 5.1.3.6 or 5.3.5). regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 09 15:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5E-0000vP-E9; Thu, 09 Mar 2006 15:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5C-0000ua-Ic; Thu, 09 Mar 2006 15:50:02 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS5B-0007DY-V3; Thu, 09 Mar 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko19W015523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5B-0008VR-K4; Thu, 09 Mar 2006 15:50:01 -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, 09 Mar 2006 15:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-applicability-mobility-signaling-04.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-04.txt Pages : 73 Date : 2006-3-9 The 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 protocols, and how the protocols operate in different scenarios, and together with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-04.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-04.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-04.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: <2006-3-9104032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9104032.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 09 18:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUtU-0002hV-47; Thu, 09 Mar 2006 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 1FHUtO-0002gb-Pu; Thu, 09 Mar 2006 18:50:02 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHUtO-0006RT-Ck; Thu, 09 Mar 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k29No10e023422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHUtN-000467-S6; Thu, 09 Mar 2006 18:50:01 -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, 09 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-10.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-10.txt Pages : 78 Date : 2006-3-9 This draft describes an 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 draft explains the overall protocol approach, design decisions made and provides examples. It specifies object and message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.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-10.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-10.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: <2006-3-9150320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9150320.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 10 01:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHarI-0000AH-SC; Fri, 10 Mar 2006 01:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHarF-00008n-HP for nsis@ietf.org; Fri, 10 Mar 2006 01:12:13 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHarB-0001la-7t for nsis@ietf.org; Fri, 10 Mar 2006 01:12:13 -0500 Received: from [192.168.178.22] (p54ACA0C6.dip0.t-ipconnect.de [84.172.160.198]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A11421BAC4D for ; Fri, 10 Mar 2006 07:12:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Fri, 10 Mar 2006 07:11:53 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] New NATFW NSLP Version (-10) 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 has been a problem in the I-D submission process and the NATFW NSLP has not yet shown up in the I-D repository. Please find a copy of the draft here until the draft appears in the repository: ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp- natfw-10.txt The html diff between the version -09 and -10 is available here: http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-10- diff-to-09.html Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 11:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHktI-0005Zs-Lg; Fri, 10 Mar 2006 11:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHktH-0005WX-Pa for nsis@ietf.org; Fri, 10 Mar 2006 11:54:59 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHktF-0004rV-7Z for nsis@ietf.org; Fri, 10 Mar 2006 11:54:59 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FHkt4-0000iT-LR; Fri, 10 Mar 2006 17:54:49 +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 68E88A541; Fri, 10 Mar 2006 17:54:46 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FHkt4-0004UT-2M; Fri, 10 Mar 2006 17:54:46 +0100 Message-ID: <4411AF55.6080701@tm.uka.de> Date: Fri, 10 Mar 2006 17:54:45 +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] Re: QoS NSLP: ACK flag has no effect? References: <43E282E1.3040306@tm.uka.de> <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> <43FA4B8F.7030607@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Andrew McDonald , 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, [sorry, but I guess that I have still some major issues with the ACK] Jukka MJ Manner wrote: > No objections here. I'm really sorry, but I was thinking again about this ACK mechanism, because I'm not really convinced of its usefulness in general. It will mean _a lot_ of overhead. When reading the motivation (which was added later on my request) in section 3.2.4.: "This mechanism enables a QoS NSLP instance to rapidly detect a failure of the peer QoS NSLP instance or the underlying transport, i.e., either GIST itself or the used transport protocol below, e.g., TCP." (BTW this doesn't fit exactly to the section topic "Explicit state installation confirmation and responses"). The described goal could be achieved with less overhead by using a heartbeat mechanism per peer rather than requiring an ACK for each RESERVE (per flow). Sure, the latter contains also more information, because it is a confirmation of state installation action, but I'm not really sure that we need it all, because it is of limited use anyway compared to the RESPONSE triggered by an RII object. The only two potential other reasons in the current draft may be: - use of unreliable GIST transport (in this case we obviously don't care about the RESERVE's fate and should not try to add reliability, otherwise we better request a reliable transport from GIST) => no reason - for acknowledgment of reduced refreshes (as indicated in section 3.2.5): "These reduced refreshes require an explicit acknowledgment of state installation to ensure that the RSN reference will be understood. It is up to a QNE that receives a message containing an RII to decide whether it wants to accept reduced refreshes and provide this explicit acknowledgment." Besides the fact that I don't understand the last sentence I also don't know why reduced refreshes require an ACK and what means: "that the RSN reference will be understood". -> in case the reservation is unknown we'll get a RESPONSE back with "full QSPEC required", no ACK required -> in case the RSN is somehow out of sync (how should this happen, and, this could also be the case for normal, not reduced refreshes, so it is not specific to reduced refreshes) we may have a problem. Suppose a node sends a refresh with a smaller RSN than expected then it will be ignored and the state at the next node will timeout after a while. In case the RSN is higher than expected, the node will also emit a RESPONSE with full QSPEC required. So I don't see the usefulness of the proposed ACK. Consequently I would prefer removal of the ACK flag and possibly provide a simple HELLO mechanism (with adjustable timeouts) between peers to detect communication failures. I really don't know what fast reaction an application could undertake due a transmission/processing failure of a RESERVE message that was detected by the currently proposed ACK mechanism. -> see below >>REPLACE: >>5.2.4. Retransmissions >> >> There are two retransmission mechanisms for RESERVE, one for >> retransmissions between two directly adjacent QNEs (using the ACK >> flag), and one for end-to-end retransmissions, e.g., between >> QNI and QNR (using an RII object). >> >> First, in case a QNE transmits a RESERVE with a set ACK flag it >> awaits a RESPONSE (either positive or an error) from the receiving >> QNE as acknowledgment of processing the REQUEST. If there is no such >> acknowledgment, the sender may resend the same message after a >> timeout of QOSNSLP_ACK_WAIT with an initial value of 500 ms. >> The timeout may be dynamically determined like the RTO for TCP >> in rules 2.2 and 2.3 from [RFC 2988]. An implementation MAY cache >> the last RTO measurement as the initial value for future requests >> to the QNE. Further retransmissions may be initiated with >> exponentially increasing wait intervals (doubling the wait interval >> each time) up to QOSNSLP_ACK_WAIT_MAX (defaults to 2s) after ^^^^^^^^^^^^^^^ better: (defaults to QOSNSLP_REQUEST_RETRY, see below) >> the initial transmission. The latter limit is provided to ensure >> a fast reaction to failures and to avoid conflicts with a potential >> retransmission when an included RII object will trigger another >> retransmission. In case no RII object is contained in the Nevertheless an incoming retransmission by the RII inserting node could happen well before QOSNSLP_ACK_WAIT_MAX and should stop therefore stop any local retransmissions. >> RESERVE, a failure should be indicated to the signaling >> application. Is this enough? Shouldn't the application send a NOTIFY upstream indicating a transport failure? What can the application do about it? Possibly a rerouting will happen in case there are alternatives, but if there aren't any we have a longer-term problem anyway. >> >> Second, in case a QNE transmits a RESERVE with an RII object set it >> waits for a RESPONSE from the responding QNE. >> QoS-NSLP messages for which a response is requested by including >> an RII object, but fail to elicit a response are retransmitted. >> The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY >> wait period. Retransmissions MUST be made with exponentially >> increasing wait intervals (doubling the wait each time). QoS-NSLP >> messages should be retransmitted until either a response (which might >> be an error) has been obtained, or until QOSNSLP_RETRY_MAX seconds >> after the initial transmission. In the latter case, a failure should >> be indicated to the signaling application. Retransmissions as proposed in the latter paragraph should be kept though. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 12:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlFf-00027P-EB; Fri, 10 Mar 2006 12:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlFd-00023E-4Q for nsis@ietf.org; Fri, 10 Mar 2006 12:18:05 -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 1FHlFc-0005w7-Hs for nsis@ietf.org; Fri, 10 Mar 2006 12:18:04 -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; Fri, 10 Mar 2006 19:18:03 +0200 id 0007014E.4411B4CB.000005B0 Date: Fri, 10 Mar 2006 19:18:03 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP updated In-Reply-To: <441027F7.4040006@tm.uka.de> Message-ID: References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> <441027F7.4040006@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: b280b4db656c3ca28dd62e5e0b03daa8 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, If you use a local mobility management scheme, controlled by a MAP, then you don't need to change the IP address after each handover. Thus, a refresh from the MAP towards the MN will look like an ordinary refresh, and will not help in making reservations closer to the MN, say, at the access router. If you can force a refresh, you can repair the reservation faster. Jukka On Thu, 9 Mar 2006, Roland Bless wrote: > Hi Jukka, > > > The "forced" refresh is useful to have, and makes it possible for any node > ^^^^^^^^^ > Yes, I'm interested in examples that show its usefulness (they should > possibly mentioned in the draft section 4). > > > to force a refresh operation to be carried. For example, a mobility anchor > > point may get to know that an MN has moved, and can force a refresh > > towards the MN. A similar indication and a subsequent refresh can happen > > Hm, I don't quite get it. In case the MN has moved he also > changed his CoA and thus the MRI, and, in this case, the MAP will > usually send a new RESERVE with a different MRI. > > > with Mobile IP, when the HA, or CN receive a binding update, and know that > > the path near the MN has changed. > > I don't see why a forced refresh will help much in mobility scenarios. > Basically what you achieve with a forced refresh is that the state > along the whole path doesn't expire, but states will not expire > using the normal peer refreshes in case nothing else changed. > So in case the routing in the network didn't change, the refreshing > RESERVE will take exactly the same path as before. If the MN has changed > its CoA, you will usually end up sending a RESERVE with a different MRI > which then may traverse along a new path. Then states along the > unchanged path are refreshed anyway. > The only benefit would be IMHO to force a refresh before a handover > so that the time period for performing the handover is long enough > to keep the reservation while the QNI moves. But this could be achieved > by an ordinary refresh, too. > > Regards, > Roland > > > On Thu, 9 Mar 2006, Roland Bless wrote: > > > >> Hi Jukka, > >> > >>> On Sat, 4 Mar 2006, Bernd Schloer wrote: > >>> > >>>> Hi Jukka, > >>>> > >>>> a few things are not quite clear to me: > >>>> > >>>> Who is responsible to trigger the Refresh Messages? Is it the QNI or the > >>>> Client Application connected to the QNI? > >>> Page 4: > >>> "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 > >>> [RFC2205], and uses soft-state peer-to-peer refresh messages as the > >>> primary state management mechanism (i.e. state installation/refresh > >>> is performed between pairs of adjacent NSLP nodes, rather than in an > >>> end-to-end fashion along the complete signalling path)." > >> The latter is, however, possible in case one uses a refreshing RESERVE > >> with an RII object included: > >> 5.1.2.1. RESERVE > >> ... > >> A refresh right along the path can be forced by requesting a RESPONSE > >> from the far end (i.e. (i.e., by including an RII object in the RESERVE > >> message). > >> > >> I still don't know what it's good for... > >> > >> Regards, > >> Roland > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 17:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpqq-0004gU-EO; Fri, 10 Mar 2006 17:12:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpqp-0004gO-3L for nsis@ietf.org; Fri, 10 Mar 2006 17:12:47 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHpql-0001i1-S3 for nsis@ietf.org; Fri, 10 Mar 2006 17:12:47 -0500 Received: from ccs (dhcp-65-64.ee.columbia.edu [128.59.65.64]) (user=qs2005 mech=LOGIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2AMChKE027813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 10 Mar 2006 17:12:43 -0500 (EST) From: "Charles Shen" To: Date: Fri, 10 Mar 2006 17:12:43 -0500 Organization: Columbia University Message-ID: <003b01c6448f$c0f854b0$40413b80@ccs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZEj8C353hkr/xaQB+osksMEbnScw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [NSIS] Fw: I-D ACTION:draft-shen-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 Dear all, The NSIS-tunnel draft has been updated, http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-02.txt Comments greatly appreciated. Best regards, Charles Ps. 9.3.1. Changes in Version -02 1. Rearranged section names to emphasize the difference between dynamically created tunnel sessions and pre-configured tunnel sessions. 2. Added implementation considerations section about how to deal with the race condition in the separate session model, and allowed the dynamically created tunnel session to be an aggregate session. 3. Added operation examples on the two scenarios where e2e and tunnel session uses different signaling initiation modes. 4. Removed the illustration of binding_code for tunnel BOUND_SESSION_ID object since it has been added to NSLP specification. 5. Clarified that tunnel capability discovery is at NSLP layer. 6. Updated some of the message processing rules. 7. Updated some parts of the appendix. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 18:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHr8p-0005KO-CE; Fri, 10 Mar 2006 18:35:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHr8o-0005I9-Ac for nsis@ietf.org; Fri, 10 Mar 2006 18:35:26 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHr8m-0004HY-60 for nsis@ietf.org; Fri, 10 Mar 2006 18:35:26 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FHr8L-0001RF-VQ; Sat, 11 Mar 2006 00:35: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 C3B00853C; Sat, 11 Mar 2006 00:34:57 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FHr8L-0004i7-2e; Sat, 11 Mar 2006 00:34:57 +0100 Message-ID: <44120CCA.40306@tm.uka.de> Date: Sat, 11 Mar 2006 00:33:30 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Andrew McDonald Subject: Re: [NSIS] QoS NSLP: rerouting issues References: <43CE14CD.9030604@roke.co.uk> <43E279FA.3040304@tm.uka.de> <44073056.5020902@roke.co.uk> In-Reply-To: <44073056.5020902@roke.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: Georgios Karagiannis , Jukka MJ Manner , 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, > Thanks for looking at this. Sorry for the slow reply, this e-mail got > half-written and I didn't get round to finishing it. Some > replies/comments below. Dito. I was moving within the last weeks, so I had time for another look at the draft in the last days merely. I think it's good that the WGLC was extended since I found more fundamental issues :-( Please see below. > Roland Bless wrote: >>> Proposed updates: >>> >>> ##### section 3.2.10 ##### >>> >> >> [previous text ok.] >> >>> Reservation on the new path happens when a refreshing RESERVE message >>> arrives at the QNE where the old and the new path diverge. The >>> refreshing RESERVE will be interpreted as a new RESERVE on the new >>> path. Depending on the transfer mode, this may require installation >> >> >> Hm, I'm a little bit confused about this statement. The incoming >> refreshing RESERVE will usually _not_ trigger a transmission of >> a new RESERVE along the new path. Refreshing state is independently >> triggered at each node rather than a refreshing RESERVE traversing >> the path downstream. The branching node (i.e. the QNE >> where the old and the new path diverge) will send a refresh >> to his downstream peer. If rerouting happens, there >> are different cases to be considered: >> - GIST will detect a new path by its own mechanism, i.e. while >> sending an NTLP refresh. In this case a notification may be given >> to the NSLP that a downstream SII has changed. This should >> trigger immediate sending of a refreshing RESERVE (usually >> with full QSPEC and RII, otherwise we'll get an error back first). >> - NSLP has to send a refresh to its downstream peer, because the refresh >> timer expired. GIST will find the new route then, notify NSLP of a >> new SII and will also get back an error message from its downstream >> peer, because he needs a full QSPEC. NSLP then should send the RESERVE >> with RII and full QSPEC again. > > Yes, rereading this I'm a little bit confused too. :-) > > Most of the 3.2.10 text is unchanged from -08 (mostly deleted/reworded > rather than added text), so we should probably have noticed this before. > :-) > > I think we could say: > > Reservation on the new path happens when a RESERVE message arrives at > the QNE beyond the point where the old and new paths diverge. A > refreshing RESERVE (with no QSpec) will be identified as an error by a > QNE on the new path. It will send back an error message which results in > a full RESERVE message being sent. Depending on the transfer mode, this > may require installation ... Sounds better, but the second sentence holds only in case we hit a "new" QNE: in case the QNE is the same as before, it will not send back an error message >>> of a new messaging association. Rapid recovery at the NSLP layer >>> therefore requires short refresh periods. Detection before the next >>> RESERVE message arrives is only possible at the IP layer or through >>> monitoring of GIST peering relations (e.g. by TTL counting the >>> number of GIST hops between NSLP peers or the observing changes in >>> the outgoing interface towards GIST peer). These mechanisms can >>> provide implementation specific optimisations, and are outside the >>> scope of this specification. >> >> >> Yep. >> >> >>> When the QoS NSLP is aware of the route change, it needs to set up >>> the reservation on the new path. This is done by incrementing the >>> RSN and then sending a new RESERVE message. On links that are common >>> to the old and the new path, this RESERVE message is interpreted as a >>> refreshing RESERVE. On new links, it creates the reservation. >> >> >> Not quite correct. Incrementing the RSN is not necessary in this >> case and contradicts to the statement that an increased RSN indicates >> a changed session. Furthermore, remember that an RSN has only >> local significance. >> Because the RSN is different it will not directly >> be considered as refresh by nodes that know this session. >> Only if the QSPEC and MRI did not change, >> then there is no need to send it further along the path. >> I would suggest that we clarify text when to "forward" >> a RESERVE (at end of sec. 5.4.1) or TEAR anyway. >> Section 5.3.1. states >> It MUST be incremented for each new RESERVE message where the >> reservation for the session changes. >> Strictly speaking the above statement does not infer that >> a new RSN necessarily means that the session changes. But >> in case nothing changed, the RSN must stay the same. >> >> Let's look what happens: the branching node should send >> a full refreshing RESERVE (RSN not changed, added RII) along the new >> link. If the next QNE is really a new peer that doesn't >> know about the reservation, it will setup a new reservation >> anyway. In this case this QNE will also emit a _new_ RESERVE >> (include a new RSN, because the QNE is new). In case the >> RESERVE hits the merging node again, the latter should >> detect that: it knows the referenced session and that it >> has a new upstream peer. But because neither MRI nor QSPEC >> are changed, a new RESERVE along the unchanged path will >> not be triggered (the normal refreshing RESERVE will be sent >> when the refreshing timer fires). > > Yes, RSN does not need to be incremented since the same reservation is > being requested. (I'd probably say 'changed reservation' or 'changed > state' rather than 'changed session'). > > However, there is the issue of wanting to send a TEAR and not being 100% > certain whether the next peer has changed (third paragraph of section > 5.2.5.2). Nice trick with the RSN+2 and RSN-1, but is it really necessary? Last paragraph of 5.2.5.2 should be sufficient: A node receiving a RESERVE message with the TEAR flag set which does not come from the current peer QNE, identified by its SII, MUST be ignored and MUST NOT be forwarded. So even when the tearing RESERVE arrives at the same QNE as before but over a different incoming link or i/f, the SII will be different and the last condition will hold, or am I missing something? Further and NEW but also more general issue in a similar context: if I remember correctly RSVP sends a PathTEAR in case state expires. QoS NSLP doesn't do so. However, in case we have a node failure etc. re-routing will possibly happen which will then trigger the explicit TEAR from the branching node, right? In this particular case reservations along the old branch will be torn down relatively fast. But the forwarding of the tearing RESERVE may, however, stop at a failed node. State in subsequent nodes may take a long time until they expire if we don't send a tearing RESERVE upon state expiration. >> The last two sentences are confusing, because >> the RESERVE will not be forwarded (esp. not with the very same RSN). >> Correct would be: The RESERVE may be sent along a new link but possibly >> hits the same QNE as before (multi-homing scenario). In this case the >> QNE will consider the RESERVE as refresh. If a new QNE is hit, it will >> establish a new reservation (if possible) and send a new RESERVE >> downstream. > > Agreed. I think this is remnants of a time when we weren't so clear what > service abstract-NTLP/GIMPS/GIST would provide. > > I suggest replacing this paragraph and removing the details which fit > better into section 5. > > Suggested replacement: > When the QoS NSLP is aware of the route change, it needs to set up the > reservation on the new path. This is done by sending a new RESERVE > message. If the next QNE is, in fact, unchanged then this will be used > to refresh/update the existing reservation. Otherwise it will lead to > the reservation being installed on the new path. Ok. >>> After the reservation on the new path is set up, the branching node >>> or the merging node may want to tear down the reservation on the old >>> path (faster than what would result from normal soft-state time-out). >> >> >> As already written earlier >> (http://www.ietf.org/mail-archive/web/nsis/current/msg05826.html): >> I don't know how the merging node (i.e. the node where the paths >> join again) should TEAR down the session. >> Currently this is not possible because a RESERVE with TEAR can only >> flow in the direction from QNI to QNR. > > Agreed. > > This paragraph also has some old 'requests GIST to provide' text. > > Suggested replacement: > After the reservation on the new path is set up, the branching nodenode s/nodenode/node > may want to tear down the reservation on the old path (sooner than would > result from normal soft-state time-out). This functionality is supported > by keeping track of the old SII-Handle provided over the GIST API. This > handle can be used by the QoS NSLP to route messages explicitly to the > next node. Ok. >>> When the QoS NSLP is aware of the route change, it needs to set up >>> the reservation on the new path. This is done by incrementing the >>> RSN and sending a RESERVE message. On links that are common to the >>> old and the new path, this RESERVE message is interpreted as a >>> refreshing RESERVE. On new links, it creates the reservation. >> >> >> This is the same text as above. I'm not really sure that we need >> this redundancy. >> >> >>> After the reservation on the new path is set up, the branching node or >>> the merging node may want to tear down the reservation on the old path >> >> >> Only the branching node... see above > > > Would it be better to fold the remaining non-redundant parts of 4.8 into > 3.2.10? Section 4,8 should describe an example, so protocol behavior should better be described in section 3.2.10 and in more detail in section 5.2.5. >>> downstream peer. A QNE that has detected the route change via the >>> SII change sends a RESERVE message towards the QNR on the old path >>> (using the old SII) with the TEAR flag set. Note that in case of >> >> >> This TEAR would IMHO be too early. The TEAR should be triggered by the >> RESPONSE to the RESERVE on the new path indicating that the reservation >> is already installed. > > Yes. > >>> receiver-initiated reservations, this involves a QNE that is notified >>> of the route change in another way and wants to tear down the old >>> branch needs to send the RESERVE on the new path with an RII object. >>> When it receives the RESPONSE message back, it can check whether its >>> peer has effectively changed and send a RESERVE with the TEAR flag >>> set if it has. Otherwise, teardown is not needed. A QNE that is >>> unable to support an RII or does not receive a RESPONSE needs to rely >>> on soft-state timeout on the old branch. >> >> >> This is ok, but also applicable to the sender-initiated case. > > Yes. > > I find the last sentences of this paragraph unclear. I'm not sure that > they're saying anything particularly useful (i.e. provides useful > information beyond that in section 3.2.10). > > Generally 4.8 feels a bit repetitive of 3.2.10. There's possibly some > new content in the last paragraph. Maybe that could be folded in to > 3.2.10, and remove 4.8? You are right. The current section 4.8 (of draft -10), however, is still not correct. I would really describe a scenario and which protocol actions happen (which is not so easy, because the details are defined in section 5). >>> QoS NSLP is notified by GIST when GIST believes that a rerouting event >>> may have occurred. As part of the API, GIST provides an SII-Handle >>> which can be used by the NSLP to direct a signalling message to a >>> particular peer. The current SII-Handle will change if the signalling >>> peer changes. However, it is not guaranteed to remain the same after a >>> rerouting event where the peer does not change. Therefore, the QoS >>> NSLP mechanism for reservation maintenance after a route change >>> includes robustness mechanisms to avoid accidentally tearing down a >>> reservation in situations where the peer QNE has remained the same >>> after a 'route change' notification from GIST. >>> >>> When a QNE detects that its neighbour QNE in the direction of the QNR >>> has changed, it SHOULD send a RESERVE message, including the full >>> QSPEC. This RESERVE message MUST include an RII, to request a response >>> from the QNR. When sending this message the RSN MUST be incremented by >>> two (and this becomes the current RSN value). An SII MUST NOT be >>> specified when passing this message over the API to GIST, so that it >>> is correctly routed to the new peer QNE. >>> >>> When the QNE receives the RESPONSE message that relates to that the >>> RESERVE message sent down the new path, it SHOULD send a RESERVE >>> message with the TEAR flag sent down the old path, by specifying the >>> SII relating to the old peer QNE. When sending this RESERVE message >>> the RSN field MUST be set to one less than the current RSN value (and >>> the current RSN value remains unchanged). This 'RSN-1' will cause the >>> message to be reject by the next peer if the old and new next peers >>> are actually the same. >>> >>> Depending on the particular route change, there may be a 'merge point' >>> (or 'crossover node') where the old and new paths merge. Initially this >>> has a reservation installed by the old peer QNE, identified by an old >>> SII. When the new reservation is installed after the route change the >>> new peer QNE will be identified by a new SII. At a later point the >>> crossover node may receive a RESERVE message with the TEAR flag set >>> from the QNE identified by the old SII. A node receiving a RESERVE >>> message with the TEAR flag set which does not come from the current >>> peer QNE, identified by its SII, MUST be ignored and MUST NOT be >>> forwarded. >> >> >> Yep. Therefore, we should exactly describe at the end of the >> RESERVE section 5.4.1 that a RESERVE with a TEAR should >> not be sent to the next peer in this case. > > I'd probably put this in after paragraph 4 of 5.4.1 (The one beginning > "When the RESERVE is authorized..."), so it is with the other text > discussing the TEAR flag. > > Suggested text: > As discussed in section 5.2.5.2, to avoid incorrect removal of state > after a rerouting event, a node receiving a RESERVE message with the > TEAR flag set which does not come from the current peer QNE, identified > by its SII, MUST be ignored and MUST NOT be forwarded. See above... >>> .sh 4 "Upstream route change notification" >>> >>> GIST may notify QoS NSLP that a possible upstream route change has >>> occurred over the GIST API. On receiving such a notification, QoS NSLP >>> SHOULD send a NOTIFY message with Informational code ????? for >>> signalling sessions associated with the identified MRI. >>> >>> On receiving such a NOTIFY message, QoS NSLP SHOULD use the >>> InvalidateRoutingState API call to inform GIST that routing state >>> may be out of date. QoS NSLP SHOULD send a NOTIFY message upstream. >> >> >> When should forwarding of NOTIFY stop? >> I'm currently not sure how the branching node will detect this >> case. Maybe if the NOTIFY arrives via an inactive/invalid routing >> state. > > I'm not sure what we should do here. I guess that it makes sense to send a NOTIFY from the merging/crossover node to the previous active hop. The latter should stop sending refreshes due to the InvalidateRoutingState (at the GIST level) that is useful to avoid route oscillation. Lets take the example from Markus Ott's mail: Old path A-B-E-D, new path A-C-D /-\ /-\ /--|B|-----|E|---\ / \-/ \-/ \ /-\ /-\ ----|A| |D|-------- \-/ \-/ \ /-\ / \--|C|-----------/ \-/ Let's assume the link A-B is broken and A detects re-routing to C. After GIST indicated the re-routing to QoS- NSLP, it will send a new RESERVE with RII. C will install new state and "forward" the RESERVE to D. GIST in D will detect that the RESERVE was received via another interface and indicates a new SII-handle to QoS NSLP. D will detect that it is a cross-over node and stop forwarding of the RESERVE in case nothing else (MRI or QSPEC) has changed. It will send back a RESPONSE towards A, which will try to send a RESERVE w/ TEAR flag along the old path. This will fail because the link to B is broken. Note that B may still send a refreshing RESERVE towards E. If D sends a NOTIFY towards E, E may stop to send a GIST refresh avoiding to trigger another route change at D. However, if the reservation state at E is not torn down it will send another refreshing reserve (and thus re-establishing the GIST route). But tearing down the state at E would not be enough since B can also re-establish state by sending its periodic refresh. A further issue comes to my mind: the RSN at D was the one from E before the route change. But what happens after the rout change when C sends its new RESERVE with a new RSN (but even potentially lower RSN)? So D must update its locally stored RSN in case it is a rerouting event, right? This should be mentioned in section 5.3.1. > It is quite probable (if the possible route change indiciation from GIST > is correct) that the node that the NOTIFY is initially sent to is no > longer on the path. Some possible options: Which one would it be in the example above? Do you mean E or B? >From the discussion above follows that forwarding should not stop at E, but at the branching node A at last. So notify should be forwarded up to the branching node if possible. However, I'm not completely sure that it's really safe to tear down state due to the NOTIFY. > - don't forward it at all (but since the node receiving the NOTIFY might > not be on the path, but would still have the node sending the NOTIFY as > its next downstream hop for that flow, it is not clear that sending the > NOTIFY message is useful) > - let it go all the way back to the QNI/QNR > - let it go all the way back to a QNE which determines that it's > downstream peer has changed > - something else > > Any thoughts on the best answer? ('best' rather than 'correct' since > this is, at best, a hint) In this context I would also repeat Markus Ott's question again: (section 3.1.2). The sentence "Examples would be notification to an upstream peer about state being torn down or..." is not clear to me. Take for instance following example: /-\ /-\ /--|B|-----|E|---\ / \-/ \-/ \ /-\ /-\ ----|A| |D|-------- \-/ \-/ \ /-\ / \--|C|-----------/ \-/ All the nodes are QNEs. The flow is going from A to D. The old flow was going through A-B-E-D. Then because of rerouting the new flow is going now through A-C-D. The A sends a RESERVE with the TEAR_DOWN bit set to B. B tears down its state and forwards the RESERVE with TEAR_DOWN bit set to E. If the node B notifies node A with NOTIFY message about its state being torn down - there will be no problem. But if the next node E after tearing down its state will send a NOTIFY message to B, then what will happen? Will the node B just forward this message because it will not find the appropriate SESSION_ID or just drop it? If it will just drop it, then there is no sense to send this NOTIFY message at all. If the node B will forward this message to A, then what can A do with this NOTIFY message? There can be 10-20 nodes between A and D on the old path. What will node A do in this case with 10-20 NOTIFY messages? So upstream notification in case of state expiration is questionable... >>> .sh 4 "Route change oscillation" >>> >>> In some circumstances a route change may occur, but the path than >> >> typo: then > > yes > >>> falls back to the original route. >>> >>> After a route change the routers on the old path will continue to >>> refresh the reservation until soft state times out, or an explicit >>> TEAR is received. >>> >>> After detecting an upstream route change a QNE SHOULD consider the new >>> upstream peer as current and not fall back to the old upstream peer >>> unless: >>> >>> - it stops receiving refreshes from the old upstream peer for at least >>> the soft state timeout period >> >> ??? in this case it really makes no sense to fall back to the old >> upstream peer ??? > > There is a vital bit missing from the end of this sentence: > "and then starts receiving messages from the old upstream peer again" Oops, missed that one... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 19:45:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHsEb-0001jR-40; Fri, 10 Mar 2006 19:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHsEZ-0001QJ-9p for nsis@ietf.org; Fri, 10 Mar 2006 19:45:27 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHsEY-0006qv-02 for nsis@ietf.org; Fri, 10 Mar 2006 19:45:27 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 066161054B for ; Sat, 11 Mar 2006 01:45:25 +0100 (CET) Received: from [84.132.135.59] (p5484873B.dip0.t-ipconnect.de [84.132.135.59]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP for ; Sat, 11 Mar 2006 01:45:24 +0100 (CET) Message-ID: <44121DA6.1020405@cs.uni-goettingen.de> Date: Sat, 11 Mar 2006 01:45:26 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] Diagnostics NSLP design options draft update 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 have made some small changes to diagnostics NSLP design options draft, you may find it in http://www.ietf.org/internet-drafts/draft-fu-nsis-diagnostics-nslp-01.txt Your comments, suggestions are greatly appreciated. Best regards, Xiaoming PS. interested people may take a look at the slides in IETF#64 meeting: http://www3.ietf.org/proceedings/05nov/slides/nsis-11/nsis-11.ppt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 19:45:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHsEh-0002mQ-Mm; Fri, 10 Mar 2006 19:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHsEg-0002X1-8Q for nsis@ietf.org; Fri, 10 Mar 2006 19:45:34 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHsEe-0006r2-Uq for nsis@ietf.org; Fri, 10 Mar 2006 19:45:34 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 8D0D21054B for ; Sat, 11 Mar 2006 01:45:32 +0100 (CET) Received: from [84.132.135.59] (p5484873B.dip0.t-ipconnect.de [84.132.135.59]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP for ; Sat, 11 Mar 2006 01:45:32 +0100 (CET) Message-ID: <44121DAE.70305@cs.uni-goettingen.de> Date: Sat, 11 Mar 2006 01:45:34 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] I-D GIST over SCTP 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, According to the comments from WG members and changes in GIST spec, we=20 have made corresponding changes in GIST over SCTP draft. Here you find=20 the I-D: http://www.ietf.org/internet-drafts/draft-fu-nsis-ntlp-sctp-01.txt As you may find from the diff file: http://user.informatik.uni-goettingen.de/~nsis/internet-drafts/Diff_draft= -fu-nsis-ntlp-sctp-01from00.html main changes are: - readapted API, Stack-Configuration-Data, PR-SCTP. - added a bit-level-format for Higher-Layer-Addressing. - renamed the new MA-Type =93Forwards-SCTP=94 (since GIST also calls=20 standard TCP mode as =93Forwards-TCP=94). (these changes are now also reflected in our code.) Comments are very appreciated. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 10 19:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHsFG-0005FW-Iv; Fri, 10 Mar 2006 19:46:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHsFE-000593-Mp for nsis@ietf.org; Fri, 10 Mar 2006 19:46:08 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHsFD-0006s0-D3 for nsis@ietf.org; Fri, 10 Mar 2006 19:46:08 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 044291054B for ; Sat, 11 Mar 2006 01:46:07 +0100 (CET) Received: from [84.132.135.59] (p5484873B.dip0.t-ipconnect.de [84.132.135.59]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP for ; Sat, 11 Mar 2006 01:46:06 +0100 (CET) Message-ID: <44121DD0.1050908@cs.uni-goettingen.de> Date: Sat, 11 Mar 2006 01:46:08 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] NSLP state machines 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 have updated the state machine documents for NSLPs mostly based on their snapshot pre-releases: http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine-03.pdf, txt http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-nslp-statemachine-02.txt (PDF/VISIO figures can be found in http://user.informatik.uni-goettingen.de/~nsteinle/fsm/natfw/02/ ) Comments, suggestions are very appreciated. (Both have been implemented in our code; hope folks especially implementors may find them useful.) Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 13 02:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIhb1-000608-Dc; Mon, 13 Mar 2006 02:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIhb0-0005yZ-LB for nsis@ietf.org; Mon, 13 Mar 2006 02:36:02 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIhaz-00048M-9B for nsis@ietf.org; Mon, 13 Mar 2006 02:36:02 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 13 Mar 2006 08:35:59 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Mar 2006 08:35:58 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6267@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: bless@tm.uka.de Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Mon, 13 Mar 2006 08:35:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: andrew.mcdonald@roke.co.uk, karagian@cs.utwente.nl, jmanner@cs.Helsinki.FI, 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 Hello Roland, |Consequently I would prefer removal of the ACK flag and possibly |provide a simple HELLO mechanism (with adjustable timeouts) |between peers to detect communication failures. I really don't know |what fast reaction an application could undertake due a |transmission/processing failure of a RESERVE message that was |detected by the currently proposed ACK mechanism. -> see below Such a Hello mechanism may indeed be the better idea. The current=20 NSLP version seems to be rather stable. Would you propose to=20 include the Hello mechanism in the current draft or would it be=20 acceptable to to start working on it in a later version (e.g.=20 separate document - may be a feature desireable for other=20 nslps too - or qos nslp version 2)? Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 13 07:22:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIm46-0006UH-V9; Mon, 13 Mar 2006 07:22:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIm46-0006UC-GP for nsis@ietf.org; Mon, 13 Mar 2006 07:22:22 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIm45-0004O3-2R for nsis@ietf.org; Mon, 13 Mar 2006 07:22:22 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FIm3n-0000mz-FY; Mon, 13 Mar 2006 13:22:15 +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 0A1DDA53C; Mon, 13 Mar 2006 13:22:02 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FIm3m-0001YT-MJ; Mon, 13 Mar 2006 13:22:02 +0100 Message-ID: <441563EA.4010905@tm.uka.de> Date: Mon, 13 Mar 2006 13:22:02 +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: "Geib, Ruediger" Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <6439282641581441A36F7F6F83ED2ED20E6267@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E6267@S4DE8PSAAFQ.mitte.t-com.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: andrew.mcdonald@roke.co.uk, karagian@cs.utwente.nl, jmanner@cs.Helsinki.FI, 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 Ruediger, Geib, Ruediger wrote: > |Consequently I would prefer removal of the ACK flag and possibly > |provide a simple HELLO mechanism (with adjustable timeouts) > |between peers to detect communication failures. I really don't know > |what fast reaction an application could undertake due a > |transmission/processing failure of a RESERVE message that was > |detected by the currently proposed ACK mechanism. -> see below > > Such a Hello mechanism may indeed be the better idea. The current > NSLP version seems to be rather stable. Would you propose to > include the Hello mechanism in the current draft or would it be > acceptable to to start working on it in a later version (e.g. > separate document - may be a feature desireable for other > nslps too - or qos nslp version 2)? I think that adding a simple Hello mechanism would be not so complex, since overall it would be easier than implementing the currently proposed ACK mechanism with retransmissions per message. On the other hand we have a problem, because information is missing about the identity of the next QoS NSLP peer since the latter is managed by GIST and the NLI is currently not passed over the API (which makes it also hard to realize summary refreshes BTW). So one could think about an API extension that allows to pass NLIs from GIST to NSLPs so that the NSLP instance is at least able to monitor a mapping from sessions or flows to peers/neighbors. Note that GIST has already a HELLO mechanism per MA though it's primary purpose was not to detect failures, but to keep the MA open, right? Thus the rate of HELLO messages would be relatively low. Moreover, it will not detect the liveliness of the QoS NSLP instance, only of the GIST instance. The second issue that we need to decide about is the reaction of QoS NSLP when a failure is detected. Possibly it can send an Invalidate Routing State to it's own GIST instance. This may not help, however, in case the routing and GIST is still working correctly. Sending a NOTIFY (but for which peers exactly?) would also be an option, but I doubt that this would help much. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 13 08:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIn5e-0007or-Qg; Mon, 13 Mar 2006 08:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIn5e-0007oE-4s for nsis@ietf.org; Mon, 13 Mar 2006 08:28:02 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIn5b-0006Sk-Jh for nsis@ietf.org; Mon, 13 Mar 2006 08:28:02 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FIn5U-0004uV-Qb; Mon, 13 Mar 2006 14:27:56 +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 932068A1C; Mon, 13 Mar 2006 14:27:52 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FIn5S-0001h9-Tj; Mon, 13 Mar 2006 14:27:51 +0100 Message-ID: <44157356.1020408@tm.uka.de> Date: Mon, 13 Mar 2006 14:27:50 +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] QoS NSLP updated References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> <441027F7.4040006@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Jukka, > If you use a local mobility management scheme, controlled by a MAP, then > you don't need to change the IP address after each handover. Thus, a Maybe I don't understand that because the scenario is not quite clear to me. Do you mean we use something like H-MIP? If yes, then we may have a situation like this: MN---AR1 \ R1---R2(MAP)--R3--R4--...--CN / AR2 I assumed that we consider a reservation from CN->MN and the MN changes ARs. In this case the MN will get a new IP address which is indeed hidden for the CN. However, I thought that we have more or less two reservations, one from CN->MAP and one from CN->MN. The latter will be updated in case the MN registers its new address at the MAP. In this case the MAP will use a new MRI towards the MN anyway, so it is not a "refresh" because it will be forwarded along the whole path from the MAP to the MN. > refresh from the MAP towards the MN will look like an ordinary refresh, > and will not help in making reservations closer to the MN, say, at the > access router. If you can force a refresh, you can repair the reservation > faster. I apologize that I still don't understand. In case the MN's local address doesn't change the refreshing RESERVE will also not take any new path from MAP to CN?! Maybe you can explain it with help of the above example. Regards, Roland > Jukka > > On Thu, 9 Mar 2006, Roland Bless wrote: > >> Hi Jukka, >> >>> The "forced" refresh is useful to have, and makes it possible for any node >> ^^^^^^^^^ >> Yes, I'm interested in examples that show its usefulness (they should >> possibly mentioned in the draft section 4). >> >>> to force a refresh operation to be carried. For example, a mobility anchor >>> point may get to know that an MN has moved, and can force a refresh >>> towards the MN. A similar indication and a subsequent refresh can happen >> Hm, I don't quite get it. In case the MN has moved he also >> changed his CoA and thus the MRI, and, in this case, the MAP will >> usually send a new RESERVE with a different MRI. >> >>> with Mobile IP, when the HA, or CN receive a binding update, and know that >>> the path near the MN has changed. >> I don't see why a forced refresh will help much in mobility scenarios. >> Basically what you achieve with a forced refresh is that the state >> along the whole path doesn't expire, but states will not expire >> using the normal peer refreshes in case nothing else changed. >> So in case the routing in the network didn't change, the refreshing >> RESERVE will take exactly the same path as before. If the MN has changed >> its CoA, you will usually end up sending a RESERVE with a different MRI >> which then may traverse along a new path. Then states along the >> unchanged path are refreshed anyway. >> The only benefit would be IMHO to force a refresh before a handover >> so that the time period for performing the handover is long enough >> to keep the reservation while the QNI moves. But this could be achieved >> by an ordinary refresh, too. >> >> Regards, >> Roland >> >>> On Thu, 9 Mar 2006, Roland Bless wrote: >>> >>>> Hi Jukka, >>>> >>>>> On Sat, 4 Mar 2006, Bernd Schloer wrote: >>>>> >>>>>> Hi Jukka, >>>>>> >>>>>> a few things are not quite clear to me: >>>>>> >>>>>> Who is responsible to trigger the Refresh Messages? Is it the QNI or the >>>>>> Client Application connected to the QNI? >>>>> Page 4: >>>>> "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 >>>>> [RFC2205], and uses soft-state peer-to-peer refresh messages as the >>>>> primary state management mechanism (i.e. state installation/refresh >>>>> is performed between pairs of adjacent NSLP nodes, rather than in an >>>>> end-to-end fashion along the complete signalling path)." >>>> The latter is, however, possible in case one uses a refreshing RESERVE >>>> with an RII object included: >>>> 5.1.2.1. RESERVE >>>> ... >>>> A refresh right along the path can be forced by requesting a RESPONSE >>>> from the far end (i.e. (i.e., by including an RII object in the RESERVE >>>> message). >>>> >>>> I still don't know what it's good for... >>>> >>>> Regards, >>>> Roland >> >> > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 13 08:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FInOm-0003MU-Be; Mon, 13 Mar 2006 08:47:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FInOi-0003DE-2a for nsis@ietf.org; Mon, 13 Mar 2006 08:47:44 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FInEB-0006hE-1D for nsis@ietf.org; Mon, 13 Mar 2006 08:36:51 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 13 Mar 2006 14:36:49 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Mar 2006 14:36:49 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6271@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: bless@tm.uka.de Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Mon, 13 Mar 2006 14:36:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: andrew.mcdonald@roke.co.uk, karagian@cs.utwente.nl, jmanner@cs.Helsinki.FI, 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 Hello Roland, I didn't track it closely but would I be wrong if I say that the QoS=20 NSLP was designed not have any topology awareness? If that's true=20 and if mixing GIST and NSLP state information would be required=20 for a useful NSLP Keep Alive mechanism, it may be better=20 to concentrate on =20 "Design Options of NSIS Diagnostics NSLP" and work out a mechanism for re-active NSLP monitoring=20 (like PING and traceroute). Would you agree? Regards, R=FCdiger RoB|Consequently I would prefer removal of the ACK flag and possibly |> |provide a simple HELLO mechanism (with adjustable timeouts) |> |between peers to detect communication failures. I really don't know |> |what fast reaction an application could undertake due a |> |transmission/processing failure of a RESERVE message that was |> |detected by the currently proposed ACK mechanism. -> see below |>=20 RG Such a Hello mechanism may indeed be the better idea. The current=20 |> NSLP version seems to be rather stable. Would you propose to=20 |> include the Hello mechanism in the current draft or would it be=20 |> acceptable to to start working on it in a later version (e.g.=20 |> separate document - may be a feature desireable for other=20 |> nslps too - or qos nslp version 2)? RoB |I think that adding a simple Hello mechanism would be not |so complex, since overall it would be easier than implementing the |currently proposed ACK mechanism with retransmissions |per message. On the other hand we have a problem, because |information is missing about the identity of the next QoS NSLP peer |since the latter is managed by GIST and the NLI is currently |not passed over the API (which makes it also hard to realize summary |refreshes BTW). So one could think |about an API extension that allows to pass NLIs from GIST to NSLPs so |that the NSLP instance is at least able to monitor a mapping from |sessions or flows to peers/neighbors. | |Note that GIST has already a HELLO mechanism per MA though it's = primary |purpose was not to detect failures, but to keep the MA open,=20 |right? Thus |the rate of HELLO messages would be relatively low. Moreover, it will |not detect the liveliness of the QoS NSLP instance, only of the GIST |instance. The second issue that we need to decide about is |the reaction of QoS NSLP when a failure is detected. |Possibly it can send an Invalidate Routing State to it's own GIST |instance. This may not help, however, in case the routing and GIST |is still working correctly. Sending a NOTIFY (but for which peers |exactly?) would also be an option, but I doubt that this would help |much. | |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 13 09:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoWK-0000EX-77; Mon, 13 Mar 2006 09:59:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoWJ-0000ER-FC for nsis@ietf.org; Mon, 13 Mar 2006 09:59:39 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoWE-0000kZ-VW for nsis@ietf.org; Mon, 13 Mar 2006 09:59:39 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2DExOti011832 for ; Mon, 13 Mar 2006 14:59:24 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 14:59:24 +0000 Message-ID: <441588CC.705@roke.co.uk> Date: Mon, 13 Mar 2006 14:59:24 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Nsis (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 14:59:24.0799 (UTC) FILETIME=[B7C458F0:01C646AE] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [NSIS] NSLP IDs and RAO values 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, In thinking about the aggregation parts of the QoS NSLP draft, there are some IANA-related issues: - IANA considerations currently requests a single NSLP ID for the QoS NSLP, the aggregation mechanism as described in 4.6/4.7 needs multiple NSLP IDs - the document doesn't mentioned what Router Alert Option (RAO) values should be used for the NSLP ID(s) that are allocated For IPv6, it is fairly clear that we should be asking for (or referring to) allocations in the IPv6 Router Alert Option Values (RFC2711) registry (http://www.iana.org/assignments/ipv6-routeralert-values). This contains the aggregation RAO values from RFC3175. For IPv4 (RFC2113), I can't see an appropriate registry. I seem to remember discussing this before, but don't think we reached a conclusion. RFC2113 defines a value of 0, and leaves others reserved. Allocation by IANA of additional values is not mentioned. Is it implicitly assumed to be in step with the IPv6 list? Do we need to do something to make this explicit? This is an issue for the NSLP drafts, and also relevant for the extensibility draft. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 13 12:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqqi-00050z-MG; Mon, 13 Mar 2006 12:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqqh-00050u-Bu for nsis@ietf.org; Mon, 13 Mar 2006 12:28:51 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIqqf-0005yu-Po for nsis@ietf.org; Mon, 13 Mar 2006 12:28:51 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id k2DHSiPt005046; Mon, 13 Mar 2006 18:28:44 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k2DHSiD8029035; Mon, 13 Mar 2006 18:28:45 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k2DHSgG27666; Mon, 13 Mar 2006 18:28:42 +0100 (MET) Date: Mon, 13 Mar 2006 18:28:42 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: Ruediger.Geib@t-systems.com, bless@tm.uka.de Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 13 Mar 2006 17:28:42 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E6271@S4DE8PSAAFQ.mitte.t-com.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: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 13 Mar 2006 18:28:46 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "andrew.mcdonald@roke.co.uk" , "jmanner@cs.Helsinki.FI" , "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 Rudiger Hi Roland Rudiger, are you refering tothe draft: draft-fu-nsis-diagnostics-nslp-01? If yes, then I agree with you! Roland, please note that the functionality associated with the ACK flag can be used by QoS models to give the possibility to a peer to request the imediate generation of a Response from its neighbouring peer. I am in favour of keeping this functionality. Best Regards, Georgios On 3/13/2006, "Geib, Ruediger" wrote: >Hello Roland, > >I didn't track it closely but would I be wrong if I say that the QoS >NSLP was designed not have any topology awareness? If that's true >and if mixing GIST and NSLP state information would be required >for a useful NSLP Keep Alive mechanism, it may be better >to concentrate on > >"Design Options of NSIS Diagnostics NSLP" > >and work out a mechanism for re-active NSLP monitoring >(like PING and traceroute). Would you agree? > >Regards, > >R=FCdiger > >RoB|Consequently I would prefer removal of the ACK flag and possibly >|> |provide a simple HELLO mechanism (with adjustable timeouts) >|> |between peers to detect communication failures. I really don't know >|> |what fast reaction an application could undertake due a >|> |transmission/processing failure of a RESERVE message that was >|> |detected by the currently proposed ACK mechanism. -> see below >|> >RG Such a Hello mechanism may indeed be the better idea. The current >|> NSLP version seems to be rather stable. Would you propose to >|> include the Hello mechanism in the current draft or would it be >|> acceptable to to start working on it in a later version (e.g. >|> separate document - may be a feature desireable for other >|> nslps too - or qos nslp version 2)? > >RoB >|I think that adding a simple Hello mechanism would be not >|so complex, since overall it would be easier than implementing the >|currently proposed ACK mechanism with retransmissions >|per message. On the other hand we have a problem, because >|information is missing about the identity of the next QoS NSLP peer >|since the latter is managed by GIST and the NLI is currently >|not passed over the API (which makes it also hard to realize summary >|refreshes BTW). So one could think >|about an API extension that allows to pass NLIs from GIST to NSLPs so >|that the NSLP instance is at least able to monitor a mapping from >|sessions or flows to peers/neighbors. >| >|Note that GIST has already a HELLO mechanism per MA though it's primary >|purpose was not to detect failures, but to keep the MA open, >|right? Thus >|the rate of HELLO messages would be relatively low. Moreover, it will >|not detect the liveliness of the QoS NSLP instance, only of the GIST >|instance. The second issue that we need to decide about is >|the reaction of QoS NSLP when a failure is detected. >|Possibly it can send an Invalidate Routing State to it's own GIST >|instance. This may not help, however, in case the routing and GIST >|is still working correctly. Sending a NOTIFY (but for which peers >|exactly?) would also be an option, but I doubt that this would help >|much. >| >|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 13 12:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqu7-0007FC-Sk; Mon, 13 Mar 2006 12:32:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIqu6-0007F7-Pq for nsis@ietf.org; Mon, 13 Mar 2006 12:32:22 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIqu5-00066x-As for nsis@ietf.org; Mon, 13 Mar 2006 12:32:22 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id k2DHWIic005248; Mon, 13 Mar 2006 18:32:18 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k2DHWID8029667; Mon, 13 Mar 2006 18:32:18 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k2DHWIf27714; Mon, 13 Mar 2006 18:32:18 +0100 (MET) Date: Mon, 13 Mar 2006 18:32:18 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: andrew.mcdonald@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] NSLP IDs and RAO values Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 13 Mar 2006 17:32:17 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <441588CC.705@roke.co.uk> 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: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 13 Mar 2006 18:32:19 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Andrew Yes, I think that it is needed to explicitly describe the allocation by IANA of additional values. Best Regards, Georgios On 3/13/2006, "Andrew McDonald" wrote: >Hi all, > >In thinking about the aggregation parts of the QoS NSLP draft, there are >some IANA-related issues: >- IANA considerations currently requests a single NSLP ID for the QoS >NSLP, the aggregation mechanism as described in 4.6/4.7 needs multiple >NSLP IDs >- the document doesn't mentioned what Router Alert Option (RAO) values >should be used for the NSLP ID(s) that are allocated > >For IPv6, it is fairly clear that we should be asking for (or referring >to) allocations in the IPv6 Router Alert Option Values (RFC2711) >registry (http://www.iana.org/assignments/ipv6-routeralert-values). This >contains the aggregation RAO values from RFC3175. > >For IPv4 (RFC2113), I can't see an appropriate registry. I seem to >remember discussing this before, but don't think we reached a >conclusion. RFC2113 defines a value of 0, and leaves others reserved. >Allocation by IANA of additional values is not mentioned. Is it >implicitly assumed to be in step with the IPv6 list? Do we need to do >something to make this explicit? > >This is an issue for the NSLP drafts, and also relevant for the >extensibility draft. > >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 Mon Mar 13 12:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrJ8-0000YI-F8; Mon, 13 Mar 2006 12:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrJ7-0000YC-R9 for nsis@ietf.org; Mon, 13 Mar 2006 12:58:13 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrJ5-00079L-OC for nsis@ietf.org; Mon, 13 Mar 2006 12:58:13 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2DHw6ti001587 for ; Mon, 13 Mar 2006 17:58:06 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 17:58:06 +0000 Message-ID: <4415B2AE.2080908@roke.co.uk> Date: Mon, 13 Mar 2006 17:58:06 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Nsis (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 17:58:06.0549 (UTC) FILETIME=[AE6D9050:01C646C7] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [NSIS] QoS NSLP - aggregation marking 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, Some thoughts/issues from thinking about the aggregation aspects of the QoS NSLP: The current text in 4.6/4.7 is a bit too vague on what happens: "The marking MUST be accomplished by the Aggregator by modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value." What 'predefined value'? Is only a single aggregation level being proposed (i.e. like RFC3175 RSVP/RSVP-E2E-IGNORE protocol remarking, but not like RFC3175 RAO value remarking)? Is there any reasoning for why a method using remarking is used? Section 3.4 of the extensibility draft, draft-loughney-nsis-ext-02.txt, talks about the two ways that aggregation marking can be made to work: 1) all routers process at 'aggregation level 0'; routers are configured at the ingress remark messages to a higher level; routers at the egress remark messages to a lower level 2) routers are configured to process messages at a particular 'aggregation level' and ignore all others; aggregate-related messages are marked at a different level to end-to-end messages; messages are never remarked The extensibility draft says: The first technique requires aggregating/deaggregating routers to be configured with which of their interfaces lie at which aggregation level, and also requires consistent message rewriting at these boundaries. The second technique eliminates the rewriting, but requires interior routers to be configured also. It is not clear what the right trade-off between these options is. There are also some differences when things go wrong: - in (1), e2e (remarked) messages that 'escape' (e.g. misconfigured egress) get ignored at regular routers, but should probably also be flagged as an error if coming into an edge router on the wrong interface. Messages for an aggregate that 'escape' are essentially undetectable through basic NSLP processing - it may be picked up by policy control mechanisms. - in (2), e2e messages are not remarked, so if they 'escape' they are correctly processed by routers outside the aggregation region. Messages for an aggregate that escape from the region are ignored at regular routers, but should probably also be flagged as an error if coming into an edge router on the wrong interface. We should probably say something more about the error cases (at least the ones that we can potentially catch). The QoS NSLP draft has chosen (1), but doesn't include any rationale. Given that the extensibility draft says "you have a choice" it might be useful to do so. I'm not sure why we've chosen (1), other than that is the way RFC3175 does it. There were IESG concerns about the internet draft that became RFC3175, see past IETF proceedings: http://www3.ietf.org/proceedings/00dec/00dec-138.htm http://www3.ietf.org/proceedings/01mar/ietf50-142.htm The concerns are focussed on the IP protocol remarking rather than the RAO value remarking. It appears that the concerns were addressed by changes in the security considerations section. In our case, the NSLP ID remarking is similar to the IP protocol remarking, and the security considerations are likely to be similar. (Since the choice of RAO value follows on from the NSLP ID choice, we need to decide the NSLP ID marking policy first.) Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID combination stays constant along the path, which simplifies diagnostics. The failure case (described above) also seems better. So, it's not entirely clear to me why (1) is preferred over (2). regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 14 02:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4FW-000500-AC; Tue, 14 Mar 2006 02:47:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4FU-0004vW-Nt for nsis@ietf.org; Tue, 14 Mar 2006 02:47:20 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ4FT-00004y-7a for nsis@ietf.org; Tue, 14 Mar 2006 02:47:20 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id k2E7lESc018707; Tue, 14 Mar 2006 08:47:14 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k2E7lED8027060; Tue, 14 Mar 2006 08:47:14 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k2E7lEW15105; Tue, 14 Mar 2006 08:47:14 +0100 (MET) Date: Tue, 14 Mar 2006 08:47:14 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: andrew.mcdonald@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] QoS NSLP - aggregation marking Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 14 Mar 2006 07:47:14 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4415B2AE.2080908@roke.co.uk> 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: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 14 Mar 2006 08:47:16 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Hallo Andrew I thought that we have discussed this issue and decided to use (1). Best Regards, Georgios On 3/13/2006, "Andrew McDonald" wrote: >Hi all, > >Some thoughts/issues from thinking about the aggregation aspects of the >QoS NSLP: > >The current text in 4.6/4.7 is a bit too vague on what happens: "The >marking MUST be accomplished by the Aggregator by modifying the QoS-NSLP >default NSLP-ID value to a NSLP-ID predefined value." >What 'predefined value'? >Is only a single aggregation level being proposed (i.e. like RFC3175 >RSVP/RSVP-E2E-IGNORE protocol remarking, but not like RFC3175 RAO value >remarking)? > >Is there any reasoning for why a method using remarking is used? > >Section 3.4 of the extensibility draft, draft-loughney-nsis-ext-02.txt, >talks about the two ways that aggregation marking can be made to work: >1) all routers process at 'aggregation level 0'; routers are configured >at the ingress remark messages to a higher level; routers at the egress >remark messages to a lower level >2) routers are configured to process messages at a particular >'aggregation level' and ignore all others; aggregate-related messages >are marked at a different level to end-to-end messages; messages are >never remarked > >The extensibility draft says: > The first technique requires aggregating/deaggregating routers to be > configured with which of their interfaces lie at which aggregation > level, and also requires consistent message rewriting at these > boundaries. The second technique eliminates the rewriting, but > requires interior routers to be configured also. It is not clear > what the right trade-off between these options is. > >There are also some differences when things go wrong: >- in (1), e2e (remarked) messages that 'escape' (e.g. misconfigured >egress) get ignored at regular routers, but should probably also be >flagged as an error if coming into an edge router on the wrong >interface. Messages for an aggregate that 'escape' are essentially >undetectable through basic NSLP processing - it may be picked up by >policy control mechanisms. >- in (2), e2e messages are not remarked, so if they 'escape' they are >correctly processed by routers outside the aggregation region. Messages >for an aggregate that escape from the region are ignored at regular >routers, but should probably also be flagged as an error if coming into >an edge router on the wrong interface. > >We should probably say something more about the error cases (at least >the ones that we can potentially catch). > >The QoS NSLP draft has chosen (1), but doesn't include any rationale. >Given that the extensibility draft says "you have a choice" it might be >useful to do so. I'm not sure why we've chosen (1), other than that is >the way RFC3175 does it. > >There were IESG concerns about the internet draft that became RFC3175, >see past IETF proceedings: >http://www3.ietf.org/proceedings/00dec/00dec-138.htm >http://www3.ietf.org/proceedings/01mar/ietf50-142.htm >The concerns are focussed on the IP protocol remarking rather than the >RAO value remarking. It appears that the concerns were addressed by >changes in the security considerations section. In our case, the NSLP ID >remarking is similar to the IP protocol remarking, and the security >considerations are likely to be similar. (Since the choice of RAO value >follows on from the NSLP ID choice, we need to decide the NSLP ID >marking policy first.) > >Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID combination >stays constant along the path, which simplifies diagnostics. The failure >case (described above) also seems better. So, it's not entirely clear to >me why (1) is preferred over (2). > > >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 14 04:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ5Sa-0000Gt-HO; Tue, 14 Mar 2006 04:04:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ5SZ-0000Go-Gc for nsis@ietf.org; Tue, 14 Mar 2006 04:04:55 -0500 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.encs.concordia.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ5SY-0002ZC-7u for nsis@ietf.org; Tue, 14 Mar 2006 04:04:55 -0500 Received: from localhost (nul-web@tact-96.encs.concordia.ca [132.205.96.48]) by perseverance.encs.concordia.ca (8.12.11/8.12.11) with ESMTP id k2E94rIQ010893 for ; Tue, 14 Mar 2006 04:04:53 -0500 X-Received-HTTP: from toronto-HSE-ppp3953037.sympatico.ca (toronto-HSE-ppp3953037.sympatico.ca [70.49.93.229]) by mail.encs.concordia.ca (Horde MIME library) with HTTP; Tue, 14 Mar 2006 04:04:53 -0500 Message-ID: <20060314040453.96eusgst68mc0k0c@mail.encs.concordia.ca> Date: Tue, 14 Mar 2006 04:04:53 -0500 From: Bo Gao To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Scanned-By: MIMEDefang 2.43 on perseverance.encs.concordia.ca at 2006/03/14 04:04:53 EST X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] Some small errors 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 Hello, In the Internet-Draft of GIST http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-09.txt, At Page 34,line 5, "it if" should be "if it". At Page 50, "NTLP" should be modified to "GIST" in the sentence "Alternatively, receipt of an upstream Query at the flow source MAY be used to trigger setup of NTLP state in the downstream direction" as the name has been already changed. At Page 61, in the rule 2 "if a new MA-SM would be needed for this peer, create one in listening state", I think this applies to rule 1 too. As the confirm can be sent over the new established MA (Not sure). Also I have a question about the local processing, How could the signaling application indicate it wishes to become a signaling peer with the Querying node? I checked the service interface between GIST and NSLP, I couldn't figure out if it is a functionality of the SendMessage or a functionality of RecvMessage. Is the parameter " Transfer-Attribute " in the ReceMessage a in-out parameter? Sincerely Bo Gao E-mail: gao_b@cs.concordia.ca Web: http://www.cs.concordia.ca/~gao_b _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 14 17:54:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIPY-0003PY-6e; Tue, 14 Mar 2006 17:54:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIPX-0003PS-6c for nsis@ietf.org; Tue, 14 Mar 2006 17:54:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJIPV-00008p-PY for nsis@ietf.org; Tue, 14 Mar 2006 17:54:39 -0500 Received: (qmail invoked by alias); 14 Mar 2006 22:54:36 -0000 Received: from p54985927.dip.t-dialin.net (EHLO [192.168.2.102]) [84.152.89.39] by mail.gmx.net (mp028) with SMTP; 14 Mar 2006 23:54:36 +0100 X-Authenticated: #29516787 Message-ID: <441749A8.60600@gmx.net> Date: Tue, 14 Mar 2006 23:54:32 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org, john.loughney@nokia.com, jmanner@cs.helsinki.fi, andrew.mcdonald@roke.co.uk, karagian@cs.utwente.nl 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: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [NSIS] QoS NSLP 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, when I started my review work I thought that I could quickly go through all documents (QoS NSLP, QSPEC, Y.1541, RMD, etc.). Unfortunately, I got stuck with the QoS NSLP and the review took days! I still plan to review the other documents. (Btw, I suggest everyone who asks for feedback regarding their favorite document to also review other drafts.) Please find comments and some text changes incorporated into a MS Word document: http://www.tschofenig.priv.at/TEMP/QoSNSLP-review.doc Although I have a large number of comments (more than 130) I don't think they are critical. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 15 00:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOin-0003af-Im; Wed, 15 Mar 2006 00:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOim-0003aa-CD for nsis@ietf.org; Wed, 15 Mar 2006 00:38:56 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJOij-0003Jp-SV for nsis@ietf.org; Wed, 15 Mar 2006 00:38:56 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2F5beOb025416 for ; Wed, 15 Mar 2006 07:37:41 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 07:38:51 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 07:38:52 +0200 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, 15 Mar 2006 07:38:51 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869F8F@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jabber service for IETF meetings Thread-Index: AcZH6NViP19TeXceQriei26pCpihbAACdQwg From: To: X-OriginalArrivalTime: 15 Mar 2006 05:38:52.0740 (UTC) FILETIME=[BE52E840:01C647F2] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [NSIS] FW: Jabber service for IETF meetings 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 FYI - if anyone is planning on participating remotely, let me know. John >-----Original Message----- >From: ext IETF Secretariat [mailto:ietf-secretariat@ietf.org]=20 >Sent: 15 March, 2006 06:26 >To: Working Group Chairs >Subject: Jabber service for IETF meetings=20 > >Dear IETF WG Chairs, > >The Secretariat is pleased to announce a new Instant Messaging=20 >service. This service will provide jabber chat rooms to all=20 >IETF working groups for their text conferencing at IETF 65 and=20 >future meetings. > >The new jabber server is located at jabber.ietf.org and is=20 >currently accessible. For those who are interested, please=20 >visit the above location to join any of the available chat rooms. > >Over the next few days, please take the time to test this new=20 >service and provide us with all questions, comments, and=20 >suggestions. Your feedback is key to our success! > >Please note: > >All traffic within the defined rooms (except "noc") is being=20 >logged and updated every 5 minutes to the ietf.org website. > >To view the log directories, point your browser to=20 >http://www.ietf.org/meetings/ietf-logs/. > >If you click on a room directory, you will see one or more=20 >files named "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you=20 >click on one of those files, you will see all logged traffic=20 >for that day. >=20 >Please visit the IETF Text Conferencing Web page >(http://www.ietf.org/meetings/text_conf.html) for more information. > >The IETF Secretariat. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 15 05:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTSw-0004CR-I3; Wed, 15 Mar 2006 05:42:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTSv-0004CM-38 for nsis@ietf.org; Wed, 15 Mar 2006 05:42:53 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTSq-0004PM-KZ for nsis@ietf.org; Wed, 15 Mar 2006 05:42:53 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2FAgPti000467; Wed, 15 Mar 2006 10:42:25 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 10:42:25 +0000 Message-ID: <4417EF8D.90207@roke.co.uk> Date: Wed, 15 Mar 2006 10:42:21 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] NSLP IDs and RAO values References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2006 10:42:25.0170 (UTC) FILETIME=[25C72F20:01C6481D] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Karagiannis wrote: > Yes, I think that it is needed to explicitly describe the allocation by > IANA of additional values. From an off-list clarification (posted with permission): Georgios Karagiannis wrote: > What I mean is: > In my opinion it is implicitly assumed to be in step with the > IPv6 list. > This should be made explicit in the QoS-NSLP draft, etc... I would have thought this would need an update to RFC2113 (doing it in the QoS NSLP draft seems a bit odd to me from a process point of view). Also, having checked a bit further, it doesn't look to me as if the IPv4/IPv6 RAO values are in step since: IPv4: 0 - Router shall examine packet (RFC2113) IPv6: 0 - Datagram contains a Multicast Listener Discovery message (RFC2710/RFC2711) To add slightly more to my confusion, RFC2113 defines: >>> Value: A two octet code with the following values: 0 - Router shall examine packet 1-65535 - Reserved <<< and says: >>> Hosts shall ignore this option. Routers that do not recognize this option shall ignore it. Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary. Unrecognized value fields shall be silently ignored. The semantics of other values in the Value field are for further study. <<< RFC3175 then says: >>> The IPv4 Router Alert [RFC2113] has the option simply to ask the router to look at the protocol type of the intercepted datagram and decide what to do with it; the parameter is additional information to that decision. <<< and defines a use for the 'Reserved' values to indicate the aggregation level. However, there is no explicit update of RFC2113 to redefine (and provide new semantics for) those reserved values. Andrew > On 3/13/2006, "Andrew McDonald" wrote: > >> Hi all, >> >> In thinking about the aggregation parts of the QoS NSLP draft, there are >> some IANA-related issues: >> - IANA considerations currently requests a single NSLP ID for the QoS >> NSLP, the aggregation mechanism as described in 4.6/4.7 needs multiple >> NSLP IDs >> - the document doesn't mentioned what Router Alert Option (RAO) values >> should be used for the NSLP ID(s) that are allocated >> >> For IPv6, it is fairly clear that we should be asking for (or referring >> to) allocations in the IPv6 Router Alert Option Values (RFC2711) >> registry (http://www.iana.org/assignments/ipv6-routeralert-values). This >> contains the aggregation RAO values from RFC3175. >> >> For IPv4 (RFC2113), I can't see an appropriate registry. I seem to >> remember discussing this before, but don't think we reached a >> conclusion. RFC2113 defines a value of 0, and leaves others reserved. >> Allocation by IANA of additional values is not mentioned. Is it >> implicitly assumed to be in step with the IPv6 list? Do we need to do >> something to make this explicit? >> >> This is an issue for the NSLP drafts, and also relevant for the >> extensibility draft. >> >> regards, >> >> Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 15 13:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJajz-0001Py-0s; Wed, 15 Mar 2006 13:28:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJajx-0001OR-Bt for nsis@ietf.org; Wed, 15 Mar 2006 13:28:57 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJajw-0002VY-DT for nsis@ietf.org; Wed, 15 Mar 2006 13:28:57 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 18:28:52 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 18:28:52 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1142447330723; Wed, 15 Mar 2006 18:28:50 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.132]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id k2FISkYE005277; Wed, 15 Mar 2006 18:28:49 GMT Message-Id: <5.2.1.1.2.20060314150347.025dae90@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 15 Mar 2006 18:27:20 +0000 To: From: Bob Briscoe Subject: RE: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-marking can do it In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CEBF8@esebe100.NOE.Nokia. com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 15 Mar 2006 18:28:52.0463 (UTC) FILETIME=[4F812FF0:01C6485E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ce9c9805f9fd7f2a8e6eb8268c6b0fc Cc: nsis@ietf.org, philip.eardley@bt.com, karagian@cs.utwente.nl, tsvwg@ietf.org, attila.bader@ericsson.com 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 John, Some time ago you asked how we would resolve the disagreement between=20 re-marking Diffserv or ECN fields for admission control and pre-emption=20 (old thread below). We have included a number of candidate options for re-marking in the=20 appendices to=20 .=20 With pros and cons. This is a prompt for the people involved in that discussion (and others) to= =20 read the appendices to the above I-D and comment on the list. The aim is=20 that the eventual consensus can be recorded in a future version of that=20 draft, with the aim of eventually moving to standards track. Phil Eardley's= =20 presentation in Dallas intends to re-open debate from the mic as well. Also, I have produced an extended argument for one of the choices=20 (Alternative 5) as part of=20 ,=20 mainly on security grounds. [This is a corrected version of=20 draft-briscoe-tsvwg-re-ecn-border-cheat-00.txt inserting a missing "NOT"=20 in a key sentence. It will be posted once the I-D gates open again.] Bob At 12:35 12/12/2005, john.loughney@nokia.com wrote: >Bob (& by extension the TSVWG WG), > >I'm still left feeling like we don't have consensus around the issues=20 >out-lined >in your mail in the tsvwg community, even outside of RMD issues. > >I'm wondering if we should start trying to find somethings that we could= get >consensus on and then see what to do about the other issues. Many of the= =20 >points >are still experimental (in the TSVWG sense of experimental), so I'm= wondering >what the next steps should be. > >thanks, >John > > >-----Original Message----- > >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > >Behalf Of ext Attila B=E1der (IJ/ETH) > >Sent: 08 December, 2005 16:02 > >To: Bob Briscoe > >Cc: philip.eardley@bt.com; Georgios Karagiannis; > >tsvwg@ietf.org; nsis@ietf.org > >Subject: RE: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN > >re-markingwhen DSCPre-markingcan do it > > > >Hi Bob, Thank you for your answer, please see my comments below. > > > >Best regards, Attila > > > >> -----Original Message----- > >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] > >> Sent: Thursday, November 24, 2005 6:41 PM > >> To: Georgios Karagiannis > >> Cc: philip.eardley@bt.com; tsvwg@ietf.org; nsis@ietf.org > >> Subject: Re: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN > >> re-markingwhen DSCP re-markingcan do it > >> > >> > >> Georgios, > >> > >> (long e-mail) > >> > >> We thought long and hard about which re-marking to use. My primary > >> concern was to keep the Internet architecture consistent, > >which leads > >> to the arguments below. > >> > >> 1/ Intended semantics of the Internet Architecture > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >> > >> 1.1/ Intended re-marking semantics of Diffserv & ECN > >> -------------------------------------------------- > >> Diffserv re-marking was defined for two reasons: > >> i) To allow the ingress of a Diffserv domain to prevent traffic > >> in excess of the contracted rate/burstiness from being given > >> favourable treatment at downstream routers if they became congested > >> themselves. > >> ii) To allow a border router to map the DSCP used for a per-hop > >> behaviour in the upstream domain to that used for the same > >PHB in the > >> downstream domain. > >> > >> ECN re-marking is used by a node to indicate that the node itself is > >> approaching congestion. The intent is to reduce the load from the > >> source, but marking is forwarded downstream in the > >expectation that it > >> will be fed back to the source. > >> > >> Thus, the intent of Diffserv re-marking is to alter the > >> downstream per hop forwarding behaviour if necessary. Diffserv > >> re-marking was not intended to be fed back to the source. > >> The intent of ECN re-marking is to reduce the load at source > >> through feedback. ECN re-marking was specifically not intended to > >> alter the downstream forwarding behaviour of re-marked packets. > >> > >> That's the idealistic view. In practice, it can be convenient to break > >> architecture. But architecture is there to warn you to think long and > >> hard when you depart from it, so you are aware of what you > >might break > >> in the future. > >> > > > >I agree that this would be an idealistic picture. Note that > >you would like to use ECN for Admission Control. Diffserv is > >used also for admission control so there is an overlap between > >ECN and Diffserv. In the meantime ECN was defined for > >end-to-end congestion control of elastic traffic type that > >makes things complicate. While there is no such limitation to > >use remaining Diffserv codepoints for congestion notification > >edge-to-edge. > > > >> 1.2/ Was ECN at the IP layer intended to have end-to-end semantics? > >> ------------------------------------------------------------------- > >> RFC3168 was written so that the ECN semantics in IP could be separated > >> from the end-to-end ECN semantics of TCP when other ECN transports > >> were defined. > >> > >> [According to Sally Floyd at the time, the main reason for specifying > >> ECN for TCP & IP together in the same RFC was to encourage the first > >> experiments with ECN to be in TCP implementations which tend to be > >> written with a lot more care by a few kernel experts.] > >> > >> Indeed, Jon Crowcroft and I wrote an I-D reviewing the ECN I-D before > >> it became RFC3168. In section 12, we proposed text on ECN semantics > >> for proxies (edge-to-edge), asking that it be added to the ECN RFC: > >> (Expired) > >> > >> Sally Floyd's response (off-line) at the time is quoted here: > >> > >> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >> /\/\/\/\/\/\/\/ > >> At 11:35 21/02/01 -0800, Sally Floyd wrote: > >> >Feedback on Section 12, proposing rules for allowing proxies in the > >> >network to change ECN codepoints: > >> > > >> >I think that this is complicated, and has to be dealt with in a > >> >separate document, in context. That is, when people have specific > >> >proposals for intermediate nodes to modify the ECN field, >then I > >> think they have to be addressed at that time. My own opinion >is > >> that making general rules ahead of time, in the abstract, >such as > >> "we will now propose rules for changing the ECN >capability of a > >> packet at intermediate nodes", never gets it right. > >> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >> /\/\/\/\/\/\/\/ > >> > >> is exactly that. A= separate > >> document about the semantics of ECN proxies, in this case with a flow > >> signalling transport like RSVP (or NSIS). > >> > >> The idea of RMD and of > >> is for the node at the > >> end of a long signalling 'hop' (a whole Diffserv region) to see how > >> much congestion has accumulated since the start of the region. > >> Potentially there may be other signalling 'hops' further downstream > >> using the same technique again. So the egress of one signalling hop > >> must tidy things up by folding any re-marked packets back in to the > >> same marking as un-re-marked packets, to avoid confusing further > >> region(s) downstream if they are using the same technique. > >> > >> [For instance, you are thinking of RMD being used for admission > >> control across a radio access network. But there may be another RAN at > >> the other end of the network using the same technique. So you must > >> ensure any re-marked DSCPs are folded back into the same DSCP as > >> non-re-marked packets at the RMD egress. ] > >> > > > >Yes, I agree that Egress edge should restore the orig. DSCP, > >otherwise there can be multiple actions for the same event. It > >may not be restored if there is agreement between domains that > >a downsteram domain handles the problem. > > > >> 1.3/ Summary of architectural concerns > >> -------------------------------------- > >> To indicate the need for admission control, it is certainly more > >> convenient to do Diffserv re-marking as RMD does, but I believe it is > >> more architecturally consistent to use ECN re-marking, as we do. > >> > >> However, architecture is like religion. You can break it, if it > >> becomes too inconvenient, and if you can convince enough people you > >> have a good excuse. > >> > >> 2. Practical issues > >> ------------------- > >> I don't think we need to break the architecture in this case > >(which is > >> why we use ECN), but using ECN re-marking edge-edge does raise the > >> following issue... > >> > >> 2.1/ Edge-to-edge ECN conflicts with end-to-end ECN > >> --------------------------------------------------- > >> We fully understand that use of ECN re-marking to trigger admission > >> control within Diffserv regions would conflict with end-to-end ECN > >> congestion control for the *same* flow. But we deliberately chose to > >> specify the end to end service we were providing as "controlled load > >> [RFC2211]" to try to preclude such cases. > >> > >> RFC 2211 says: > >> > >> " ... > >> 2. End-to-End Behavior > >> ... Should the client's traffic > >> generation properties fall outside of the region described by the > >> TSpec parameters, the QoS provided to the client may exhibit > >> characteristics indicative of overload, including large > >numbers of > >> delayed or dropped packets. > >> > >> ... > >> > >> 7. Policing > >> ... the network element > >> MUST attempt > >> to forward the excess traffic on a best-effort basis if > >> sufficient > >> resources are available > >> > >> ... > >> > >> Beyond requirements 2 and 3 above, the controlled-load service > >> does > >> not define the QoS behavior delivered to flows with > >non-conformant > >> arriving traffic. Specifically, it is permissible either to > >> degrade > >> the service delivered to all of the flow's packets equally, or to > >> sort the flow's packets into a conformant set and a > >nonconformant > >> set > >> and deliver different levels of service to the two sets. > >> > >> ... > >> > >> 9. Guidelines for Implementors > >> > >> ... > >> If most controlled-load traffic arises from rate-adaptive > >> realtime or elastic applications attempting to establish > >a bounded > >> minimum level of service, the use of separate resource classes > >> might > >> be preferable. > >> > >> " > >> I won't paste everything RF2211 says on with advice for implementors > >> on scheduling elastic flows with a bounded minimum, as > >there's rather > >> a lot. > >> But basically, you get unavoidably bad re-ordering and other > >> complications that make it hard. Even though this seems a desirable > >> service, it's unlikely to work well in practice. > >> > >> 2.2/ End-to-end ECN conflicts with edge-to-edge admission control > >> ----------------------------------------------------------------- > >> The congestion-based admission control mechanism used in RMD and in > >> our would break if a > >> significant proportion of admitted traffic were adaptive. If > >> congestion on an interior path were close to the threshold where > >> admission control was needed, adaptive traffic might > >temporarily drop > >> well below its minimum bound. More flows might then be > >accepted, then > >> the adaptive traffic could grow again, destroying the > >controlled load > >> service for all flows through that path. > >> > >> [Note: Variable bit rate (VBR) like video traffic would superfically > >> seem to break a measurement-based admission control system > >in the same > >> way as adaptive traffic. But unlike with adaptive traffic, > >troughs in > >> VBR load are not correlated with congestion. Our analyses of how the > >> effective bandwidth of VBR (and silence-suppressed voice) aggregates > >> has shown that our solution works OK for VBR, given specific > >> conditions on the amount of aggregation and provided VBR traffic > >> sources are not correlated. We are currently preparing this analysis > >> for publication.] > >> > > > >That study sounds interesting. I do not think that the > >congestion-based admission control is good enough for all > >networks. Meas. based methods certainly have limitations, > >especially in access network, as you also mention in your > >draft. In RMD edge nodes are statefull nodes. I think that > >unit-based aggregated reservation in core combined with > >per-flow schedulers in edges can provide an Intserv-like > >service in the domain as well. > > > >> 2.3/ Summary of end/edge conflicts > >> ---------------------------------- > >> So, we prefer to say that a different service would have to be > >> requested to cater for your hybrid requirement. Hence my preference > >> for explicitly requesting "adaptive rate control with a bounded > >> minimum" in the signalling, as a different QoS service. In > >NSIS terms, > >> this is would be in the QSPEC, I believe. > >> > > > >I think this traffic should use controlled load service. Or > >define a new QoS model. > > > >> 2.4/ Codepoint space > >> -------------------- > >> Real-estate in the IP header is at a premium. Treating the 6-bit > >> Diffserv field and the 2-bit ECN field separately leads to > >2^6 + 2^2 =3D > >> 68 codepoints. Treating them together leads to 2^8 =3D 256 codepoints. > >> In the MPLS EXP field, real-estate is a far greater headache. > >> > >> If ECN marking is orthogonal to Diffserv marking for most Diffserv > >> codepoints, it makes sense to treate the field as 6-bit and 2-bit > >> sub-fields. But I don't believe we should be averse to bending the > >> rules to save codepoint space across both fields. > >> > >> For instance both our approach and RMD need another marking > >state for > >> a router in the Diffserv interior to indicate the need for flow > >> pre-emption (eg. after re-routes). Pre-emption represents severe > >> congestion and needs to be fed back upstream. So by my > >arguments above > >> pre-emption should be re-marked using the ECN field. But in our > >> current pre-emption solution, if two or more nodes in a path require > >> some flows to be pre-empted, packets that have already been > >re-marked > >> once to indicate pre-emption need to be treated differently by > >> downstream nodes. So by my arguments above pre-emption > >should also be > >> re-marked using the DSCP. > >> > >> Well, it would be silly to waste two codepoints for one state. And > >> there aren't enough ECN codepoints anyway. So, IMHO, you have to be > >> pragmatic and be willing to re-mark the Diffserv codepoint for > >> pre-emption > >> (CAVEAT: the > >> authors of > >still haven't > >> reached consensus on marking - that's why > >> hasn't been updated yet). > > > >We think that both DSCP and ECN remarking could be used for > >congestion notification admission control and severe > >congestion [pre-emption] with limitation. > > > >> > >> 7/ Consistent meaning of an ECN marking > >> --------------------------------------- > >> I hope I have answered your question about why we use ECN > >not Diffserv > >> re-marking. We are not completely inflexible about using > >ECN, but I do > >> have further reasons for preferring ECN re-marking---to do with the > >> economic interpretation of congestion marking across different > >> classes. It would take too long to go into that here, but > >you can read > >> a recent paper I published on the subject if interested. > >> > >> Commercial Models for IP Quality of Service Interconnect, > >Bob Briscoe > >> & Steve Rudkin (BT), in BTTJ Special Edition on IP Quality > >of Service, > >> 23(2) (Apr 2005) > >> > >> > >> I have also given responses inline... > >> > >> At 09:28 24/11/2005, Georgios Karagiannis wrote: > >> >----- Original Message ----- From: > >> >To: ; > >> >Cc: ; > >> >Sent: Thursday, November 24, 2005 1:23 AM > >> >Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP > >> >re-markingcan do it > >> > > >> > > >> >>>>[GK] What is the technical reason of using ECN for edge-toedge > >> >>>>congestion control? > >> >>[PE] The use of Ecn seems natural to me, since we wnat the > >> network to > >> >>indicate incipient congestion and that's what ECN is > >> supposed to do. Note > >> >>that the semantics are the same as rfc3168 (ECN) - ie same > >> codepoints of > >> >>ECN field and CE codepoint indicates incipient congestion. > >> I also think > >> >>it can help with migration to a fully ecn world. As operators get > >> >>experience of using ecn, whilst not requiring all nws / end > >> hosts to be > >> >>using it. > >> > > >> >Georgios: yes I understand but the ECN semantics apply > >> end-to-end, not > >> >edge-toedge, > >> >please see the previous discussions on this issue! > >> > >> [BB] ECN semantics were originally defined for an end-to-end > >protocol > >> (TCP). That does not imply they were only intended to ever be > >> end-to-end. > >> RFC3168 did not preclude edge-to-edge. And at least one of > >the authors > >> believed edge-to-edge semantics could be a valid thing to > >define later > >> (see quote from Sally Floyd above). > >> > >> > >> > >> >>[PE] Second, using DSCP re-marking seems to need a lot of DSCPs. > >> >>According to your draft, admission control implies 2 per > >> traffic class > >> >>(one for re-marked pkts, one for other pkts passing thru the same > >> >>router). Plus another for the severe congestion indication. > >> In addition, > >> >>in the core network an interesting future extension is to use the > >> >>mechanisms in a network with MPLS-TE (see our framework > >> draft for brief > >> >>discussion) - there isnt sufficient space in the label for > >> these extra dscps. > >> > > >> >Georgios: regarding the number of DSCP's you are right, but > >> there are ways > >> >of reducing this number, please see the RMD draft. > >> >Please also note that the streaming aplication example that > >has been > >> >discussed in the tsvwg and nsis mailing lists shows that it is > >> >usefull to use end-to-end ECN based congestion control for reserved > >> >traffic. > >> >This streaming application example can very efficiently use > >> RSVP and the > >> >DCCP protocol (which uses the end-to-end ECN concept). > >> > >> [BB] No-one on the list has said it would be efficient. In fact the > >> opposite has been said (by Louise Burness) and no-one has > >disagreed. I > >> believe this hybrid service should be set aside for someone else to > >> define a mechanism for later. Intserv couldn't even do it very well, > >> even though it had a per-flow scheduler. > >> > >> > >> >[GK] Please also note that the support of this type of this type of > >> >streaming application that combines the end to end ECN > >semantics with > >> >reserved minimum bandwidth is needed not only in the > >backbone network > >> >but also in the wireless network as well. > >> >Therefore the rate-adaptation function of ECN (DCCP functionality) > >> >combined with minimum bandwidth reservation can be very important. > >> > >> [BB] Yes, an adaptive application with a minimum rate would be a > >> desirable service. But it's not the one we are defining. And > >you will > >> find it doesn't work with RMD's congestion-based admission scheme > >> either. > >> > >> [BB] We are trying to do Controlled Load to scale to the > >Internet. We > >> don't know how to implement this hybrid at Internet scale. > >We have had > >> to limit our scope to avoid this hybrid problem. And you will find > >> that such a hybrid service wouldn't work with the mechanism you have > >> defined for RMD either. > >> > >> [BB] So I need to turn your question back on you: how would you > >> prevent adaptive applications using your RMD congestion > >mechanism, and > >> breaking the admission control system? > >> > >> [BB] The solution I have proposed is to require the application to > >> signal this hybrid requirement and if it is not signalled, > >to drop any > >> excess traffic at the region ingress in order to disincentivise any > >> adaptive application trying to use the wrong service for its needs. > >> > >> > >> >>Third, (as bob has pointed out) that it's easy to overcome > >> the end-to-end > >> >>vs edge-to-edge > >> >marking issue (if that's really needed, which I'm inclined > >> to think it isnt) > >> > > >> >Georgios: regarding this point I am not sure if it is easy! > >> It depends on the > >> >imposed additional complexity. > >> > >> [BB] If a request for this hybrid were signalled (and an operator > >> chose to support the hybrid service), with the current state of > >> knowledge, I would say that this hybrid traffic would have > >to be dealt > >> with by a less scalable means, such as Intserv per-flow > >schedulers on > >> every node, or your hop by hop reservation method in RMD. > >> > >> > >> Bob > >> > >> >Best regards, > >> >Georgios > >> > > >> > > >> >> > >> >>________________________________ > >> >> > >> >>From: tsvwg-bounces@ietf.org on behalf of philip.eardley@bt.com > >> >>Sent: Wed 23/11/2005 23:48 > >> >>To: karagian@cs.utwente.nl > >> >>Cc: tsvwg@ietf.org; nsis@ietf.org > >> >>Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP > >> >>re-markingcan do it > >> >> > >> >> > >> >> > >> >>some comments below. > >> >> > >> >>best wishes, phil > >> >> > >> >>________________________________ > >> >> > >> >>* To: > > > >>>* Subject: [Tsvwg] why use edge-to-edge ECN re-marking > >when DSCP > >>>re-marking can do it > >>>* From: "Georgios Karagiannis" >>> > > >>>* Date: Mon, 21 Nov 2005 10:52:22 +0100 > >>>* Cc: tsvwg at ietf.org , nsis at > >>>ietf.org > >>> > >>>Hi Bob > >>> > >>>In addition to the previous discussion I would like to > >discuss and ask > >>>you the following. > >>> > >>>[chop] > >>>What is the technical reason of using ECN for edge-toedge congestion > >>>control, when the same solution (on providing admission > >control based > >>>on congestion notification and severe congestion > >[pre-emption]) can be > >>>provided by using DSCP re-marking? > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>tsvwg mailing list > >>>tsvwg@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/tsvwg > >>> > >> > >> > >>_______________________________________________ > >>nsis mailing list > >>nsis@ietf.org > >>https://www1.ietf.org/mailman/listinfo/nsis > > > >_______________________________________________________________ > >_____________ > >Bob Briscoe, Networks Research > >Centre, BT Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > >+44 1473 645196 > > > > > > > >_______________________________________________ > >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 > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 16 03:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEt-0005fz-8U; Thu, 16 Mar 2006 03:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEs-0005bQ-Jg for nsis@ietf.org; Thu, 16 Mar 2006 03:53:46 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoD9-0000zB-Vj for nsis@ietf.org; Thu, 16 Mar 2006 03:52:03 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FJoCk-0006kp-Lz; Thu, 16 Mar 2006 09:51:45 +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 EA0D0853C; Thu, 16 Mar 2006 09:51:32 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FJoCi-0007Vt-GQ; Thu, 16 Mar 2006 09:51:32 +0100 Message-ID: <44192713.4040200@tm.uka.de> Date: Thu, 16 Mar 2006 09:51:31 +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] Re: QoS NSLP: ACK flag has no effect? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "andrew.mcdonald@roke.co.uk" , "jmanner@cs.Helsinki.FI" , "nsis@ietf.org" , Ruediger.Geib@t-systems.com 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, > Rudiger, are you refering tothe draft: > draft-fu-nsis-diagnostics-nslp-01? > > If yes, then I agree with you! Ok, the problem is that this diagnostics nslp is separated from the QoS nslp and other nslps, therefore results may be different. > Roland, please note that the functionality associated with the ACK flag > can be used > by QoS models to give the possibility to a peer to request the imediate > generation of a Response from its neighbouring peer. Yep, but the way the ACK mechanism was previously specified made no sense. A received confirmation or a missing confirmation had no effect. That's why I proposed some retransmission mechanism within QoS NSLP. Maybe that was too ambitious and wasn't required actually (that's why I asked exactly about the original problem the ACK mechanism tried to solve!). > I am in favour of keeping this functionality. Georgious, you may be in favor of keeping it, but are there technical reasons? Now (after Ruediger is probably satisfied with a different solution and Georgious wants this explicit confirmation) I see different options: 1.) Provide a generic ACK mechanism for QoS models only. Thus, retransmissions etc. are QoS model specific. This is was more or less defined by the versions before -10. However, in this case we need to From nsis-bounces@ietf.org Thu Mar 16 03:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEt-0005fz-8U; Thu, 16 Mar 2006 03:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEs-0005bQ-Jg for nsis@ietf.org; Thu, 16 Mar 2006 03:53:46 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoD9-0000zB-Vj for nsis@ietf.org; Thu, 16 Mar 2006 03:52:03 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FJoCk-0006kp-Lz; Thu, 16 Mar 2006 09:51:45 +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 EA0D0853C; Thu, 16 Mar 2006 09:51:32 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FJoCi-0007Vt-GQ; Thu, 16 Mar 2006 09:51:32 +0100 Message-ID: <44192713.4040200@tm.uka.de> Date: Thu, 16 Mar 2006 09:51:31 +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] Re: QoS NSLP: ACK flag has no effect? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "andrew.mcdonald@roke.co.uk" , "jmanner@cs.Helsinki.FI" , "nsis@ietf.org" , Ruediger.Geib@t-systems.com 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, > Rudiger, are you refering tothe draft: > draft-fu-nsis-diagnostics-nslp-01? > > If yes, then I agree with you! Ok, the problem is that this diagnostics nslp is separated from the QoS nslp and other nslps, therefore results may be different. > Roland, please note that the functionality associated with the ACK flag > can be used > by QoS models to give the possibility to a peer to request the imediate > generation of a Response from its neighbouring peer. Yep, but the way the ACK mechanism was previously specified made no sense. A received confirmation or a missing confirmation had no effect. That's why I proposed some retransmission mechanism within QoS NSLP. Maybe that was too ambitious and wasn't required actually (that's why I asked exactly about the original problem the ACK mechanism tried to solve!). > I am in favour of keeping this functionality. Georgious, you may be in favor of keeping it, but are there technical reasons? Now (after Ruediger is probably satisfied with a different solution and Georgious wants this explicit confirmation) I see different options: 1.) Provide a generic ACK mechanism for QoS models only. Thus, retransmissions etc. are QoS model specific. This is was more or less defined by the versions before -10. However, in this case we need to specify the actions, i.e., the QoS model decides when the ACK flag is set, the receipt of a RESPONSE solicited by an ACK should be indicated to the QoS NSLP application/QoS model, and, the QoS model may retransmit a RESERVE in case no RESPONSE was received. 2.) Use QoS NSLP internal semantics as currently defined, i.e. QoS NSLP will trigger retransmissions. In either case I suggest to remove the statement: "This flag SHOULD be set on transmission by default." to "This flag MAY be set on transmission". Currently, I prefer option 1.) if the ACK functionality is really required. Regards, Roland > On 3/13/2006, "Geib, Ruediger" wrote: > >> Hello Roland, >> >> I didn't track it closely but would I be wrong if I say that the QoS >> NSLP was designed not have any topology awareness? If that's true >> and if mixing GIST and NSLP state information would be required >> for a useful NSLP Keep Alive mechanism, it may be better >> to concentrate on >> >> "Design Options of NSIS Diagnostics NSLP" >> >> and work out a mechanism for re-active NSLP monitoring >> (like PING and traceroute). Would you agree? >> >> Regards, >> >> Rüdiger >> >> RoB|Consequently I would prefer removal of the ACK flag and possibly >> |> |provide a simple HELLO mechanism (with adjustable timeouts) >> |> |between peers to detect communication failures. I really don't know >> |> |what fast reaction an application could undertake due a >> |> |transmission/processing failure of a RESERVE message that was >> |> |detected by the currently proposed ACK mechanism. -> see below >> |> >> RG Such a Hello mechanism may indeed be the better idea. The current >> |> NSLP version seems to be rather stable. Would you propose to >> |> include the Hello mechanism in the current draft or would it be >> |> acceptable to to start working on it in a later version (e.g. >> |> separate document - may be a feature desireable for other >> |> nslps too - or qos nslp version 2)? >> >> RoB >> |I think that adding a simple Hello mechanism would be not >> |so complex, since overall it would be easier than implementing the >> |currently proposed ACK mechanism with retransmissions >> |per message. On the other hand we have a problem, because >> |information is missing about the identity of the next QoS NSLP peer >> |since the latter is managed by GIST and the NLI is currently >> |not passed over the API (which makes it also hard to realize summary >> |refreshes BTW). So one could think >> |about an API extension that allows to pass NLIs from GIST to NSLPs so >> |that the NSLP instance is at least able to monitor a mapping from >> |sessions or flows to peers/neighbors. >> | >> |Note that GIST has already a HELLO mechanism per MA though it's primary >> |purpose was not to detect failures, but to keep the MA open, >> |right? Thus >> |the rate of HELLO messages would be relatively low. Moreover, it will >> |not detect the liveliness of the QoS NSLP instance, only of the GIST >> |instance. The second issue that we need to decide about is >> |the reaction of QoS NSLP when a failure is detected. >> |Possibly it can send an Invalidate Routing State to it's own GIST >> |instance. This may not help, however, in case the routing and GIST >> |is still working correctly. Sending a NOTIFY (but for which peers >> |exactly?) would also be an option, but I doubt that this would help >> |much. >> | >> |Regards, >> | Roland >> | >> | >> | >> |_______________________________________________ >> |nsis mailing list >> |nsis@ietf.org >> |https://www1.ietf.org/mailman/listinfo/nsis >> | > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 16 03:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.specify the actions, i.e., the QoS model decides when the ACK flag is set, the receipt of a RESPONSE solicited by an ACK should be indicated to the QoS NSLP application/QoS model, and, the QoS model may retransmit a RESERVE in case no RESPONSE was received. 2.) Use QoS NSLP internal semantics as currently defined, i.e. QoS NSLP will trigger retransmissions. In either case I suggest to remove the statement: "This flag SHOULD be set on transmission by default." to "This flag MAY be set on transmission". Currently, I prefer option 1.) if the ACK functionality is really required. Regards, Roland > On 3/13/2006, "Geib, Ruediger" wrote: > >> Hello Roland, >> >> I didn't track it closely but would I be wrong if I say that the QoS >> NSLP was designed not have any topology awareness? If that's true >> and if mixing GIST and NSLP state information would be required >> for a useful NSLP Keep Alive mechanism, it may be better >> to concentrate on >> >> "Design Options of NSIS Diagnostics NSLP" >> >> and work out a mechanism for re-active NSLP monitoring >> (like PING and traceroute). Would you agree? >> >> Regards, >> >> Rüdiger >> >> RoB|Consequently I would prefer removal of the ACK flag and possibly >> |> |provide a simple HELLO mechanism (with adjustable timeouts) >> |> |between peers to detect communication failures. I really don't know >> |> |what fast reaction an application could undertake due a >> |> |transmission/processing failure of a RESERVE message that was >> |> |detected by the currently proposed ACK mechanism. -> see below >> |> >> RG Such a Hello mechanism may indeed be the better idea. The current >> |> NSLP version seems to be rather stable. Would you propose to >> |> include the Hello mechanism in the current draft or would it be >> |> acceptable to to start working on it in a later version (e.g. >> |> separate document - may be a feature desireable for other >> |> nslps too - or qos nslp version 2)? >> >> RoB >> |I think that adding a simple Hello mechanism would be not >> |so complex, since overall it would be easier than implementing the >> |currently proposed ACK mechanism with retransmissions >> |per message. On the other hand we have a problem, because >> |information is missing about the identity of the next QoS NSLP peer >> |since the latter is managed by GIST and the NLI is currently >> |not passed over the API (which makes it also hard to realize summary >> |refreshes BTW). So one could think >> |about an API extension that allows to pass NLIs from GIST to NSLPs so >> |that the NSLP instance is at least able to monitor a mapping from >> |sessions or flows to peers/neighbors. >> | >> |Note that GIST has already a HELLO mechanism per MA though it's primary >> |purpose was not to detect failures, but to keep the MA open, >> |right? Thus >> |the rate of HELLO messages would be relatively low. Moreover, it will >> |not detect the liveliness of the QoS NSLP instance, only of the GIST >> |instance. The second issue that we need to decide about is >> |the reaction of QoS NSLP when a failure is detected. >> |Possibly it can send an Invalidate Routing State to it's own GIST >> |instance. This may not help, however, in case the routing and GIST >> |is still working correctly. Sending a NOTIFY (but for which peers >> |exactly?) would also be an option, but I doubt that this would help >> |much. >> | >> |Regards, >> | Roland >> | >> | >> | >> |_______________________________________________ >> |nsis mailing list >> |nsis@ietf.org >> |https://www1.ietf.org/mailman/listinfo/nsis >> | > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 16 03:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEt-0005iD-OH; Thu, 16 Mar 2006 03:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEs-0005bQ-Q7 for nsis@ietf.org; Thu, 16 Mar 2006 03:53:46 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoAx-0000sb-8r for nsis@ietf.org; Thu, 16 Mar 2006 03:49: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 E6FC21BAC4D; Thu, 16 Mar 2006 09:49:16 +0100 (CET) In-Reply-To: <4417EF8D.90207@roke.co.uk> References: <4417EF8D.90207@roke.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NSLP IDs and RAO values Date: Thu, 16 Mar 2006 09:49:40 +0100 To: Andrew McDonald X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Georgios Karagiannis , 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, Good catch by Andrew on the NSLP IDs and RAO. The RAO value is also missing in the NATFW NSLP and is now issue No. 71 (https:// kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue71). There is no need for the NATFW NSLP to have multiple RAO values, since there is no aggregation on this level. More inline. Am 15.03.2006 um 11:42 schrieb Andrew McDonald: > Georgios Karagiannis wrote: >> Yes, I think that it is needed to explicitly describe the >> allocation by >> IANA of additional values. > > From an off-list clarification (posted with permission): > Georgios Karagiannis wrote: > > What I mean is: > > In my opinion it is implicitly assumed to be in step with the > > IPv6 list. > > This should be made explicit in the QoS-NSLP draft, etc... > > I would have thought this would need an update to RFC2113 (doing it > in the QoS NSLP draft seems a bit odd to me from a process point of > view). This is probably a procedural question: What happens if there is a document specifying protocol values that actually should be administrated by IANA, *BUT* the request to IANA was not issued at the time the RFC was made? Does this require a RFC 2113 bis or is it sufficient to get IANA on board by an IESG decision? > > Also, having checked a bit further, it doesn't look to me as if the > IPv4/IPv6 RAO values are in step since: > IPv4: 0 - Router shall examine packet (RFC2113) > IPv6: 0 - Datagram contains a Multicast Listener Discovery message > (RFC2710/RFC2711) There are not in step, since there is no IANA registry for IPv4 and IPv6 has already these entries (http://www.iana.org/assignments/ipv6- routeralert-values): Value Description Reference ----- --------------------------------------------- --------- 0 Datagram contains a Multicast Listener [RFC2711] Discovery message [RFC2710] 1 Datagram contains RSVP message [RFC2711] 2 Datagram contains an Active Networks message [RFC2711] 3-35 Aggregated Reservation Nesting Level [RFC3175] 36-65534 Reserved to IANA for future use 65535 Reserved [IANA] > > To add slightly more to my confusion, RFC2113 defines: > >>> > Value: A two octet code with the following values: > 0 - Router shall examine packet > 1-65535 - Resietf.org with esmtp (Exim 4.43) id 1FJoEt-0005iD-OH; Thu, 16 Mar 2006 03:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEs-0005bQ-Q7 for nsis@ietf.org; Thu, 16 Mar 2006 03:53:46 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoAx-0000sb-8r for nsis@ietf.org; Thu, 16 Mar 2006 03:49: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 E6FC21BAC4D; Thu, 16 Mar 2006 09:49:16 +0100 (CET) In-Reply-To: <4417EF8D.90207@roke.co.uk> References: <4417EF8D.90207@roke.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NSLP IDs and RAO values Date: Thu, 16 Mar 2006 09:49:40 +0100 To: Andrew McDonald X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Georgios Karagiannis , 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, Good catch by Andrew on the NSLP IDs and RAO. The RAO value is also missing in the NATFW NSLP and is now issue No. 71 (https:// kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue71). There is no need for the NATFW NSLP to have multiple RAO values, since there is no aggregation on this level. More inline. Am 15.03.2006 um 11:42 schrieb Andrew McDonald: > Georgios Karagiannis wrote: >> Yes, I think that it is needed to explicitly describe the >> allocation by >> IANA of additional values. > > From an off-list clarification (posted with permission): > Georgios Karagiannis wrote: > > What I mean is: > > In my opinion it is implicitly assumed to be in step with the > > IPv6 list. > > This should be made explicit in the QoS-NSLP draft, etc... > > I would have thought this would need an update to RFC2113 (doing it > in the QoS NSLP draft seems a bit odd to me from a process point of > view). This is probably a procedural question: What happens if there is a document specifying protocol values that actually should be administrated by IANA, *BUT* the request to IANA was not issued at the time the RFC was made? Does this require a RFC 2113 bis or is it sufficient to get IANA on board by an IESG decision? > > Also, having checked a bit further, it doesn't look to me as if the > IPv4/IPv6 RAO values are in step since: > IPv4: 0 - Router shall examine packet (RFC2113) > IPv6: 0 - Datagram contains a Multicast Listener Discovery message > (RFC2710/RFC2711) There are not in step, since there is no IANA registry for IPv4 and IPv6 has already these entries (http://www.iana.org/assignments/ipv6- routeralert-values): Value Description Reference ----- --------------------------------------------- --------- 0 Datagram contains a Multicast Listener [RFC2711] Discovery message [RFC2710] 1 Datagram contains RSVP message [RFC2711] 2 Datagram contains an Active Networks message [RFC2711] 3-35 Aggregated Reservation Nesting Level [RFC3175] 36-65534 Reserved to IANA for future use 65535 Reserved [IANA] > > To add slightly more to my confusion, RFC2113 defines: > >>> > Value: A two octet code with the following values: > 0 - Router shall examine packet > 1-65535 - Reserved > <<< > and says: > >>> > Hosts shall ignore this option. Routers that do not recognize this > option shall ignore it. Routers that recognize this option shall > examine packets carrying it more closely (check the IP Protocol > field, for example) to determine whether or not further > processing is > necessary. Unrecognized value fields shall be silently ignored. > > The semantics of other values in the Value field are for further > study. > <<< > RFC3175 then says: > >>> > The IPv4 Router > Alert [RFC2113] has the option simply to ask the router to look at > the protocol type of the intercepted datagram and decide what to do > with it; the parameter is additional information to that decision. > <<< > and defines a use for the 'Reserved' values to indicate the > aggregation level. However, there is no explicit update of RFC2113 > to redefine (and provide new semantics for) those reserved values. I see this as a big mistake of RFC 3175. We could try to meet with the RFC 3175 authors and have a quick chat with them about it. Martin > > Andrew > > >> On 3/13/2006, "Andrew McDonald" wrote: >>> Hi all, >>> >>> In thinking about the aggregation parts of the QoS NSLP draft, >>> there are >>> some IANA-related issues: >>> - IANA considerations currently requests a single NSLP ID for the >>> QoS >>> NSLP, the aggregation mechanism as described in 4.6/4.7 needs >>> multiple >>> NSLP IDs >>> - the document doesn't mentioned what Router Alert Option (RAO) >>> values >>> should be used for the NSLP ID(s) that are allocated >>> >>> For IPv6, it is fairly clear that we should be asking for (or >>> referring >>> to) allocations in the IPv6 Router Alert Option Values (RFC2711) >>> registry (http://www.iana.org/assignments/ipv6-routeralert- >>> values). This >>> contains the aggregation RAO values from RFC3175. >>> >>> For IPv4 (RFC2113), I can't see an appropriate registry. I seem to >>> remember discussing this before, but don't think we reached a >>> conclusion. RFC2113 defines a value of 0, and leaves others >>> reserved. >>> Allocation by IANA of additional values is not mentioned. Is it >>> implicitly assumed to be in step with the IPv6 list? Do we need >>> to do >>> something to make this explicit? >>> >>> This is an issue for the NSLP drafts, and also relevant for the >>> extensibility draft. >>> >>> 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 erved > <<< > and says: > >>> > Hosts shall ignore this option. Routers that do not recognize this > option shall ignore it. Routers that recognize this option shall > examine packets carrying it more closely (check the IP Protocol > field, for example) to determine whether or not further > processing is > necessary. Unrecognized value fields shall be silently ignored. > > The semantics of other values in the Value field are for further > study. > <<< > RFC3175 then says: > >>> > The IPv4 Router > Alert [RFC2113] has the option simply to ask the router to look at > the protocol type of the intercepted datagram and decide what to do > with it; the parameter is additional information to that decision. > <<< > and defines a use for the 'Reserved' values to indicate the > aggregation level. However, there is no explicit update of RFC2113 > to redefine (and provide new semantics for) those reserved values. I see this as a big mistake of RFC 3175. We could try to meet with the RFC 3175 authors and have a quick chat with them about it. Martin > > Andrew > > >> On 3/13/2006, "Andrew McDonald" wrote: >>> Hi all, >>> >>> In thinking about the aggregation parts of the QoS NSLP draft, >>> there are >>> some IANA-related issues: >>> - IANA considerations currently requests a single NSLP ID for the >>> QoS >>> NSLP, the aggregation mechanism as described in 4.6/4.7 needs >>> multiple >>> NSLP IDs >>> - the document doesn't mentioned what Router Alert Option (RAO) >>> values >>> should be used for the NSLP ID(s) that are allocated >>> >>> For IPv6, it is fairly clear that we should be asking for (or >>> referring >>> to) allocations in the IPv6 Router Alert Option Values (RFC2711) >>> registry (http://www.iana.org/assignments/ipv6-routeralert- >>> values). This >>> contains the aggregation RAO values from RFC3175. >>> >>> For IPv4 (RFC2113), I can't see an appropriate registry. I seem to >>> remember discussing this before, but don't think we reached a >>> conclusion. RFC2113 defines a value of 0, and leaves others >>> reserved. >>> Allocation by IANA of additional values is not mentioned. Is it >>> implicitly assumed to be in step with the IPv6 list? Do we need >>> to do >>> something to make this explicit? >>> >>> This is an issue for the NSLP drafts, and also relevant for the >>> extensibility draft. >>> >>> 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 Thu Mar 16 04:04:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoP4-0000Ml-79; Thu, 16 Mar 2006 04:04:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoP3-0000Mg-16 for nsis@ietf.org; Thu, 16 Mar 2006 04:04:17 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoOz-0001YZ-Bs for nsis@ietf.org; Thu, 16 Mar 2006 04:04:16 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id k2G946F1003348; Thu, 16 Mar 2006 10:04:06 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k2G945D8018639; Thu, 16 Mar 2006 10:04:05 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k2G945Y12815; Thu, 16 Mar 2006 10:04:05 +0100 (MET) Date: Thu, 16 Mar 2006 10:04:05 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: bless@tm.uka.de Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 16 Mar 2006 09:04:05 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <44192713.4040200@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: -5.678 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 16 Mar 2006 10:04:08 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: "andrew.mcdonald@roke.co.uk" , "jmanner@cs.Helsinki.FI" , "nsis@ietf.org" , "Ruediger.Geib@t-systems.com" 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! The ACK is not needed at all! In case a node expects a RESPONSE it may include a RII if there is no RII carried by the incoming RESERVE. Thus I also support the proposal of removing completely the ACK functionality! Best Regards, Georgios Best Re On 3/16/2006, "Roland Bless" wrote: >Hi Georgios, > >> Rudiger, are you refering tothe draft: >> draft-fu-nsis-diagnostics-nslp-01? >> >> If yes, then I agree with you! > >Ok, the problem is that this diagnostics nslp is >separated from the QoS nslp and other nslps, >therefore results may be different. > >> Roland, please note that the functionality associated with the ACK flag >> can be used >> by QoS models to give the possibility to a peer to request the imediate >> generation of a Response from its neighbouring peer. > >Yep, but the way the ACK mechanism was previously >specified made no sense. A received confirmation or a >missing confirmation had no effect. That's why I proposed >some retransmission mechanism within QoS NSLP. Maybe that >was too ambitious and wasn't required actually (that's why >I asked exactly about the original problem the ACK mechanism >tried to solve!). > >> I am in favour of keeping this functionality. > >Georgious, you may be in favor of keeping it, but are there >technical reasons? >Now (after Ruediger is probably satisfied with a different solution >and Georgious wants this explicit confirmation) >I see different options: > >1.) Provide a generic ACK mechanism for QoS models only. > Thus, retransmissions etc. are QoS model specific. > This is was more or less defined by the versions before -10. > However, in this case we need to specify the actions, > i.e., the QoS model decides when the ACK flag is set, > the receipt of a RESPONSE solicited by an ACK should > be indicated to the QoS NSLP application/QoS model, and, > the QoS model may retransmit a RESERVE in case no RESPONSE > was received. > >2.) Use QoS NSLP internal semantics as currently defined, > i.e. QoS NSLP will trigger retransmissions. > >In either case I suggest to remove the statement: >"This flag SHOULD be set on transmission by default." >to >"This flag MAY be set on transmission". > >Currently, I prefer option 1.) if the ACK functionality is >really required. > >Regards, > Roland > >> On 3/13/2006, "Geib, Ruediger" wrote: >> >>> Hello Roland, >>> >>> I didn't track it closely but would I be wrong if I say that the QoS >>> NSLP was designed not have any topology awareness? If that's true >>> and if mixing GIST and NSLP state information would be required >>> for a useful NSLP Keep Alive mechanism, it may be better >>> to concentrate on >>> >>> "Design Options of NSIS Diagnostics NSLP" >>> >>> and work out a mechanism for re-active NSLP monitoring >>> (like PING and traceroute). Would you agree? >>> >>> Regards, >>> >>> R=FCdiger >>> >>> RoB|Consequently I would prefer removal of the ACK flag and possibly >>> |> |provide a simple HELLO mechanism (with adjustable timeouts) >>> |> |between peers to detect communication failures. I really don't know >>> |> |what fast reaction an application could undertake due a >>> |> |transmission/processing failure of a RESERVE message that was >>> |> |detected by the currently proposed ACK mechanism. -> see below >>> |> >>> RG Such a Hello mechanism may indeed be the better idea. The current >>> |> NSLP version seems to be rather stable. Would you propose to >>> |> include the Hello mechanism in the current draft or would it be >>> |> acceptable to to start working on it in a later version (e.g. >>> |> separate document - may be a feature desireable for other >>> |> nslps too - or qos nslp version 2)? >>> >>> RoB >>> |I think that adding a simple Hello mechanism would be not >>> |so complex, since overall it would be easier than implementing the >>> |currently proposed ACK mechanism with retransmissions >>> |per message. On the other hand we have a problem, because >>> |information is missing about the identity of the next QoS NSLP peer >>> |since the latter is managed by GIST and the NLI is currently >>> |not passed over the API (which makes it also hard to realize summary >>> |refreshes BTW). So one could think >>> |about an API extension that allows to pass NLIs from GIST to NSLPs so >>> |that the NSLP instance is at least able to monitor a mapping from >>> |sessions or flows to peers/neighbors. >>> | >>> |Note that GIST has already a HELLO mechanism per MA though it's primary >>> |purpose was not to detect failures, but to keep the MA open, >>> |right? Thus >>> |the rate of HELLO messages would be relatively low. Moreover, it will >>> |not detect the liveliness of the QoS NSLP instance, only of the GIST >>> |instance. The second issue that we need to decide about is >>> |the reaction of QoS NSLP when a failure is detected. >>> |Possibly it can send an Invalidate Routing State to it's own GIST >>> |instance. This may not help, however, in case the routing and GIST >>> |is still working correctly. Sending a NOTIFY (but for which peers >>> |exactly?) would also be an option, but I doubt that this would help >>> |much. >>> | >>> |Regards, >>> | Roland >>> | >>> | >>> | >>> |_______________________________________________ >>> |nsis mailing list >>> |nsis@ietf.org >>> |https://www1.ietf.org/mailman/listinfo/nsis >>> | >> > > >-- >Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless >Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH), Germany >Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 >Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 16 04:21:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJofg-0004kQ-Dj; Thu, 16 Mar 2006 04:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoff-0004kL-Cd for nsis@ietf.org; Thu, 16 Mar 2006 04:21:27 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJofe-0002gT-Vi for nsis@ietf.org; Thu, 16 Mar 2006 04:21:27 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FJofa-00085I-MQ; Thu, 16 Mar 2006 10:21: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 7FF6F8A4F; Thu, 16 Mar 2006 10:21:22 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FJofZ-0007Xi-Mp; Thu, 16 Mar 2006 10:21:21 +0100 Message-ID: <44192E11.2010007@tm.uka.de> Date: Thu, 16 Mar 2006 10:21:21 +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] Re: QoS NSLP: ACK flag has no effect? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "andrew.mcdonald@roke.co.uk" , "jmanner@cs.Helsinki.FI" , "nsis@ietf.org" , "Ruediger.Geib@t-systems.com" 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, > You are right! > The ACK is not needed at all! > In case a node expects a RESPONSE it may include a RII if there is no RII > carried by the incoming RESERVE. Yes, exactly. > Thus I also support the proposal of removing completely the ACK > functionality! Ok, that was option 3.) as proposed in an earlier mail :-) Regards, Roland > On 3/16/2006, "Roland Bless" wrote: > >> Hi Georgios, >> >>> Rudiger, are you refering tothe draft: >>> draft-fu-nsis-diagnostics-nslp-01? >>> >>> If yes, then I agree with you! >> Ok, the problem is that this diagnostics nslp is >> separated from the QoS nslp and other nslps, >> therefore results may be different. >> >>> Roland, please note that the functionality associated with the ACK flag >>> can be used >>> by QoS models to give the possibility to a peer to request the imediate >>> generation of a Response from its neighbouring peer. >> Yep, but the way the ACK mechanism was previously >> specified made no sense. A received confirmation or a >> missing confirmation had no effect. That's why I proposed >> some retransmission mechanism within QoS NSLP. Maybe that >> was too ambitious and wasn't required actually (that's why >> I asked exactly about the original problem the ACK mechanism >> tried to solve!). >> >>> I am in favour of keeping this functionality. >> Georgious, you may be in favor of keeping it, but are there >> technical reasons? >> Now (after Ruediger is probably satisfied with a different solution >> and Georgious wants this explicit confirmation) >> I see different options: >> >> 1.) Provide a generic ACK mechanism for QoS models only. >> Thus, retransmissions etc. are QoS model specific. >> This is was more or less defined by the versions before -10. >> However, in this case we need to specify the actions, >> i.e., the QoS model decides when the ACK flag is set, >> the receipt of a RESPONSE solicited by an ACK should >> be indicated to the QoS NSLP application/QoS model, and, >> the QoS model may retransmit a RESERVE in case no RESPONSE >> was received. >> >> 2.) Use QoS NSLP internal semantics as currently defined, >> i.e. QoS NSLP will trigger retransmissions. >> >> In either case I suggest to remove the statement: >> "This flag SHOULD be set on transmission by default." >> to >> "This flag MAY be set on transmission". >> >> Currently, I prefer option 1.) if the ACK functionality is >> really required. >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 16 09:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtIy-0005H8-Bv; Thu, 16 Mar 2006 09:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtIx-0005Gy-B3 for nsis@ietf.org; Thu, 16 Mar 2006 09:18:19 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtIv-0003QP-TA for nsis@ietf.org; Thu, 16 Mar 2006 09:18:19 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2GEI2ti024046; Thu, 16 Mar 2006 14:18:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Some small errors Date: Thu, 16 Mar 2006 14:18:02 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Some small errors Thread-Index: AcZHRnUsj5WQlrytQsGQX9Uto1NXqwBvROJQ From: "Hancock, Robert" To: "Bo Gao" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Bo, Thanks for the comments. Please see in line: > -----Original Message----- > From: Bo Gao [mailto:gao_b@cs.concordia.ca]=20 > Sent: 14 March 2006 09:05 > To: nsis@ietf.org > Subject: [NSIS] Some small errors >=20 >=20 > Hello, > In the Internet-Draft of GIST=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-09.txt, > At Page 34,line 5, "it if" should be "if it". > At Page 50, "NTLP" should be modified to "GIST" in the sentence=20 > "Alternatively, receipt of an upstream Query at the flow=20 > source MAY be=20 > used to trigger setup of NTLP state in the downstream=20 > direction" as the=20 > name has been already changed. > At Page 61, in the rule 2 "if a new MA-SM would be needed for this=20 > peer, create one in listening state", I think this applies to rule 1=20 > too. As the confirm can be sent over the new established MA=20 > (Not sure). I've added these to the issue tracker at=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue105 basically the answers are *) yes *) yes *) not quite; in fact, the rules about when to create a listening MA are not really consistently listed (should also be in rules 1 and 5 here and also rule 1 for the node level SM). the point is that listening MA creation is only loosely correlated with the message processing; this needs to be clarified in the context of what state needs to be in=20 place before a Response is sent. >=20 > Also I have a question about the local processing, How could the=20 > signaling application indicate it wishes to become a signaling peer=20 > with the Querying node? I checked the service interface between GIST=20 > and NSLP, I couldn't figure out if it is a functionality of the=20 > SendMessage or a functionality of RecvMessage. Is the parameter "=20 > Transfer-Attribute " in the ReceMessage a in-out parameter? this is handled in the RecvMessage primitive: when a Query is received the NSLP gets a RecvMessage, and its reaction determines whether peering takes place and the payload in the Response. See the discussion of the Routing-State-Check argument to RecvMessage in B.2 (and references therein). cheers, r. >=20 > Sincerely >=20 > Bo Gao > E-mail: gao_b@cs.concordia.ca > Web: http://www.cs.concordia.ca/~gao_b >=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 16 12:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwTh-0002pf-Pi; Thu, 16 Mar 2006 12:41:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwTg-0002pa-Mp for nsis@ietf.org; Thu, 16 Mar 2006 12:41:36 -0500 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJwTg-000238-8m for nsis@ietf.org; Thu, 16 Mar 2006 12:41:36 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-124.messagelabs.com!1142530673!7802799!57 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19531 invoked from network); 16 Mar 2006 17:41:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-124.messagelabs.com with SMTP; 16 Mar 2006 17:41:34 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4401E007002750CC; Thu, 16 Mar 2006 12:41: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 Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes Date: Thu, 16 Mar 2006 11:41:33 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC753A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7525@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP INFO_SPEC and error codes Thread-Index: AcZDnkdSQlCrDHd3RMWXekjIkJhyXAD/lNaAAF+LhgA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Ash, Gerald R \(Jerry\), ALABS" , attila.bader@ericsson.com, cornelia.kappler@siemens.com 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, Please see comments in line: > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Thursday, March 09, 2006 12:23 PM > To: Jukka MJ Manner; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: [NSIS] QoS NSLP INFO_SPEC and error codes >=20 > A few comments in the area of the INFO_SPEC object and error codes. >=20 > Draft -10 doesn't seem to have appeared yet, but these comments apply=20 > equally to -09 and -10. >=20 > Protocol errors include: > * 0x08 - Unknown QSPEC type: the QoS Model ID refers to a > QoS Model which is not known by this QNE. > It's not clear to me that is a protocol error. Firstly, QoS Model ID > is inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly, > my understanding from the QSPEC template is that, in the case of an > unknown QoS Model ID, the RMF should continue to process mandatory=20 > QSPEC parameters. Jerry> Both comments are correct. This error subcode should probably be deleted. Should it be replaced by some other type of error involving QOSM ID (none come to mind for me)? =20 > Transient failure codes include: > * 0x01 - Requested resources not available > * 0x02 - Insufficient bandwidth available > * 0x03 - Delay requirement cannot be met >=20 > Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since > they directly relate to information in the QSPEC rather than the > main QoS NSLP data? Jerry> I agree that 0x02 and 0x03 are specific cases of 0x01, but they are not IMO "QoS model specific" since is a mandatory QSPEC parameter and is an optional QSPEC parameter. Similarly, perhaps "cannot be met" error subcodes should be defined for , , and parameters, which are also optional QSPEC parameters. =20 Perhaps it's better to describe the '4-bit error class', '12-bit error codes', and '8-bit QoS model-specific error subcode' in terms of "QSPEC/RMF-specific" rather than "QoS Model specific". So then the 4-bit error class=20 "0x06 - QoS model-specific Error"=20 becomes=20 "0x06 - QSPEC/RMF-specific Error". And also redefine the=20 "8-bit QoS model-specific error subcode"=20 as "8-bit QSPEC/RMF-specific error subcode". Then within the 4-bit error class "0x06 - QSPEC/RMF-specific Error" the following 12-bit error code is defined (now a 'transient failure code"): 0x01 - Requested resources not available And within that 12-bit error code the following "8-bit QSPEC/RMF-specific error subcodes" are defined: 0x02 - cannot be met 0x03 - cannot be met and perhaps others, e.g., 0xab - cannot be met 0xcd - cannot be met 0xef - cannot be met=20 etc. These error codes pertaining to mandatory/optional QSPEC parameters (defined within the QSPEC I-D) can either be defined in the QoS-NSLP I-D (preferably IMO) or alternatively within the QSPEC I-D. =20 Additional 'QSPEC/RMF-specific Errors' and their '12-bit error code' and '8-bit QSPEC/RMF-specific error subcodes' pertaining to (optional) QSPEC parameters defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, etc.) should also be defined in the QOSM-specific I-Ds. Should any of the above be identified as issues to be discussed at IETF-65? Please let me know what you think. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 16 18:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1o5-0002JF-DI; Thu, 16 Mar 2006 18:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1o4-0002JA-W1 for nsis@ietf.org; Thu, 16 Mar 2006 18:23:00 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1o3-0006oI-Mm for nsis@ietf.org; Thu, 16 Mar 2006 18:23:00 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 1AA71102AE for ; Fri, 17 Mar 2006 00:22:59 +0100 (CET) Received: from [84.132.199.146] (p5484C792.dip0.t-ipconnect.de [84.132.199.146]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP for ; Fri, 17 Mar 2006 00:22:58 +0100 (CET) Message-ID: <4419F350.20505@cs.uni-goettingen.de> Date: Fri, 17 Mar 2006 00:22:56 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "nsis@ietf.org" Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <44192E11.2010007@tm.uka.de> In-Reply-To: <44192E11.2010007@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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, There could be several non-competing options (to apply in different scenarios): A. making trigger messages be reliable (which could be very useful, as concluded by [1]) B. making usual refreshes be reliable (which could be not as useful as A) C. making reduced overhead extension refreshes to be reliable (which will be useful per RFC2961/[2]). D. making removal messages be reliable (which could be useful, as concluded by [1]) "Reliable" above means whether one needs an explict Response to be sent from the recipient upon receipt of the corresponding trigger/refresh/removal. My view is that unreliable transmission would suffice B; for A and C reliability SHOULD/MUST be made; for D reliability MAY be made. Relying on the existence of RII to determine whether to give a response is probably not a typical behavior from my personal limited understanding of other protocols. [1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison of Hard-State and Soft-State Signaling Protocols, SIGCOMM 2003. [2] P. Pan and H. Schulzrine, Staged Refresh Timers for RSVP, Global Internet 1997. Cheers, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 17 05:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBpr-0007wI-9B; Fri, 17 Mar 2006 05:05:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBpq-0007wD-6A for nsis@ietf.org; Fri, 17 Mar 2006 05:05:30 -0500 Received: from pproxy.gmail.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBpm-0000hk-RW for nsis@ietf.org; Fri, 17 Mar 2006 05:05:30 -0500 Received: by pproxy.gmail.com with SMTP id n25so826683pyg for ; Fri, 17 Mar 2006 02:05:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=WG/zXIwAteICxpR+JezjLiDdgNg/SdFJ5oj3gbSkP3BcmZ4iXHAF/HceVa2Jpk7TZovUqb0Mw5buLy+/CcDCblRUhSLLxqUFnxNIkkNO7z08K5K47qE0roN4blcVwtBYcwIgwJDMDcdH38RwnMM/PeK/6J7YCVsXcy5dCIUnZdk= Received: by 10.35.127.7 with SMTP id e7mr503129pyn; Fri, 17 Mar 2006 02:05:25 -0800 (PST) Received: by 10.35.95.14 with HTTP; Fri, 17 Mar 2006 02:05:25 -0800 (PST) Message-ID: <666f9ac70603170205m7f5249bbm@mail.gmail.com> Date: Fri, 17 Mar 2006 11:05:25 +0100 From: "Gregory William Ray" To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 1.9 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [NSIS] Presentation 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'm a student and I must study NSIS for my thesis! I have already read some draft and RFC of the working group. I'm interested to NSIS in mobile environment. I would want to know if there are NSIS implementation (or a patch for NS2). Thanks in advance, Gregory W. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 18 13:03:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKflp-0008IH-5b; Sat, 18 Mar 2006 13:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKflo-0008GQ-FC for nsis@ietf.org; Sat, 18 Mar 2006 13:03:20 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKflo-0001ij-0B for nsis@ietf.org; Sat, 18 Mar 2006 13:03:20 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2II1DYo018895; Sat, 18 Mar 2006 20:01:14 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:03:18 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:03:18 +0200 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] NSLP IDs and RAO values Date: Sat, 18 Mar 2006 20:03:18 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A02B@esebe100.NOE.Nokia.com> In-Reply-To: <441588CC.705@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSLP IDs and RAO values Thread-Index: AcZGruViWoJ78mEaSnmfjlFKxroWDwEBkVMw From: To: , X-OriginalArrivalTime: 18 Mar 2006 18:03:18.0420 (UTC) FILETIME=[3C620D40:01C64AB6] X-Spam-Score: 0.2 (/) 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 Andrew, Couple of questions: >In thinking about the aggregation parts of the QoS NSLP draft,=20 >there are some IANA-related issues: >- IANA considerations currently requests a single NSLP ID for=20 >the QoS NSLP, the aggregation mechanism as described in=20 >4.6/4.7 needs multiple NSLP IDs >From 4.6, it says: The marking MUST be accomplished by the Aggregator by modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value.=20 This text somewhat confuses me, and I confess that I missed this earlier. I guess the idea is to use different RAO for aggregated reservation nesting? Would we have 1 NSLP-ID per nested reservation? Or something else? >- the document doesn't mentioned what Router Alert Option=20 >(RAO) values should be used for the NSLP ID(s) that are allocated This should be fixed in the QoS NSLP, IMO. I think it should mention how to match the RAO with NSLPIDs. >For IPv6, it is fairly clear that we should be asking for (or referring >to) allocations in the IPv6 Router Alert Option Values (RFC2711) registry=20 >(http://www.iana.org/assignments/ipv6-routeralert-values).=20 >This contains the aggregation RAO values from RFC3175. This is what we would use in the QoS NSLP, correct? I guess the QOS NSLP should say something about this. >For IPv4 (RFC2113), I can't see an appropriate registry. I=20 >seem to remember discussing this before, but don't think we=20 >reached a conclusion. RFC2113 defines a value of 0, and leaves=20 >others reserved.=20 I will check on this. >Allocation by IANA of additional values is not mentioned. Is=20 >it implicitly assumed to be in step with the IPv6 list? Do we=20 >need to do something to make this explicit? I think we need to say what RAO we need to use, and if we need to allocate them, then that would be the IANA considerations. >This is an issue for the NSLP drafts, and also relevant for=20 >the extensibility draft. Agreed. However, I think for the Extensibility draft, the general relationship between the RAO & NSLP could be discussed, but I'm not sure if there should be much else. =20 Thoughts? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 18 13:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfo9-0000jQ-Qx; Sat, 18 Mar 2006 13:05:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfo8-0000jL-9S for nsis@ietf.org; Sat, 18 Mar 2006 13:05:44 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKfo5-0001ma-O1 for nsis@ietf.org; Sat, 18 Mar 2006 13:05:44 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2II5bk0020543; Sat, 18 Mar 2006 20:05:37 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:05:37 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:05:36 +0200 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] NSLP IDs and RAO values Date: Sat, 18 Mar 2006 20:05:36 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A02C@esebe100.NOE.Nokia.com> In-Reply-To: <4417EF8D.90207@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSLP IDs and RAO values Thread-Index: AcZIHaiYfFaqy+MTSFqAfEMB7UTObwCmNJTA From: To: , X-OriginalArrivalTime: 18 Mar 2006 18:05:36.0772 (UTC) FILETIME=[8ED8E440:01C64AB6] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Andrew, I'll try to sort out the RAO for IPv4 and get back with a solution. John >-----Original Message----- >From: ext Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 >Sent: 15 March, 2006 12:42 >To: Georgios Karagiannis >Cc: nsis@ietf.org >Subject: Re: [NSIS] NSLP IDs and RAO values > >Georgios Karagiannis wrote: >> Yes, I think that it is needed to explicitly describe the allocation=20 >> by IANA of additional values. > > From an off-list clarification (posted with permission): >Georgios Karagiannis wrote: > > What I mean is: > > In my opinion it is implicitly assumed to be in step with=20 >the > IPv6 list. > > This should be made explicit in the QoS-NSLP draft, etc... > >I would have thought this would need an update to RFC2113=20 >(doing it in the QoS NSLP draft seems a bit odd to me from a=20 >process point of view). > >Also, having checked a bit further, it doesn't look to me as if the >IPv4/IPv6 RAO values are in step since: >IPv4: 0 - Router shall examine packet (RFC2113) >IPv6: 0 - Datagram contains a Multicast Listener Discovery message >(RFC2710/RFC2711) > >To add slightly more to my confusion, RFC2113 defines: > >>> > Value: A two octet code with the following values: > 0 - Router shall examine packet > 1-65535 - Reserved ><<< >and says: > >>> > Hosts shall ignore this option. Routers that do not recognize this > option shall ignore it. Routers that recognize this option shall > examine packets carrying it more closely (check the IP Protocol > field, for example) to determine whether or not further=20 >processing is > necessary. Unrecognized value fields shall be silently ignored. > > The semantics of other values in the Value field are for further > study. ><<< >RFC3175 then says: > >>> > The IPv4 Router > Alert [RFC2113] has the option simply to ask the router to look at > the protocol type of the intercepted datagram and decide what to do > with it; the parameter is additional information to that decision. ><<< >and defines a use for the 'Reserved' values to indicate the=20 >aggregation level. However, there is no explicit update of=20 >RFC2113 to redefine (and provide new semantics for) those=20 >reserved values. > >Andrew > > >> On 3/13/2006, "Andrew McDonald" wrote: >>=20 >>> Hi all, >>> >>> In thinking about the aggregation parts of the QoS NSLP=20 >draft, there=20 >>> are some IANA-related issues: >>> - IANA considerations currently requests a single NSLP ID=20 >for the QoS=20 >>> NSLP, the aggregation mechanism as described in 4.6/4.7 needs=20 >>> multiple NSLP IDs >>> - the document doesn't mentioned what Router Alert Option (RAO)=20 >>> values should be used for the NSLP ID(s) that are allocated >>> >>> For IPv6, it is fairly clear that we should be asking for (or=20 >>> referring >>> to) allocations in the IPv6 Router Alert Option Values (RFC2711)=20 >>> registry (http://www.iana.org/assignments/ipv6-routeralert-values).=20 >>> This contains the aggregation RAO values from RFC3175. >>> >>> For IPv4 (RFC2113), I can't see an appropriate registry. I seem to=20 >>> remember discussing this before, but don't think we reached a=20 >>> conclusion. RFC2113 defines a value of 0, and leaves others=20 >reserved. >>> Allocation by IANA of additional values is not mentioned. Is it=20 >>> implicitly assumed to be in step with the IPv6 list? Do we=20 >need to do=20 >>> something to make this explicit? >>> >>> This is an issue for the NSLP drafts, and also relevant for the=20 >>> extensibility draft. >>> >>> 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 Sat Mar 18 13:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfsc-0004us-4N; Sat, 18 Mar 2006 13:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfsa-0004un-Dw for nsis@ietf.org; Sat, 18 Mar 2006 13:10:20 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKfsY-0001yg-SY for nsis@ietf.org; Sat, 18 Mar 2006 13:10:20 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2IIAGTa016580; Sat, 18 Mar 2006 20:10:16 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:10:16 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:10:16 +0200 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] QoS NSLP - aggregation marking Date: Sat, 18 Mar 2006 20:10:15 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A02D@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP - aggregation marking Thread-Index: AcZHO+JVGJugAjIfQoO02BGtYPIArADevVvw From: To: , , X-OriginalArrivalTime: 18 Mar 2006 18:10:16.0378 (UTC) FILETIME=[358161A0:01C64AB7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Georgios, I think Andrew just wants some extra explaination in the document. The extensibility draft basically says that for any NSLP (1) or (2) is possible, and my feeling is that it is up to the NSLP to decide which is better. So, I think having some justification in the QoS NSLP would be a good thing. John >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 14 March, 2006 09:47 >To: andrew.mcdonald@roke.co.uk; nsis@ietf.org >Subject: Re: [NSIS] QoS NSLP - aggregation marking > > >Hallo Andrew > >I thought that we have discussed this issue and decided to use (1). > >Best Regards, >Georgios > > >On 3/13/2006, "Andrew McDonald" wrote: > >>Hi all, >> >>Some thoughts/issues from thinking about the aggregation=20 >aspects of the=20 >>QoS NSLP: >> >>The current text in 4.6/4.7 is a bit too vague on what happens: "The=20 >>marking MUST be accomplished by the Aggregator by modifying the=20 >>QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value." >>What 'predefined value'? >>Is only a single aggregation level being proposed (i.e. like RFC3175=20 >>RSVP/RSVP-E2E-IGNORE protocol remarking, but not like RFC3175=20 >RAO value=20 >>remarking)? >> >>Is there any reasoning for why a method using remarking is used? >> >>Section 3.4 of the extensibility draft,=20 >draft-loughney-nsis-ext-02.txt,=20 >>talks about the two ways that aggregation marking can be made to work: >>1) all routers process at 'aggregation level 0'; routers are=20 >configured=20 >>at the ingress remark messages to a higher level; routers at=20 >the egress=20 >>remark messages to a lower level >>2) routers are configured to process messages at a particular=20 >>'aggregation level' and ignore all others; aggregate-related messages=20 >>are marked at a different level to end-to-end messages; messages are=20 >>never remarked >> >>The extensibility draft says: >> The first technique requires aggregating/deaggregating routers to be >> configured with which of their interfaces lie at which aggregation >> level, and also requires consistent message rewriting at these >> boundaries. The second technique eliminates the rewriting, but >> requires interior routers to be configured also. It is not clear >> what the right trade-off between these options is. >> >>There are also some differences when things go wrong: >>- in (1), e2e (remarked) messages that 'escape' (e.g. misconfigured >>egress) get ignored at regular routers, but should probably also be=20 >>flagged as an error if coming into an edge router on the wrong=20 >>interface. Messages for an aggregate that 'escape' are essentially=20 >>undetectable through basic NSLP processing - it may be picked up by=20 >>policy control mechanisms. >>- in (2), e2e messages are not remarked, so if they 'escape' they are=20 >>correctly processed by routers outside the aggregation region. Messages=20 >>for an aggregate that escape from the region are ignored at regular=20 >>routers, but should probably also be flagged as an error if coming into=20 >>an edge router on the wrong interface. >> >>We should probably say something more about the error cases (at least=20 >>the ones that we can potentially catch). >> >>The QoS NSLP draft has chosen (1), but doesn't include any rationale. >>Given that the extensibility draft says "you have a choice" it might be=20 >>useful to do so. I'm not sure why we've chosen (1), other than that is >>the way RFC3175 does it. >> >>There were IESG concerns about the internet draft that became RFC3175, >>see past IETF proceedings: >>http://www3.ietf.org/proceedings/00dec/00dec-138.htm >>http://www3.ietf.org/proceedings/01mar/ietf50-142.htm >>The concerns are focussed on the IP protocol remarking rather than the >>RAO value remarking. It appears that the concerns were addressed by=20 >>changes in the security considerations section. In our case, the NSLP=20 >>ID remarking is similar to the IP protocol remarking, and the security >>considerations are likely to be similar. (Since the choice of RAO value=20 >>follows on from the NSLP ID choice, we need to decide the NSLP ID=20 >>marking policy first.) >> >>Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID=20 >>combination stays constant along the path, which simplifies=20 >>diagnostics. The failure case (described above) also seems better. So, >>it's not entirely clear to me why (1) is preferred over (2). >> >> >>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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 18 13:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgJJ-00076q-Gg; Sat, 18 Mar 2006 13:37:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgJI-00076l-NA for nsis@ietf.org; Sat, 18 Mar 2006 13:37:56 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKgJI-0002mO-A3 for nsis@ietf.org; Sat, 18 Mar 2006 13:37:56 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2IIbnZ4008053; Sat, 18 Mar 2006 20:37:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:37:51 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:37:50 +0200 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: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS Extensibility Doc on QOSMs Date: Sat, 18 Mar 2006 20:37:50 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A030@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS Extensibility Doc on QOSMs Thread-Index: AcZCj1XL+yqZ9ErYTmGRpplkJFgSYgIK0zaQ From: To: , X-OriginalArrivalTime: 18 Mar 2006 18:37:50.0882 (UTC) FILETIME=[0FAAA820:01C64ABB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: gash@att.com, nsis@ietf.org, hannes.tschofenig@siemens.com, Attila.Bader@ericsson.com, bless@tm.uka.de, cornelia.kappler@siemens.com 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 wouldn't like to reopen it but at the point when discussing=20 >it in the past, we haven't had the NSLPs we have now. I would=20 >prefer a short status check whether the assumptions of the >2004 discussions still hold. I think that a common NSLP registry is a good thing, as the NSLPs will have more in common than unrelated protocols, IMO. However, I think the common registry could be for broad issues. >There is also another issue: The error code registry. >I think this is going to separated between the different=20 >NSLPs, since the severity classes of the QoS and NATFW NSLP=20 >differ quite much as the response codes do as well. So, would a common registry be acceptable if we allow a specific registry for some issues like error codes? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 18 13:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgP0-00020j-He; Sat, 18 Mar 2006 13:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKgOz-00020e-Jz for nsis@ietf.org; Sat, 18 Mar 2006 13:43:49 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKgOy-0002rj-66 for nsis@ietf.org; Sat, 18 Mar 2006 13:43:49 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2IIhkoP008581; Sat, 18 Mar 2006 20:43:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:43:46 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Mar 2006 20:43:46 +0200 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 Meeting Date: Sat, 18 Mar 2006 20:43:46 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A031@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Meeting Thread-Index: AcZCjjJ7512AO2m0RGi72ioYd89/LAILaSrQ From: To: X-OriginalArrivalTime: 18 Mar 2006 18:43:46.0621 (UTC) FILETIME=[E3B41ED0:01C64ABB] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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've added this to the agenda=20 >-----Original Message----- >From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 >Sent: 08 March, 2006 10:55 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org >Subject: Re: [NSIS] NSIS Meeting > >Fine with me when you add the IANA topic for GIST and the NSLPs. > >Thanks, > > Martin > >Am 07.03.2006 um 08:27 schrieb >: > >> Hi all, >> >> I am planning the meeting agenda. My rough plan is as follows: >> >> THURSDAY, March 23, 2006 >> 0900-1130 Morning Session I >> TSV nsis Next Steps in Signaling WG >> >> WG Status update >> GIST update - 5 minutes >> QoS work update - 15 minutes (QoS NSLP, various QoS model drafts)=20 >> NATFW work update - 15 minutes Mobility discussion - 15 minutes >> >> mini off-path bof - 1 hour >> (note - many people have been asking about this topic, so some open >> discussion for the WG is warrented). =09 >> >> 1510-1610 Afternoon Session II >> TSV nsis Next Steps in Signaling WG >> >> New Work discussion - 1 hour >> - I'm lumping all non-WG drafts into this hour, to get a sense of=20 >> what people >> think should be done. >> - Please review the non-working drafts before the meeting and post=20 >> your >> opinions if the work is of interest or not. >> - http://tools.ietf.org/wg/nsis/ contains most of the drafts in=20 >> question, IMO. >> >> thoughts, comments? >> >> 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 Sun Mar 19 08:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKy1a-0007Sq-2q; Sun, 19 Mar 2006 08:32:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKy1Z-0007Sl-IS for nsis@ietf.org; Sun, 19 Mar 2006 08:32:49 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKy1W-0002ft-45 for nsis@ietf.org; Sun, 19 Mar 2006 08:32:49 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JDWie1011972; Sun, 19 Mar 2006 15:32:44 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 15:31:56 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 15:31:55 +0200 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] Presentation Date: Sun, 19 Mar 2006 15:31:55 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A044@esebe100.NOE.Nokia.com> In-Reply-To: <666f9ac70603170205m7f5249bbm@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Presentation Thread-Index: AcZJq03S2lnQ/ckgRIqWnHO/47xg1gBrIDcQ From: To: , X-OriginalArrivalTime: 19 Mar 2006 13:31:55.0965 (UTC) FILETIME=[7DB256D0:01C64B59] X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Gregory, >I'm a student and I must study NSIS for my thesis! >I have already read some draft and RFC of the working group. >I'm interested to NSIS in mobile environment. There are the following documents to look at (but look at all current drafts): http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobili ty-signaling-04.txt http://www.ietf.org/rfc/rfc3583.txt >I would want to know if there are NSIS implementation (or a=20 >patch for NS2). Here are two implementations, but there are others as well: http://user.informatik.uni-goettingen.de/~nsis/ http://nsis.dei.uc.pt/ John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 10:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzVV-0001kW-DV; Sun, 19 Mar 2006 10:07:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzVU-0001iv-4T for nsis@ietf.org; Sun, 19 Mar 2006 10:07:48 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzVT-0005jE-E5 for nsis@ietf.org; Sun, 19 Mar 2006 10:07:48 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2JF7Wti007266; Sun, 19 Mar 2006 15:07:32 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 15:07:31 +0000 From: "Robert Hancock" To: , , , Subject: RE: [NSIS] QoS NSLP - aggregation marking Date: Sun, 19 Mar 2006 09:07:28 -0600 Message-ID: <000001c64b66$d846bde0$6500000a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A02D@esebe100.NOE.Nokia.com> Importance: Normal X-OriginalArrivalTime: 19 Mar 2006 15:07:32.0431 (UTC) FILETIME=[D8E595F0:01C64B66] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 My concern about this is that option (1) just seems like an inferior approach, and I'd like to understand why I'm wrong. Part of the concern is about resilience-against-misconfiguration issue noted below: a domain which muddles up its remarking rules breaks the end-to-end operation and has to depend on downstream domains to detect the problem and guess how to fix things. Misconfiguration in option (2) gets locally detected and fixed. Related to this is that option (1) imposes quite a strict topology constraint on how aggregation is done (they have to be simple and convex). It also just doesn't feel right. To me, the signalling message represents an end system's desire for a resource reservation. That desire didn't metamorphose into something else just because an operator defined an aggregation region; what has happened is that the routers in that region have decided not to be interested in that sort of message, and that should be reflected in the router's own configuration. For a concrete implication of this, suppose at some point in the future that the QoS-NSLP/qspec/policy combination acquired more multi-hop knowledge (e.g. as part of some more sophisticated price distribution mechanisms). You would probably protect payload elements over those multiple hops, including the NSLPID. So it makes sense (to me) to think of the NSLPID as something which is not changed in handling this sort of requirement. r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 18 March 2006 12:10 > To: karagian@cs.utwente.nl; andrew.mcdonald@roke.co.uk; nsis@ietf.org > Subject: RE: [NSIS] QoS NSLP - aggregation marking > > > Georgios, > > I think Andrew just wants some extra explaination in the > document. The > extensibility draft basically says that for any NSLP (1) or (2) is > possible, > and my feeling is that it is up to the NSLP to decide which is better. > > So, I think having some justification in the QoS NSLP would be a good > thing. > > John > > >-----Original Message----- > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >Sent: 14 March, 2006 09:47 > >To: andrew.mcdonald@roke.co.uk; nsis@ietf.org > >Subject: Re: [NSIS] QoS NSLP - aggregation marking > > > > > >Hallo Andrew > > > >I thought that we have discussed this issue and decided to use (1). > > > >Best Regards, > >Georgios > > > > > >On 3/13/2006, "Andrew McDonald" wrote: > > > >>Hi all, > >> > >>Some thoughts/issues from thinking about the aggregation > >aspects of the > >>QoS NSLP: > >> > >>The current text in 4.6/4.7 is a bit too vague on what > happens: "The > >>marking MUST be accomplished by the Aggregator by modifying the > >>QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value." > >>What 'predefined value'? > >>Is only a single aggregation level being proposed (i.e. > like RFC3175 > >>RSVP/RSVP-E2E-IGNORE protocol remarking, but not like RFC3175 > >RAO value > >>remarking)? > >> > >>Is there any reasoning for why a method using remarking is used? > >> > >>Section 3.4 of the extensibility draft, > >draft-loughney-nsis-ext-02.txt, > >>talks about the two ways that aggregation marking can be > made to work: > >>1) all routers process at 'aggregation level 0'; routers are > >configured > >>at the ingress remark messages to a higher level; routers at > >the egress > >>remark messages to a lower level > >>2) routers are configured to process messages at a particular > >>'aggregation level' and ignore all others; > aggregate-related messages > >>are marked at a different level to end-to-end messages; > messages are > >>never remarked > >> > >>The extensibility draft says: > >> The first technique requires aggregating/deaggregating > routers to > be > >> configured with which of their interfaces lie at which > aggregation > >> level, and also requires consistent message rewriting at these > >> boundaries. The second technique eliminates the rewriting, but > >> requires interior routers to be configured also. It is > not clear > >> what the right trade-off between these options is. > >> > >>There are also some differences when things go wrong: > >>- in (1), e2e (remarked) messages that 'escape' (e.g. misconfigured > >>egress) get ignored at regular routers, but should probably also be > >>flagged as an error if coming into an edge router on the wrong > >>interface. Messages for an aggregate that 'escape' are essentially > >>undetectable through basic NSLP processing - it may be picked up by > >>policy control mechanisms. > >>- in (2), e2e messages are not remarked, so if they > 'escape' they are > >>correctly processed by routers outside the aggregation region. > Messages > >>for an aggregate that escape from the region are ignored at regular > >>routers, but should probably also be flagged as an error if coming > into > >>an edge router on the wrong interface. > >> > >>We should probably say something more about the error cases > (at least > >>the ones that we can potentially catch). > >> > >>The QoS NSLP draft has chosen (1), but doesn't include any > rationale. > >>Given that the extensibility draft says "you have a choice" it might > be > >>useful to do so. I'm not sure why we've chosen (1), other > than that is > > >>the way RFC3175 does it. > >> > >>There were IESG concerns about the internet draft that > became RFC3175, > > >>see past IETF proceedings: > >>http://www3.ietf.org/proceedings/00dec/00dec-138.htm > >>http://www3.ietf.org/proceedings/01mar/ietf50-142.htm > >>The concerns are focussed on the IP protocol remarking > rather than the > > >>RAO value remarking. It appears that the concerns were addressed by > >>changes in the security considerations section. In our > case, the NSLP > >>ID remarking is similar to the IP protocol remarking, and > the security > > >>considerations are likely to be similar. (Since the choice of RAO > value > >>follows on from the NSLP ID choice, we need to decide the NSLP ID > >>marking policy first.) > >> > >>Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID > >>combination stays constant along the path, which simplifies > >>diagnostics. The failure case (described above) also seems > better. So, > > >>it's not entirely clear to me why (1) is preferred over (2). > >> > >> > >>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 > > > > _______________________________________________ > 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 19 10:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKziJ-000828-NN; Sun, 19 Mar 2006 10:21:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKziI-000819-AF for nsis@ietf.org; Sun, 19 Mar 2006 10:21:02 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKziG-0006SW-RC for nsis@ietf.org; Sun, 19 Mar 2006 10:21:02 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2JFKEti009208; Sun, 19 Mar 2006 15:20:14 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 15:20:13 +0000 From: "Robert Hancock" To: "'Henning Schulzrinne'" Subject: RE: [NSIS] GIST extensibility concern (IANA considerations) Date: Sun, 19 Mar 2006 09:20:11 -0600 Message-ID: <000101c64b68$9e52db30$6500000a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 19 Mar 2006 15:20:14.0165 (UTC) FILETIME=[9EECF850:01C64B68] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: john.loughney@nokia.com, 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've stored this in the issue tracker http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue106 so it gets into the next update. r. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 16 February 2006 08:35 > To: Hancock, Robert > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) > > > I'd be fine with a "black box" warning, to use the medical drug > terminology. I think compared to other experiments, this has to be > much more tightly controlled. This isn't likely to be an issue until > NSIS is widely deployed in routers, for example. Once NSIS has wider > deployment, this experimental mode is essentially only > suitable for a > closed network where the experimenter is on a first-name basis with > all network elements. In other words, "lab" experiments, rather than > "Internet" experiments. > > I'm used to the SMTP X- and SIP P- headers, which have far lighter > impact on the non-implementing world, as they are generally only > informational, rather than directing processing. > > On Feb 16, 2006, at 4:09 AM, Hancock, Robert wrote: > > > hi, > > > > a quick comment on the message type/protocol id/mrm aspects. > > > > i think there are actually two aspects here: > > - whether GIST can cope (in some sense) with new protocol > > numbers > > - whether experimental numbers are useful > > > > we have to be able to do the first, whether the new protocol > > number comes because of an experiment or some other official > > assignment. In the three cases mentioned, I think the spec is > > ok: > > - unknown message types are rejected with an error (don't > > change subsequent processing) > > - unknown protocol IDs are ignored (when deciding what type > > of MA to build) > > the case of an unknown MRM is slightly more subtle; it was > > discussed in the thread starting here > > http://www1.ietf.org/mail-archive/web/nsis/current/msg05367.html > > the upshot is that you should only get experimental MRMs with > > experimental NSLPs; and if you don't support the experimental > > NSLP you ignore the MRM. > > > > so I think that experimental values for these are safe in the > > sense that unknown values are handled correctly. > > > > of course, they are not safe if people adopt conflicting definitions > > of the unknown values. so the only environment in which valid > > experiments can be done is some sort of closed/private one (i.e. > > one in which the experimenter knows all the experiments that are > > in progress). i think this is (implicitly) the type of experiment > > that rfc3692 is talking about. I still think it's useful to have > > an assignment range for that type of experiment, because it > > guarantees that some kind of software upgrade that brings in non- > > experimental new protocol numbers (e.g. because of some other > > standards work or expert review) will not suddenly cause a > > collision. it's a not very sophisticated mechanism for a not > > very ambitious goal. > > > > it may be that the IANA section (whatever else we do with it) > > should be more explicit about what 'private/experimental' means, > > including possibly a reference to 3692. i'd like not to ban > > experiments, especially in the protocol ID and MRM cases, because > > actually I can think of some very interesting experiments to do > > there. > > > > cheers, > > > > r. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 10:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL04C-0004Eb-88; Sun, 19 Mar 2006 10:43:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL04A-0004EW-Pl for nsis@ietf.org; Sun, 19 Mar 2006 10:43:38 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL047-000746-BT for nsis@ietf.org; Sun, 19 Mar 2006 10:43:38 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2JFhTti012788 for ; Sun, 19 Mar 2006 15:43:29 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 15:43:28 +0000 From: "Robert Hancock" To: Date: Sun, 19 Mar 2006 09:43:26 -0600 Message-ID: <000201c64b6b$ddcb4d30$6500000a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 19 Mar 2006 15:43:29.0134 (UTC) FILETIME=[DE6458E0:01C64B6B] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [NSIS] Can we do without Q-spec stacking? 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 reviewed the QoS-NSLP on the flight yesterday and the above question occurred to me about half-way across. We introduced stacking [see below for historical background] as a means for accommodating localisation of the QoS specification within particular domains. I think that's still a legitimate goal. However, the specification now has another way to achieve the same thing, namely by creating a local signalling session and using the BOUND_SESSION_ID to correlate the two at the edges, with the e2e session ignored in the interior. I don't think it would take much work to eliminate the concept from the qos-nslp (I haven't checked the qspec yet). And I'm sure there would be tears of joy in some quarters. r. Background: For a trip down memory lane, check out section 4.4 of http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt (from 2002...). At the time, the main advantage of the stacking approach was that domain boundary nodes could do all their processing on a single message rather than having to correlate messages of multiple sessions. However, it now turns out that we can't avoid that type of complexity for other reasons, including - any sort of aggregation (where you have to handle 1+N messages) - where the interior session needs uses different GIST transport characteristics (RMD) - where it is natural to hide the e2e session in the interior (tunnel e.g. for mobility/vpn scenarios) Given that session correlation is needed in all these other cases, the advantage of being able to do without it in a particular case basically vanishes. It's probably simpler to use a single mechanism to handle everything. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 11:12:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0Vl-0001cX-Ba; Sun, 19 Mar 2006 11:12:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0Vk-0001cH-Jp for nsis@ietf.org; Sun, 19 Mar 2006 11:12:08 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0Vj-0007oY-TV for nsis@ietf.org; Sun, 19 Mar 2006 11:12:08 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGAixC017550; Sun, 19 Mar 2006 18:10:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:12:04 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:12:04 +0200 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] QoS NSLP - aggregation marking Date: Sun, 19 Mar 2006 18:12:04 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A04B@esebe100.NOE.Nokia.com> In-Reply-To: <000001c64b66$d846bde0$6500000a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP - aggregation marking Thread-Index: AcZLZukG5M22ej0uRnGDPAFOclQAkQACGrMA From: To: , , , X-OriginalArrivalTime: 19 Mar 2006 16:12:04.0741 (UTC) FILETIME=[DCF93350:01C64B6F] X-Spam-Score: 0.2 (/) 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 Chair-hat off, I tend to concur with Robert. Re-writing is also something that tends to get the IESG nervous, so we should have a good reason for doing the re-writing. While re-reading the spec on my flight, I had similar concerns about misconfiguration. Also, just wondering if there could be situations where re-rewriting doesn't occur, and the signaling escapes the local network with the rewritten fields. If this would happen, then the=20 end-to-end signaling would be broken. John =20 >-----Original Message----- >From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: 19 March, 2006 17:07 >To: Loughney John (Nokia-NRC/Helsinki);=20 >karagian@cs.utwente.nl; andrew.mcdonald@roke.co.uk; nsis@ietf.org >Subject: RE: [NSIS] QoS NSLP - aggregation marking > >My concern about this is that option (1) just seems like an=20 >inferior approach, and I'd like to understand why I'm wrong. > >Part of the concern is about resilience-against-misconfiguration >issue noted below: a domain which muddles up its remarking=20 >rules breaks the end-to-end operation and has to depend on=20 >downstream domains to detect the problem and guess how to fix things. >Misconfiguration in option (2) gets locally detected and fixed. >Related to this is that option (1) imposes quite a strict=20 >topology constraint on how aggregation is done (they have to=20 >be simple and convex). > >It also just doesn't feel right. To me, the signalling message=20 >represents an end system's desire for a resource reservation.=20 >That desire didn't metamorphose into something else just=20 >because an operator defined an aggregation region; what has=20 >happened is that the routers in that region have decided not=20 >to be interested in that sort of message, and that should be=20 >reflected in the router's own configuration. > >For a concrete implication of this, suppose at some point in=20 >the future that the QoS-NSLP/qspec/policy combination acquired=20 >more multi-hop knowledge (e.g. as part of some more=20 >sophisticated price distribution mechanisms). You would=20 >probably protect payload elements over those multiple hops,=20 >including the NSLPID. So it makes sense (to me) to think of=20 >the NSLPID as something which is not changed in handling this=20 >sort of requirement. > >r. > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: 18 March 2006 12:10 >> To: karagian@cs.utwente.nl; andrew.mcdonald@roke.co.uk; nsis@ietf.org >> Subject: RE: [NSIS] QoS NSLP - aggregation marking >>=20 >>=20 >> Georgios, >>=20 >> I think Andrew just wants some extra explaination in the document. =20 >> The extensibility draft basically says that for any NSLP (1)=20 >or (2) is=20 >> possible, and my feeling is that it is up to the NSLP to=20 >decide which=20 >> is better. >>=20 >> So, I think having some justification in the QoS NSLP would=20 >be a good=20 >> thing. >>=20 >> John >>=20 >> >-----Original Message----- >> >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >Sent: 14 March, 2006 09:47 >> >To: andrew.mcdonald@roke.co.uk; nsis@ietf.org >> >Subject: Re: [NSIS] QoS NSLP - aggregation marking >> > >> > >> >Hallo Andrew >> > >> >I thought that we have discussed this issue and decided to use (1). >> > >> >Best Regards, >> >Georgios >> > >> > >> >On 3/13/2006, "Andrew McDonald" wrote: >> > >> >>Hi all, >> >> >> >>Some thoughts/issues from thinking about the aggregation >> >aspects of the >> >>QoS NSLP: >> >> >> >>The current text in 4.6/4.7 is a bit too vague on what >> happens: "The >> >>marking MUST be accomplished by the Aggregator by modifying the=20 >> >>QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value." >> >>What 'predefined value'? >> >>Is only a single aggregation level being proposed (i.e.=20 >> like RFC3175 >> >>RSVP/RSVP-E2E-IGNORE protocol remarking, but not like RFC3175 >> >RAO value >> >>remarking)? >> >> >> >>Is there any reasoning for why a method using remarking is used? >> >> >> >>Section 3.4 of the extensibility draft, >> >draft-loughney-nsis-ext-02.txt, >> >>talks about the two ways that aggregation marking can be >> made to work: >> >>1) all routers process at 'aggregation level 0'; routers are >> >configured >> >>at the ingress remark messages to a higher level; routers at >> >the egress >> >>remark messages to a lower level >> >>2) routers are configured to process messages at a particular=20 >> >>'aggregation level' and ignore all others; >> aggregate-related messages >> >>are marked at a different level to end-to-end messages; >> messages are >> >>never remarked >> >> >> >>The extensibility draft says: >> >> The first technique requires aggregating/deaggregating >> routers to >> be >> >> configured with which of their interfaces lie at which >> aggregation >> >> level, and also requires consistent message rewriting at these >> >> boundaries. The second technique eliminates the rewriting, but >> >> requires interior routers to be configured also. It is >> not clear >> >> what the right trade-off between these options is. >> >> >> >>There are also some differences when things go wrong: >> >>- in (1), e2e (remarked) messages that 'escape' (e.g. misconfigured >> >>egress) get ignored at regular routers, but should=20 >probably also be=20 >> >>flagged as an error if coming into an edge router on the wrong=20 >> >>interface. Messages for an aggregate that 'escape' are essentially=20 >> >>undetectable through basic NSLP processing - it may be=20 >picked up by=20 >> >>policy control mechanisms. >> >>- in (2), e2e messages are not remarked, so if they >> 'escape' they are >> >>correctly processed by routers outside the aggregation region. >> Messages >> >>for an aggregate that escape from the region are ignored=20 >at regular=20 >> >>routers, but should probably also be flagged as an error if coming >> into >> >>an edge router on the wrong interface. >> >> >> >>We should probably say something more about the error cases >> (at least >> >>the ones that we can potentially catch). >> >> >> >>The QoS NSLP draft has chosen (1), but doesn't include any >> rationale. >> >>Given that the extensibility draft says "you have a=20 >choice" it might >> be >> >>useful to do so. I'm not sure why we've chosen (1), other >> than that is >>=20 >> >>the way RFC3175 does it. >> >> >> >>There were IESG concerns about the internet draft that >> became RFC3175, >>=20 >> >>see past IETF proceedings: >> >>http://www3.ietf.org/proceedings/00dec/00dec-138.htm >> >>http://www3.ietf.org/proceedings/01mar/ietf50-142.htm >> >>The concerns are focussed on the IP protocol remarking >> rather than the >>=20 >> >>RAO value remarking. It appears that the concerns were=20 >addressed by=20 >> >>changes in the security considerations section. In our >> case, the NSLP >> >>ID remarking is similar to the IP protocol remarking, and >> the security >>=20 >> >>considerations are likely to be similar. (Since the choice of RAO >> value >> >>follows on from the NSLP ID choice, we need to decide the NSLP ID=20 >> >>marking policy first.) >> >> >> >>Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID=20 >> >>combination stays constant along the path, which simplifies=20 >> >>diagnostics. The failure case (described above) also seems >> better. So, >>=20 >> >>it's not entirely clear to me why (1) is preferred over (2). >> >> >> >> >> >>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 >> > >>=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 19 11:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0dE-0008VT-WF; Sun, 19 Mar 2006 11:19:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0dD-0008BP-5Z for nsis@ietf.org; Sun, 19 Mar 2006 11:19:51 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0dB-00085R-L5 for nsis@ietf.org; Sun, 19 Mar 2006 11:19:51 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGINdo020980; Sun, 19 Mar 2006 18:18:23 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:19:44 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:19:43 +0200 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 extensibility concern (IANA considerations) Date: Sun, 19 Mar 2006 18:19:42 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A04C@esebe100.NOE.Nokia.com> In-Reply-To: <000101c64b68$9e52db30$6500000a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST extensibility concern (IANA considerations) Thread-Index: AcZLaMDaaDiTkxdAQpWIQdT0R3UjywACBMWQ From: To: , X-OriginalArrivalTime: 19 Mar 2006 16:19:43.0161 (UTC) FILETIME=[EE368A90:01C64B70] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Robert, I think that the GIST document should have a general statement in the IANA considerations section, but I could also add a short discussion about this in the extensions draft as well. Thoughts? John=20 >-----Original Message----- >From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: 19 March, 2006 17:20 >To: 'Henning Schulzrinne' >Cc: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] GIST extensibility concern (IANA considerations) > >I've stored this in the issue tracker >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue106 >so it gets into the next update. > >r. > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: 16 February 2006 08:35 >> To: Hancock, Robert >> Cc: john.loughney@nokia.com; nsis@ietf.org >> Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) >>=20 >>=20 >> I'd be fine with a "black box" warning, to use the medical drug=20 >> terminology. I think compared to other experiments, this has to be=20 >> much more tightly controlled. This isn't likely to be an issue until=20 >> NSIS is widely deployed in routers, for example. Once NSIS has wider=20 >> deployment, this experimental mode is essentially only=20 >suitable for a=20 >> closed network where the experimenter is on a first-name basis with=20 >> all network elements. In other words, "lab" experiments, rather than=20 >> "Internet" experiments. >>=20 >> I'm used to the SMTP X- and SIP P- headers, which have far lighter=20 >> impact on the non-implementing world, as they are generally only=20 >> informational, rather than directing processing. >>=20 >> On Feb 16, 2006, at 4:09 AM, Hancock, Robert wrote: >>=20 >> > hi, >> > >> > a quick comment on the message type/protocol id/mrm aspects. >> > >> > i think there are actually two aspects here: >> > - whether GIST can cope (in some sense) with new protocol >> > numbers >> > - whether experimental numbers are useful >> > >> > we have to be able to do the first, whether the new=20 >protocol number=20 >> > comes because of an experiment or some other official=20 >assignment. In=20 >> > the three cases mentioned, I think the spec is >> > ok: >> > - unknown message types are rejected with an error (don't >> > change subsequent processing) >> > - unknown protocol IDs are ignored (when deciding what type >> > of MA to build) >> > the case of an unknown MRM is slightly more subtle; it was=20 >discussed=20 >> > in the thread starting here=20 >> > http://www1.ietf.org/mail-archive/web/nsis/current/msg05367.html >> > the upshot is that you should only get experimental MRMs with=20 >> > experimental NSLPs; and if you don't support the experimental NSLP=20 >> > you ignore the MRM. >> > >> > so I think that experimental values for these are safe in=20 >the sense=20 >> > that unknown values are handled correctly. >> > >> > of course, they are not safe if people adopt conflicting=20 >definitions=20 >> > of the unknown values. so the only environment in which valid=20 >> > experiments can be done is some sort of closed/private one (i.e. >> > one in which the experimenter knows all the experiments=20 >that are in=20 >> > progress). i think this is (implicitly) the type of=20 >experiment that=20 >> > rfc3692 is talking about. I still think it's useful to have an=20 >> > assignment range for that type of experiment, because it=20 >guarantees=20 >> > that some kind of software upgrade that brings in non-=20 >experimental=20 >> > new protocol numbers (e.g. because of some other standards work or=20 >> > expert review) will not suddenly cause a collision. it's a=20 >not very=20 >> > sophisticated mechanism for a not very ambitious goal. >> > >> > it may be that the IANA section (whatever else we do with=20 >it) should=20 >> > be more explicit about what 'private/experimental' means,=20 >including=20 >> > possibly a reference to 3692. i'd like not to ban experiments,=20 >> > especially in the protocol ID and MRM cases, because=20 >actually I can=20 >> > think of some very interesting experiments to do there. >> > >> > cheers, >> > >> > r. >> > >>=20 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 11:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0eQ-0002Bx-Pf; Sun, 19 Mar 2006 11:21:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0eQ-0002Bs-Ad for nsis@ietf.org; Sun, 19 Mar 2006 11:21:06 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0eO-00087H-RY for nsis@ietf.org; Sun, 19 Mar 2006 11:21:06 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JGIt9J020286; Sun, 19 Mar 2006 18:18:56 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:21:03 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 18:21:03 +0200 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] Can we do without Q-spec stacking? Date: Sun, 19 Mar 2006 18:21:02 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A04D@esebe100.NOE.Nokia.com> In-Reply-To: <000201c64b6b$ddcb4d30$6500000a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Can we do without Q-spec stacking? Thread-Index: AcZLa/Dit8WGJWWiQ72kUOBu2FYxHwABRFRA From: To: , X-OriginalArrivalTime: 19 Mar 2006 16:21:03.0127 (UTC) FILETIME=[1DE06270:01C64B71] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Robert, Your suggestion seems like a very good simplification. I guess we=20 would need some text, but how do others feel. I think this would make the QoS NSLP a good deal simpler. Comments? John=20 >-----Original Message----- >From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: 19 March, 2006 17:43 >To: nsis@ietf.org >Subject: [NSIS] Can we do without Q-spec stacking? > >Hi, > >I reviewed the QoS-NSLP on the flight yesterday and the above=20 >question occurred to me about half-way across.=20 > >We introduced stacking [see below for historical background]=20 >as a means for accommodating localisation of the QoS=20 >specification within particular domains. I think that's still=20 >a legitimate goal. However, the specification now has another=20 >way to achieve the same thing, namely by creating a local=20 >signalling session and using the BOUND_SESSION_ID to correlate=20 >the two at the edges, with the e2e session ignored in the interior.=20 > >I don't think it would take much work to eliminate the concept=20 >from the qos-nslp (I haven't checked the qspec yet). And I'm=20 >sure there would be tears of joy in some quarters. > >r. > >Background: >For a trip down memory lane, check out section 4.4 of=20 >http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt >(from 2002...). At the time, the main advantage of the=20 >stacking approach was that domain boundary nodes could do all=20 >their processing on a single message rather than having to=20 >correlate messages of multiple sessions. However, it now turns=20 >out that we can't avoid that type of complexity for other=20 >reasons, including >- any sort of aggregation (where you have to handle 1+N messages) >- where the interior session needs uses different GIST transport > characteristics (RMD) >- where it is natural to hide the e2e session in the interior > (tunnel e.g. for mobility/vpn scenarios) Given that session=20 >correlation is needed in all these other cases, the advantage=20 >of being able to do without it in a particular case basically=20 >vanishes. It's probably simpler to use a single mechanism to=20 >handle everything. > > >_______________________________________________ >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 19 11:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0sc-0004FB-8F; Sun, 19 Mar 2006 11:35:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0sb-0004Ea-7Z for nsis@ietf.org; Sun, 19 Mar 2006 11:35:45 -0500 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FL0sa-0008WJ-SN for nsis@ietf.org; Sun, 19 Mar 2006 11:35:45 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-126.messagelabs.com!1142786125!10324065!3 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 22335 invoked from network); 19 Mar 2006 16:35:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-126.messagelabs.com with SMTP; 19 Mar 2006 16:35:43 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4401E007002BA35B; Sun, 19 Mar 2006 11:35:42 -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] Can we do without Q-spec stacking? Date: Sun, 19 Mar 2006 10:35:41 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7556@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A04D@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Can we do without Q-spec stacking? Thread-Index: AcZLa/Dit8WGJWWiQ72kUOBu2FYxHwABRFRAAABn5MA= From: "Ash, Gerald R \(Jerry\), ALABS" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Ash, Gerald R \(Jerry\), ALABS" 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 QSPEC I-D assumes a stack of 2 QSPECs can be used in a local domain. If the BOUND_SESSION_ID provides equivalent functionality, that would be OK but we need to verify the details. Jerry -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Sunday, March 19, 2006 11:21 AM To: robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: [NSIS] Can we do without Q-spec stacking? Robert, Your suggestion seems like a very good simplification. I guess we=20 would need some text, but how do others feel. I think this would make the QoS NSLP a good deal simpler. Comments? John=20 >-----Original Message----- >From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: 19 March, 2006 17:43 >To: nsis@ietf.org >Subject: [NSIS] Can we do without Q-spec stacking? > >Hi, > >I reviewed the QoS-NSLP on the flight yesterday and the above=20 >question occurred to me about half-way across.=20 > >We introduced stacking [see below for historical background]=20 >as a means for accommodating localisation of the QoS=20 >specification within particular domains. I think that's still=20 >a legitimate goal. However, the specification now has another=20 >way to achieve the same thing, namely by creating a local=20 >signalling session and using the BOUND_SESSION_ID to correlate=20 >the two at the edges, with the e2e session ignored in the interior.=20 > >I don't think it would take much work to eliminate the concept=20 >from the qos-nslp (I haven't checked the qspec yet). And I'm=20 >sure there would be tears of joy in some quarters. > >r. > >Background: >For a trip down memory lane, check out section 4.4 of=20 >http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt >(from 2002...). At the time, the main advantage of the=20 >stacking approach was that domain boundary nodes could do all=20 >their processing on a single message rather than having to=20 >correlate messages of multiple sessions. However, it now turns=20 >out that we can't avoid that type of complexity for other=20 >reasons, including >- any sort of aggregation (where you have to handle 1+N messages) >- where the interior session needs uses different GIST transport > characteristics (RMD) >- where it is natural to hide the e2e session in the interior > (tunnel e.g. for mobility/vpn scenarios) Given that session=20 >correlation is needed in all these other cases, the advantage=20 >of being able to do without it in a particular case basically=20 >vanishes. It's probably simpler to use a single mechanism to=20 >handle everything. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 14:44:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3p8-0007tL-7v; Sun, 19 Mar 2006 14:44:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3p7-0007tG-DS for nsis@ietf.org; Sun, 19 Mar 2006 14:44:21 -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 1FL3p5-0007M6-QY for nsis@ietf.org; Sun, 19 Mar 2006 14:44:21 -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; Sun, 19 Mar 2006 21:44:18 +0200 id 00070196.441DB492.00006181 Date: Sun, 19 Mar 2006 21:44:17 +0200 (EET) From: Jukka MJ Manner To: Georgios Karagiannis Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: "andrew.mcdonald@roke.co.uk" , bless@tm.uka.de, "nsis@ietf.org" , "Ruediger.Geib@t-systems.com" 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 (trying to follow up on the latest comments) =20 Hi, =20 Say you are a mobile node, and your next peer is the access router. Having TCP there as GIST transport is a bad idea. Yet, I'd still like to know=20 immediately that my message was received by the next AR.=20 I was re-reading the QoS NSLP spec to see what is actually said about the RII, and it is not really clear, who actually replies to the RII. It should be the QNR, right, but this is not very well said. Thus, if you would use the RII to request a confirmation for your RESERVE, you need to wait up the e2e RTT before you know, whether your RESERVE ever got to the QNR. I'd rather use Roland's second option, that is, the ACK-flag should not be used by default (as it creates a lot of overhead), but only in special cases. So, a MAY would be fine. Jukka On Thu, 16 Mar 2006, Georgios Karagiannis wrote: >=20 > Hi Roland >=20 > You are right! > The ACK is not needed at all! > In case a node expects a RESPONSE it may include a RII if there is no RII > carried by the incoming RESERVE. >=20 > Thus I also support the proposal of removing completely the ACK > functionality! >=20 > Best Regards, > Georgios >=20 >=20 > Best Re >=20 > On 3/16/2006, "Roland Bless" wrote: >=20 > >Hi Georgios, > > > >> Rudiger, are you refering tothe draft: > >> draft-fu-nsis-diagnostics-nslp-01? > >> > >> If yes, then I agree with you! > > > >Ok, the problem is that this diagnostics nslp is > >separated from the QoS nslp and other nslps, > >therefore results may be different. > > > >> Roland, please note that the functionality associated with the ACK fla= g > >> can be used > >> by QoS models to give the possibility to a peer to request the imediat= e > >> generation of a Response from its neighbouring peer. > > > >Yep, but the way the ACK mechanism was previously > >specified made no sense. A received confirmation or a > >missing confirmation had no effect. That's why I proposed > >some retransmission mechanism within QoS NSLP. Maybe that > >was too ambitious and wasn't required actually (that's why > >I asked exactly about the original problem the ACK mechanism > >tried to solve!). > > > >> I am in favour of keeping this functionality. > > > >Georgious, you may be in favor of keeping it, but are there > >technical reasons? > >Now (after Ruediger is probably satisfied with a different solution > >and Georgious wants this explicit confirmation) > >I see different options: > > > >1.) Provide a generic ACK mechanism for QoS models only. > > Thus, retransmissions etc. are QoS model specific. > > This is was more or less defined by the versions before -10. > > However, in this case we need to specify the actions, > > i.e., the QoS model decides when the ACK flag is set, > > the receipt of a RESPONSE solicited by an ACK should > > be indicated to the QoS NSLP application/QoS model, and, > > the QoS model may retransmit a RESERVE in case no RESPONSE > > was received. > > > >2.) Use QoS NSLP internal semantics as currently defined, > > i.e. QoS NSLP will trigger retransmissions. > > > >In either case I suggest to remove the statement: > >"This flag SHOULD be set on transmission by default." > >to > >"This flag MAY be set on transmission". > > > >Currently, I prefer option 1.) if the ACK functionality is > >really required. > > > >Regards, > > Roland > > > >> On 3/13/2006, "Geib, Ruediger" wrote: > >> > >>> Hello Roland, > >>> > >>> I didn't track it closely but would I be wrong if I say that the QoS > >>> NSLP was designed not have any topology awareness? If that's true > >>> and if mixing GIST and NSLP state information would be required > >>> for a useful NSLP Keep Alive mechanism, it may be better > >>> to concentrate on > >>> > >>> "Design Options of NSIS Diagnostics NSLP" > >>> > >>> and work out a mechanism for re-active NSLP monitoring > >>> (like PING and traceroute). Would you agree? > >>> > >>> Regards, > >>> > >>> R=FCdiger > >>> > >>> RoB|Consequently I would prefer removal of the ACK flag and possibly > >>> |> |provide a simple HELLO mechanism (with adjustable timeouts) > >>> |> |between peers to detect communication failures. I really don't kn= ow > >>> |> |what fast reaction an application could undertake due a > >>> |> |transmission/processing failure of a RESERVE message that was > >>> |> |detected by the currently proposed ACK mechanism. -> see below > >>> |> > >>> RG Such a Hello mechanism may indeed be the better idea. The current > >>> |> NSLP version seems to be rather stable. Would you propose to > >>> |> include the Hello mechanism in the current draft or would it be > >>> |> acceptable to to start working on it in a later version (e.g. > >>> |> separate document - may be a feature desireable for other > >>> |> nslps too - or qos nslp version 2)? > >>> > >>> RoB > >>> |I think that adding a simple Hello mechanism would be not > >>> |so complex, since overall it would be easier than implementing the > >>> |currently proposed ACK mechanism with retransmissions > >>> |per message. On the other hand we have a problem, because > >>> |information is missing about the identity of the next QoS NSLP peer > >>> |since the latter is managed by GIST and the NLI is currently > >>> |not passed over the API (which makes it also hard to realize summary > >>> |refreshes BTW). So one could think > >>> |about an API extension that allows to pass NLIs from GIST to NSLPs s= o > >>> |that the NSLP instance is at least able to monitor a mapping from > >>> |sessions or flows to peers/neighbors. > >>> | > >>> |Note that GIST has already a HELLO mechanism per MA though it's prim= ary > >>> |purpose was not to detect failures, but to keep the MA open, > >>> |right? Thus > >>> |the rate of HELLO messages would be relatively low. Moreover, it wil= l > >>> |not detect the liveliness of the QoS NSLP instance, only of the GIST > >>> |instance. The second issue that we need to decide about is > >>> |the reaction of QoS NSLP when a failure is detected. > >>> |Possibly it can send an Invalidate Routing State to it's own GIST > >>> |instance. This may not help, however, in case the routing and GIST > >>> |is still working correctly. Sending a NOTIFY (but for which peers > >>> |exactly?) would also be an option, but I doubt that this would help > >>> |much. > >>> | > >>> |Regards, > >>> | Roland > >>> | > >>> | > >>> | > >>> |_______________________________________________ > >>> |nsis mailing list > >>> |nsis@ietf.org > >>> |https://www1.ietf.org/mailman/listinfo/nsis > >>> | > >> > > > > > >-- > >Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless > >Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH), Germany > >Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 > >Tel.: +49 721 608-6413 Fax: +49 721 608-6789 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 14:57:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL424-0004Bg-Ds; Sun, 19 Mar 2006 14:57:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL423-0004Bb-7v for nsis@ietf.org; Sun, 19 Mar 2006 14:57:43 -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 1FL422-0007wK-Nn for nsis@ietf.org; Sun, 19 Mar 2006 14:57:43 -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; Sun, 19 Mar 2006 21:57:42 +0200 id 000701E4.441DB7B6.0000437C Date: Sun, 19 Mar 2006 21:57:41 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP updated In-Reply-To: <44157356.1020408@tm.uka.de> Message-ID: References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> <441027F7.4040006@tm.uka.de> <44157356.1020408@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: 8fbbaa16f9fd29df280814cb95ae2290 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, using your topology, we use an LMM scheme that does not change the IP address, say CIP or BCMP. We have a true e2e reservation. The MRI does not change after handover. If we have the MAP at R3, it gets to know the MN moved, and sends a RESERVE. R2 gets the RESERVE and thinks it is a simple refresh, since no information is different. We could use an RII in the RESERVE, which forces the refresh to go all the way, and the MAP gets back a RESPONSE. If we use a forcing refresh, we get the refresh through all the way, and don't need back a RESPONSE. I could live with both ways to get the refresh through. Jukka On Mon, 13 Mar 2006, Roland Bless wrote: > Hi Jukka, > > > If you use a local mobility management scheme, controlled by a MAP, then > > you don't need to change the IP address after each handover. Thus, a > > Maybe I don't understand that because the scenario is not quite clear > to me. Do you mean we use something like H-MIP? If yes, then we may > have a situation like this: > > MN---AR1 > \ > R1---R2(MAP)--R3--R4--...--CN > / > AR2 > > I assumed that we consider a reservation from CN->MN and the > MN changes ARs. In this case the MN will get a new IP address > which is indeed hidden for the CN. However, I thought that > we have more or less two reservations, one from CN->MAP and > one from CN->MN. The latter will be updated in case the MN > registers its new address at the MAP. In this case the MAP will > use a new MRI towards the MN anyway, so it is not a "refresh" > because it will be forwarded along the whole path from the MAP > to the MN. > > > refresh from the MAP towards the MN will look like an ordinary refresh, > > and will not help in making reservations closer to the MN, say, at the > > access router. If you can force a refresh, you can repair the reservation > > faster. > > I apologize that I still don't understand. In case the MN's local > address doesn't change the refreshing RESERVE will also not take any > new path from MAP to CN?! Maybe you can explain it with help of the > above example. > > Regards, > Roland > > > Jukka > > > > On Thu, 9 Mar 2006, Roland Bless wrote: > > > >> Hi Jukka, > >> > >>> The "forced" refresh is useful to have, and makes it possible for any node > >> ^^^^^^^^^ > >> Yes, I'm interested in examples that show its usefulness (they should > >> possibly mentioned in the draft section 4). > >> > >>> to force a refresh operation to be carried. For example, a mobility anchor > >>> point may get to know that an MN has moved, and can force a refresh > >>> towards the MN. A similar indication and a subsequent refresh can happen > >> Hm, I don't quite get it. In case the MN has moved he also > >> changed his CoA and thus the MRI, and, in this case, the MAP will > >> usually send a new RESERVE with a different MRI. > >> > >>> with Mobile IP, when the HA, or CN receive a binding update, and know that > >>> the path near the MN has changed. > >> I don't see why a forced refresh will help much in mobility scenarios. > >> Basically what you achieve with a forced refresh is that the state > >> along the whole path doesn't expire, but states will not expire > >> using the normal peer refreshes in case nothing else changed. > >> So in case the routing in the network didn't change, the refreshing > >> RESERVE will take exactly the same path as before. If the MN has changed > >> its CoA, you will usually end up sending a RESERVE with a different MRI > >> which then may traverse along a new path. Then states along the > >> unchanged path are refreshed anyway. > >> The only benefit would be IMHO to force a refresh before a handover > >> so that the time period for performing the handover is long enough > >> to keep the reservation while the QNI moves. But this could be achieved > >> by an ordinary refresh, too. > >> > >> Regards, > >> Roland > >> > >>> On Thu, 9 Mar 2006, Roland Bless wrote: > >>> > >>>> Hi Jukka, > >>>> > >>>>> On Sat, 4 Mar 2006, Bernd Schloer wrote: > >>>>> > >>>>>> Hi Jukka, > >>>>>> > >>>>>> a few things are not quite clear to me: > >>>>>> > >>>>>> Who is responsible to trigger the Refresh Messages? Is it the QNI or the > >>>>>> Client Application connected to the QNI? > >>>>> Page 4: > >>>>> "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 > >>>>> [RFC2205], and uses soft-state peer-to-peer refresh messages as the > >>>>> primary state management mechanism (i.e. state installation/refresh > >>>>> is performed between pairs of adjacent NSLP nodes, rather than in an > >>>>> end-to-end fashion along the complete signalling path)." > >>>> The latter is, however, possible in case one uses a refreshing RESERVE > >>>> with an RII object included: > >>>> 5.1.2.1. RESERVE > >>>> ... > >>>> A refresh right along the path can be forced by requesting a RESPONSE > >>>> from the far end (i.e. (i.e., by including an RII object in the RESERVE > >>>> message). > >>>> > >>>> I still don't know what it's good for... > >>>> > >>>> Regards, > >>>> Roland > >> > >> > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 15:06:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4AQ-0007AX-Fr; Sun, 19 Mar 2006 15:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4AP-0007AS-5j for nsis@ietf.org; Sun, 19 Mar 2006 15:06:21 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL4AM-0008Lp-GB for nsis@ietf.org; Sun, 19 Mar 2006 15:06:21 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id k2JK6Eea005606; Sun, 19 Mar 2006 21:06:14 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k2JK6ED8029457; Sun, 19 Mar 2006 21:06:14 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k2JK6E818768; Sun, 19 Mar 2006 21:06:14 +0100 (MET) Date: Sun, 19 Mar 2006 21:06:14 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: [NSIS] Can we do without Q-spec stacking? Received: from 194.88.55.211 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 19 Mar 2006 20:06:14 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <000201c64b6b$ddcb4d30$6500000a@comm.ad.roke.co.uk> 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: -5.849 () ALL_TRUSTED,AWL,BAYES_00,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 19 Mar 2006 21:06:16 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 This feature can be considered as a main feature that can be used to increase the support of different QoS models on the same end-to-end path. Long time ago we agreed to use this feature, which is already extensively used by some QoS models. Therefore I am not in favour of removing this feature from the QoS-NSLP draft Best Regards, Georgios On 3/19/2006, "Robert Hancock" wrote: >Hi, > >I reviewed the QoS-NSLP on the flight yesterday and the above >question occurred to me about half-way across. > >We introduced stacking [see below for historical background] as >a means for accommodating localisation of the QoS specification >within particular domains. I think that's still a legitimate >goal. However, the specification now has another way to achieve >the same thing, namely by creating a local signalling session >and using the BOUND_SESSION_ID to correlate the two at the edges, >with the e2e session ignored in the interior. > >I don't think it would take much work to eliminate the concept from >the qos-nslp (I haven't checked the qspec yet). And I'm sure there >would be tears of joy in some quarters. > >r. > >Background: >For a trip down memory lane, check out section 4.4 of >http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt >(from 2002...). At the time, the main advantage of the stacking >approach was that domain boundary nodes could do all their processing >on a single message rather than having to correlate messages of >multiple sessions. However, it now turns out that we can't avoid >that type of complexity for other reasons, including >- any sort of aggregation (where you have to handle 1+N messages) >- where the interior session needs uses different GIST transport > characteristics (RMD) >- where it is natural to hide the e2e session in the interior > (tunnel e.g. for mobility/vpn scenarios) >Given that session correlation is needed in all these other cases, >the advantage of being able to do without it in a particular case >basically vanishes. It's probably simpler to use a single mechanism >to handle everything. > > >_______________________________________________ >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 19 15:39:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4gR-0006Gp-Me; Sun, 19 Mar 2006 15:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4gP-0006Gh-O7 for nsis@ietf.org; Sun, 19 Mar 2006 15:39:25 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL4gO-0001IQ-25 for nsis@ietf.org; Sun, 19 Mar 2006 15:39:25 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D906C533; Sun, 19 Mar 2006 21:39:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 21:39:22 +0100 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 21:39:22 +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: RE: [NSIS] Can we do without Q-spec stacking? Date: Sun, 19 Mar 2006 21:39:21 +0100 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D050BD17C@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Can we do without Q-spec stacking? Thread-Index: AcZLa++VWLpUAvm0T4+Kuol2ypRJUQAKTt0A From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Robert Hancock" , X-OriginalArrivalTime: 19 Mar 2006 20:39:22.0175 (UTC) FILETIME=[34076CF0:01C64B95] X-Brightmail-Tracker: AAAAAA== 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 Robert, We have discussed this issue earlier. Stacking increases the flexibility = of NSIS, for example to support heterogenios networks using different = QoS models. In addition, it reduces the no. of required sign. messages = considerably in some cases. As a consensus, we have limited the number = of possible QSpec to 2. So I am not in favor to remove this feature. Best regards, Attila > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > Sent: Sunday, March 19, 2006 4:43 PM > To: nsis@ietf.org > Subject: [NSIS] Can we do without Q-spec stacking? >=20 >=20 > Hi, >=20 > I reviewed the QoS-NSLP on the flight yesterday and the above > question occurred to me about half-way across.=20 >=20 > We introduced stacking [see below for historical background] as > a means for accommodating localisation of the QoS specification > within particular domains. I think that's still a legitimate=20 > goal. However, the specification now has another way to achieve > the same thing, namely by creating a local signalling session > and using the BOUND_SESSION_ID to correlate the two at the edges, > with the e2e session ignored in the interior.=20 >=20 > I don't think it would take much work to eliminate the concept from > the qos-nslp (I haven't checked the qspec yet). And I'm sure there > would be tears of joy in some quarters. >=20 > r. >=20 > Background: > For a trip down memory lane, check out section 4.4 of > http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt > (from 2002...). At the time, the main advantage of the stacking > approach was that domain boundary nodes could do all their processing > on a single message rather than having to correlate messages of=20 > multiple sessions. However, it now turns out that we can't avoid > that type of complexity for other reasons, including > - any sort of aggregation (where you have to handle 1+N messages) > - where the interior session needs uses different GIST transport > characteristics (RMD) > - where it is natural to hide the e2e session in the interior > (tunnel e.g. for mobility/vpn scenarios) > Given that session correlation is needed in all these other cases, > the advantage of being able to do without it in a particular case > basically vanishes. It's probably simpler to use a single mechanism > to handle everything. >=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 19 15:48:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4ol-0002zL-TT; Sun, 19 Mar 2006 15:48:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4ok-0002wx-TW for nsis@ietf.org; Sun, 19 Mar 2006 15:48:02 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL4ok-0001T0-Di for nsis@ietf.org; Sun, 19 Mar 2006 15:48:02 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D3F624F0001; Sun, 19 Mar 2006 21:48:01 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 21:48:01 +0100 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 20:52:37 +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: RE: [NSIS] Can we do without Q-spec stacking? Date: Sun, 19 Mar 2006 20:51:20 +0100 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D050BD179@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Can we do without Q-spec stacking? Thread-Index: AcZLa++VWLpUAvm0T4+Kuol2ypRJUQAILmpA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Robert Hancock" , X-OriginalArrivalTime: 19 Mar 2006 19:52:37.0698 (UTC) FILETIME=[AC6E3220:01C64B8E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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, We have discussed this issue earlier. Stacking increases the flexibility = of NSIS, for example to support heterogenios networks using different = QoS models. In addition, it reduces the no. of required sign. messages = considerably in some cases. As a consensus, we have limited the number = of possible QSpec to 2. So I am not in favor to remove this feature. Best regards, Attila > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > Sent: Sunday, March 19, 2006 4:43 PM > To: nsis@ietf.org > Subject: [NSIS] Can we do without Q-spec stacking? >=20 >=20 > Hi, >=20 > I reviewed the QoS-NSLP on the flight yesterday and the above > question occurred to me about half-way across.=20 >=20 > We introduced stacking [see below for historical background] as > a means for accommodating localisation of the QoS specification > within particular domains. I think that's still a legitimate=20 > goal. However, the specification now has another way to achieve > the same thing, namely by creating a local signalling session > and using the BOUND_SESSION_ID to correlate the two at the edges, > with the e2e session ignored in the interior.=20 >=20 > I don't think it would take much work to eliminate the concept from > the qos-nslp (I haven't checked the qspec yet). And I'm sure there > would be tears of joy in some quarters. >=20 > r. >=20 > Background: > For a trip down memory lane, check out section 4.4 of > http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt > (from 2002...). At the time, the main advantage of the stacking > approach was that domain boundary nodes could do all their processing > on a single message rather than having to correlate messages of=20 > multiple sessions. However, it now turns out that we can't avoid > that type of complexity for other reasons, including > - any sort of aggregation (where you have to handle 1+N messages) > - where the interior session needs uses different GIST transport > characteristics (RMD) > - where it is natural to hide the e2e session in the interior > (tunnel e.g. for mobility/vpn scenarios) > Given that session correlation is needed in all these other cases, > the advantage of being able to do without it in a particular case > basically vanishes. It's probably simpler to use a single mechanism > to handle everything. >=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 19 16:05:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL55s-0004GG-Du; Sun, 19 Mar 2006 16:05:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL55r-0004GB-Gf for nsis@ietf.org; Sun, 19 Mar 2006 16:05:43 -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 1FL55q-00026j-1k for nsis@ietf.org; Sun, 19 Mar 2006 16:05:43 -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; Sun, 19 Mar 2006 23:05:40 +0200 id 00070116.441DC7A4.000036A0 Date: Sun, 19 Mar 2006 23:05:40 +0200 (EET) From: Jukka MJ Manner To: Robert Hancock Subject: Re: [NSIS] Can we do without Q-spec stacking? In-Reply-To: <000201c64b6b$ddcb4d30$6500000a@comm.ad.roke.co.uk> Message-ID: References: <000201c64b6b$ddcb4d30$6500000a@comm.ad.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: 0a7aa2e6e558383d84476dc338324fab 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 Rob, I really don't see how life would be so much more fun with a single QSPEC allowed. The stacking of two QSPECs is a good idea, quite simple to implement the processing for it, and has shown to have support for a long time. To support the stacking through implementing a separate domain-internal session concept, and the processing for it would be a number of times more complex and time consuming. If one wants to implement the same functionality to stacking through a separate session, he is free to do so. Jukka On Sun, 19 Mar 2006, Robert Hancock wrote: > Hi, > > I reviewed the QoS-NSLP on the flight yesterday and the above > question occurred to me about half-way across. > > We introduced stacking [see below for historical background] as > a means for accommodating localisation of the QoS specification > within particular domains. I think that's still a legitimate > goal. However, the specification now has another way to achieve > the same thing, namely by creating a local signalling session > and using the BOUND_SESSION_ID to correlate the two at the edges, > with the e2e session ignored in the interior. > > I don't think it would take much work to eliminate the concept from > the qos-nslp (I haven't checked the qspec yet). And I'm sure there > would be tears of joy in some quarters. > > r. > > Background: > For a trip down memory lane, check out section 4.4 of > http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt > (from 2002...). At the time, the main advantage of the stacking > approach was that domain boundary nodes could do all their processing > on a single message rather than having to correlate messages of > multiple sessions. However, it now turns out that we can't avoid > that type of complexity for other reasons, including > - any sort of aggregation (where you have to handle 1+N messages) > - where the interior session needs uses different GIST transport > characteristics (RMD) > - where it is natural to hide the e2e session in the interior > (tunnel e.g. for mobility/vpn scenarios) > Given that session correlation is needed in all these other cases, > the advantage of being able to do without it in a particular case > basically vanishes. It's probably simpler to use a single mechanism > to handle everything. > > > _______________________________________________ > 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 19 16:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL59W-0001BP-QF; Sun, 19 Mar 2006 16:09:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL59W-0001BK-1B for nsis@ietf.org; Sun, 19 Mar 2006 16:09:30 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL59V-0002Fg-Jw for nsis@ietf.org; Sun, 19 Mar 2006 16:09:30 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FL59L-0001fA-9l; Sun, 19 Mar 2006 22:09: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 6B41F8A33; Sun, 19 Mar 2006 22:09:18 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FL59J-0004Rl-UX; Sun, 19 Mar 2006 22:09:18 +0100 Message-ID: <441DC846.9050208@tm.uka.de> Date: Sun, 19 Mar 2006 22:08:22 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "andrew.mcdonald@roke.co.uk" , Georgios Karagiannis , "nsis@ietf.org" , "Ruediger.Geib@t-systems.com" 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, > Say you are a mobile node, and your next peer is the access router. Having > TCP there as GIST transport is a bad idea. Yet, I'd still like to know Ok, I'm not totally sure that we should try to put reliability mechanisms into QoS NSLP itself. One early design decision was to don't do it again, but to let us re-use the well-known transport protocols below GIST. > immediately that my message was received by the next AR. Ok, for what purpose (I still want to know what problem should be solved by this ACK)? So that you know that your message was not dropped and is on the way? This would be more transport related. We also had other reasons for the ACK: know that the other QoS NSLP instance has received it and know that it's alive etc. The main question is: what do you do if you did not receive that confirmation? Can you do anything about it? In case of loss it would be retransmission, in case of a link/node/transport failure there will be not so many options available. > I was re-reading the QoS NSLP spec to see what is actually said about the > RII, and it is not really clear, who actually replies to the RII. It > should be the QNR, right, but this is not very well said. Thus, if you In case we have this rerouting scenario the replying node may be the crossover node and not the QNR. > would use the RII to request a confirmation for your RESERVE, you need to > wait up the e2e RTT before you know, whether your RESERVE ever got to the > QNR. Is there another possibility to do so? A confirmation from the QNR would take an e2e RTT any case or am I missing something? > I'd rather use Roland's second option, that is, the ACK-flag should not be > used by default (as it creates a lot of overhead), but only in special > cases. So, a MAY would be fine. That wasn't exactly option 2 (see below). The SHOULD->MAY change was meant for both options (though one may discuss a SHOULD in case of unreliable transport). In case we need a confirmation I'm still for my first option, namely to keep the ACK, but to don't do retransmissions within QoS NSLP itself. Option 2 would make sense in case we use unreliable transport and want simple reliability (like SIP, RTSP, etc.). %1.) Provide a generic ACK mechanism for QoS models only. % Thus, retransmissions etc. are QoS model specific. % This is was more or less defined by the versions before -10. % However, in this case we need to specify the actions, % i.e., the QoS model decides when the ACK flag is set, % the receipt of a RESPONSE solicited by an ACK should % be indicated to the QoS NSLP application/QoS model, and, % the QoS model may retransmit a RESERVE in case no RESPONSE % was received. % %2.) Use QoS NSLP internal semantics as currently defined, % i.e. QoS NSLP will trigger retransmissions. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 16:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5lP-00072U-OX; Sun, 19 Mar 2006 16:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5lO-00072O-Q6 for nsis@ietf.org; Sun, 19 Mar 2006 16:48:38 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL5lO-0003lm-Cl for nsis@ietf.org; Sun, 19 Mar 2006 16:48:38 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FL5lL-0003ZS-OS; Sun, 19 Mar 2006 22:48: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 2C060A53B; Sun, 19 Mar 2006 22:48:35 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FL5lK-0004TG-HV; Sun, 19 Mar 2006 22:48:34 +0100 Message-ID: <441DD17C.7010008@tm.uka.de> Date: Sun, 19 Mar 2006 22:47:40 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Xiaoming Fu Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <44192E11.2010007@tm.uka.de> <4419F350.20505@cs.uni-goettingen.de> In-Reply-To: <4419F350.20505@cs.uni-goettingen.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Xiaoming, > There could be several non-competing options (to apply in different > scenarios): > > A. making trigger messages be reliable (which could be very useful, as > concluded by [1]) > > B. making usual refreshes be reliable (which could be not as useful as A) > > C. making reduced overhead extension refreshes to be reliable (which > will be useful per RFC2961/[2]). I guess that this is more related and more essential to _summary_ refreshes which we currently don't have. > D. making removal messages be reliable (which could be useful, as > concluded by [1]) > > "Reliable" above means whether one needs an explict Response to be sent > from the recipient upon receipt of the corresponding > trigger/refresh/removal. Ok, but who is "the recipient"? In case of the RESPONSE from the far end it's usually the QNR, in case of the ACK it's the next QNE, maybe for different purposes. Consider the action that should be taken on a missing ACK: in case of unreliable transport you probably can recover a packet loss by simply retransmitting the request again; but in case you are already using reliable transport, you may indicate a failure after some timeout. > My view is that unreliable transmission would suffice B; for A and C > reliability SHOULD/MUST be made; for D reliability MAY be made. Just wanted to note that a RESPONSE may also be lost in case of unreliable transport, and, as already said: I guess that reliable transport is more the task of GIST than of QoS NSLP. > Relying > on the existence of RII to determine whether to give a response is > probably not a typical behavior from my personal limited understanding > of other protocols. You are right. I would prefer to always get a RESPONSE (from the QNR or far end). The ACK mechanism is a different thing, because it is only triggering a response from the direct peer. It would help a lot if we could actually write down the requirements. From the past discussions I have the impression that people want to achieve totally different things with the defined retransmission mechanisms. Thus it would be good to clearly describe the problem(s) we want to solve. Short summary: Ruediger: wants liveliness check Georgious: wants some confirmation (for what purpose?) Jukka: wants to recover loss(?) in case of unreliable transport (wants to avoid using TCP for mobile nodes...) > [1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison of Hard-State > and Soft-State Signaling Protocols, SIGCOMM 2003. > [2] P. Pan and H. Schulzrine, Staged Refresh Timers for RSVP, Global > Internet 1997. > Cheers, > Xiaoming Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Mar 19 17:09:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL65n-0005OY-Ex; Sun, 19 Mar 2006 17:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL65l-0005Iu-IM for nsis@ietf.org; Sun, 19 Mar 2006 17:09:41 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL65l-0004n0-1O for nsis@ietf.org; Sun, 19 Mar 2006 17:09:41 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FL65g-0004ZQ-31; Sun, 19 Mar 2006 23:09:38 +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 CE067A53B; Sun, 19 Mar 2006 23:09:35 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FL65f-0004Tj-6V; Sun, 19 Mar 2006 23:09:35 +0100 Message-ID: <441DD668.3000401@tm.uka.de> Date: Sun, 19 Mar 2006 23:08:40 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP updated References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> <441027F7.4040006@tm.uka.de> <44157356.1020408@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Jukka, > using your topology, we use an LMM scheme that does not change the IP > address, say CIP or BCMP. We have a true e2e reservation. The MRI does not > change after handover. Ok, now it's getting clearer... > If we have the MAP at R3, it gets to know the MN moved, and sends a > RESERVE. R2 gets the RESERVE and thinks it is a simple refresh, since no > information is different. We could use an RII in the RESERVE, which forces > the refresh to go all the way, and the MAP gets back a RESPONSE. If we use > a forcing refresh, we get the refresh through all the way, and don't need > back a RESPONSE. Forcing refresh would mean a new flag? > I could live with both ways to get the refresh through. Regards, Roland > Jukka > > On Mon, 13 Mar 2006, Roland Bless wrote: > >> Hi Jukka, >> >>> If you use a local mobility management scheme, controlled by a MAP, then >>> you don't need to change the IP address after each handover. Thus, a >> Maybe I don't understand that because the scenario is not quite clear >> to me. Do you mean we use something like H-MIP? If yes, then we may >> have a situation like this: >> >> MN---AR1 >> \ >> R1---R2(MAP)--R3--R4--...--CN >> / >> AR2 >> >> I assumed that we consider a reservation from CN->MN and the >> MN changes ARs. In this case the MN will get a new IP address >> which is indeed hidden for the CN. However, I thought that >> we have more or less two reservations, one from CN->MAP and >> one from CN->MN. The latter will be updated in case the MN >> registers its new address at the MAP. In this case the MAP will >> use a new MRI towards the MN anyway, so it is not a "refresh" >> because it will be forwarded along the whole path from the MAP >> to the MN. >> >>> refresh from the MAP towards the MN will look like an ordinary refresh, >>> and will not help in making reservations closer to the MN, say, at the >>> access router. If you can force a refresh, you can repair the reservation >>> faster. >> I apologize that I still don't understand. In case the MN's local >> address doesn't change the refreshing RESERVE will also not take any >> new path from MAP to CN?! Maybe you can explain it with help of the >> above example. >> >> Regards, >> Roland >> >>> Jukka >>> >>> On Thu, 9 Mar 2006, Roland Bless wrote: >>> >>>> Hi Jukka, >>>> >>>>> The "forced" refresh is useful to have, and makes it possible for any node >>>> ^^^^^^^^^ >>>> Yes, I'm interested in examples that show its usefulness (they should >>>> possibly mentioned in the draft section 4). >>>> >>>>> to force a refresh operation to be carried. For example, a mobility anchor >>>>> point may get to know that an MN has moved, and can force a refresh >>>>> towards the MN. A similar indication and a subsequent refresh can happen >>>> Hm, I don't quite get it. In case the MN has moved he also >>>> changed his CoA and thus the MRI, and, in this case, the MAP will >>>> usually send a new RESERVE with a different MRI. >>>> >>>>> with Mobile IP, when the HA, or CN receive a binding update, and know that >>>>> the path near the MN has changed. >>>> I don't see why a forced refresh will help much in mobility scenarios. >>>> Basically what you achieve with a forced refresh is that the state >>>> along the whole path doesn't expire, but states will not expire >>>> using the normal peer refreshes in case nothing else changed. >>>> So in case the routing in the network didn't change, the refreshing >>>> RESERVE will take exactly the same path as before. If the MN has changed >>>> its CoA, you will usually end up sending a RESERVE with a different MRI >>>> which then may traverse along a new path. Then states along the >>>> unchanged path are refreshed anyway. >>>> The only benefit would be IMHO to force a refresh before a handover >>>> so that the time period for performing the handover is long enough >>>> to keep the reservation while the QNI moves. But this could be achieved >>>> by an ordinary refresh, too. >>>> >>>> Regards, >>>> Roland >>>> >>>>> On Thu, 9 Mar 2006, Roland Bless wrote: >>>>> >>>>>> Hi Jukka, >>>>>> >>>>>>> On Sat, 4 Mar 2006, Bernd Schloer wrote: >>>>>>> >>>>>>>> Hi Jukka, >>>>>>>> >>>>>>>> a few things are not quite clear to me: >>>>>>>> >>>>>>>> Who is responsible to trigger the Refresh Messages? Is it the QNI or the >>>>>>>> Client Application connected to the QNI? >>>>>>> Page 4: >>>>>>> "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 >>>>>>> [RFC2205], and uses soft-state peer-to-peer refresh messages as the >>>>>>> primary state management mechanism (i.e. state installation/refresh >>>>>>> is performed between pairs of adjacent NSLP nodes, rather than in an >>>>>>> end-to-end fashion along the complete signalling path)." >>>>>> The latter is, however, possible in case one uses a refreshing RESERVE >>>>>> with an RII object included: >>>>>> 5.1.2.1. RESERVE >>>>>> ... >>>>>> A refresh right along the path can be forced by requesting a RESPONSE >>>>>> from the far end (i.e. (i.e., by including an RII object in the RESERVE >>>>>> message). >>>>>> >>>>>> I still don't know what it's good for... _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 20 02:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEz6-0006py-Ia; Mon, 20 Mar 2006 02:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEz4-0006pn-Bk for nsis@ietf.org; Mon, 20 Mar 2006 02:39:22 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLEyz-0006t0-Hc for nsis@ietf.org; Mon, 20 Mar 2006 02:39:21 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 20 Mar 2006 08:39:15 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Mar 2006 08:39:15 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6282@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: bless@tm.uka.de Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Mon, 20 Mar 2006 08:39:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Roland, Jukka's intentions on Ack's at the access aren't too far from mine.=20 My personal preferenceis to operate NSIS on customer network edges = only.=20 I'd expect no more than 4 QoS NSLP speaking devices along a path.=20 Any Reserve passing a customer edge should be Acked anyway,=20 I think (similar as Jukka).=20 I didn't read the draft how to couple RSVP to Bob Briscoe's=20 http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-01.pdf . But I'm pretty sure that the destination edge router informs the=20 upstream origin edge router about the congestion state of the backbone. = In the case of QoS NSLP, that doesn't need to be an Ack, but if the=20 Ack was there anyway, it could nicely be used. That's a little bit more than a bare keep alive mechanism now. It is=20 a special case too, as others will prefer other QoS NSLP architectures. = Regards, R=FCdiger |You are right. I would prefer to always get a RESPONSE (from the QNR |or far end). |The ACK mechanism is a different thing, because it is only triggering |a response from the direct peer. It would help a lot if we could |actually write down the requirements. From the past discussions I |have the impression that people want to achieve totally=20 |different things with the defined retransmission mechanisms.=20 |Thus it would be good to clearly describe the problem(s) we want=20 |to solve. Short summary: |Ruediger: wants liveliness check |Georgious: wants some confirmation (for what purpose?) |Jukka: wants to recover loss(?) in case of unreliable |transport (wants to avoid using TCP for mobile nodes...) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 20 03:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFST-0008Ua-US; Mon, 20 Mar 2006 03:09:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFSS-0008UV-9t for nsis@ietf.org; Mon, 20 Mar 2006 03:09:44 -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 1FLFSK-0007m6-Vu for nsis@ietf.org; Mon, 20 Mar 2006 03:09:41 -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; Mon, 20 Mar 2006 10:09:36 +0200 id 000702C0.441E6340.0000262C Date: Mon, 20 Mar 2006 10:09:34 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] QoS NSLP updated In-Reply-To: <441DD668.3000401@tm.uka.de> Message-ID: References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> <441027F7.4040006@tm.uka.de> <44157356.1020408@tm.uka.de> <441DD668.3000401@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: 93e7fb8fef2e780414389440f367c879 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, got mixed up with what I would want to have, and what is there actually. :) A "force refresh" flag isn't there, it is only in my LRSVP. The QoS NSLP can only force a refresh by include the RII, which gets back a response. Jukka On Sun, 19 Mar 2006, Roland Bless wrote: > Hi Jukka, > > > using your topology, we use an LMM scheme that does not change the IP > > address, say CIP or BCMP. We have a true e2e reservation. The MRI does not > > change after handover. > > Ok, now it's getting clearer... > > > If we have the MAP at R3, it gets to know the MN moved, and sends a > > RESERVE. R2 gets the RESERVE and thinks it is a simple refresh, since no > > information is different. We could use an RII in the RESERVE, which forces > > the refresh to go all the way, and the MAP gets back a RESPONSE. If we use > > a forcing refresh, we get the refresh through all the way, and don't need > > back a RESPONSE. > > Forcing refresh would mean a new flag? > > > I could live with both ways to get the refresh through. > > Regards, > Roland > > > Jukka > > > > On Mon, 13 Mar 2006, Roland Bless wrote: > > > >> Hi Jukka, > >> > >>> If you use a local mobility management scheme, controlled by a MAP, then > >>> you don't need to change the IP address after each handover. Thus, a > >> Maybe I don't understand that because the scenario is not quite clear > >> to me. Do you mean we use something like H-MIP? If yes, then we may > >> have a situation like this: > >> > >> MN---AR1 > >> \ > >> R1---R2(MAP)--R3--R4--...--CN > >> / > >> AR2 > >> > >> I assumed that we consider a reservation from CN->MN and the > >> MN changes ARs. In this case the MN will get a new IP address > >> which is indeed hidden for the CN. However, I thought that > >> we have more or less two reservations, one from CN->MAP and > >> one from CN->MN. The latter will be updated in case the MN > >> registers its new address at the MAP. In this case the MAP will > >> use a new MRI towards the MN anyway, so it is not a "refresh" > >> because it will be forwarded along the whole path from the MAP > >> to the MN. > >> > >>> refresh from the MAP towards the MN will look like an ordinary refresh, > >>> and will not help in making reservations closer to the MN, say, at the > >>> access router. If you can force a refresh, you can repair the reservation > >>> faster. > >> I apologize that I still don't understand. In case the MN's local > >> address doesn't change the refreshing RESERVE will also not take any > >> new path from MAP to CN?! Maybe you can explain it with help of the > >> above example. > >> > >> Regards, > >> Roland > >> > >>> Jukka > >>> > >>> On Thu, 9 Mar 2006, Roland Bless wrote: > >>> > >>>> Hi Jukka, > >>>> > >>>>> The "forced" refresh is useful to have, and makes it possible for any node > >>>> ^^^^^^^^^ > >>>> Yes, I'm interested in examples that show its usefulness (they should > >>>> possibly mentioned in the draft section 4). > >>>> > >>>>> to force a refresh operation to be carried. For example, a mobility anchor > >>>>> point may get to know that an MN has moved, and can force a refresh > >>>>> towards the MN. A similar indication and a subsequent refresh can happen > >>>> Hm, I don't quite get it. In case the MN has moved he also > >>>> changed his CoA and thus the MRI, and, in this case, the MAP will > >>>> usually send a new RESERVE with a different MRI. > >>>> > >>>>> with Mobile IP, when the HA, or CN receive a binding update, and know that > >>>>> the path near the MN has changed. > >>>> I don't see why a forced refresh will help much in mobility scenarios. > >>>> Basically what you achieve with a forced refresh is that the state > >>>> along the whole path doesn't expire, but states will not expire > >>>> using the normal peer refreshes in case nothing else changed. > >>>> So in case the routing in the network didn't change, the refreshing > >>>> RESERVE will take exactly the same path as before. If the MN has changed > >>>> its CoA, you will usually end up sending a RESERVE with a different MRI > >>>> which then may traverse along a new path. Then states along the > >>>> unchanged path are refreshed anyway. > >>>> The only benefit would be IMHO to force a refresh before a handover > >>>> so that the time period for performing the handover is long enough > >>>> to keep the reservation while the QNI moves. But this could be achieved > >>>> by an ordinary refresh, too. > >>>> > >>>> Regards, > >>>> Roland > >>>> > >>>>> On Thu, 9 Mar 2006, Roland Bless wrote: > >>>>> > >>>>>> Hi Jukka, > >>>>>> > >>>>>>> On Sat, 4 Mar 2006, Bernd Schloer wrote: > >>>>>>> > >>>>>>>> Hi Jukka, > >>>>>>>> > >>>>>>>> a few things are not quite clear to me: > >>>>>>>> > >>>>>>>> Who is responsible to trigger the Refresh Messages? Is it the QNI or the > >>>>>>>> Client Application connected to the QNI? > >>>>>>> Page 4: > >>>>>>> "The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 > >>>>>>> [RFC2205], and uses soft-state peer-to-peer refresh messages as the > >>>>>>> primary state management mechanism (i.e. state installation/refresh > >>>>>>> is performed between pairs of adjacent NSLP nodes, rather than in an > >>>>>>> end-to-end fashion along the complete signalling path)." > >>>>>> The latter is, however, possible in case one uses a refreshing RESERVE > >>>>>> with an RII object included: > >>>>>> 5.1.2.1. RESERVE > >>>>>> ... > >>>>>> A refresh right along the path can be forced by requesting a RESPONSE > >>>>>> from the far end (i.e. (i.e., by including an RII object in the RESERVE > >>>>>> message). > >>>>>> > >>>>>> I still don't know what it's good for... > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 20 07:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLJtn-0001uG-Gh; Mon, 20 Mar 2006 07:54:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLJtm-0001uB-2H for nsis@ietf.org; Mon, 20 Mar 2006 07:54:14 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLJtj-0000F1-Jo for nsis@ietf.org; Mon, 20 Mar 2006 07:54:14 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 12986FE94; Mon, 20 Mar 2006 13:54:10 +0100 (CET) Received: from [172.22.0.51] (tmg51.tmg.loc [172.22.0.51]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 20 Mar 2006 13:54:09 +0100 (CET) Message-ID: <441EA5F1.6040300@cs.uni-goettingen.de> Date: Mon, 20 Mar 2006 13:54:09 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <44192E11.2010007@tm.uka.de> <4419F350.20505@cs.uni-goettingen.de> <441DD17C.7010008@tm.uka.de> In-Reply-To: <441DD17C.7010008@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Roland, Roland Bless wrote: > Hi Xiaoming, > > >>There could be several non-competing options (to apply in different >>scenarios): >> >>A. making trigger messages be reliable (which could be very useful, as >>concluded by [1]) >> >>B. making usual refreshes be reliable (which could be not as useful as A) >> >>C. making reduced overhead extension refreshes to be reliable (which >>will be useful per RFC2961/[2]). > > > I guess that this is more related and more essential > to _summary_ refreshes which we currently don't have. Besides Srefreshes (supported in current text 3.2.5), options in RFC2961 can be also useful: - reliability by hop-by-hop acknowledgement (context of ACK discussions here) - bundled messages: currently we don't have (?). > >>D. making removal messages be reliable (which could be useful, as >>concluded by [1]) >> >>"Reliable" above means whether one needs an explict Response to be sent >>from the recipient upon receipt of the corresponding >>trigger/refresh/removal. > > > Ok, but who is "the recipient"? In case of the RESPONSE from the far > end it's usually the QNR, in case of the ACK it's the next QNE, maybe > for different purposes. - Per-hop ACK is probably necessary, when the reliable GIST transport is used. - Response from the far end should be always good to have, in order to have a reasonable reliability in QoS NSLP level. > Consider the action that should be taken on a missing ACK: > in case of unreliable transport you probably can recover a > packet loss by simply retransmitting the request again; but in case you > are already using reliable transport, you may indicate a failure > after some timeout. Yes I agree we probably need to let the reaction to a receiving ACK to depend on used GIST property. > > >>My view is that unreliable transmission would suffice B; for A and C >>reliability SHOULD/MUST be made; for D reliability MAY be made. > > > Just wanted to note that a RESPONSE may also be lost > in case of unreliable transport, and, as already said: > I guess that reliable transport is more the task of GIST > than of QoS NSLP. Maybe QoS NSLP could have its own "reliability" by allowing QNI/R to be more consistent with their own engines. > > >>Relying >>on the existence of RII to determine whether to give a response is >>probably not a typical behavior from my personal limited understanding >>of other protocols. > > > You are right. I would prefer to always get a RESPONSE (from the QNR > or far end). We are inline with each other here. :) Regards, Xiaoming > The ACK mechanism is a different thing, because it is only triggering > a response from the direct peer. It would help a lot if we could > actually write down the requirements. From the past discussions I > have the impression that people want to achieve totally different things > with the defined retransmission mechanisms. Thus it would be good to > clearly describe the problem(s) we want to solve. Short summary: > Ruediger: wants liveliness check > Georgious: wants some confirmation (for what purpose?) > Jukka: wants to recover loss(?) in case of unreliable > transport (wants to avoid using TCP for mobile nodes...) > > >>[1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison of Hard-State >>and Soft-State Signaling Protocols, SIGCOMM 2003. >>[2] P. Pan and H. Schulzrine, Staged Refresh Timers for RSVP, Global >>Internet 1997. >>Cheers, >>Xiaoming > > > 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 20 08:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKWB-0001Iy-E1; Mon, 20 Mar 2006 08:33:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKWA-0001It-82 for nsis@ietf.org; Mon, 20 Mar 2006 08:33:54 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKW6-0002JN-1K for nsis@ietf.org; Mon, 20 Mar 2006 08:33:54 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2KDVJti007790; Mon, 20 Mar 2006 13:31:19 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 13:31:18 +0000 From: "Robert Hancock" To: "'Jukka MJ Manner'" Subject: RE: [NSIS] Can we do without Q-spec stacking? Date: Mon, 20 Mar 2006 07:31:15 -0600 Message-ID: <007b01c64c22$91e0b6a0$6500000a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 20 Mar 2006 13:31:19.0158 (UTC) FILETIME=[922BC960:01C64C22] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 jukka, > Hi Rob, > > I really don't see how life would be so much more fun with a > single QSPEC > allowed. The stacking of two QSPECs is a good idea, quite simple to > implement the processing for it, and has shown to have > support for a long > time. To support the stacking through implementing a separate > domain-internal session concept, and the processing for it would be a > number of times more complex and time consuming. how is it more complex than what the draft already states or implies is needed for aggregation and tunnel operation (and all the other session binding scenarios)? > If one wants to implement > the same functionality to stacking through a separate > session, he is free to do so. what I am questioning is that it seems we could have a choice between: a) implement something complex for cases A-Y and simple for case Z b) implement something complex for cases A-Z Which of (a) or (b) leads to a simpler protocol? r. (leaving aside of course the question of whether stacking is really simple, on which other people have much stronger views than me.) > > Jukka > > On Sun, 19 Mar 2006, Robert Hancock wrote: > > > Hi, > > > > I reviewed the QoS-NSLP on the flight yesterday and the above > > question occurred to me about half-way across. > > > > We introduced stacking [see below for historical background] as > > a means for accommodating localisation of the QoS specification > > within particular domains. I think that's still a legitimate > > goal. However, the specification now has another way to achieve > > the same thing, namely by creating a local signalling session > > and using the BOUND_SESSION_ID to correlate the two at the edges, > > with the e2e session ignored in the interior. > > > > I don't think it would take much work to eliminate the concept from > > the qos-nslp (I haven't checked the qspec yet). And I'm sure there > > would be tears of joy in some quarters. > > > > r. > > > > Background: > > For a trip down memory lane, check out section 4.4 of > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt > > (from 2002...). At the time, the main advantage of the stacking > > approach was that domain boundary nodes could do all their > processing > > on a single message rather than having to correlate messages of > > multiple sessions. However, it now turns out that we can't avoid > > that type of complexity for other reasons, including > > - any sort of aggregation (where you have to handle 1+N messages) > > - where the interior session needs uses different GIST transport > > characteristics (RMD) > > - where it is natural to hide the e2e session in the interior > > (tunnel e.g. for mobility/vpn scenarios) > > Given that session correlation is needed in all these other cases, > > the advantage of being able to do without it in a particular case > > basically vanishes. It's probably simpler to use a single mechanism > > to handle everything. > > > > > > _______________________________________________ > > 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 20 08:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKmD-00020N-PQ; Mon, 20 Mar 2006 08:50:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKmC-0001zT-C9 for nsis@ietf.org; Mon, 20 Mar 2006 08:50:28 -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 1FLKmA-0002f4-SW for nsis@ietf.org; Mon, 20 Mar 2006 08:50:28 -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; Mon, 20 Mar 2006 15:50:26 +0200 id 00070111.441EB322.00007903 Date: Mon, 20 Mar 2006 15:50:26 +0200 (EET) From: Jukka MJ Manner To: Robert Hancock Subject: RE: [NSIS] Can we do without Q-spec stacking? In-Reply-To: <007b01c64c22$91e0b6a0$6500000a@comm.ad.roke.co.uk> Message-ID: References: <007b01c64c22$91e0b6a0$6500000a@comm.ad.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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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, So, your idea is that since one anyway implements session binding and tunneling, then stacking comes along "free". What if one doesn't implement the binding and aggregation at all in his routers because the domain only needs the simple stacking functionality, i.e., use a different QOSM within the domain? Jukka On Mon, 20 Mar 2006, Robert Hancock wrote: > jukka, > > > Hi Rob, > > > > I really don't see how life would be so much more fun with a > > single QSPEC > > allowed. The stacking of two QSPECs is a good idea, quite simple to > > implement the processing for it, and has shown to have > > support for a long > > time. To support the stacking through implementing a separate > > domain-internal session concept, and the processing for it would be a > > number of times more complex and time consuming. > > how is it more complex than what the draft already states or implies > is needed for aggregation and tunnel operation (and all the other > session binding scenarios)? > > > If one wants to implement > > the same functionality to stacking through a separate > > session, he is free to do so. > > what I am questioning is that it seems we could have a choice > between: > a) implement something complex for cases A-Y and simple for case Z > b) implement something complex for cases A-Z > Which of (a) or (b) leads to a simpler protocol? > > r. > > (leaving aside of course the question of whether stacking is really > simple, on which other people have much stronger views than me.) > > > > > Jukka > > > > On Sun, 19 Mar 2006, Robert Hancock wrote: > > > > > Hi, > > > > > > I reviewed the QoS-NSLP on the flight yesterday and the above > > > question occurred to me about half-way across. > > > > > > We introduced stacking [see below for historical background] as > > > a means for accommodating localisation of the QoS specification > > > within particular domains. I think that's still a legitimate > > > goal. However, the specification now has another way to achieve > > > the same thing, namely by creating a local signalling session > > > and using the BOUND_SESSION_ID to correlate the two at the edges, > > > with the e2e session ignored in the interior. > > > > > > I don't think it would take much work to eliminate the concept from > > > the qos-nslp (I haven't checked the qspec yet). And I'm sure there > > > would be tears of joy in some quarters. > > > > > > r. > > > > > > Background: > > > For a trip down memory lane, check out section 4.4 of > > > > > http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt > > > (from 2002...). At the time, the main advantage of the stacking > > > approach was that domain boundary nodes could do all their > > processing > > > on a single message rather than having to correlate messages of > > > multiple sessions. However, it now turns out that we can't avoid > > > that type of complexity for other reasons, including > > > - any sort of aggregation (where you have to handle 1+N messages) > > > - where the interior session needs uses different GIST transport > > > characteristics (RMD) > > > - where it is natural to hide the e2e session in the interior > > > (tunnel e.g. for mobility/vpn scenarios) > > > Given that session correlation is needed in all these other cases, > > > the advantage of being able to do without it in a particular case > > > basically vanishes. It's probably simpler to use a single mechanism > > > to handle everything. > > > > > > > > > _______________________________________________ > > > 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 20 10:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMbS-0003Io-KC; Mon, 20 Mar 2006 10:47:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMbR-0003Ij-Cd for nsis@ietf.org; Mon, 20 Mar 2006 10:47:29 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMbN-00078S-V9 for nsis@ietf.org; Mon, 20 Mar 2006 10:47:29 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FLMbE-0001UF-UC; Mon, 20 Mar 2006 16:47:23 +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 B6965BEEB; Mon, 20 Mar 2006 16:47:16 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FLMbA-0005uD-1a; Mon, 20 Mar 2006 16:47:16 +0100 Message-ID: <441ECE45.7090702@tm.uka.de> Date: Mon, 20 Mar 2006 16:46:13 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP updated References: <4408D872.9050003@cs.uni-goettingen.de> <440FFEFB.5090306@tm.uka.de> <441027F7.4040006@tm.uka.de> <44157356.1020408@tm.uka.de> <441DD668.3000401@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list 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 Hi Jukka, > Hi, sorry, got mixed up with what I would want to have, and what is there > actually. :) A "force refresh" flag isn't there, it is only in my LRSVP. > The QoS NSLP can only force a refresh by include the RII, which gets back > a response. Yep. So is it possibly of interest/advantage to have that flag, i.e., RESERVE w/o RII, but with this new F flag? I would also suggest to add a little rationale for both cases. Regards, Roland > On Sun, 19 Mar 2006, Roland Bless wrote: > >> Hi Jukka, >> >>> using your topology, we use an LMM scheme that does not change the IP >>> address, say CIP or BCMP. We have a true e2e reservation. The MRI does not >>> change after handover. >> Ok, now it's getting clearer... >> >>> If we have the MAP at R3, it gets to know the MN moved, and sends a >>> RESERVE. R2 gets the RESERVE and thinks it is a simple refresh, since no >>> information is different. We could use an RII in the RESERVE, which forces >>> the refresh to go all the way, and the MAP gets back a RESPONSE. If we use >>> a forcing refresh, we get the refresh through all the way, and don't need >>> back a RESPONSE. >> Forcing refresh would mean a new flag? >> >>> I could live with both ways to get the refresh through. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 20 11:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNCo-0004Xh-3K; Mon, 20 Mar 2006 11:26:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNCn-0004Sf-44 for nsis@ietf.org; Mon, 20 Mar 2006 11:26:05 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNCm-0000KM-FT for nsis@ietf.org; Mon, 20 Mar 2006 11:26:05 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FLNCf-0004Gw-9B; Mon, 20 Mar 2006 17:26:03 +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 E516EBF10; Mon, 20 Mar 2006 17:25:56 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FLNCd-0005vi-LM; Mon, 20 Mar 2006 17:25:56 +0100 Message-ID: <441ED75B.8080106@tm.uka.de> Date: Mon, 20 Mar 2006 17:24:59 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Xiaoming Fu Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <44192E11.2010007@tm.uka.de> <4419F350.20505@cs.uni-goettingen.de> <441DD17C.7010008@tm.uka.de> <441EA5F1.6040300@cs.uni-goettingen.de> In-Reply-To: <441EA5F1.6040300@cs.uni-goettingen.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Xiaoming, >>> There could be several non-competing options (to apply in different >>> scenarios): >>> >>> A. making trigger messages be reliable (which could be very useful, as >>> concluded by [1]) >>> >>> B. making usual refreshes be reliable (which could be not as useful >>> as A) >>> >>> C. making reduced overhead extension refreshes to be reliable (which >>> will be useful per RFC2961/[2]). >> >> >> I guess that this is more related and more essential >> to _summary_ refreshes which we currently don't have. > Besides Srefreshes (supported in current text 3.2.5), options in RFC2961 Sorry, but 3.2.5 is about _Reduced_ Refresh which is a little bit different from a summary refresh. The former only leaves out the QSPEC, the latter would refresh several reservations/sessions with only one packet. Currently, we don't have such a feature => (Would it be desirable?) > can be also useful: > - reliability by hop-by-hop acknowledgement (context of ACK discussions > here) The main motivation for ACKing was packet loss of non-refresh messages and too long timeouts for faster retransmission, quotes from RFC 2961: The reliability and latency problem occurs when a non-refresh RSVP message is lost in transmission. Standard RSVP [RFC2205] recovers from a lost message via RSVP refresh messages. In the face of transmission loss of RSVP messages, the end-to-end latency of RSVP signaling is tied to the refresh interval of the node(s) experiencing the loss. When end-to-end signaling is limited by the refresh interval, the delay incurred in the establishment or the change of a reservation may be beyond the range of what is acceptable for some applications. ... The ACK_Desired flag is set when the MESSAGE_ID object generator wants a MESSAGE_ID_ACK object sent in response to the message. Such information can be used to ensure reliable delivery of RSVP messages in the face of network loss. Nodes setting the ACK_Desired flag SHOULD retransmit unacknowledged messages at a more rapid interval than the standard refresh period until the message is acknowledged or until a "rapid" retry limit is reached. Rapid retransmission rate MUST be based on the exponential exponential back-off procedures defined in section 6. The ACK_Desired flag will typically be set only in trigger messages. The ACK_Desired flag MAY be set in refresh messages. Issues relate to multicast sessions are covered in a later section. However, I guess that we simply could use our underlying reliable GIST transport to avoid that. > - bundled messages: currently we don't have (?). IIRC signaling message bundling is supported by SCTP. If you want that, you probably want to use GIST with SCTP. This is, however, a little bit different from bundling within QoS NSLP, because we still have the overhead of multiple GIST and QoS NSLP headers. >> >>> D. making removal messages be reliable (which could be useful, as >>> concluded by [1]) >>> >>> "Reliable" above means whether one needs an explict Response to be sent >>> from the recipient upon receipt of the corresponding >>> trigger/refresh/removal. >> >> >> Ok, but who is "the recipient"? In case of the RESPONSE from the far >> end it's usually the QNR, in case of the ACK it's the next QNE, maybe >> for different purposes. > > - Per-hop ACK is probably necessary, when the reliable GIST transport is > used. ??? do you mean _un_reliable ?? > - Response from the far end should be always good to have, in order to > have a reasonable reliability in QoS NSLP level. And feedback about the actually reserved resources, etc. >> Consider the action that should be taken on a missing ACK: >> in case of unreliable transport you probably can recover a >> packet loss by simply retransmitting the request again; but in case you >> are already using reliable transport, you may indicate a failure >> after some timeout. > > Yes I agree we probably need to let the reaction to a receiving ACK to > depend on used GIST property. > >> >> >>> My view is that unreliable transmission would suffice B; for A and C >>> reliability SHOULD/MUST be made; for D reliability MAY be made. >> >> >> Just wanted to note that a RESPONSE may also be lost >> in case of unreliable transport, and, as already said: >> I guess that reliable transport is more the task of GIST >> than of QoS NSLP. > > Maybe QoS NSLP could have its own "reliability" by allowing QNI/R to be > more consistent with their own engines. Hmm, therefore I would propose to add that ACK flag, but let the corresponding reaction up to the QoS model/application. >>> Relying >>> on the existence of RII to determine whether to give a response is >>> probably not a typical behavior from my personal limited understanding >>> of other protocols. >> >> >> You are right. I would prefer to always get a RESPONSE (from the QNR >> or far end). > We are inline with each other here. :) Regards, Roland >> The ACK mechanism is a different thing, because it is only triggering >> a response from the direct peer. It would help a lot if we could >> actually write down the requirements. From the past discussions I >> have the impression that people want to achieve totally different things >> with the defined retransmission mechanisms. Thus it would be good to >> clearly describe the problem(s) we want to solve. Short summary: >> Ruediger: wants liveliness check >> Georgious: wants some confirmation (for what purpose?) >> Jukka: wants to recover loss(?) in case of unreliable >> transport (wants to avoid using TCP for mobile nodes...) >> >> >>> [1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison of Hard-State >>> and Soft-State Signaling Protocols, SIGCOMM 2003. >>> [2] P. Pan and H. Schulzrine, Staged Refresh Timers for RSVP, Global >>> Internet 1997. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 20 11:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNQ0-0004FM-VU; Mon, 20 Mar 2006 11:39:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNPz-0004FH-FD for nsis@ietf.org; Mon, 20 Mar 2006 11:39:43 -0500 Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNPy-0000nb-0x for nsis@ietf.org; Mon, 20 Mar 2006 11:39:43 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id 01A2CFE94; Mon, 20 Mar 2006 17:39:41 +0100 (CET) Received: from [192.168.4.34] (dslb-082-083-034-118.pools.arcor-ip.net [82.83.34.118]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 20 Mar 2006 17:39:40 +0100 (CET) Message-ID: <441EDACC.2020702@cs.uni-goettingen.de> Date: Mon, 20 Mar 2006 17:39:40 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <44192E11.2010007@tm.uka.de> <4419F350.20505@cs.uni-goettingen.de> <441DD17C.7010008@tm.uka.de> <441EA5F1.6040300@cs.uni-goettingen.de> <441ED75B.8080106@tm.uka.de> In-Reply-To: <441ED75B.8080106@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Roland, Roland Bless wrote: > Hi Xiaoming, > >>>I guess that this is more related and more essential >>>to _summary_ refreshes which we currently don't have. >> >>Besides Srefreshes (supported in current text 3.2.5), options in RFC2961 > > > Sorry, but 3.2.5 is about _Reduced_ Refresh which is a little bit > different from a summary refresh. The former only leaves out the QSPEC, > the latter would refresh several reservations/sessions with only one > packet. Currently, we don't have such a feature => (Would it be > desirable?) I interpreted Srefreshes as method using Message_ID to reduce refresh message size. Ok. > >>can be also useful: >>- reliability by hop-by-hop acknowledgement (context of ACK discussions >>here) > > > The main motivation for ACKing was packet loss of non-refresh messages > and too long timeouts for faster retransmission, quotes from RFC 2961: > > The reliability and latency problem occurs when a non-refresh RSVP > message is lost in transmission. Standard RSVP [RFC2205] recovers > from a lost message via RSVP refresh messages. In the face of > transmission loss of RSVP messages, the end-to-end latency of RSVP > signaling is tied to the refresh interval of the node(s) experiencing > the loss. When end-to-end signaling is limited by the refresh > interval, the delay incurred in the establishment or the change of a > reservation may be beyond the range of what is acceptable for some > applications. > > ... > > The ACK_Desired flag is set when the MESSAGE_ID object generator > wants a MESSAGE_ID_ACK object sent in response to the message. Such > information can be used to ensure reliable delivery of RSVP messages > in the face of network loss. Nodes setting the ACK_Desired flag > SHOULD retransmit unacknowledged messages at a more rapid interval > than the standard refresh period until the message is acknowledged or > until a "rapid" retry limit is reached. Rapid retransmission rate > MUST be based on the exponential exponential back-off procedures > defined in section 6. The ACK_Desired flag will typically be set > only in trigger messages. The ACK_Desired flag MAY be set in refresh > messages. Issues relate to multicast sessions are covered in a later > section. > > However, I guess that we simply could use our underlying reliable > GIST transport to avoid that. Agreed/ > > >>- bundled messages: currently we don't have (?). > > > IIRC signaling message bundling is supported by SCTP. > If you want that, you probably want to use GIST with SCTP. > This is, however, a little bit different from bundling within QoS NSLP, > because we still have the overhead of multiple GIST and QoS NSLP > headers. Will bundling in the GIST level make GIST too involved with NSLP semantic? > >> >>- Per-hop ACK is probably necessary, when the reliable GIST transport is >>used. > > ??? do you mean _un_reliable ?? > Sorry, my typo. > >>- Response from the far end should be always good to have, in order to >>have a reasonable reliability in QoS NSLP level. > > > And feedback about the actually reserved resources, etc. Yup. > >>>Consider the action that should be taken on a missing ACK: >>>in case of unreliable transport you probably can recover a >>>packet loss by simply retransmitting the request again; but in case you >>>are already using reliable transport, you may indicate a failure >>>after some timeout. >> > > Hmm, therefore I would propose to add that ACK flag, > but let the corresponding reaction up to the QoS model/application. Also my feeling. in short: - Whether one needs an ACK: determined by GIST property (reliable v.s unreliable) - How to react on received ACKs: determined by QoSM/higher. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Mar 20 14:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPm2-0004o5-Ab; Mon, 20 Mar 2006 14:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPm1-0004nt-2h for nsis@ietf.org; Mon, 20 Mar 2006 14:10:37 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLPm0-0006l3-4Z for nsis@ietf.org; Mon, 20 Mar 2006 14:10:37 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2KJAOti014585; Mon, 20 Mar 2006 19:10:24 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 19:10:23 +0000 From: "Robert Hancock" To: "'Roland Bless'" , "'Xiaoming Fu'" Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Mon, 20 Mar 2006 13:10:21 -0600 Message-ID: <054f01c64c51$f059b270$73848182@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <441ED75B.8080106@tm.uka.de> X-OriginalArrivalTime: 20 Mar 2006 19:10:24.0103 (UTC) FILETIME=[F0B40770:01C64C51] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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 all, some issues about the interactions between nslp and gist also occurred to me while reading the draft. specifically: *) in 5.2.4, the correct rules for the qos-nslp do depend on whether GIST is being used for reliable transport or not. but in either case, I don't think that initialising the RTO estimate using transport layer algorithms is valid, since the ACK at the NSLP level also has to take account of application level interactions (e.g. policy checks) for which such estimates are invalid. indeed, this was one of the main motivations for supporting reliable transport in GIST: to optimise transport layer retransmission behaviour better than the application will ever be able to, allowing the application to concentrate on handling application layer timeouts correctly. if GIST reliable transport is being used, I think there is a good case for saying that if GIST reports a message delivery failure then the NSLP should just give up as a fatal error condition. only if unreliable transport is being used should the application try to do something more clever. but I would then question why you would set the Ack flag and request unreliable transport. *) similarly, i'm not sure that 5.3.4 is fully correct. at least, you could say that if reliable transport is being provided by GIST, then this sort of special slew handling is unnecessary; the slew handling algorithms are only there to handle lost messages. you could simply say 'if you want to use unreliable transport you must keep the refresh period fixed for a given period', which would simplify this section quite considerably. *) there is some discussion below about bundling. to avoid any doubt, GIST will bundle any messages sent over the reliable transport if it can work out they are to the same peer. (in particular, it will do this with TCP, you don't need SCTP.) if you want message summarisation as well, that could be done either at the NSLP level (invisible to GIST), or it could be added as a protocol option to GIST, in which case one could imagine rather efficient solutions which exploited redundancy between GIST and NSLP messages as well as between successive messages. (I have occasionally wondered about writing a 2-3 page specification for sigcomp/RFC3320 as a messaging association protocol. Maybe something for the new work discussion.) r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: 20 March 2006 10:25 > To: Xiaoming Fu > Cc: nsis > Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? > > > Hi Xiaoming, > > >>> There could be several non-competing options (to apply in > different > >>> scenarios): > >>> > >>> A. making trigger messages be reliable (which could be > very useful, as > >>> concluded by [1]) > >>> > >>> B. making usual refreshes be reliable (which could be not > as useful > >>> as A) > >>> > >>> C. making reduced overhead extension refreshes to be > reliable (which > >>> will be useful per RFC2961/[2]). > >> > >> > >> I guess that this is more related and more essential > >> to _summary_ refreshes which we currently don't have. > > Besides Srefreshes (supported in current text 3.2.5), > options in RFC2961 > > Sorry, but 3.2.5 is about _Reduced_ Refresh which is a little bit > different from a summary refresh. The former only leaves out > the QSPEC, > the latter would refresh several reservations/sessions with only one > packet. Currently, we don't have such a feature => (Would it be > desirable?) > > > can be also useful: > > - reliability by hop-by-hop acknowledgement (context of ACK > discussions > > here) > > The main motivation for ACKing was packet loss of non-refresh messages > and too long timeouts for faster retransmission, quotes from RFC 2961: > > The reliability and latency problem occurs when a non-refresh RSVP > message is lost in transmission. Standard RSVP [RFC2205] recovers > from a lost message via RSVP refresh messages. In the face of > transmission loss of RSVP messages, the end-to-end latency of RSVP > signaling is tied to the refresh interval of the node(s) > experiencing > the loss. When end-to-end signaling is limited by the refresh > interval, the delay incurred in the establishment or the > change of a > reservation may be beyond the range of what is acceptable for some > applications. > > ... > > The ACK_Desired flag is set when the MESSAGE_ID object generator > wants a MESSAGE_ID_ACK object sent in response to the > message. Such > information can be used to ensure reliable delivery of > RSVP messages > in the face of network loss. Nodes setting the ACK_Desired flag > SHOULD retransmit unacknowledged messages at a more rapid interval > than the standard refresh period until the message is > acknowledged or > until a "rapid" retry limit is reached. Rapid retransmission rate > MUST be based on the exponential exponential back-off procedures > defined in section 6. The ACK_Desired flag will typically be set > only in trigger messages. The ACK_Desired flag MAY be set > in refresh > messages. Issues relate to multicast sessions are covered > in a later > section. > > However, I guess that we simply could use our underlying reliable > GIST transport to avoid that. > > > - bundled messages: currently we don't have (?). > > IIRC signaling message bundling is supported by SCTP. > If you want that, you probably want to use GIST with SCTP. > This is, however, a little bit different from bundling within > QoS NSLP, > because we still have the overhead of multiple GIST and QoS NSLP > headers. > > >> > >>> D. making removal messages be reliable (which could be useful, as > >>> concluded by [1]) > >>> > >>> "Reliable" above means whether one needs an explict > Response to be sent > >>> from the recipient upon receipt of the corresponding > >>> trigger/refresh/removal. > >> > >> > >> Ok, but who is "the recipient"? In case of the RESPONSE > from the far > >> end it's usually the QNR, in case of the ACK it's the next > QNE, maybe > >> for different purposes. > > > > - Per-hop ACK is probably necessary, when the reliable GIST > transport is > > used. > > ??? do you mean _un_reliable ?? > > > - Response from the far end should be always good to have, > in order to > > have a reasonable reliability in QoS NSLP level. > > And feedback about the actually reserved resources, etc. > > >> Consider the action that should be taken on a missing ACK: > >> in case of unreliable transport you probably can recover a > >> packet loss by simply retransmitting the request again; > but in case you > >> are already using reliable transport, you may indicate a failure > >> after some timeout. > > > > Yes I agree we probably need to let the reaction to a > receiving ACK to > > depend on used GIST property. > > > >> > >> > >>> My view is that unreliable transmission would suffice B; > for A and C > >>> reliability SHOULD/MUST be made; for D reliability MAY be made. > >> > >> > >> Just wanted to note that a RESPONSE may also be lost > >> in case of unreliable transport, and, as already said: > >> I guess that reliable transport is more the task of GIST > >> than of QoS NSLP. > > > > Maybe QoS NSLP could have its own "reliability" by allowing > QNI/R to be > > more consistent with their own engines. > > Hmm, therefore I would propose to add that ACK flag, > but let the corresponding reaction up to the QoS model/application. > > >>> Relying > >>> on the existence of RII to determine whether to give a response is > >>> probably not a typical behavior from my personal limited > understanding > >>> of other protocols. > >> > >> > >> You are right. I would prefer to always get a RESPONSE > (from the QNR > >> or far end). > > We are inline with each other here. :) > > Regards, > Roland > > >> The ACK mechanism is a different thing, because it is only > triggering > >> a response from the direct peer. It would help a lot if we could > >> actually write down the requirements. From the past discussions I > >> have the impression that people want to achieve totally > different things > >> with the defined retransmission mechanisms. Thus it would > be good to > >> clearly describe the problem(s) we want to solve. Short summary: > >> Ruediger: wants liveliness check > >> Georgious: wants some confirmation (for what purpose?) > >> Jukka: wants to recover loss(?) in case of unreliable > >> transport (wants to avoid using TCP for mobile nodes...) > >> > >> > >>> [1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison > of Hard-State > >>> and Soft-State Signaling Protocols, SIGCOMM 2003. > >>> [2] P. Pan and H. Schulzrine, Staged Refresh Timers for > RSVP, Global > >>> Internet 1997. > > > _______________________________________________ > 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 20 15:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRL9-0001yn-PU; Mon, 20 Mar 2006 15:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRL9-0001yi-0Q for nsis@ietf.org; Mon, 20 Mar 2006 15:50:59 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRL7-0002Wd-8M for nsis@ietf.org; Mon, 20 Mar 2006 15:50:58 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FLRKt-0002eb-GF; Mon, 20 Mar 2006 21:50:56 +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 EE55DBF4F; Mon, 20 Mar 2006 21:50:42 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FLRKr-00069U-UM; Mon, 20 Mar 2006 21:50:42 +0100 Message-ID: <441F156A.7060109@tm.uka.de> Date: Mon, 20 Mar 2006 21:49:46 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <054f01c64c51$f059b270$73848182@comm.ad.roke.co.uk> In-Reply-To: <054f01c64c51$f059b270$73848182@comm.ad.roke.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: 'Xiaoming Fu' , '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 Robert, > some issues about the interactions between nslp and gist also > occurred to me while reading the draft. specifically: > > *) in 5.2.4, the correct rules for the qos-nslp do depend on > whether GIST is being used for reliable transport or not. but in > either case, I don't think that initialising the RTO estimate using > transport layer algorithms is valid, since the ACK at the NSLP > level also has to take account of application level interactions > (e.g. policy checks) for which such estimates are invalid. You are right that the current proposed RTT estimate includes all processing within the QoS NSLP and also above it. Indeed, it depends on what you're trying to achieve with that ACK mechanism (that's why I'm insisting so stringent on a precise problem statement). If the purpose of the ACK mechanism is to confirm state installation (including policy data verification, admission control test etc.) then the estimate simply expresses the expected average processing time including transport. But if, as you noted below, the primary objective is to recover from packet loss, this is far from being optimal. > indeed, this was one of the main motivations for supporting > reliable transport in GIST: to optimise transport layer > retransmission behaviour better than the application will ever > be able to, allowing the application to concentrate on handling > application layer timeouts correctly. Agreed. > if GIST reliable transport is being used, I think there is a good > case for saying that if GIST reports a message delivery failure > then the NSLP should just give up as a fatal error condition. only > if unreliable transport is being used should the application try > to do something more clever. but I would then question why you would > set the Ack flag and request unreliable transport. Yes, that's what I repeatedly said. Jukka mentioned that TCP is to heavyweight for mobile nodes. Then, I would say, simply add another suitable transport protocol to GIST. Moreover, you could request unreliable transport, but GIST may switch to reliable transport without notice (due to fragmentation) and then you end up with double ACKing... > *) similarly, i'm not sure that 5.3.4 is fully correct. at least, > you could say that if reliable transport is being provided by > GIST, then this sort of special slew handling is unnecessary; Yep. I'm feeling uncomfortable with the current 5.2.4 section. > the slew handling algorithms are only there to handle lost messages. > you could simply say 'if you want to use unreliable transport you > must keep the refresh period fixed for a given period', which would > simplify this section quite considerably. I'm not quite sure that I get your point. > *) there is some discussion below about bundling. to avoid any > doubt, GIST will bundle any messages sent over the reliable > transport if it can work out they are to the same peer. (in > particular, it will do this with TCP, you don't need SCTP.) You are right, messages are probably queued and send out together...simply forgot that :-) > if you want message summarisation as well, that could be done > either at the NSLP level (invisible to GIST), or it could be IMHO this is not easily possible: At NSLP level, peer identities are not known anymore, so you could not find out which reservations have the same peer (currently it is not required that an SII handle for different MRIs is the same for the same peer). > added as a protocol option to GIST, in which case one could > imagine rather efficient solutions which exploited redundancy > between GIST and NSLP messages as well as between successive > messages. (I have occasionally wondered about writing a 2-3 page > specification for sigcomp/RFC3320 as a messaging association > protocol. Maybe something for the new work discussion.) Good. Regards, Roland >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: 20 March 2006 10:25 >> To: Xiaoming Fu >> Cc: nsis >> Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? >> >> >> Hi Xiaoming, >> >>>>> There could be several non-competing options (to apply in >> different >>>>> scenarios): >>>>> >>>>> A. making trigger messages be reliable (which could be >> very useful, as >>>>> concluded by [1]) >>>>> >>>>> B. making usual refreshes be reliable (which could be not >> as useful >>>>> as A) >>>>> >>>>> C. making reduced overhead extension refreshes to be >> reliable (which >>>>> will be useful per RFC2961/[2]). >>>> >>>> I guess that this is more related and more essential >>>> to _summary_ refreshes which we currently don't have. >>> Besides Srefreshes (supported in current text 3.2.5), >> options in RFC2961 >> >> Sorry, but 3.2.5 is about _Reduced_ Refresh which is a little bit >> different from a summary refresh. The former only leaves out >> the QSPEC, >> the latter would refresh several reservations/sessions with only one >> packet. Currently, we don't have such a feature => (Would it be >> desirable?) >> >>> can be also useful: >>> - reliability by hop-by-hop acknowledgement (context of ACK >> discussions >>> here) >> The main motivation for ACKing was packet loss of non-refresh messages >> and too long timeouts for faster retransmission, quotes from RFC 2961: >> >> The reliability and latency problem occurs when a non-refresh RSVP >> message is lost in transmission. Standard RSVP [RFC2205] recovers >> from a lost message via RSVP refresh messages. In the face of >> transmission loss of RSVP messages, the end-to-end latency of RSVP >> signaling is tied to the refresh interval of the node(s) >> experiencing >> the loss. When end-to-end signaling is limited by the refresh >> interval, the delay incurred in the establishment or the >> change of a >> reservation may be beyond the range of what is acceptable for some >> applications. >> >> ... >> >> The ACK_Desired flag is set when the MESSAGE_ID object generator >> wants a MESSAGE_ID_ACK object sent in response to the >> message. Such >> information can be used to ensure reliable delivery of >> RSVP messages >> in the face of network loss. Nodes setting the ACK_Desired flag >> SHOULD retransmit unacknowledged messages at a more rapid interval >> than the standard refresh period until the message is >> acknowledged or >> until a "rapid" retry limit is reached. Rapid retransmission rate >> MUST be based on the exponential exponential back-off procedures >> defined in section 6. The ACK_Desired flag will typically be set >> only in trigger messages. The ACK_Desired flag MAY be set >> in refresh >> messages. Issues relate to multicast sessions are covered >> in a later >> section. >> >> However, I guess that we simply could use our underlying reliable >> GIST transport to avoid that. >> >>> - bundled messages: currently we don't have (?). >> IIRC signaling message bundling is supported by SCTP. >> If you want that, you probably want to use GIST with SCTP. >> This is, however, a little bit different from bundling within >> QoS NSLP, >> because we still have the overhead of multiple GIST and QoS NSLP >> headers. >> >>>>> D. making removal messages be reliable (which could be useful, as >>>>> concluded by [1]) >>>>> >>>>> "Reliable" above means whether one needs an explict >> Response to be sent >>>>> from the recipient upon receipt of the corresponding >>>>> trigger/refresh/removal. >>>> >>>> Ok, but who is "the recipient"? In case of the RESPONSE >> from the far >>>> end it's usually the QNR, in case of the ACK it's the next >> QNE, maybe >>>> for different purposes. >>> - Per-hop ACK is probably necessary, when the reliable GIST >> transport is >>> used. >> ??? do you mean _un_reliable ?? >> >>> - Response from the far end should be always good to have, >> in order to >>> have a reasonable reliability in QoS NSLP level. >> And feedback about the actually reserved resources, etc. >> >>>> Consider the action that should be taken on a missing ACK: >>>> in case of unreliable transport you probably can recover a >>>> packet loss by simply retransmitting the request again; >> but in case you >>>> are already using reliable transport, you may indicate a failure >>>> after some timeout. >>> Yes I agree we probably need to let the reaction to a >> receiving ACK to >>> depend on used GIST property. >>> >>>> >>>>> My view is that unreliable transmission would suffice B; >> for A and C >>>>> reliability SHOULD/MUST be made; for D reliability MAY be made. >>>> >>>> Just wanted to note that a RESPONSE may also be lost >>>> in case of unreliable transport, and, as already said: >>>> I guess that reliable transport is more the task of GIST >>>> than of QoS NSLP. >>> Maybe QoS NSLP could have its own "reliability" by allowing >> QNI/R to be >>> more consistent with their own engines. >> Hmm, therefore I would propose to add that ACK flag, >> but let the corresponding reaction up to the QoS model/application. >> >>>>> Relying >>>>> on the existence of RII to determine whether to give a response is >>>>> probably not a typical behavior from my personal limited >> understanding >>>>> of other protocols. >>>> >>>> You are right. I would prefer to always get a RESPONSE >> (from the QNR >>>> or far end). >>> We are inline with each other here. :) >> Regards, >> Roland >> >>>> The ACK mechanism is a different thing, because it is only >> triggering >>>> a response from the direct peer. It would help a lot if we could >>>> actually write down the requirements. From the past discussions I >>>> have the impression that people want to achieve totally >> different things >>>> with the defined retransmission mechanisms. Thus it would >> be good to >>>> clearly describe the problem(s) we want to solve. Short summary: >>>> Ruediger: wants liveliness check >>>> Georgious: wants some confirmation (for what purpose?) >>>> Jukka: wants to recover loss(?) in case of unreliable >>>> transport (wants to avoid using TCP for mobile nodes...) >>>> >>>> >>>>> [1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison >> of Hard-State >>>>> and Soft-State Signaling Protocols, SIGCOMM 2003. >>>>> [2] P. Pan and H. Schulzrine, Staged Refresh Timers for >> RSVP, Global >>>>> Internet 1997. >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 00:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYyd-00010i-Th; Tue, 21 Mar 2006 00:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYyd-00010d-8z for nsis@ietf.org; Tue, 21 Mar 2006 00:00:15 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLYya-0005BT-LP for nsis@ietf.org; Tue, 21 Mar 2006 00:00:15 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2L501ti030504 for ; Tue, 21 Mar 2006 05:00:01 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 05:00:00 +0000 From: "Robert Hancock" To: "'nsis'" Date: Mon, 20 Mar 2006 22:59:58 -0600 Message-ID: <000201c64ca4$4e8f9ce0$f87060cc@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 21 Mar 2006 05:00:00.0982 (UTC) FILETIME=[4EF75F60:01C64CA4] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [NSIS] Some further comments on the QoS-NSLP 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 Hi all, I have some further slightly post-WGLC comments on the QoS-NSLP draft. = 95% of them are about editorial/clarification/structure issues, which I'll = pass on directly to the authors. Listed below are the points which may have = more generally interesting technical content. Cheers, robert h. Section 3.2.6: I believe that all the protocol machinery for local = receiver initiated reservations is in fact already available for scenarios (topologies) where it is possible in the first place: just send a = RESERVE in the upstream direction and rely on GIST using the (optional) upstream GIST-Query encapsulation to route it. In general it would be good to = reduce the use of upstream/downstream terminology in the draft (except where it really matters) and refer more to the initiator/responder distinction. Section 4.3 foot of p23: I believe this has been discussed before, but = the maintenance of reverse path state is not a QoS-NSLP responsibility, it = is a GIST responsibility. This doesn't stop the QoS-NSLP generating QUERY messages, but GIST will manage its own routing state refresh timer autonomously from them. Section 4.7 end: in the receiver initiated case, how is the propagation = of the end-to-end reserve made dependent on the success of the interior reserve? (The interior reserve goes back to the egress but the = end-to-end reserve is waiting at the ingress before proceeding.) Section 5.1.3.4: I think here (and elsewhere) it would helpful to be = more explicit about the 'direction' of the binding dependencies. For example, = for dependency 0x04, does it mean that the session dies if the bound session dies, or vice versa? Section 7.1 figure 19: the adjacency check, SII handle, IP-Distance and = GHC will all be set to non-trivial values (by a proper GIST implementation). Section 7.6: The MessageDeliveryError is actually signalled by the MessageStatus api primitive. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 12:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkVR-0006fm-8X; Tue, 21 Mar 2006 12:18:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkVP-0006f7-Sw for nsis@ietf.org; Tue, 21 Mar 2006 12:18:51 -0500 Received: from natsluvver.rzone.de ([81.169.145.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkVO-0000G2-H0 for nsis@ietf.org; Tue, 21 Mar 2006 12:18:51 -0500 Received: from [192.168.178.200] (p5484A948.dip0.t-ipconnect.de [84.132.169.72]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k2LHISNn017869; Tue, 21 Mar 2006 18:18:28 +0100 (MET) Message-ID: <44203502.40902@cs.uni-goettingen.de> Date: Tue, 21 Mar 2006 18:16:50 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nsis@ietf.org Subject: [NSIS] QoS NSLP receiver initiated reservation 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, in paragraph 4.3 the draft says "This QUERY message does not need to trigger a RESPONSE message and therefore, the QNI must not include the RII object (Section 5.4.2), into the QUERY message." The QUERY is send from QNR to QNI. Isn't it the QNR who must not include the RII object? What is the meaning of 'must not' here? It is not allowed? I'm a bit confused by this sentence under the figure 5: "The QUERY message is transported by GIST to the next downstream QoS NSLP node." In a sender-initiated reservation downstream is from sender(QNI) to receiver(QNR). Is in a receiver initiated reservation downstream from sender(QNR) to receiver(QNI)? And at the end of paragraph 5.4.2 the draft says "Note that QUERY messages with the R-bit set should always be answered by the QNR." Isn't it the QNI who should answer the QUERY messages? Thanks, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 12:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkkm-000164-EN; Tue, 21 Mar 2006 12:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkkk-00015u-G9 for nsis@ietf.org; Tue, 21 Mar 2006 12:34:42 -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 1FLkkj-0000lD-6I for nsis@ietf.org; Tue, 21 Mar 2006 12:34:42 -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; Tue, 21 Mar 2006 19:34:40 +0200 id 00070132.44203930.00006784 Date: Tue, 21 Mar 2006 19:34:40 +0200 (EET) From: Jukka MJ Manner To: Bernd Schloer In-Reply-To: <44203502.40902@cs.uni-goettingen.de> Message-ID: References: <44203502.40902@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nsis@ietf.org Subject: [NSIS] Re: QoS NSLP receiver initiated reservation 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, it seems we have the Is and Rs mixed up pretty nicely...:) On Tue, 21 Mar 2006, Bernd Schloer wrote: > Hi Jukka, > > in paragraph 4.3 the draft says > > "This QUERY message does not need to trigger a RESPONSE message and therefore, > the QNI must not include the RII object (Section 5.4.2), into the QUERY > message." > > The QUERY is send from QNR to QNI. Isn't it the QNR who must not include the > RII object? What is the meaning of 'must not' here? It is not allowed? The QNR sends the QUERY. If it wants to use the QUERY to initiate a RESERVE from the QNI (a receiver initiated reservation), then it uses the R-bit, and does not need to use RII. A MUST NOT is used, since the RII is not needed, and thus could confuse the receiver QNI. > > I'm a bit confused by this sentence under the figure 5: "The QUERY message is > transported by GIST to the next downstream QoS NSLP node." In a > sender-initiated reservation downstream is from sender(QNI) to receiver(QNR). > Is in a receiver initiated reservation downstream from sender(QNR) to > receiver(QNI)? This is a bit tricky... As I see it, if you want to query for resources before sending a RESERVE yourself, you send the QUERY to the downstream QNE. Yet, if you are actually signaling for a receiver initiated reservation, then you are sending the message to your future upstream node... Rob already commented about these ups and downs being a bit wierd. I'll see to those. > > And at the end of paragraph 5.4.2 the draft says "Note that QUERY messages > with the R-bit set should always be answered by the QNR." Isn't it the QNI who > should answer the QUERY messages? Yes, the QNI answers R-bit messages. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 13:02:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlBq-0001uA-3E; Tue, 21 Mar 2006 13:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlBo-0001tO-D9 for nsis@ietf.org; Tue, 21 Mar 2006 13:02:40 -0500 Received: from natfrord.rzone.de ([81.169.145.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlBm-00025f-W5 for nsis@ietf.org; Tue, 21 Mar 2006 13:02:40 -0500 Received: from [192.168.178.200] (p5484A948.dip0.t-ipconnect.de [84.132.169.72]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k2LI2Z1o022005; Tue, 21 Mar 2006 19:02:36 +0100 (MET) Message-ID: <44203F59.6060704@cs.uni-goettingen.de> Date: Tue, 21 Mar 2006 19:00:57 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner References: <44203502.40902@cs.uni-goettingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: nsis@ietf.org Subject: [NSIS] Re: QoS NSLP receiver initiated reservation 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, > QNE. Yet, if you are actually signaling for a receiver initiated > reservation, then you are sending the message to your future upstream > node... Does message here mean QUERY? But that would be the opposite meaning. That was also my understanding that the QUERY is sent from the sender(QNR) to the receiver(QNI) upstream. I guess here is no wrong or right. It's just a matter of the perspective. Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 15:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnoI-0006n5-Ul; Tue, 21 Mar 2006 15:50:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnnp-0005ji-0i; Tue, 21 Mar 2006 15:50:05 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnno-0008Hq-UY; Tue, 21 Mar 2006 15:50:04 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLnnm-0003Ik-Ts; Tue, 21 Mar 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2LKo20e018633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FLnnm-0006KL-En; Tue, 21 Mar 2006 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: Tue, 21 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-10.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-10.txt Pages : 101 Date : 2006-3-21 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-10.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-10.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-10.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: <2006-3-21132712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-21132712.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 21 17:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSv-0000BO-FI; Tue, 21 Mar 2006 17:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSu-0000BG-P5; Tue, 21 Mar 2006 17:36:36 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpSt-0007hk-5w; Tue, 21 Mar 2006 17:36:36 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2LMaRti007307; Tue, 21 Mar 2006 22:36:27 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 22:36:27 +0000 From: "Robert Hancock" To: Date: Tue, 21 Mar 2006 16:36:25 -0600 Message-ID: <001501c64d37$e3d190e0$73848182@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 21 Mar 2006 22:36:27.0692 (UTC) FILETIME=[E463BEC0:01C64D37] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'nsis' Subject: [NSIS] RE: NSIS, Diameter & QoS 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 answer the question the other way round, I am interested in AAA support for QoS authorisation. authorisation for differential access to resources is a key part of the QoS story, and to me it is a major deployment simplification if that authorisation can be built as an extension to existing AAA infrastructures. in other words, if QoS and AAA make sense individually, it makes sense to define their interaction. i have cycles and can provide input (proof: i have already done so). r. > In advance of the meeting, I'd like to put out a call - who is > interested > in QoS support in Diameter (not just this document, but in general)? > Would anyone have cycles to review this and give input? > thanks, > John >-----Original Message----- >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig at siemens.com] >Sent: 02 March, 2006 11:33 >To: dime at ietf.org >Subject: [Dime] Diameter QoS Application > >Hi all, > >we have resubmitted our Diameter QoS application draft to the >DIME working group. > >Here is the new draft version: Diameter Quality of Service Application > >Abstract > > This document describes a Diameter application that performs > Authentication, Authorization, and Accounting for Quality of Service > (QoS) reservations. This protocol is used by elements >along the path > of a given application flow to authenticate a reservation request, > ensure that the reservation is authorized, and to account for > resources consumed during the lifetime of the application flow. > Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. > >http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter >-qos-00.t >xt > >This version of the draft is based on >draft-alfano-aaa-qosprot-05.txt and contains feedback we >received by John, Robert Hancock and Jerry Ash. >The issue tracker of this document can be found at: >http://www.tschofenig.priv.at:8080/diameter-qos/index > >Ciao >Hannes > >_______________________________________________ >DiME mailing list >DiME at ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME at ietf.org https://www1.ietf.org/mailman/listinfo/dime * References: _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 17:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpW9-0001Vs-Jy; Tue, 21 Mar 2006 17:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpW8-0001Vi-4S for nsis@ietf.org; Tue, 21 Mar 2006 17:39:56 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpW5-0007ne-Lc for nsis@ietf.org; Tue, 21 Mar 2006 17:39:56 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LMdq9a028935 for ; Wed, 22 Mar 2006 00:39:52 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 00:38:57 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 00:38:57 +0200 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, 22 Mar 2006 00:38:56 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0A9@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 Thread-Index: AcZNNtzAPKx2fCWSSPejOfcXnhSuYgAATWHg From: To: X-OriginalArrivalTime: 21 Mar 2006 22:38:57.0590 (UTC) FILETIME=[3DBC5D60:01C64D38] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [NSIS] FW: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 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 For those of you in Dallas, you might be interested to head to the bar for this bar bof. This is overlapping with some of our NSIS QoS work, so it would be great for interested parties to participate. John =3D=3D=3D=3D=3D All, For a couple of TSVWG meetings, we've had two documents on the on the agenda: draft-briscoe-tsvwg-cl-architecture draft-briscoe-tsvwg-cl-phb These have raised little discussion of their content, but there has been discussion of the place of the work in the working group and the relation to work taking place in the NSIS working group under the name RMD (resource management in diffserv): draft-ietf-nsis-rmd-06.txt The authors of that work also published a document with an NSIS basis for this discussion that is very very new to the list: draft-karagiannis-ru-pdb-01.txt We've decided (Old and New Chairs) to offer an opportunity for an Ad Hoc BoF (sort of like a Bar Bof from RFC 3160, but lacking in drinks) to let folks get at some of the cross-cutting questions about how this work fits together and help TSVWGers with later thinking. This will be only one hour, very informal and it belongs to the Bar BoFers. It's a Bar BoF - not Our BoF (IETF). There are no commitments about its outcome, not results for the documents. The only IETF formality for these things is that the Note Well applies to the discussion. The agenda will be described by the discussants. James (formerly known as the "Experiment") will be the TimeKeeper. I will suggest that this avoid tutorials and try for up-leveling as much as possible. This will give more likelihood of group discussion and illumination. *** Time: Wednesday (tomorrow), Afternoon II, 15:10-16:10 *** Place: Coronado BCD Allison (TSVWG Chair Emerita) and James, for your TSVWG Chairs _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg=09 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 17:42:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpYW-0004Ce-Us; Tue, 21 Mar 2006 17:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpYV-0004CJ-9e; Tue, 21 Mar 2006 17:42:23 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpYU-0007sQ-KV; Tue, 21 Mar 2006 17:42:23 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k2LMgL9S029592; Tue, 21 Mar 2006 23:42:21 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k2LMgLTD012406; Tue, 21 Mar 2006 23:42:21 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 23:42:21 +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] RE: NSIS, Diameter & QoS Date: Tue, 21 Mar 2006 23:42:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: NSIS, Diameter & QoS Thread-Index: AcZNN++8ufsCnpHFTOqCiVbuki7/CQAAInXg From: "Tschofenig, Hannes" To: "Robert Hancock" , X-OriginalArrivalTime: 21 Mar 2006 22:42:21.0338 (UTC) FILETIME=[B72DD7A0:01C64D38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Thank you Robert for your feedback.=20 For those who haven't followed the discussion on the Diameter QoS work: = Robert has provided a lot of feedback in the past. Some of his comments = are still subject for further discussion.=20 See http://www.tschofenig.priv.at:8080/diameter-qos/ Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 > Gesendet: Dienstag, 21. M=E4rz 2006 16:36 > An: dime@ietf.org > Cc: 'nsis' > Betreff: [NSIS] RE: NSIS, Diameter & QoS >=20 > hi, >=20 > to answer the question the other way round, I am interested in > AAA support for QoS authorisation. authorisation for differential > access to resources is a key part of the QoS story, and to me it > is a major deployment simplification if that authorisation can be > built as an extension to existing AAA infrastructures. >=20 > in other words, if QoS and AAA make sense individually, it makes > sense to define their interaction. >=20 > i have cycles and can provide input (proof: i have already done so). >=20 > r. >=20 >=20 > > In advance of the meeting, I'd like to put out a call - who is > > interested > > in QoS support in Diameter (not just this document, but in general)? >=20 > > Would anyone have cycles to review this and give input? >=20 > > thanks, > > John=20 >=20 > >-----Original Message----- > >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig at=20 > siemens.com]=20 > >Sent: 02 March, 2006 11:33 > >To: dime at ietf.org > >Subject: [Dime] Diameter QoS Application > > > >Hi all,=20 > > > >we have resubmitted our Diameter QoS application draft to the=20 > >DIME working group.=20 > > > >Here is the new draft version: Diameter Quality of Service=20 > Application > > > >Abstract > > > > This document describes a Diameter application that performs > > Authentication, Authorization, and Accounting for Quality=20 > of Service > > (QoS) reservations. This protocol is used by elements=20 > >along the path > > of a given application flow to authenticate a reservation request, > > ensure that the reservation is authorized, and to account for > > resources consumed during the lifetime of the application flow. > > Clients that implement the Diameter QoS application contact an > > authorizing entity/application server that is located somewhere in > > the network, allowing for a wide variety of flexible deployment > > models. > > > >http://www.tschofenig.priv.at/drafts/draft-tschofenig-dime-diameter > >-qos-00.t > >xt > > > >This version of the draft is based on=20 > >draft-alfano-aaa-qosprot-05.txt and contains feedback we=20 > >received by John, Robert Hancock and Jerry Ash. > >The issue tracker of this document can be found at: > >http://www.tschofenig.priv.at:8080/diameter-qos/index > > > >Ciao > >Hannes > > > >_______________________________________________ > >DiME mailing list > >DiME at ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME at ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 > * References: >=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 21 20:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrlj-00032E-MV; Tue, 21 Mar 2006 20:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrlh-000320-Dp; Tue, 21 Mar 2006 20:04:09 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrlg-0004nH-S1; Tue, 21 Mar 2006 20:04:09 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 01:04:08 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 01:04:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Mar 2006 00:59:47 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 Thread-Index: AcZNNtKpAilxd84XTwmmFU+QHP0t2QAFReJv From: To: , X-OriginalArrivalTime: 22 Mar 2006 01:04:07.0499 (UTC) FILETIME=[853F01B0:01C64D4C] X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: lars.eggert@netlab.nec.de, jmpolk@cisco.com, nsis@ietf.org Subject: [NSIS] RE: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 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 Here's the draft agenda for the Bar BOF. As Allison suggests, we hope = for feedback & discussion, rather than=20 =20 =20 ________________________________ From: Allison Mankin [mailto:mankin@psg.com] Sent: Tue 21/03/2006 22:27 To: tsvwg@ietf.org Cc: lars.eggert@netlab.nec.de; magnus.westerlund@ericsson.com; = jmpolk@cisco.com; mankin@psg.com Subject: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) = 15:10 All, For a couple of TSVWG meetings, we've had two documents on the on the agenda: draft-briscoe-tsvwg-cl-architecture draft-briscoe-tsvwg-cl-phb These have raised little discussion of their content, but there has been discussion of the place of the work in the working group and the relation to work taking place in the NSIS working group under the name RMD (resource management in diffserv): draft-ietf-nsis-rmd-06.txt The authors of that work also published a document with an NSIS basis for this discussion that is very very new to the list: draft-karagiannis-ru-pdb-01.txt We've decided (Old and New Chairs) to offer an opportunity for an Ad Hoc BoF (sort of like a Bar Bof from RFC 3160, but lacking in drinks) to let folks get at some of the cross-cutting questions about how this work fits together and help TSVWGers with later thinking. This will be only one hour, very informal and it belongs to the Bar BoFers. It's a Bar BoF - not Our BoF (IETF). There are no commitments about its outcome, not results for the documents. The only IETF formality for these things is that the Note Well applies to the discussion. The agenda will be described by the discussants. James (formerly known as the "Experiment") will be the TimeKeeper. I will suggest that this avoid tutorials and try for up-leveling as much as possible. This will give more likelihood of group discussion and illumination. *** Time: Wednesday (tomorrow), Afternoon II, 15:10-16:10 *** Place: Coronado BCD Allison (TSVWG Chair Emerita) and James, for your TSVWG Chairs _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 21 20:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLru4-0001LJ-SA; Tue, 21 Mar 2006 20:12:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLru3-0001KC-Fo; Tue, 21 Mar 2006 20:12:47 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLru3-0004w0-2R; Tue, 21 Mar 2006 20:12:47 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 01:12:46 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 01:12:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Mar 2006 01:12:44 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 Thread-Index: AcZNNtKpAilxd84XTwmmFU+QHP0t2QAFReJvAAArOq0= From: To: , , X-OriginalArrivalTime: 22 Mar 2006 01:12:45.0908 (UTC) FILETIME=[BA3DF140:01C64D4D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lars.eggert@netlab.nec.de, jmpolk@cisco.com, nsis@ietf.org Subject: [NSIS] RE: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 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 Here's the draft agenda for the Bar BOF. As Allison suggests, we hope = for feedback & discussion, rather than just us talking at you! =20 1. The general approach - 15 mins (5 mins slides, 10 mins discussion) - Purpose: identify key concerns, get prioritisation of work (which = deployment models to concentrate on earlier) 2. Encoding - 20 mins (10 mins slides, 10 mins discussion) - Purpose: start getting community input on the possibilities 3. Proof of concept / simulations - 15 mins (15 mins slides, discussion = after session for those interested) - Purpose: show "it works"=20 4. Standardisation approach - 10 mins (2 min slide, 8 mins discussion) - Purpose: feedback on proposed document structure =20 best wishes, philip eardley ________________________________ From: Allison Mankin [mailto:mankin@psg.com] Sent: Tue 21/03/2006 22:27 To: tsvwg@ietf.org Cc: lars.eggert@netlab.nec.de; magnus.westerlund@ericsson.com; = jmpolk@cisco.com; mankin@psg.com Subject: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) = 15:10 All, For a couple of TSVWG meetings, we've had two documents on the on the agenda: draft-briscoe-tsvwg-cl-architecture draft-briscoe-tsvwg-cl-phb These have raised little discussion of their content, but there has been discussion of the place of the work in the working group and the relation to work taking place in the NSIS working group under the name RMD (resource management in diffserv): draft-ietf-nsis-rmd-06.txt The authors of that work also published a document with an NSIS basis for this discussion that is very very new to the list: draft-karagiannis-ru-pdb-01.txt We've decided (Old and New Chairs) to offer an opportunity for an Ad Hoc BoF (sort of like a Bar Bof from RFC 3160, but lacking in drinks) to let folks get at some of the cross-cutting questions about how this work fits together and help TSVWGers with later thinking. This will be only one hour, very informal and it belongs to the Bar BoFers. It's a Bar BoF - not Our BoF (IETF). There are no commitments about its outcome, not results for the documents. The only IETF formality for these things is that the Note Well applies to the discussion. The agenda will be described by the discussants. James (formerly known as the "Experiment") will be the TimeKeeper. I will suggest that this avoid tutorials and try for up-leveling as much as possible. This will give more likelihood of group discussion and illumination. *** Time: Wednesday (tomorrow), Afternoon II, 15:10-16:10 *** Place: Coronado BCD Allison (TSVWG Chair Emerita) and James, for your TSVWG Chairs _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 03:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLyaF-0000hb-Si; Wed, 22 Mar 2006 03:20:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLyaF-0000dC-0r for nsis@ietf.org; Wed, 22 Mar 2006 03:20:47 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLyaD-0004U6-IU for nsis@ietf.org; Wed, 22 Mar 2006 03:20:46 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 22 Mar 2006 09:20:44 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Mar 2006 09:20:43 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED20E629C@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: bschloer@cs.uni-goettingen.de Subject: RE: [NSIS] Re: QoS NSLP receiver initiated reservation Date: Wed, 22 Mar 2006 09:20:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Hallo Bernd, RFC2205 defines: - The PATH message is sent downstream by the sender - The RESERVE message is sent upstream by the receiver Does NSIS change that? Regards, R=FCdiger |> QNE. Yet, if you are actually signaling for a receiver initiated=20 |> reservation, then you are sending the message to your future=20 |> upstream node... | |Does message here mean QUERY? But that would be the opposite=20 |meaning. That was also my understanding that the QUERY is sent=20 |from the sender(QNR) to the receiver(QNI) upstream. I guess=20 |here is no wrong or right. It's just a matter of the perspective. | |Bernd | |_______________________________________________ |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 22 10:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5W4-0002NT-JY; Wed, 22 Mar 2006 10:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5W3-0002LK-2H for nsis@ietf.org; Wed, 22 Mar 2006 10:44:55 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM5W1-0004KX-PX for nsis@ietf.org; Wed, 22 Mar 2006 10:44:55 -0500 Received: (qmail invoked by alias); 22 Mar 2006 15:44:52 -0000 Received: from DHCP-Wireless-129-200.ietf65.org (EHLO [130.129.129.200]) [130.129.129.200] by mail.gmx.net (mp038) with SMTP; 22 Mar 2006 16:44:52 +0100 X-Authenticated: #29516787 Message-ID: <442170F9.7020506@gmx.net> Date: Wed, 22 Mar 2006 09:44:57 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [NSIS] Slides - Please 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 us your slides. We will make them avaiable at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 11:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Ef-0006rV-Ii; Wed, 22 Mar 2006 11:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Ee-0006rK-9e for nsis@ietf.org; Wed, 22 Mar 2006 11:31:00 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6Ec-0006gq-Kl for nsis@ietf.org; Wed, 22 Mar 2006 11:31:00 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2MGUiti027838; Wed, 22 Mar 2006 16:30:44 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 16:30:43 +0000 From: "Robert Hancock" To: "'Roland Bless'" Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Wed, 22 Mar 2006 10:30:40 -0600 Message-ID: <00d601c64dcd$f635e740$f87060cc@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <441F156A.7060109@tm.uka.de> Importance: Normal X-OriginalArrivalTime: 22 Mar 2006 16:30:44.0068 (UTC) FILETIME=[F7623240:01C64DCD] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Xiaoming Fu' , '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, one clarification: > > the slew handling algorithms are only there to handle lost messages. > > you could simply say 'if you want to use unreliable transport you=20 > > must keep the refresh period fixed for a given period', which would > > simplify this section quite considerably. >=20 > I'm not quite sure that I get your point. the problem with slew and unreliable transport is that if you send a = message with an extended refresh period which is lost then - the sender increases the time between refresh messages (according to = the new period) - the receiver still expects more rapid refresh messages (according to = the old period) - the receiver is likely to drop the session (according to the "three dropped messages and you're out" rule) there are two solutions here (apart from the slew handling algorithms): - make sure the refresh gets delivered - don't change the refresh period r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 11:44:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6RO-0006wO-3L; Wed, 22 Mar 2006 11:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6RM-0006wB-Ty for nsis@ietf.org; Wed, 22 Mar 2006 11:44:08 -0500 Received: from web30508.mail.mud.yahoo.com ([68.142.200.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM6RM-0007OH-Ct for nsis@ietf.org; Wed, 22 Mar 2006 11:44:08 -0500 Received: (qmail 36691 invoked by uid 60001); 22 Mar 2006 16:43:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.sg; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xmg4wh6qCj2p2OL34q6xKKhXq7+erPJ5PJ4aP8z0K4xJONeKgvea3qmAN6rbr62JTqUBu2O9WH+i0Isn/2U1P5TdkGsxNnXg1oAJtEbsDKAw2p6DMtLGrchaAzPgUk2nl+p7TjXgsf0eaq31mc4J50MJgk2SBVFkmFfFlXp/NQs= ; Message-ID: <20060322164352.36689.qmail@web30508.mail.mud.yahoo.com> Received: from [130.129.130.145] by web30508.mail.mud.yahoo.com via HTTP; Thu, 23 Mar 2006 00:43:51 CST Date: Thu, 23 Mar 2006 00:43:51 +0800 (CST) From: Shivanajay Marwaha Subject: Re: [NSIS] RE: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 To: philip.eardley@bt.com, mankin@psg.com In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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: , Content-Type: multipart/mixed; boundary="===============0078929781==" Errors-To: nsis-bounces@ietf.org --===============0078929781== Content-Type: multipart/alternative; boundary="0-1558278645-1143045831=:36606" Content-Transfer-Encoding: 8bit --0-1558278645-1143045831=:36606 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Philip and Allison, Are the slides available somewhere for this session today afternoon? Thanks, Shivanajay philip.eardley@bt.com wrote: Here's the draft agenda for the Bar BOF. As Allison suggests, we hope for feedback & discussion, rather than just us talking at you! 1. The general approach - 15 mins (5 mins slides, 10 mins discussion) - Purpose: identify key concerns, get prioritisation of work (which deployment models to concentrate on earlier) 2. Encoding - 20 mins (10 mins slides, 10 mins discussion) - Purpose: start getting community input on the possibilities 3. Proof of concept / simulations - 15 mins (15 mins slides, discussion after session for those interested) - Purpose: show "it works" 4. Standardisation approach - 10 mins (2 min slide, 8 mins discussion) - Purpose: feedback on proposed document structure best wishes, philip eardley ________________________________ From: Allison Mankin [mailto:mankin@psg.com] Sent: Tue 21/03/2006 22:27 To: tsvwg@ietf.org Cc: lars.eggert@netlab.nec.de; magnus.westerlund@ericsson.com; jmpolk@cisco.com; mankin@psg.com Subject: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 All, For a couple of TSVWG meetings, we've had two documents on the on the agenda: draft-briscoe-tsvwg-cl-architecture draft-briscoe-tsvwg-cl-phb These have raised little discussion of their content, but there has been discussion of the place of the work in the working group and the relation to work taking place in the NSIS working group under the name RMD (resource management in diffserv): draft-ietf-nsis-rmd-06.txt The authors of that work also published a document with an NSIS basis for this discussion that is very very new to the list: draft-karagiannis-ru-pdb-01.txt We've decided (Old and New Chairs) to offer an opportunity for an Ad Hoc BoF (sort of like a Bar Bof from RFC 3160, but lacking in drinks) to let folks get at some of the cross-cutting questions about how this work fits together and help TSVWGers with later thinking. This will be only one hour, very informal and it belongs to the Bar BoFers. It's a Bar BoF - not Our BoF (IETF). There are no commitments about its outcome, not results for the documents. The only IETF formality for these things is that the Note Well applies to the discussion. The agenda will be described by the discussants. James (formerly known as the "Experiment") will be the TimeKeeper. I will suggest that this avoid tutorials and try for up-leveling as much as possible. This will give more likelihood of group discussion and illumination. *** Time: Wednesday (tomorrow), Afternoon II, 15:10-16:10 *** Place: Coronado BCD Allison (TSVWG Chair Emerita) and James, for your TSVWG Chairs _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 1GB free storage! --0-1558278645-1143045831=:36606 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear Philip and Allison,
 
Are the slides available somewhere for this session today afternoon?

Thanks,
Shivanajay

philip.eardley@bt.com wrote:
Here's the draft agenda for the Bar BOF. As Allison suggests, we hope for feedback & discussion, rather than just us talking at you!

1. The general approach - 15 mins (5 mins slides, 10 mins discussion)

- Purpose: identify key concerns, get prioritisation of work (which deployment models to concentrate on earlier)

2. Encoding - 20 mins (10 mins slides, 10 mins discussion)

- Purpose: start getting community input on the possibilities

3. Proof of concept / simulations - 15 mins (15 mins slides, discussion after session for those interested)

- Purpose: show "it works"

4. Standardisation approach - 10 mins (2 min slide, 8 mins discussion)

- Purpose: feedback on proposed document structure


best wishes,
philip eardley

________________________________

From: Allison Mankin [mailto:mankin@psg.com]
Sent: Tue 21/03/2006 22:27
To: tsvwg@ietf.org
Cc: lars.eggert@netlab.nec.de; magnus.westerlund@ericsson.com; jmpolk@cisco.com; mankin@psg.com
Subject: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10



All,

For a couple of TSVWG meetings, we've had two documents on the
on the agenda:
draft-briscoe-tsvwg-cl-architecture
draft-briscoe-tsvwg-cl-phb
These have raised little discussion of their content, but
there has been discussion of the place of the work in the
working group and the relation to work taking place in the
NSIS working group under the name RMD (resource management
in diffserv):
draft-ietf-nsis-rmd-06.txt
The authors of that work also published a document with an
NSIS basis for this discussion that is very very new to the
list:
draft-karagiannis-ru-pdb-01.txt

We've decided (Old and New Chairs) to offer an opportunity for an
Ad Hoc BoF (sort of like a Bar Bof from RFC 3160, but lacking in drinks)
to let folks get at some of the cross-cutting questions about how this
work fits together and help TSVWGers with later thinking.

This will be only one hour, very informal and it belongs to the
Bar BoFers. It's a Bar BoF - not Our BoF (IETF). There are no
commitments about its outcome, not results for the documents.
The only IETF formality for these things is that the Note Well
applies to the discussion.

The agenda will be described by the discussants. James (formerly
known as the "Experiment") will be the TimeKeeper.

I will suggest that this avoid tutorials and try for up-leveling
as much as possible. This will give more likelihood of group
discussion and illumination.

*** Time: Wednesday (tomorrow), Afternoon II, 15:10-16:10

*** Place: Coronado BCD

Allison (TSVWG Chair Emerita) and James, for your TSVWG Chairs




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



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


Do you Yahoo!?
New and Improved Yahoo! Mail - 1GB free storage! --0-1558278645-1143045831=:36606-- --===============0078929781== 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 --===============0078929781==-- From nsis-bounces@ietf.org Wed Mar 22 11:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6e8-0000W3-Ah; Wed, 22 Mar 2006 11:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6e7-0000T0-7t for nsis@ietf.org; Wed, 22 Mar 2006 11:57:19 -0500 Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6e3-00082S-RO for nsis@ietf.org; Wed, 22 Mar 2006 11:57:19 -0500 Received: from [192.168.178.200] (p5484BE1F.dip0.t-ipconnect.de [84.132.190.31]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k2MGvDZc019060; Wed, 22 Mar 2006 17:57:14 +0100 (MET) Message-ID: <44218185.3020708@cs.uni-goettingen.de> Date: Wed, 22 Mar 2006 17:55:33 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [NSIS] Re: QoS NSLP receiver initiated reservation References: <6439282641581441A36F7F6F83ED2ED20E629C@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E629C@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Hello R=FCdiger, > RFC2205 defines: > - The PATH message is sent downstream by the sender > - The RESERVE message is sent upstream by the receiver >=20 > Does NSIS change that? no, NSIS does not change that. I was wrong. The QNR which is the receiver of the reservation for a session and the se= nder of=20 the data flow sends a QUERY message downstream to the QNI which is the re= ceiver=20 of the data flow and the initiator of the reservation. The RESERVE messag= e is=20 sent upstream towards the QNR which confirms the reservation request with= a=20 downstream RESPONSE message. Is that correct now? Thanks, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 13:29:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM85j-0006vl-47; Wed, 22 Mar 2006 13:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM85h-0006vf-FQ for nsis@ietf.org; Wed, 22 Mar 2006 13:29:53 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM85g-0003sQ-23 for nsis@ietf.org; Wed, 22 Mar 2006 13:29:53 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FM85b-0004Ca-Sf; Wed, 22 Mar 2006 19:29: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 BA6E1BF4F; Wed, 22 Mar 2006 19:29:47 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FM85b-000158-CW; Wed, 22 Mar 2006 19:29:47 +0100 Message-ID: <4421976D.3070305@tm.uka.de> Date: Wed, 22 Mar 2006 19:29:01 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <00d601c64dcd$f635e740$f87060cc@comm.ad.roke.co.uk> In-Reply-To: <00d601c64dcd$f635e740$f87060cc@comm.ad.roke.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Robert Hancock schrieb: > hi roland, > > one clarification: > >>> the slew handling algorithms are only there to handle lost messages. >>> you could simply say 'if you want to use unreliable transport you >>> must keep the refresh period fixed for a given period', which would >>> simplify this section quite considerably. >> I'm not quite sure that I get your point. > > the problem with slew and unreliable transport is that if you send a message > with an extended refresh period which is lost then > - the sender increases the time between refresh messages (according to the > new period) > - the receiver still expects more rapid refresh messages (according to the > old period) > - the receiver is likely to drop the session (according to the "three > dropped messages and you're out" rule) > > there are two solutions here (apart from the slew handling algorithms): > - make sure the refresh gets delivered > - don't change the refresh period You're right. I guess we got it wrong, because the problem we were trying to solve wasn't quite clear. Mixing up retransmissions for reliability with state installation confirmation seems to be a bad idea. So I'm still not quite sure what is required. However, I could think of something like a "provisional" response if people want to get sure that their message was received. In this case the application may ask for this response which is sent as soon as the message was received by the other peer (so no confirmation of state installation and no advanced NSLP processing). This may induce a security problem, because then even unauthorized requests may generate a response. Further reactions like retransmission should depend on the application. Nevertheless, I guess it's not useful to discuss solutions for not exactly specified problems and we need to discuss first the general reliable transmission aspects. I have no problem to use the normal reliable GIST transport, however, other people seem to like the idea of using an unreliable protocol like UDP and then adding a simple retransmission mechanism above (like in SIP over UDP). I'm not sure that this is covered by the design decisions for NTLP/NSLP we made once. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 16:17:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAhQ-0001ok-FQ; Wed, 22 Mar 2006 16:17:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAhO-0001mF-F9 for nsis@ietf.org; Wed, 22 Mar 2006 16:16:58 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAhM-0003GP-N3 for nsis@ietf.org; Wed, 22 Mar 2006 16:16:58 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 21:16:55 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 21:16:55 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1143062214876; Wed, 22 Mar 2006 21:16:54 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.4]) by bagheera.jungle.bt.co.uk (8.13.5/8.13.5) with ESMTP id k2MLGmuG004946; Wed, 22 Mar 2006 21:16:52 GMT Message-Id: <5.2.1.1.2.20060322211100.028d74a0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 22 Mar 2006 21:15:57 +0000 To: Shivanajay Marwaha , tsvwg , nsis@ietf.org From: Bob Briscoe Subject: Re: [NSIS] RE: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 In-Reply-To: <20060322164352.36689.qmail@web30508.mail.mud.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Mar 2006 21:16:55.0766 (UTC) FILETIME=[F2835F60:01C64DF5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: mankin@psg.com 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 Shivanajay, Slides are at: But, it is mostly about discussion, these are just to get discussion going. Cheers Bob At 16:43 22/03/2006, Shivanajay Marwaha wrote: >Dear Philip and Allison, > >Are the slides available somewhere for this session today afternoon? > >Thanks, >Shivanajay > >philip.eardley@bt.com wrote: >Here's the draft agenda for the Bar BOF. As Allison suggests, we hope for >feedback & discussion, rather than just us talking at you! > >1. The general approach - 15 mins (5 mins slides, 10 mins discussion) > >- Purpose: identify key concerns, get prioritisation of work (which >deployment models to concentrate on earlier) > >2. Encoding - 20 mins (10 mins slides, 10 mins discussion) > >- Purpose: start getting community input on the possibilities > >3. Proof of concept / simulations - 15 mins (15 mins slides, discussion >after session for those interested) > >- Purpose: show "it works" > >4. Standardisation approach - 10 mins (2 min slide, 8 mins discussion) > >- Purpose: feedback on proposed document structure > > >best wishes, >philip eardley > >________________________________ > >From: Allison Mankin [mailto:mankin@psg.com] >Sent: Tue 21/03/2006 22:27 >To: tsvwg@ietf.org >Cc: lars.eggert@netlab.nec.de; magnus.westerlund@ericsson.com; >jmpolk@cisco.com; mankin@psg.com >Subject: [Tsvwg] A Bar BOF on CL and RMD Directions - Tomorrow (Weds) 15:10 > > > >All, > >For a couple of TSVWG meetings, we've had two documents on the >on the agenda: >draft-briscoe-tsvwg-cl-architecture >draft-briscoe-tsvwg-cl-phb >These have raised little discussion of their content, but >there has been discussion of the place of the work in the >working group and the relation to work taking place in the >NSIS working group under the name RMD (resource management >in diffserv): >draft-ietf-nsis-rmd-06.txt >The authors of that work also published a document with an >NSIS basis for this discussion that is very very new to the >list: >draft-karagiannis-ru-pdb-01.txt > >We've decided (Old and New Chairs) to offer an opportunity for an >Ad Hoc BoF (sort of like a Bar Bof from RFC 3160, but lacking in drinks) >to let folks get at some of the cross-cutting questions about how this >work fits together and help TSVWGers with later thinking. > >This will be only one hour, very informal and it belongs to the >Bar BoFers. It's a Bar BoF - not Our BoF (IETF). There are no >commitments about its outcome, not results for the documents. >The only IETF formality for these things is that the Note Well >applies to the discussion. > >The agenda will be described by the discussants. James (formerly >known as the "Experiment") will be the TimeKeeper. > >I will suggest that this avoid tutorials and try for up-leveling >as much as possible. This will give more likelihood of group >discussion and illumination. > >*** Time: Wednesday (tomorrow), Afternoon II, 15:10-16:10 > >*** Place: Coronado BCD > >Allison (TSVWG Chair Emerita) and James, for your TSVWG Chairs > > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > > >Do you Yahoo!? >New >and Improved Yahoo! Mail - 1GB free storage! >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 17:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBgj-0002XP-Be; Wed, 22 Mar 2006 17:20:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBgh-0002XH-Sf for nsis@ietf.org; Wed, 22 Mar 2006 17:20:19 -0500 Received: from natscum.rzone.de ([81.169.145.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMBgg-0005NN-H8 for nsis@ietf.org; Wed, 22 Mar 2006 17:20:19 -0500 Received: from [192.168.178.200] (p5484BE1F.dip0.t-ipconnect.de [84.132.190.31]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k2MMKGaW014497; Wed, 22 Mar 2006 23:20:16 +0100 (MET) Message-ID: <4421CD3B.1010701@cs.uni-goettingen.de> Date: Wed, 22 Mar 2006 23:18:35 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [NSIS] Re: QoS NSLP receiver initiated reservation References: <6439282641581441A36F7F6F83ED2ED20E629C@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E629C@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 R=FCdiger, > RFC2205 defines: > - The PATH message is sent downstream by the sender > - The RESERVE message is sent upstream by the receiver >=20 > Does NSIS change that? I would say that NSIS is here similar to RSVP and extends it by the sende= r=20 initiated reservation where the RESERVE message is sent downstream by the= sender. Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 19:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDzd-0003P3-TI; Wed, 22 Mar 2006 19:48:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDzc-0003Oy-R4 for nsis@ietf.org; Wed, 22 Mar 2006 19:48:00 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMDzb-00059G-H9 for nsis@ietf.org; Wed, 22 Mar 2006 19:48:00 -0500 Received: (qmail invoked by alias); 23 Mar 2006 00:47:57 -0000 Received: from DHCP-Wireless-129-200.ietf65.org (EHLO [130.129.129.200]) [130.129.129.200] by mail.gmx.net (mp036) with SMTP; 23 Mar 2006 01:47:57 +0100 X-Authenticated: #29516787 Message-ID: <4421F041.9090302@gmx.net> Date: Wed, 22 Mar 2006 18:48:01 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] Slides for the NSIS meeting 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 me your slides! I need to put them to the WG Proceedings webpage. If you cannot find your presentation at the following webpage https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 then send them to me again. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 20:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEpp-0002EM-5y; Wed, 22 Mar 2006 20:41:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEpo-0002EH-T8 for nsis@ietf.org; Wed, 22 Mar 2006 20:41:56 -0500 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEpo-00083W-Ec for nsis@ietf.org; Wed, 22 Mar 2006 20:41:56 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2N1ful9012324 for ; Wed, 22 Mar 2006 20:41:56 -0500 (EST) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k2N1frGS015900 for ; Wed, 22 Mar 2006 20:41:53 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Mar 2006 20:41:52 -0500 Message-ID: From: Black_David@emc.com To: nsis@ietf.org Date: Wed, 22 Mar 2006 20:41:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.03.22.171109 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Subject: [NSIS] RMD 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 These are intended to be WG Last Call comments on the RMD draft, but I held them back until this afternoon's bar-free Bar BoF was over with in the hopes of avoiding confusion/entanglement with that set of concerns. The resulting short notice prior to tomorrow's meeting is an unfortunate result. I have two major concerns, plus some less important comments. --- (1) RMD is subset of diffserv --- Overall, RMD is about use of a subset of diffserv, specifically EF or a class selector that has EF-like behavior. It does not support AF-like functionality where multiple PHBs/DSCPs are used to encode drop precedence for at least the following reasons: (a) contains only a Bandwidth element. It does not contain the two token buckets needed to signal AF in full generality (cf. the QSpec Template draft which does contain these two token buckets). (b) The PHB_Class parameter is not capable of signaling a PHB set, such as the various AF sets - see Section 2 of RFC 3140. A DSCP is ok to use here, as these messages should not be crossing diffserv domain boundaries. This "should not be crossing" needs to be stated as a "MUST NOT cross" restriction. (c) The severe congestion remarking algorithm destroys the drop precedence markings on AF traffic. There may be situations in which this is acceptable (e.g., the egress node will meter and remark drop precedence anyway), but it is not always the case. I recommend simply removing AF from this draft, and adding/ rewriting portions of the introduction and other material to make it clear that RMD is a diffserv-based bandwidth management methodology, including avoiding any claim or implication of full diffserv support. It would be possible to say that a single AF PHB with overprovisioning to deliver an EF-like behavior, but this would need to be carefully stated to avoid implying support for full AF drop precedence behavior. --- (2) Severe Congestion measurement/notification issues --- Sections 4.6.1.6 and 4.6.1.7 appear to be problematic. Section 4.6.1.6.2.1 recommends (SHOULD) that two DSCPs be allocated per traffic class, but only uses one of them (for proportional marking). That's wasteful, although it looks like the other one may be intended for probe-based congestion notification (Section 4.6.1.7). Section 4.6.1.6 should limit itself to one DSCP per traffic class for proportional congestion measurement, and leave threshold marking to 4.6.1.7. The following sentence on max number of DSCPs is problematic and misuses RFC 2119 terminology: It is RECOMMENDED that the total number of additional DSCPs within a RMD domain, needed for severe congestion handling MUST not exceed the limit of 16. The word "MUST" ought to be deleted to correct the RFC 2119 terminology issue. In addition, the limit of 16 is too high - that's 25% of a scarce resource, and implies that it's usually acceptable in general to use up to 25% of that space for this purpose, which is not a good idea in full generality. I would prefer a recommendation that as few as possible be used, and in particular that the number not exceed one per PHB. The algorithms in Section 4.6.1.6.2.1 and 4.6.1.6.2.2 appear to be incomplete in that they don't specify the range of bytes over which the algorithms are to operate - is this a moving window vs. a succession of fixed windows, and what are appropriate window sizes? For the latter, the window size may need to be much smaller than a typical flow duration in order to be able to make decisions faster than load conditions change. How should the sizes of the Interior and Egress node windows compare? At best, these algorithms are examples, and might be better qualified as such, as the marking framework is probably amenable to other algorithms. Section 4.6.1.7 appears to be somewhat confused - on the one hand, it describes the interior nodes as NSIS-unaware, but on the other hand is using an NSIS-specific threshold-based DSCP remarking scheme in those interior nodes. After this afternoon's session, it's fairly clear that the PCN work is digging in about the same place - using thresholds more aggressive than ordinary ECN to communicate interior congestion to the edges - it might be a *very* good idea to drop this section and refer to the appropriate CL/PCN drafts as work in progress. I'm not comfortable with these two sections and would prefer to see them removed, so that the resulting document is focused on the signaling aspects. Based on past interactions, I suspect that's not going to happen, and hence I would like to see these two sections moved to an appendix to clearly separate them from the NSIS signaling focus of the bulk of the draft. That appendix needs to state that for congestion management/signaling, no more than one additional DSCP per traffic PHB SHOULD be used, and also discuss the fact that DSCPs are a scarce resource. --- IANA Considerations --- The IANA considerations section is essentially missing - it does not tell IANA what is in the registry, what to do to establish the registry, or how to manage it. See the rfc2434bis draft. --- Nits --- p.11 and p.13 - encoding of Overload % is not stated - e.g., what percent level of overload does the value 0x10 represent? p.17 - The term "PHB group" shows up on this page without prior explanation or definition. It should not be used due to the lack of support for AF. p.17 - At the end of Section 4.3.3, the text should be clarified to make it clear that the multiple classes are for admission control (and possibly preemption?) only, as they share a single PHB (and hence forwarding treatment) within the network. p.22 - The next to last bullet says that processing is described in the following bullet, but it's actually described in the second following bullet. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 22 22:26:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMGSU-0008Md-Aa; Wed, 22 Mar 2006 22:25:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMGSS-0008Lt-Mp; Wed, 22 Mar 2006 22:25:56 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMGSR-0002oh-9e; Wed, 22 Mar 2006 22:25:56 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2N3PqUe020972; Thu, 23 Mar 2006 05:25:54 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 00:19:32 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 00:19:31 +0200 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, 23 Mar 2006 00:19:30 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0C1@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS" Thread-Index: AcZN/q60gWBbw8IwRxyIUQ9y3dHgfg== From: To: , X-OriginalArrivalTime: 22 Mar 2006 22:19:32.0163 (UTC) FILETIME=[B1801130:01C64DFE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [NSIS] "A QoS Model for Signaling IntServ Controlled-Load Service with 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 At today's TSVWG bar bof, I mentioned the Controlled Load QoS Model in NSIS. It can be found here: http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload -02.txt The Working Group has indicated that they are interested in this topic, but I would welcome comments, input, etc. on this. As I mentioned, I would support supporting PCN signaling in NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 02:05:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJsj-0003pA-2V; Thu, 23 Mar 2006 02:05:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJsh-0003n3-KJ for nsis@ietf.org; Thu, 23 Mar 2006 02:05:15 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMJsg-00032D-7b for nsis@ietf.org; Thu, 23 Mar 2006 02:05:15 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 23 Mar 2006 08:05:13 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Mar 2006 08:05:13 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED20E62A1@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: bschloer@cs.uni-goettingen.de Subject: RE: [NSIS] Re: QoS NSLP receiver initiated reservation Date: Thu, 23 Mar 2006 08:05:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-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 Hallo Bernd, thanks, especially for the prior message in the thread. Things=20 look clearer again. Regards, R=FCdiger |> RFC2205 defines: |> - The PATH message is sent downstream by the sender |> - The RESERVE message is sent upstream by the receiver |>=20 |> Does NSIS change that? | |I would say that NSIS is here similar to RSVP and extends it=20 |by the sender initiated reservation where the RESERVE=20 |message is sent downstream by the sender. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 07:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOU2-0000xy-JP; Thu, 23 Mar 2006 07:00:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOU1-0000xt-1L for nsis@ietf.org; Thu, 23 Mar 2006 07:00:05 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMOTw-0006yu-3x for nsis@ietf.org; Thu, 23 Mar 2006 07:00:04 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2NBxoti002532; Thu, 23 Mar 2006 11:59:50 GMT Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 11:59:49 +0000 From: "Robert Hancock" To: "'Roland Bless'" Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Thu, 23 Mar 2006 05:59:46 -0600 Message-ID: <003301c64e71$4917b800$8b7160cc@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4421976D.3070305@tm.uka.de> Importance: Normal X-OriginalArrivalTime: 23 Mar 2006 11:59:50.0319 (UTC) FILETIME=[49CEABF0:01C64E71] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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, for the record, i'm highly sceptical about the idea of a=20 'mini-tcp' for constrained hosts. if it was possible to achieve something with any useful functionality that was significantly simpler than tcp, i believe we would have it already, and then we could invoke it within GIST. I can=20 certainly think of someone who I guess would not regard the=20 case of adding reliability to SIP over UDP as a good=20 role model to follow. Brian Carpenter made the same point when reviewing the pre-WG GIMPS: > I certainly think > Henning is correct to consider using either a reliable transport > or not; everyone who tries to bypass TCP ends up partially > recreating it. and there was BoF on the general topic at ietf#43; from Harald Alvestrand's notes "One BOF called RUTS (I forget why) explored why people used UDP = protocols. A most entertaining discussion of NFS was what I got to hear; explaining = how they eventually had added almost every feature of TCP to their UDP-based implementation, and then decided to simply switch to TCP.....whenever = you have something more complex than an unloaded LAN, it seems that TCP just behaves better." there is a much wordier analysis at http://www.watersprings.org/pub/id/draft-hancock-nsis-reliability-00.txt r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 22 March 2006 12:29 > To: Robert Hancock > Cc: nsis > Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? >=20 >=20 > Robert Hancock schrieb: > > hi roland, > >=20 > > one clarification: > >=20 > >>> the slew handling algorithms are only there to handle=20 > lost messages. > >>> you could simply say 'if you want to use unreliable transport you=20 > >>> must keep the refresh period fixed for a given period',=20 > which would > >>> simplify this section quite considerably. > >> I'm not quite sure that I get your point. > >=20 > > the problem with slew and unreliable transport is that if=20 > you send a message > > with an extended refresh period which is lost then > > - the sender increases the time between refresh messages=20 > (according to the > > new period) > > - the receiver still expects more rapid refresh messages=20 > (according to the > > old period) > > - the receiver is likely to drop the session (according to=20 > the "three > > dropped messages and you're out" rule) > >=20 > > there are two solutions here (apart from the slew handling=20 > algorithms): > > - make sure the refresh gets delivered > > - don't change the refresh period >=20 > You're right. I guess we got it wrong, because > the problem we were trying to solve wasn't quite clear. > Mixing up retransmissions for reliability with state installation > confirmation seems to be a bad idea. So I'm still not quite > sure what is required. >=20 > However, I could think of something like a "provisional" > response if people want to get sure that their message > was received. In this case > the application may ask for this response which is sent as > soon as the message was received by the other peer (so no > confirmation of state installation and no advanced NSLP > processing). This may induce a security problem, because then > even unauthorized requests may generate a response. Further > reactions like retransmission should depend on the application. > Nevertheless, I guess it's not useful to discuss solutions > for not exactly specified problems and we need to discuss > first the general reliable transmission aspects. I have no problem > to use the normal reliable GIST transport, however, other people > seem to like the idea of using an unreliable protocol like UDP > and then adding a simple retransmission mechanism above (like in SIP > over UDP). I'm not sure that this is covered by the design decisions > for NTLP/NSLP we made once. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 07:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOaO-0005Pf-S8; Thu, 23 Mar 2006 07:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOaN-0005Pa-Oy for nsis@ietf.org; Thu, 23 Mar 2006 07:06:39 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMOaN-0007GJ-6i for nsis@ietf.org; Thu, 23 Mar 2006 07:06:39 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2NC6bPC025135; Thu, 23 Mar 2006 14:06:38 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:06:23 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:06:23 +0200 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] Re: QoS NSLP: ACK flag has no effect? Date: Thu, 23 Mar 2006 14:06:22 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0D3@esebe100.NOE.Nokia.com> In-Reply-To: <003301c64e71$4917b800$8b7160cc@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: QoS NSLP: ACK flag has no effect? Thread-Index: AcZOcaWGaRygHg/0R+Wc3PR+6y6UDwAAEr6w From: To: , X-OriginalArrivalTime: 23 Mar 2006 12:06:23.0649 (UTC) FILETIME=[34401110:01C64E72] X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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, I strongly agree with Robert on this. I had dinner with TSV & RAI ADs and was told that allowing SIP to support UDP was one of the worst mistakes they made. It seems that SIP deployments are having major problems with fragmentation, for example, and people are now doing creative things to try to fix it. My feeling is that TCP is far from a burden for modern hosts, IMO. John >-----Original Message----- >From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: 23 March, 2006 14:00 >To: 'Roland Bless' >Cc: 'nsis' >Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? > >hi, > >for the record, i'm highly sceptical about the idea of a=20 >'mini-tcp' for constrained hosts. if it was possible to=20 >achieve something with any useful functionality that was=20 >significantly simpler than tcp, i believe we would have it=20 >already, and then we could invoke it within GIST. I can=20 >certainly think of someone who I guess would not regard the=20 >case of adding reliability to SIP over UDP as a good role=20 >model to follow. > >Brian Carpenter made the same point when reviewing the pre-WG GIMPS: >> I certainly think >> Henning is correct to consider using either a reliable transport or=20 >> not; everyone who tries to bypass TCP ends up partially=20 >recreating it. > >and there was BoF on the general topic at ietf#43; from Harald=20 >Alvestrand's notes "One BOF called RUTS (I forget why)=20 >explored why people used UDP protocols. >A most entertaining discussion of NFS was what I got to hear;=20 >explaining how they eventually had added almost every feature=20 >of TCP to their UDP-based implementation, and then decided to=20 >simply switch to TCP.....whenever you have something more=20 >complex than an unloaded LAN, it seems that TCP just behaves better." > >there is a much wordier analysis at >http://www.watersprings.org/pub/id/draft-hancock-nsis-reliabili >ty-00.txt > >r. > >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: 22 March 2006 12:29 >> To: Robert Hancock >> Cc: nsis >> Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? >>=20 >>=20 >> Robert Hancock schrieb: >> > hi roland, >> >=20 >> > one clarification: >> >=20 >> >>> the slew handling algorithms are only there to handle >> lost messages. >> >>> you could simply say 'if you want to use unreliable=20 >transport you=20 >> >>> must keep the refresh period fixed for a given period', >> which would >> >>> simplify this section quite considerably. >> >> I'm not quite sure that I get your point. >> >=20 >> > the problem with slew and unreliable transport is that if >> you send a message >> > with an extended refresh period which is lost then >> > - the sender increases the time between refresh messages >> (according to the >> > new period) >> > - the receiver still expects more rapid refresh messages >> (according to the >> > old period) >> > - the receiver is likely to drop the session (according to >> the "three >> > dropped messages and you're out" rule) >> >=20 >> > there are two solutions here (apart from the slew handling >> algorithms): >> > - make sure the refresh gets delivered >> > - don't change the refresh period >>=20 >> You're right. I guess we got it wrong, because the problem we were=20 >> trying to solve wasn't quite clear. >> Mixing up retransmissions for reliability with state installation=20 >> confirmation seems to be a bad idea. So I'm still not quite=20 >sure what=20 >> is required. >>=20 >> However, I could think of something like a "provisional" >> response if people want to get sure that their message was received.=20 >> In this case the application may ask for this response which is sent=20 >> as soon as the message was received by the other peer (so no=20 >> confirmation of state installation and no advanced NSLP processing).=20 >> This may induce a security problem, because then even unauthorized=20 >> requests may generate a response. Further reactions like=20 >> retransmission should depend on the application. >> Nevertheless, I guess it's not useful to discuss solutions for not=20 >> exactly specified problems and we need to discuss first the general=20 >> reliable transmission aspects. I have no problem to use the normal=20 >> reliable GIST transport, however, other people seem to like the idea=20 >> of using an unreliable protocol like UDP and then adding a simple=20 >> retransmission mechanism above (like in SIP over UDP). I'm not sure=20 >> that this is covered by the design decisions for NTLP/NSLP we made=20 >> once. >>=20 >> Regards, >> Roland >>=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 Thu Mar 23 08:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQC0-0005c4-JM; Thu, 23 Mar 2006 08:49:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQBy-0005bw-QG for nsis@ietf.org; Thu, 23 Mar 2006 08:49:34 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQBw-0002nz-93 for nsis@ietf.org; Thu, 23 Mar 2006 08:49:34 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3609D4F007B; Thu, 23 Mar 2006 14:49:31 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:49:30 +0100 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:49:30 +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: RE: [NSIS] RMD comments Date: Thu, 23 Mar 2006 14:49:29 +0100 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D050BD18D@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RMD comments Thread-Index: AcZOGv/ogdCoui/XSGmRyd1sjCt75wAZVQ1w From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: , X-OriginalArrivalTime: 23 Mar 2006 13:49:30.0513 (UTC) FILETIME=[9BE89810:01C64E80] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) 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 Hi David, Thank you for the detailed comments, we will think of them and come back = with answers later. Best regards, Attila =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 09:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQm0-0001TC-2J; Thu, 23 Mar 2006 09:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQlx-0001K0-IT for nsis@ietf.org; Thu, 23 Mar 2006 09:26:45 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQlw-00058L-4l for nsis@ietf.org; Thu, 23 Mar 2006 09:26:45 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2NENfBG001089; Thu, 23 Mar 2006 16:23:44 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 16:25:55 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 16:25:54 +0200 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: [NSIS] RMD comments Date: Thu, 23 Mar 2006 16:25:53 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0DF@esebe100.NOE.Nokia.com> In-Reply-To: <05F34B6959F19F43BBD78FFCD4C15D050BD18D@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RMD comments Thread-Index: AcZOGv/ogdCoui/XSGmRyd1sjCt75wAZVQ1wAAFVmNA= From: To: , , X-OriginalArrivalTime: 23 Mar 2006 14:25:55.0071 (UTC) FILETIME=[B201B0F0:01C64E85] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 feel free to use some of today's meeting time to discuss these issues.=20 >-----Original Message----- >From: ext Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com]=20 >Sent: 23 March, 2006 15:49 >To: Black_David@emc.com; nsis@ietf.org >Subject: RE: [NSIS] RMD comments > >Hi David, > >Thank you for the detailed comments, we will think of them and=20 >come back with answers later. > >Best regards, Attila =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 Thu Mar 23 09:53:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRBz-0004P8-S8; Thu, 23 Mar 2006 09:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRBy-0004P3-Jm for nsis@ietf.org; Thu, 23 Mar 2006 09:53:38 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMRBx-0005da-A6 for nsis@ietf.org; Thu, 23 Mar 2006 09:53:38 -0500 Received: (qmail invoked by alias); 23 Mar 2006 14:53:36 -0000 Received: from DHCP-Wireless-129-200.ietf65.org (EHLO [130.129.129.200]) [130.129.129.200] by mail.gmx.net (mp034) with SMTP; 23 Mar 2006 15:53:36 +0100 X-Authenticated: #29516787 Message-ID: <4422B672.8050209@gmx.net> Date: Thu, 23 Mar 2006 08:53:38 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS 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: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] NSIS WG Meeting 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, info for remote participants: Audio feed: http://videolab.uoregon.edu/events/ietf/ Jabber: HOST: rooms.jabber.ietf.org ROOM: nsis Slides: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 10:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRLE-0002lR-Fw; Thu, 23 Mar 2006 10:03:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRLD-0002lM-R1 for nsis@ietf.org; Thu, 23 Mar 2006 10:03:11 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRLA-00068Z-9c for nsis@ietf.org; Thu, 23 Mar 2006 10:03:11 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FMRKu-00010p-HQ; Thu, 23 Mar 2006 16:02:56 +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 55F44853F; Thu, 23 Mar 2006 16:02:52 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FMRKt-0002YR-Pc; Thu, 23 Mar 2006 16:02:52 +0100 Message-ID: <4422B872.4070001@tm.uka.de> Date: Thu, 23 Mar 2006 16:02:10 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <003301c64e71$4917b800$8b7160cc@comm.ad.roke.co.uk> In-Reply-To: <003301c64e71$4917b800$8b7160cc@comm.ad.roke.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Robert, > for the record, i'm highly sceptical about the idea of a > 'mini-tcp' for constrained hosts. if it was possible to > achieve something with any useful functionality that was > significantly simpler than tcp, i believe we would have it > already, and then we could invoke it within GIST. I can > certainly think of someone who I guess would not regard the > case of adding reliability to SIP over UDP as a good > role model to follow. I fully agree with it. Thanks for providing the following pointers. Regards, Roland > Brian Carpenter made the same point when reviewing the pre-WG GIMPS: >> I certainly think >> Henning is correct to consider using either a reliable transport >> or not; everyone who tries to bypass TCP ends up partially >> recreating it. > > and there was BoF on the general topic at ietf#43; from Harald > Alvestrand's notes > "One BOF called RUTS (I forget why) explored why people used UDP protocols. > A most entertaining discussion of NFS was what I got to hear; explaining how > they eventually had added almost every feature of TCP to their UDP-based > implementation, and then decided to simply switch to TCP.....whenever you > have something more complex than an unloaded LAN, it seems that TCP just > behaves better." > > there is a much wordier analysis at > http://www.watersprings.org/pub/id/draft-hancock-nsis-reliability-00.txt > > r. > >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: 22 March 2006 12:29 >> To: Robert Hancock >> Cc: nsis >> Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? >> >> >> Robert Hancock schrieb: >>> hi roland, >>> >>> one clarification: >>> >>>>> the slew handling algorithms are only there to handle >> lost messages. >>>>> you could simply say 'if you want to use unreliable transport you >>>>> must keep the refresh period fixed for a given period', >> which would >>>>> simplify this section quite considerably. >>>> I'm not quite sure that I get your point. >>> the problem with slew and unreliable transport is that if >> you send a message >>> with an extended refresh period which is lost then >>> - the sender increases the time between refresh messages >> (according to the >>> new period) >>> - the receiver still expects more rapid refresh messages >> (according to the >>> old period) >>> - the receiver is likely to drop the session (according to >> the "three >>> dropped messages and you're out" rule) >>> >>> there are two solutions here (apart from the slew handling >> algorithms): >>> - make sure the refresh gets delivered >>> - don't change the refresh period >> You're right. I guess we got it wrong, because >> the problem we were trying to solve wasn't quite clear. >> Mixing up retransmissions for reliability with state installation >> confirmation seems to be a bad idea. So I'm still not quite >> sure what is required. >> >> However, I could think of something like a "provisional" >> response if people want to get sure that their message >> was received. In this case >> the application may ask for this response which is sent as >> soon as the message was received by the other peer (so no >> confirmation of state installation and no advanced NSLP >> processing). This may induce a security problem, because then >> even unauthorized requests may generate a response. Further >> reactions like retransmission should depend on the application. >> Nevertheless, I guess it's not useful to discuss solutions >> for not exactly specified problems and we need to discuss >> first the general reliable transmission aspects. I have no problem >> to use the normal reliable GIST transport, however, other people >> seem to like the idea of using an unreliable protocol like UDP >> and then adding a simple retransmission mechanism above (like in SIP >> over UDP). I'm not sure that this is covered by the design decisions >> for NTLP/NSLP we made once. >> >> Regards, >> Roland >> > > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 10:11:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRTK-0002cq-E9; Thu, 23 Mar 2006 10:11:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRTI-0002cX-PP for nsis@ietf.org; Thu, 23 Mar 2006 10:11:32 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRTH-0006nM-GS for nsis@ietf.org; Thu, 23 Mar 2006 10:11:32 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FMRT9-0001Sc-Tq; Thu, 23 Mar 2006 16:11:30 +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 B66798799; Thu, 23 Mar 2006 16:11:23 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FMRT9-0002Yn-8n; Thu, 23 Mar 2006 16:11:23 +0100 Message-ID: <4422BA71.3040201@tm.uka.de> Date: Thu, 23 Mar 2006 16:10:41 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <1AA39B75171A7144A73216AED1D7478D0186A0D3@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A0D3@esebe100.NOE.Nokia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: nsis@ietf.org, robert.hancock@roke.co.uk 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 john.loughney@nokia.com schrieb: > I strongly agree with Robert on this. I had dinner with TSV & RAI > ADs and was told that allowing SIP to support UDP was one of the > worst mistakes they made. It seems that SIP deployments are having > major problems with fragmentation, for example, and people are now > doing creative things to try to fix it. Good, that's what I wanted to hear. > My feeling is that TCP is far from a burden for modern hosts, IMO. Great, I fully agree with this. Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 10:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRi3-0000AF-4N; Thu, 23 Mar 2006 10:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRi1-0000A0-J8 for nsis@ietf.org; Thu, 23 Mar 2006 10:26:45 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMRhy-0007wp-TB for nsis@ietf.org; Thu, 23 Mar 2006 10:26:45 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 23 Mar 2006 16:26:41 +0100 Received: from [130.129.134.119] ([130.129.134.119]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 23 Mar 2006 16:26:41 +0100 Message-ID: <4422BF2B.6020106@docomolab-euro.com> Date: Thu, 23 Mar 2006 16:30:51 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [NSIS] RMD comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2006 15:26:41.0545 (UTC) FILETIME=[2F797790:01C64E8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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 Dear David and all, A very brief comment. I agree with David's suggestions of removing any allusion to AF from this draft and of clearly stating the support of RMD to a subset of Diffserv (actually that should also be done in I-D name to avoid misunderstandings). Moreover, IMO, it would be nice if any solution that proposes signalling triggered per-flow (although aiming to maintain per-class state) would present some proofs - references - that there is not a better approach to control Diffserv classes (EF in this case). Cheers Paulo Black_David@emc.com wrote: >These are intended to be WG Last Call comments on the >RMD draft, but I held them back until this afternoon's >bar-free Bar BoF was over with in the hopes of avoiding >confusion/entanglement with that set of concerns. The >resulting short notice prior to tomorrow's meeting is an >unfortunate result. > >I have two major concerns, plus some less important comments. > >--- (1) RMD is subset of diffserv --- > >Overall, RMD is about use of a subset of diffserv, specifically >EF or a class selector that has EF-like behavior. It does not >support AF-like functionality where multiple PHBs/DSCPs are >used to encode drop precedence for at least the following reasons: > >(a) contains only a Bandwidth element. It does >not contain the two token buckets needed to signal AF in full >generality (cf. the QSpec Template draft which does contain >these two token buckets). > >(b) The PHB_Class parameter is not capable of signaling a >PHB set, such as the various AF sets - see Section 2 of >RFC 3140. A DSCP is ok to use here, as these messages should >not be crossing diffserv domain boundaries. This >"should not be crossing" needs to be stated as a "MUST NOT >cross" restriction. > >(c) The severe congestion remarking algorithm destroys the >drop precedence markings on AF traffic. There may be situations >in which this is acceptable (e.g., the egress node will meter >and remark drop precedence anyway), but it is not always the >case. > >I recommend simply removing AF from this draft, and adding/ >rewriting portions of the introduction and other material to >make it clear that RMD is a diffserv-based bandwidth management >methodology, including avoiding any claim or implication of >full diffserv support. It would be possible to say that a >single AF PHB with overprovisioning to deliver an EF-like >behavior, but this would need to be carefully stated to avoid >implying support for full AF drop precedence behavior. > >--- (2) Severe Congestion measurement/notification issues --- > >Sections 4.6.1.6 and 4.6.1.7 appear to be problematic. > >Section 4.6.1.6.2.1 recommends (SHOULD) that two DSCPs be >allocated per traffic class, but only uses one of them (for >proportional marking). That's wasteful, although it looks >like the other one may be intended for probe-based congestion >notification (Section 4.6.1.7). Section 4.6.1.6 should limit >itself to one DSCP per traffic class for proportional >congestion measurement, and leave threshold marking to 4.6.1.7. > >The following sentence on max number of DSCPs is problematic >and misuses RFC 2119 terminology: > > It is RECOMMENDED that the total number of additional DSCPs within a > RMD domain, needed for severe congestion handling MUST not exceed the > limit of 16. > >The word "MUST" ought to be deleted to correct the RFC 2119 >terminology issue. In addition, the limit of 16 is too high - >that's 25% of a scarce resource, and implies that it's usually >acceptable in general to use up to 25% of that space for this >purpose, which is not a good idea in full generality. I would >prefer a recommendation that as few as possible be used, and >in particular that the number not exceed one per PHB. > >The algorithms in Section 4.6.1.6.2.1 and 4.6.1.6.2.2 appear >to be incomplete in that they don't specify the range of bytes >over which the algorithms are to operate - is this a moving window >vs. a succession of fixed windows, and what are appropriate window >sizes? For the latter, the window size may need to be much smaller >than a typical flow duration in order to be able to make decisions >faster than load conditions change. How should the sizes of the >Interior and Egress node windows compare? At best, these algorithms >are examples, and might be better qualified as such, as the marking >framework is probably amenable to other algorithms. > >Section 4.6.1.7 appears to be somewhat confused - on the one >hand, it describes the interior nodes as NSIS-unaware, but on the >other hand is using an NSIS-specific threshold-based DSCP remarking >scheme in those interior nodes. After this afternoon's session, >it's fairly clear that the PCN work is digging in about the same >place - using thresholds more aggressive than ordinary ECN to >communicate interior congestion to the edges - it might be a *very* >good idea to drop this section and refer to the appropriate CL/PCN >drafts as work in progress. > >I'm not comfortable with these two sections and would prefer to >see them removed, so that the resulting document is focused on the >signaling aspects. Based on past interactions, I suspect that's not >going to happen, and hence I would like to see these two sections >moved to an appendix to clearly separate them from the NSIS signaling >focus of the bulk of the draft. That appendix needs to state that >for congestion management/signaling, no more than one additional >DSCP per traffic PHB SHOULD be used, and also discuss the fact >that DSCPs are a scarce resource. > >--- IANA Considerations --- > >The IANA considerations section is essentially missing - it does not >tell IANA what is in the registry, what to do to establish the registry, >or how to manage it. See the rfc2434bis draft. > >--- Nits --- > >p.11 and p.13 - encoding of Overload % is not stated - e.g., >what percent level of overload does the value 0x10 represent? > >p.17 - The term "PHB group" shows up on this page without prior >explanation or definition. It should not be used due to the lack >of support for AF. > >p.17 - At the end of Section 4.3.3, the text should be clarified >to make it clear that the multiple classes are for admission >control (and possibly preemption?) only, as they share a single >PHB (and hence forwarding treatment) within the network. > >p.22 - The next to last bullet says that >processing is described in the following bullet, but it's actually >described in the second following bullet. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >black_david@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >_______________________________________________ >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 23 11:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSmC-0001Rr-0Z; Thu, 23 Mar 2006 11:35:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSmA-0001QF-W4 for nsis@ietf.org; Thu, 23 Mar 2006 11:35:06 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSm7-0002N4-53 for nsis@ietf.org; Thu, 23 Mar 2006 11:35:06 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4A9114F0002; Thu, 23 Mar 2006 17:35:02 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 17:35:02 +0100 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 17:35:02 +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: RE: [NSIS] Can we do without Q-spec stacking? Date: Thu, 23 Mar 2006 17:35:01 +0100 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D050BD18E@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Can we do without Q-spec stacking? Thread-Index: AcZMJUnE5ps092GdRymnbRtlVzNb7ACbpjPQ From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: X-OriginalArrivalTime: 23 Mar 2006 16:35:02.0001 (UTC) FILETIME=[BB896610:01C64E97] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Robert Hancock 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 also think that stacking is a useful function.=20 As an example, In RMD QoS model, we use stacking two QSPECs in Response = messages, since both QSPECs are delivered reliably edge-to-edge. We use = two Reserve messages (edge-to-edge and end-to-end) bounded together but = with a very good reason: namely intra-domain Reserve requires datagram = transport, whereas the other one reliable transport. The workaround of stacking is using two parallel messages with two = different QSPECs. I.e. it complicates the signaling schemes. My other = major concern is that sending bounded messages instead of stacking may = negatively influences the protocol performance. Bounded messages may = slow down the system if some of these messages are lost or delayed for = some reason.=20 Best regards, Attila > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Monday, March 20, 2006 2:50 PM > To: Robert Hancock > Cc: nsis@ietf.org > Subject: RE: [NSIS] Can we do without Q-spec stacking? >=20 >=20 >=20 > Hi, >=20 > So, your idea is that since one anyway implements session binding and > tunneling, then stacking comes along "free". What if one=20 > doesn't implement > the binding and aggregation at all in his routers because the=20 > domain only > needs the simple stacking functionality, i.e., use a=20 > different QOSM within=20 > the domain? >=20 > Jukka >=20 > On Mon, 20 Mar 2006, Robert Hancock wrote: >=20 > > jukka, > >=20 > > > Hi Rob, > > >=20 > > > I really don't see how life would be so much more fun with a=20 > > > single QSPEC > > > allowed. The stacking of two QSPECs is a good idea, quite=20 > simple to > > > implement the processing for it, and has shown to have=20 > > > support for a long > > > time. To support the stacking through implementing a separate > > > domain-internal session concept, and the processing for=20 > it would be a > > > number of times more complex and time consuming. > >=20 > > how is it more complex than what the draft already states or implies > > is needed for aggregation and tunnel operation (and all the other > > session binding scenarios)? > >=20 > > > If one wants to implement > > > the same functionality to stacking through a separate=20 > > > session, he is free to do so. > >=20 > > what I am questioning is that it seems we could have a choice=20 > > between: > > a) implement something complex for cases A-Y and simple for case Z > > b) implement something complex for cases A-Z > > Which of (a) or (b) leads to a simpler protocol? > >=20 > > r. > >=20 > > (leaving aside of course the question of whether stacking is really > > simple, on which other people have much stronger views than me.) > >=20 > > >=20 > > > Jukka > > >=20 > > > On Sun, 19 Mar 2006, Robert Hancock wrote: > > >=20 > > > > Hi, > > > >=20 > > > > I reviewed the QoS-NSLP on the flight yesterday and the above > > > > question occurred to me about half-way across.=20 > > > >=20 > > > > We introduced stacking [see below for historical background] as > > > > a means for accommodating localisation of the QoS specification > > > > within particular domains. I think that's still a legitimate=20 > > > > goal. However, the specification now has another way to achieve > > > > the same thing, namely by creating a local signalling session > > > > and using the BOUND_SESSION_ID to correlate the two at=20 > the edges, > > > > with the e2e session ignored in the interior.=20 > > > >=20 > > > > I don't think it would take much work to eliminate the=20 > concept from > > > > the qos-nslp (I haven't checked the qspec yet). And I'm=20 > sure there > > > > would be tears of joy in some quarters. > > > >=20 > > > > r. > > > >=20 > > > > Background: > > > > For a trip down memory lane, check out section 4.4 of > > > >=20 > > >=20 > http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt > > > > (from 2002...). At the time, the main advantage of the stacking > > > > approach was that domain boundary nodes could do all their=20 > > > processing > > > > on a single message rather than having to correlate messages of=20 > > > > multiple sessions. However, it now turns out that we can't avoid > > > > that type of complexity for other reasons, including > > > > - any sort of aggregation (where you have to handle 1+N=20 > messages) > > > > - where the interior session needs uses different GIST transport > > > > characteristics (RMD) > > > > - where it is natural to hide the e2e session in the interior > > > > (tunnel e.g. for mobility/vpn scenarios) > > > > Given that session correlation is needed in all these=20 > other cases, > > > > the advantage of being able to do without it in a=20 > particular case > > > > basically vanishes. It's probably simpler to use a=20 > single mechanism > > > > to handle everything. > > > >=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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Mar 23 11:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSrl-0008KQ-JZ; Thu, 23 Mar 2006 11:40:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSrk-0008Jq-GZ for nsis@ietf.org; Thu, 23 Mar 2006 11:40:52 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSrk-0002Zd-0w for nsis@ietf.org; Thu, 23 Mar 2006 11:40:52 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FMSre-0006hd-AJ; Thu, 23 Mar 2006 17:40:50 +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 D4186853C; Thu, 23 Mar 2006 17:40:45 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FMSrd-0002jS-0W; Thu, 23 Mar 2006 17:40:45 +0100 Message-ID: <4422CF64.50702@tm.uka.de> Date: Thu, 23 Mar 2006 17:40:04 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <1AA39B75171A7144A73216AED1D7478D0186A0D3@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A0D3@esebe100.NOE.Nokia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: nsis@ietf.org, robert.hancock@roke.co.uk 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 > I strongly agree with Robert on this. I had dinner with TSV & RAI > ADs and was told that allowing SIP to support UDP was one of the > worst mistakes they made. It seems that SIP deployments are having > major problems with fragmentation, for example, and people are now > doing creative things to try to fix it. > > My feeling is that TCP is far from a burden for modern hosts, IMO. So a consequence would be to rule out the ACK mechanism for transport reliability. Good. I would then recommend to remove the ACK mechanism completely unless someone speaks up to keep it, stating the problem it should solve. >> -----Original Message----- >> From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk] >> Sent: 23 March, 2006 14:00 >> To: 'Roland Bless' >> Cc: 'nsis' >> Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? >> >> hi, >> >> for the record, i'm highly sceptical about the idea of a >> 'mini-tcp' for constrained hosts. if it was possible to >> achieve something with any useful functionality that was >> significantly simpler than tcp, i believe we would have it >> already, and then we could invoke it within GIST. I can >> certainly think of someone who I guess would not regard the >> case of adding reliability to SIP over UDP as a good role >> model to follow. >> >> Brian Carpenter made the same point when reviewing the pre-WG GIMPS: >>> I certainly think >>> Henning is correct to consider using either a reliable transport or >>> not; everyone who tries to bypass TCP ends up partially >> recreating it. >> >> and there was BoF on the general topic at ietf#43; from Harald >> Alvestrand's notes "One BOF called RUTS (I forget why) >> explored why people used UDP protocols. >> A most entertaining discussion of NFS was what I got to hear; >> explaining how they eventually had added almost every feature >> of TCP to their UDP-based implementation, and then decided to >> simply switch to TCP.....whenever you have something more >> complex than an unloaded LAN, it seems that TCP just behaves better." >> >> there is a much wordier analysis at >> http://www.watersprings.org/pub/id/draft-hancock-nsis-reliabili >> ty-00.txt >> >> r. >> >>> -----Original Message----- >>> From: Roland Bless [mailto:bless@tm.uka.de] >>> Sent: 22 March 2006 12:29 >>> To: Robert Hancock >>> Cc: nsis >>> Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? >>> >>> >>> Robert Hancock schrieb: >>>> hi roland, >>>> >>>> one clarification: >>>> >>>>>> the slew handling algorithms are only there to handle >>> lost messages. >>>>>> you could simply say 'if you want to use unreliable >> transport you >>>>>> must keep the refresh period fixed for a given period', >>> which would >>>>>> simplify this section quite considerably. >>>>> I'm not quite sure that I get your point. >>>> the problem with slew and unreliable transport is that if >>> you send a message >>>> with an extended refresh period which is lost then >>>> - the sender increases the time between refresh messages >>> (according to the >>>> new period) >>>> - the receiver still expects more rapid refresh messages >>> (according to the >>>> old period) >>>> - the receiver is likely to drop the session (according to >>> the "three >>>> dropped messages and you're out" rule) >>>> >>>> there are two solutions here (apart from the slew handling >>> algorithms): >>>> - make sure the refresh gets delivered >>>> - don't change the refresh period >>> You're right. I guess we got it wrong, because the problem we were >>> trying to solve wasn't quite clear. >>> Mixing up retransmissions for reliability with state installation >>> confirmation seems to be a bad idea. So I'm still not quite >> sure what >>> is required. >>> >>> However, I could think of something like a "provisional" >>> response if people want to get sure that their message was received. >>> In this case the application may ask for this response which is sent >>> as soon as the message was received by the other peer (so no >>> confirmation of state installation and no advanced NSLP processing). >>> This may induce a security problem, because then even unauthorized >>> requests may generate a response. Further reactions like >>> retransmission should depend on the application. >>> Nevertheless, I guess it's not useful to discuss solutions for not >>> exactly specified problems and we need to discuss first the general >>> reliable transmission aspects. I have no problem to use the normal >>> reliable GIST transport, however, other people seem to like the idea >>> of using an unreliable protocol like UDP and then adding a simple >>> retransmission mechanism above (like in SIP over UDP). I'm not sure >>> that this is covered by the design decisions for NTLP/NSLP we made >>> once. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 24 03:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhpU-00089v-2A; Fri, 24 Mar 2006 03:39:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhpS-00089q-Ns for nsis@ietf.org; Fri, 24 Mar 2006 03:39:30 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhpR-0003uc-A6 for nsis@ietf.org; Fri, 24 Mar 2006 03:39:30 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 24 Mar 2006 09:39:27 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Mar 2006 09:39:27 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED20E62AA@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Fri, 24 Mar 2006 09:39:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: bless@tm.uka.de, 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 John, I agree, the ACK mechanism can be removed. When I proposed it, my=20 idea was to get Response messages without RII processing.=20 Couldn't the Response of the QNR be triggered=20 a) by default in the case of state changing Reserves b) by a simple flag instead of the RII I expect any application using QoS to request a confirmation of=20 resource set up and state changes. There seem to be two ways to=20 link QoS NSLP to e.g. SIP or RTSP: - Use a QoS NSLP "Response" and control QoS set up on NSLP layer.=20 SIP is informedvia an API, that QoS set up is succesful.=20 This as the more generic approach, also taken by=20 RFC3312/4032 (SIP WG) and it is required to operate PCN (TSV WG). - Use SIP itself to confirm sucessful QoS set up (i.e. no QoS NSLP=20 response) from the destination. This requires a new design for=20 each application protocol. If the ACK mechanism is removed, also Reduced Refresh is removed.=20 If Reduced Refresh is to be kept, it must be reworded. Regards, R=FCdiger |-----Original Message----- |From: Roland Bless [mailto:bless@tm.uka.de] |Sent: Thursday, March 23, 2006 5:40 PM |To: john.loughney@nokia.com |Cc: nsis@ietf.org; robert.hancock@roke.co.uk |Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? | | |Hi John | |> I strongly agree with Robert on this. I had dinner with TSV & RAI |> ADs and was told that allowing SIP to support UDP was one of the |> worst mistakes they made. It seems that SIP deployments are having |> major problems with fragmentation, for example, and people are now |> doing creative things to try to fix it. |>=20 |> My feeling is that TCP is far from a burden for modern hosts, IMO. | |So a consequence would be to rule out the ACK mechanism for |transport reliability. Good. I would then recommend to remove |the ACK mechanism completely unless someone speaks up to keep |it, stating the problem it should solve. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Mar 24 12:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpsD-0004Ml-1A; Fri, 24 Mar 2006 12:14:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpsB-0004J4-TA for nsis@ietf.org; Fri, 24 Mar 2006 12:14:51 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMpsA-0002S0-F6 for nsis@ietf.org; Fri, 24 Mar 2006 12:14:51 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FMps5-0000LO-1K; Fri, 24 Mar 2006 18:14:49 +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 B1652A213; Fri, 24 Mar 2006 18:14:44 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FMps4-0004SI-C7; Fri, 24 Mar 2006 18:14:44 +0100 Message-ID: <442428DB.7090201@tm.uka.de> Date: Fri, 24 Mar 2006 18:14:03 +0100 From: Roland Bless User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <6439282641581441A36F7F6F83ED2ED20E62AA@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E62AA@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: john.loughney@nokia.com, 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 Ruediger, > I agree, the ACK mechanism can be removed. When I proposed it, my > idea was to get Response messages without RII processing. > Couldn't the Response of the QNR be triggered > a) by default in the case of state changing Reserves > b) by a simple flag instead of the RII > > I expect any application using QoS to request a confirmation of > resource set up and state changes. There seem to be two ways to > link QoS NSLP to e.g. SIP or RTSP: > > - Use a QoS NSLP "Response" and control QoS set up on NSLP layer. > SIP is informedvia an API, that QoS set up is succesful. > This as the more generic approach, also taken by > RFC3312/4032 (SIP WG) and it is required to operate PCN (TSV WG). > > - Use SIP itself to confirm sucessful QoS set up (i.e. no QoS NSLP > response) from the destination. This requires a new design for > each application protocol. > > If the ACK mechanism is removed, also Reduced Refresh is removed. > If Reduced Refresh is to be kept, it must be reworded. > I disagree here. Why must the reduced refresh be removed when we don't have the ACK anymore? The only difference between a normal refresh and a reduced refresh is the missing QSPEC. It's not like the summary refresh in RSVP which is able to refresh several sessions with only one message. Please see also: http://www1.ietf.org/mail-archive/web/nsis/current/msg06033.html Sure, text must be reworded for reduced refreshed, but there is no technical reason why dismissing the ACK causes removal of the reduced refresh. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 25 00:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN1U7-0006aT-LB; Sat, 25 Mar 2006 00:38:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN1U7-0006aN-54 for nsis@ietf.org; Sat, 25 Mar 2006 00:38:47 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN1U5-000648-NF for nsis@ietf.org; Sat, 25 Mar 2006 00:38:47 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2P5bEjm007649 for ; Sat, 25 Mar 2006 07:37:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Mar 2006 07:38:15 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Mar 2006 07:38:15 +0200 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: Sat, 25 Mar 2006 07:38:15 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A11A@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "ITU-T resource and admission control functions for NGN" Thread-Index: AcYoSSh3OF+xi0zhQ2uPTcTDA+FuOgnhMq4g From: To: X-OriginalArrivalTime: 25 Mar 2006 05:38:15.0500 (UTC) FILETIME=[504208C0:01C64FCE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] New Liaison Statement, "ITU-T resource and admission control functions for NGN" 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 Hello all, We have a liason statement from the ITU-T. It would be helpful if the list could review it, have a discussion and then follow-up on the liason via official channels. One possible result would be we would comment on the applicable NSIS work, and forward this to the ITU-T. thanks, John From: Georges Sebek(ITU-T SG 13) To: IETF NSIS(john.loughney@nokia.com) Cc: sbrim@cisco.com Reponse Contact: sebek@itu.int huilanlu@lucent.com Technical Contact: huilanlu@lucent.com Purpose: For information Body:=20 Attachment(s): ITU-T resource and admission control functions for NGN (https://datatracker.ietf.org/documents/LIAISON/file269.pdf) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Mar 25 09:14:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN9XC-0003mS-78; Sat, 25 Mar 2006 09:14:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN9XB-0003mN-2w for nsis@ietf.org; Sat, 25 Mar 2006 09:14:29 -0500 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FN9XA-00010m-KU for nsis@ietf.org; Sat, 25 Mar 2006 09:14:29 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-126.messagelabs.com!1143296055!10005644!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19959 invoked from network); 25 Mar 2006 14:14:27 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-126.messagelabs.com with SMTP; 25 Mar 2006 14:14:27 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4401E007003A11A9; Sat, 25 Mar 2006 09:14:26 -0500 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] New Liaison Statement, "ITU-T resource and admission control functions for NGN" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 25 Mar 2006 08:14:26 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC759E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A11A@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] New Liaison Statement, "ITU-T resource and admission control functions for NGN" Thread-Index: AcYoSSh3OF+xi0zhQ2uPTcTDA+FuOgnhMq4gABIENCA= From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Ash, Gerald R \(Jerry\), ALABS" 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 Getting the copy of Y.RACF is not exactly easy. After registering, one must await the TSB to process the request. How long will that take, and then what? =20 Perhaps ITU-T can post a direct link to Y.RACF. Jerry=20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Saturday, March 25, 2006 12:38 AM To: nsis@ietf.org Subject: [NSIS] New Liaison Statement,"ITU-T resource and admission control functions for NGN"=20 Hello all, We have a liason statement from the ITU-T. It would be helpful if the list could review it, have a discussion and then follow-up on the liason via official channels. One possible result would be we would comment on the applicable NSIS work, and forward this to the ITU-T. thanks, John From: Georges Sebek(ITU-T SG 13) To: IETF NSIS(john.loughney@nokia.com) Cc: sbrim@cisco.com Reponse Contact: sebek@itu.int huilanlu@lucent.com Technical Contact: huilanlu@lucent.com Purpose: For information Body:=20 Attachment(s): ITU-T resource and admission control functions for NGN (https://datatracker.ietf.org/documents/LIAISON/file269.pdf) _______________________________________________ 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 25 22:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNM8M-0001Jr-6R; Sat, 25 Mar 2006 22:41:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNM8L-0001Jm-LW for nsis@ietf.org; Sat, 25 Mar 2006 22:41:41 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNM8K-0006QN-Dp for nsis@ietf.org; Sat, 25 Mar 2006 22:41:41 -0500 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id C64BF147AB6; Sat, 25 Mar 2006 22:41:39 -0500 (EST) 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.0.6603.0 Subject: RE: [NSIS] New Liaison Statement, "ITU-T resource and admission control functions for NGN" Date: Sat, 25 Mar 2006 22:41:39 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1025A254B@NJFPSRVEXG2KCL.research.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] New Liaison Statement, "ITU-T resource and admission control functions for NGN" Thread-Index: AcYoSSh3OF+xi0zhQ2uPTcTDA+FuOgnhMq4gABIENCAAHC8fkA== From: To: , , X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Given that the document is just a draft, and that they (the ITU-T) agreed to send it to NSIS (albeit via access to an FTP area for which one must register), I do not think sharing the draft "directly" should be a problem.=20 Certainly many people who participated in this last IETF meeting have the latest draft. My onlt reservation would be that maybe the ITTU doesn't want the draft posted on the IETF website...but looking at the file itself separately should not be a problem as I understand it. Chuck -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 Sent: Saturday, March 25, 2006 9:14 AM To: john.loughney@nokia.com; nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: [NSIS] New Liaison Statement,"ITU-T resource and admission control functions for NGN"=20 Getting the copy of Y.RACF is not exactly easy. After registering, one must await the TSB to process the request. How long will that take, and then what? =20 Perhaps ITU-T can post a direct link to Y.RACF. Jerry=20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Saturday, March 25, 2006 12:38 AM To: nsis@ietf.org Subject: [NSIS] New Liaison Statement,"ITU-T resource and admission control functions for NGN"=20 Hello all, We have a liason statement from the ITU-T. It would be helpful if the list could review it, have a discussion and then follow-up on the liason via official channels. One possible result would be we would comment on the applicable NSIS work, and forward this to the ITU-T. thanks, John From: Georges Sebek(ITU-T SG 13) To: IETF NSIS(john.loughney@nokia.com) Cc: sbrim@cisco.com Reponse Contact: sebek@itu.int huilanlu@lucent.com Technical Contact: huilanlu@lucent.com Purpose: For information Body:=20 Attachment(s): ITU-T resource and admission control functions for NGN (https://datatracker.ietf.org/documents/LIAISON/file269.pdf) _______________________________________________ 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 27 04:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNnmp-0002lU-NZ; Mon, 27 Mar 2006 04:13:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNnmo-0002iw-Id for nsis@ietf.org; Mon, 27 Mar 2006 04:13:18 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNnmn-0003wh-5x for nsis@ietf.org; Mon, 27 Mar 2006 04:13:18 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k2R9D3fK027341; Mon, 27 Mar 2006 11:13:12 +0200 (MEST) From: "Georgios Karagiannis" To: Subject: RE: [NSIS] RMD comments Date: Mon, 27 Mar 2006 11:12:57 +0200 Message-ID: <000401c6517e$a925e540$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 Thread-Index: AcZOGv/ogdCoui/XSGmRyd1sjCt75wAZVQ1wAAFVmNAAvi9l0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A0DF@esebe100.NOE.Nokia.com> X-Spam-Score: -5.669 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 27 Mar 2006 11:13:13 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nsis@ietf.org, attila.bader@ericsson.com 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 Just to inform you, Attila and I have had a discussion with=20 David Black after the NSIS meeting. David agreed that we instead of = moving=20 the admission control based on probing sections to the appendix=20 we could leave these sections, but just move the descriptions of the=20 marking algorithms to the appendix. Best Regards, Georgios=20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: donderdag 23 maart 2006 15:26 To: attila.bader@ericsson.com; Black_David@emc.com; nsis@ietf.org Subject: RE: [NSIS] RMD comments feel free to use some of today's meeting time to discuss these issues.=20 >-----Original Message----- >From: ext Attila B=E1der (IJ/ETH) [mailto:attila.bader@ericsson.com] >Sent: 23 March, 2006 15:49 >To: Black_David@emc.com; nsis@ietf.org >Subject: RE: [NSIS] RMD comments > >Hi David, > >Thank you for the detailed comments, we will think of them and come=20 >back with answers later. > >Best regards, Attila > >_______________________________________________ >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 27 04:55:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNoS0-0001fE-L3; Mon, 27 Mar 2006 04:55:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNoRz-0001cx-52 for nsis@ietf.org; Mon, 27 Mar 2006 04:55:51 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNoRx-0005p7-NQ for nsis@ietf.org; Mon, 27 Mar 2006 04:55:51 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2R9tQTG001249; Mon, 27 Mar 2006 10:55:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Mar 2006 10:55:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] New Liaison Statement, "ITU-T resource and admission control functions for NGN" Thread-Index: AcYoSSh3OF+xi0zhQ2uPTcTDA+FuOgnhMq4gABIENCAAW10tMA== From: "Hancock, Robert" To: "Ash, Gerald R \(Jerry\), ALABS" , , X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk Subject: RE: [NSIS] New Liaison Statement, "ITU-T resource and admission control functions for NGN" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 all, in the spirit of experimentation ... i went through the TSB registration process, and got a=20 (successful) response in about an hour. (I guess this is only reliable during Geneva business hours, of course...) r. > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: 25 March 2006 14:14 > To: john.loughney@nokia.com; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] New Liaison Statement,"ITU-T resource and=20 > admission control functions for NGN"=20 >=20 >=20 > Getting the copy of Y.RACF is not exactly easy. After=20 > registering, one > must await the TSB to process the request. How long will=20 > that take, and > then what? =20 >=20 > Perhaps ITU-T can post a direct link to Y.RACF. >=20 > Jerry=20 >=20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Saturday, March 25, 2006 12:38 AM > To: nsis@ietf.org > Subject: [NSIS] New Liaison Statement,"ITU-T resource and admission > control functions for NGN"=20 >=20 > Hello all, >=20 > We have a liason statement from the ITU-T. It would be helpful if the > list could review it, have a discussion and then follow-up on=20 > the liason > via official channels. >=20 > One possible result would be we would comment on the applicable NSIS > work, and forward this to the ITU-T. >=20 > thanks, > John >=20 > From: Georges Sebek(ITU-T SG 13) > To: IETF NSIS(john.loughney@nokia.com) > Cc: sbrim@cisco.com > Reponse Contact: sebek@itu.int > huilanlu@lucent.com > Technical Contact: huilanlu@lucent.com > Purpose: For information > Body:=20 > Attachment(s): >=20 > ITU-T resource and admission control functions for NGN > (https://datatracker.ietf.org/documents/LIAISON/file269.pdf) >=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 Tue Mar 28 01:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7q8-0008Au-Tn; Tue, 28 Mar 2006 01:38:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7q7-000893-Tc for nsis@ietf.org; Tue, 28 Mar 2006 01:38:03 -0500 Received: from outmx012.isp.belgacom.be ([195.238.5.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7nx-0001ml-Rq for nsis@ietf.org; Tue, 28 Mar 2006 01:35:51 -0500 Received: from outmx012.isp.belgacom.be (localhost [127.0.0.1]) by outmx012.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k2S6ZaBc023202 for ; Tue, 28 Mar 2006 08:35:36 +0200 (envelope-from ) Received: from unicornia1dd09 (194.100-200-80.adsl.skynet.be [80.200.100.194]) by outmx012.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with SMTP id k2S6ZRka023119 for ; Tue, 28 Mar 2006 08:35:31 +0200 (envelope-from ) Message-ID: <01c101c65231$d656dd90$0401a8c0@unicornia1dd09> From: "marganne etienne" To: Date: Tue, 28 Mar 2006 08:35:40 +0200 MIME-Version: 1.0 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-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [NSIS] GIST authentication 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="===============2017012108==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2017012108== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BC_01C65242.987A0310" This is a multi-part message in MIME format. ------=_NextPart_000_01BC_01C65242.987A0310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everybody, I currently am a student ending my informatic engineer studies and i am = studying NSIS and GIST through my end of study project. The topic is the = use of NSIS to provide VoIP with a signaling protocol to correctly = configure the bindings in NAT's and Firewalls. The question i have is = about authentication of GIST adjacent nodes in a NSIS path, i did not = see any mechanisms to ensure we do not add unthrustable nodes. I could = be wrong and the answer could just be lying aroung. Anyway it think this = is a big concern in security to be sure of the list of nodes member of = the NSIS data path. Thank you for reading, i hope to hear from you soon, Marganne Etienne. ------=_NextPart_000_01BC_01C65242.987A0310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everybody,
 
I currently am a student ending my = informatic=20 engineer studies and i am studying NSIS and GIST through my end of study = project. The topic is the use of NSIS to provide VoIP with a signaling = protocol=20 to correctly configure the bindings in NAT's and Firewalls. The question = i have=20 is about authentication of GIST adjacent nodes in a NSIS path, i = did not=20 see any mechanisms to ensure we do not add unthrustable nodes. I could = be wrong=20 and the answer could just be lying aroung. Anyway it think this is a big = concern=20 in security to be sure of the list of nodes member of the NSIS data=20 path.
 
Thank you for reading, i hope to hear = from you=20 soon,
 
Marganne=20 Etienne.
------=_NextPart_000_01BC_01C65242.987A0310-- --===============2017012108== 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 --===============2017012108==-- From nsis-bounces@ietf.org Tue Mar 28 02:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8oa-0005UE-TP; Tue, 28 Mar 2006 02:40:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8oY-0005TQ-Nh for nsis@ietf.org; Tue, 28 Mar 2006 02:40:30 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FO8oU-0004Fk-9D for nsis@ietf.org; Tue, 28 Mar 2006 02:40:30 -0500 Received: (qmail invoked by alias); 28 Mar 2006 07:40:24 -0000 Received: from p549866E3.dip.t-dialin.net (EHLO [192.168.2.102]) [84.152.102.227] by mail.gmx.net (mp008) with SMTP; 28 Mar 2006 09:40:24 +0200 X-Authenticated: #29516787 Message-ID: <4428E865.5080201@gmx.net> Date: Tue, 28 Mar 2006 01:40:21 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marganne etienne Subject: Re: [NSIS] GIST authentication References: <01c101c65231$d656dd90$0401a8c0@unicornia1dd09> In-Reply-To: <01c101c65231$d656dd90$0401a8c0@unicornia1dd09> 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: 21c69d3cfc2dd19218717dbe1d974352 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 Etienne, please find my comments inline: marganne etienne wrote: > Hello everybody, > > I currently am a student ending my informatic engineer studies and i am > studying NSIS and GIST through my end of study project. The topic is the > use of NSIS to provide VoIP with a signaling protocol to correctly > configure the bindings in NAT's and Firewalls. The question i have is > about authentication of GIST adjacent nodes in a NSIS path, i did not > see any mechanisms to ensure we do not add unthrustable nodes. Let me try to phrase what I think you are saying. You are concerned that - an ordinary router (i.e., non-NSIS node) claims to be an NSIS node - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice versas) - a malicious NSIS node redirects signaling messages to an off-path NSIS node - an NSIS node along the path becomes malicious? Maybe you could elaborate a little bit more about your concern. > I could > be wrong and the answer could just be lying aroung. Anyway it think this > is a big concern in security to be sure of the list of nodes member of > the NSIS data path. > > Thank you for reading, i hope to hear from you soon, > > Marganne Etienne. > Ciao Hannes > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 28 05:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOBAt-0005Vu-DZ; Tue, 28 Mar 2006 05:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOBAq-0005Vk-RI for nsis@ietf.org; Tue, 28 Mar 2006 05:11:40 -0500 Received: from outmx023.isp.belgacom.be ([195.238.4.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOBAp-0002n0-14 for nsis@ietf.org; Tue, 28 Mar 2006 05:11:40 -0500 Received: from outmx023.isp.belgacom.be (localhost [127.0.0.1]) by outmx023.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k2SABYMR018441 for ; Tue, 28 Mar 2006 12:11:34 +0200 (envelope-from ) Received: from unicornia1dd09 (194.100-200-80.adsl.skynet.be [80.200.100.194]) by outmx023.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with SMTP id k2SABLY1018291 for ; Tue, 28 Mar 2006 12:11:25 +0200 (envelope-from ) Message-ID: <020201c6524f$ffa56040$0401a8c0@unicornia1dd09> From: "marganne etienne" To: References: <01c101c65231$d656dd90$0401a8c0@unicornia1dd09> <4428E865.5080201@gmx.net> <01d101c6523d$393d28f0$0401a8c0@unicornia1dd09> <4428F404.1020301@gmx.net> <01de01c65246$5b9cf840$0401a8c0@unicornia1dd09> <442903D9.7050704@gmx.net> Subject: Re: [NSIS] GIST authentication Date: Tue, 28 Mar 2006 12:11:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b 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 everybody, Here is the discussion with Hannes about GIST. Some part of the content were already posted by not all, so now it is done. So as Mr Tschofenig said, there are no need of GIST nodes over the Internet to be present to get a NSIS session work properly. I agree with this.The problem now is this one : There is, however, an authorization question. Take a look at the figure below: +----------------------+ +--------------------------+ | Network A | | Network B | | | | | | +---------+ +---------+ | | +-///-+ Middle- | | Middle- +-///-+ | | | | box 1 | No TLS | box 2 | | | | | +---------+ +---------+ | | | | | | | | | | | | | | | | TLS | | | TLS | | +--+---+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +------+ | | +------+ | +----------------------+ +--------------------------+ The following question arises: Why should Middlebox 2 authorize the signaling message to traverse the firewall towards Host B? To what Mr Tschofenig answered : We came up with a few solutions (a deployment issue, however): - Delayed authorization (described in the main NATFW NSLP draft) - Authorization Tokens (described in a separate draft) - AAA interaction: Diameter has been used by a few SDOs to authorize the firewall request based on previous SIP interaction (in the same fashion as proposed for QoS signaling). Now what i think is : if there is no need of GIST hops between a NSIS communication work and transmitting an authorization token could solve the authorization question, what could be the role of GIST in such cases ? Also this scheme : - Two end hosts trying to communicate and open bindings in Firewall with the help of NSIS but without and GIST hops on the Internet between them. - The authorization problem solved by an authorization token delivered, let's say by SIP. - The authentication problem solved by TLS or something similar (i.e. adding an authentication part to NSIS messages at the beginning of session, to authenticate a particular session ID wich is supposed to be unique) This scheme, then, is a least a bit similar to ICE with the Media Session Authorization. There are of course differences, but i think at least it looks similar. ICE provides the connectivity and MSA a way to authenticate and authorize the session data flow. One of the differences is that ICE do not use something similar to GIST, i mean there is only one layer... also i could be wrong. Another little question : is there a way to re-use GIST states built by QOS NSLP with NAT/FW NSLP and the opposite ? Thank you for reading, Marganne Etienne. ----- Original Message ----- From: "Hannes Tschofenig" To: "marganne etienne" Sent: Tuesday, March 28, 2006 11:37 AM Subject: Re: [NSIS] GIST authentication > Hi Etienne, > > marganne etienne wrote: >> Hi Hannes, >> >> So since there are TLS and the cookies, the GIST hops can be >> authenticate. Now i have another question : >> Let's say we use NSIS NAT/FW NSLP to open bindings in Firewalls located >> at the edges of two subnets. Let's say there are no GIST aware nodes to >> create a path between both sides. Somthing like this : >> >> NSIS Proxy -- Firewall 1 ---- Internet ---- Firewall 2 --- NSIS Proxy >> >> Will it be possible to open the bindings, if both knows their IP adresses >> ? Or is it absolutly necessary to have some GIST nodes on the >> internet to create a path ? > > No, that's not necessary. > > > Btw, in your figure above it would be possible to have something like: > > End Host -- Firewall 1 ---- Internet ---- Firewall 2 --- End Host > > > (there are supposed to have several hops on >> the Internet between the two sides.) If there is a need for several >> GIST/NSIS nodes to be present on the net then there could be some >> problems with the installation of NSIS because one could have to install >> a lot of those GIST aware hops over the Internet. > This would indeed be a deployment problem. Hence, it is not necessary. > > There is, however, an authorization question. Take a look at the figure > below: > > +----------------------+ +--------------------------+ > | Network A | | Network B | > | | | | > | +---------+ +---------+ | > | +-///-+ Middle- | | Middle- +-///-+ | > | | | box 1 | No TLS | box 2 | | | > | | +---------+ +---------+ | | > | | | | | | > | | | | | | > | | TLS | | | TLS | > | +--+---+ | | +--+---+ | > | | Host | | | | Host | | > | | A | | | | B | | > | +------+ | | +------+ | > +----------------------+ +--------------------------+ > > The following question arises: Why should Middlebox 2 authorize the > signaling message to traverse the firewall towards Host B? > We came up with a few solutions (a deployment issue, however): > - Delayed authorization (described in the main NATFW NSLP draft) > - Authorization Tokens (described in a separate draft) > - AAA interaction: Diameter has been used by a few SDOs to authorize the > firewall request based on previous SIP interaction (in the same fashion as > proposed for QoS signaling). > > Ciao > Hannes > >> >> Thank you, >> >> Marganne Etienne. >> >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: "marganne etienne" >> Sent: Tuesday, March 28, 2006 10:29 AM >> Subject: Re: [NSIS] GIST authentication >> >> >>> Hi Etienne, >>> >>> marganne etienne wrote: >>> >>>> Hi Hannes, >>>> >>>> Well, indeed i was thinking about all cases that could let a GIST/NSIS >>>> node being unthrustable. >>> >>> >>> I try to avoid the term "trust" in the meanwhile since it turns out to >>> be a placeholder for many other terms. >>> >>> >>>> If such a node gets added to a NSIS path through a GIST exchange (i.e. >>>> while the path is being built), it will be hard to dectect it and >>>> therefore hard to remove. >>> >>> >>> With the path-coupled MRM a node is only added if >>> - it supports the signaling application in question >>> - it sees the signaling messages (discovery messages) >>> >>> >>>> That could happen for example in the cases you talked about : >>>> >>>> - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice >>>> versas) >>>> Is it impossible ? I do not think so, but it is not really important if >>>> we can be sure that it will act correctly according to what it claims >>>> to be. >>> >>> >>> This is certainly not an impossible scenario but somewhat hard to >>> prevent. We have written a paper about this aspect some time ago and we >>> were not sure whether this is really something to worry about: >>> >>> C. Aoun, et al.: "Securing Middlebox Discovery for Path-Directed >>> Signaling in the Internet", in 5th Workshop on Applications and Services >>> in Wireless Networks (ASWN), June 29th - July 1st, 2005. >>> >>> >>> There is also a draft that talks about some of the issues listed in the >>> paper (e.g., 3GPP GBA). >>> http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-gist-security-00.txt >>> >>> >>>> - a malicious NSIS node redirects signaling messages to an off-path >>>> NSIS node >>>> This is clearly what i was thinking about. Such nodes that redirects >>>> messages, in a way that it will break the end-to-end security are >>>> dangerous. >>> >>> >>> This threat is actually prevented with the help of cookies if the >>> off-path node is not aware of this re-direction attempt. >>> >>> Note that the term "end-to-end" security basically means between >>> neighboring GIST hops (since this is the end of the communication). >>> >>> >>>> As far as i have seen, there are nothing to authenticate GIST nodes. >>> >>> >>> Actually, Transport Layer Security provides the ability to authenticate >>> GIST nodes. >>> >>> >>>> If still there could be authorization tokens at the NSIS level, there >>>> is nothing similar for GIST, once again as far as i know. >>> >>> >>> True, there are no authorization tokens at the GIST layer. The >>> authorization tokens typically need to have some content to ensure that >>> the authorization token are meaningful. This semantic is available at >>> the signaling application layer. Hence, we have the tokens there. >>> >>> >>> >>> >>>> - an NSIS node along the path becomes malicious? >>>> In some kinds of way this is the same problem. How to be sure that they >>>> will act correctly ? >>> >>> >>> Detecting that a node acts malicious is difficult: Try to compile a >>> complete list of incorrect behavior for, e.g., a QoS NSLP node. >>> >>> Ciao >>> Hannes >>> >>>> >>>> Thanks, >>>> >>>> Marganne Etienne >>>> ----- Original Message ----- From: "Hannes Tschofenig" >>>> >>>> To: "marganne etienne" >>>> Cc: >>>> Sent: Tuesday, March 28, 2006 9:40 AM >>>> Subject: Re: [NSIS] GIST authentication >>>> >>>> >>>>> Hi Etienne, >>>>> >>>>> please find my comments inline: >>>>> >>>>> marganne etienne wrote: >>>>> >>>>>> Hello everybody, >>>>>> I currently am a student ending my informatic engineer studies and i >>>>>> am studying NSIS and GIST through my end of study project. The topic >>>>>> is the use of NSIS to provide VoIP with a signaling protocol to >>>>>> correctly configure the bindings in NAT's and Firewalls. The question >>>>>> i have is about authentication of GIST adjacent nodes in a NSIS path, >>>>>> i did not see any mechanisms to ensure we do not add unthrustable >>>>>> nodes. >>>>> >>>>> >>>>> >>>>> Let me try to phrase what I think you are saying. You are concerned >>>>> that >>>>> - an ordinary router (i.e., non-NSIS node) claims to be an NSIS node >>>>> - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice >>>>> versas) >>>>> - a malicious NSIS node redirects signaling messages to an off-path >>>>> NSIS node >>>>> - an NSIS node along the path becomes malicious? >>>>> >>>>> Maybe you could elaborate a little bit more about your concern. >>>>> >>>>>> I could be wrong and the answer could just be lying aroung. Anyway it >>>>>> think this is a big concern in security to be sure of the list of >>>>>> nodes member of the NSIS data path. >>>>>> Thank you for reading, i hope to hear from you soon, >>>>>> Marganne Etienne. >>>>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 28 07:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FODP4-00022K-DP; Tue, 28 Mar 2006 07:34:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FODP3-00020q-B7 for nsis@ietf.org; Tue, 28 Mar 2006 07:34:29 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FODP1-0000e1-FK for nsis@ietf.org; Tue, 28 Mar 2006 07:34:29 -0500 Received: (qmail invoked by alias); 28 Mar 2006 12:34:24 -0000 Received: from p5498771F.dip.t-dialin.net (EHLO [192.168.2.102]) [84.152.119.31] by mail.gmx.net (mp017) with SMTP; 28 Mar 2006 14:34:24 +0200 X-Authenticated: #29516787 Message-ID: <44292D4E.9030708@gmx.net> Date: Tue, 28 Mar 2006 06:34:22 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marganne etienne Subject: Re: [NSIS] GIST authentication References: <01c101c65231$d656dd90$0401a8c0@unicornia1dd09> <4428E865.5080201@gmx.net> <01d101c6523d$393d28f0$0401a8c0@unicornia1dd09> <4428F404.1020301@gmx.net> <01de01c65246$5b9cf840$0401a8c0@unicornia1dd09> <442903D9.7050704@gmx.net> <020201c6524f$ffa56040$0401a8c0@unicornia1dd09> In-Reply-To: <020201c6524f$ffa56040$0401a8c0@unicornia1dd09> 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: 441f623df000f14368137198649cb083 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 Etienne, please find a few comments below: marganne etienne wrote: > Hi everybody, > > Here is the discussion with Hannes about GIST. Some part of the content > were already posted by not all, so now it is done. > > So as Mr Tschofenig said, there are no need of GIST nodes over the > Internet to be present to get a NSIS session work properly. I agree with > this.The problem now is this one : > > There is, however, an authorization question. Take a look at the figure > below: > > +----------------------+ +--------------------------+ > | Network A | | Network B | > | | | | > | +---------+ +---------+ | > | +-///-+ Middle- | | Middle- +-///-+ | > | | | box 1 | No TLS | box 2 | | | > | | +---------+ +---------+ | | > | | | | | | > | | | | | | > | | TLS | | | TLS | > | +--+---+ | | +--+---+ | > | | Host | | | | Host | | > | | A | | | | B | | > | +------+ | | +------+ | > +----------------------+ +--------------------------+ > > The following question arises: Why should Middlebox 2 authorize the > signaling message to traverse the firewall towards Host B? > > To what Mr Tschofenig answered : > We came up with a few solutions (a deployment issue, however): > - Delayed authorization (described in the main NATFW NSLP draft) > - Authorization Tokens (described in a separate draft) > - AAA interaction: Diameter has been used by a few SDOs to authorize the > firewall request based on previous SIP interaction (in the same > fashion as proposed for QoS signaling). > > > Now what i think is : if there is no need of GIST hops between a NSIS > communication work and transmitting an authorization token could solve > the authorization question, what could be the role of GIST in such cases > ? From a GIST point of view Middlebox 2 appears to be the next GIST node along the path when Middlebox 1 sends a discovery message. The authorization token, if you want to use something like this, is provided by the QoS and the NATFW NSLP node. > Also this scheme : > - Two end hosts trying to communicate and open bindings in Firewall with > the help of NSIS but without and GIST hops on the Internet between them. > - The authorization problem solved by an authorization token delivered, > let's say by SIP. > - The authentication problem solved by TLS or something similar (i.e. > adding an authentication part to NSIS messages at the beginning of > session, to authenticate a particular session ID wich is supposed to be > unique) > > This scheme, then, is a least a bit similar to ICE with the Media > Session Authorization. Are you referring to draft-wing-session-auth-00? > There are of course differences, but i think at > least it looks similar. Looks similar? Hmmm. Ping Pan and Henning Schulzrinne proposed YESSIR many years ago that suggested to use a path-coupled signaling protocol (namely RTCP) as a QoS and Firewall signaling protocol with the same characteristics. The authorization token usage is also known for many-many years. > ICE provides the connectivity and MSA a way to > authenticate and authorize the session data flow. What is the MSA? > One of the differences > is that ICE do not use something similar to GIST, i mean there is only > one layer... also i could be wrong. It is true that ICE does not use GIST. It does not use a layering concept because it was not meant to be used for different usage scenarios. ICE itself is only an algorithm that uses different protocols. In fact it would make sense to use the NAT/FW protocol as one of the protocols that ICE could make use for traversing NATs and Firewalls. > > Another little question : is there a way to re-use GIST states built by > QOS NSLP with NAT/FW NSLP and the opposite ? You can reuse state established by GIST for other signaling applications. For example, if there is a messaging association between two GIST nodes then there is no need to setup a new one if the characteristics are the same. > > Thank you for reading, > Ciao Hannes > Marganne Etienne. > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: "marganne etienne" > Sent: Tuesday, March 28, 2006 11:37 AM > Subject: Re: [NSIS] GIST authentication > > >> Hi Etienne, >> >> marganne etienne wrote: >> >>> Hi Hannes, >>> >>> So since there are TLS and the cookies, the GIST hops can be >>> authenticate. Now i have another question : >>> Let's say we use NSIS NAT/FW NSLP to open bindings in Firewalls >>> located at the edges of two subnets. Let's say there are no GIST >>> aware nodes to create a path between both sides. Somthing like this : >>> >>> NSIS Proxy -- Firewall 1 ---- Internet ---- Firewall 2 --- NSIS Proxy >>> >>> Will it be possible to open the bindings, if both knows their IP >>> adresses ? Or is it absolutly necessary to have some GIST nodes on the >>> internet to create a path ? >> >> >> No, that's not necessary. >> >> >> Btw, in your figure above it would be possible to have something like: >> >> End Host -- Firewall 1 ---- Internet ---- Firewall 2 --- End Host >> >> >> (there are supposed to have several hops on >> >>> the Internet between the two sides.) If there is a need for several >>> GIST/NSIS nodes to be present on the net then there could be some >>> problems with the installation of NSIS because one could have to >>> install a lot of those GIST aware hops over the Internet. >> >> This would indeed be a deployment problem. Hence, it is not necessary. >> >> There is, however, an authorization question. Take a look at the >> figure below: >> >> +----------------------+ +--------------------------+ >> | Network A | | Network B | >> | | | | >> | +---------+ +---------+ | >> | +-///-+ Middle- | | Middle- +-///-+ | >> | | | box 1 | No TLS | box 2 | | | >> | | +---------+ +---------+ | | >> | | | | | | >> | | | | | | >> | | TLS | | | TLS | >> | +--+---+ | | +--+---+ | >> | | Host | | | | Host | | >> | | A | | | | B | | >> | +------+ | | +------+ | >> +----------------------+ +--------------------------+ >> >> The following question arises: Why should Middlebox 2 authorize the >> signaling message to traverse the firewall towards Host B? >> We came up with a few solutions (a deployment issue, however): >> - Delayed authorization (described in the main NATFW NSLP draft) >> - Authorization Tokens (described in a separate draft) >> - AAA interaction: Diameter has been used by a few SDOs to authorize >> the firewall request based on previous SIP interaction (in the same >> fashion as proposed for QoS signaling). >> >> Ciao >> Hannes >> >>> >>> Thank you, >>> >>> Marganne Etienne. >>> >>> ----- Original Message ----- From: "Hannes Tschofenig" >>> >>> To: "marganne etienne" >>> Sent: Tuesday, March 28, 2006 10:29 AM >>> Subject: Re: [NSIS] GIST authentication >>> >>> >>>> Hi Etienne, >>>> >>>> marganne etienne wrote: >>>> >>>>> Hi Hannes, >>>>> >>>>> Well, indeed i was thinking about all cases that could let a >>>>> GIST/NSIS node being unthrustable. >>>> >>>> >>>> >>>> I try to avoid the term "trust" in the meanwhile since it turns out >>>> to be a placeholder for many other terms. >>>> >>>> >>>>> If such a node gets added to a NSIS path through a GIST exchange >>>>> (i.e. while the path is being built), it will be hard to dectect it >>>>> and therefore hard to remove. >>>> >>>> >>>> >>>> With the path-coupled MRM a node is only added if >>>> - it supports the signaling application in question >>>> - it sees the signaling messages (discovery messages) >>>> >>>> >>>>> That could happen for example in the cases you talked about : >>>>> >>>>> - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice >>>>> versas) >>>>> Is it impossible ? I do not think so, but it is not really >>>>> important if we can be sure that it will act correctly according to >>>>> what it claims to be. >>>> >>>> >>>> >>>> This is certainly not an impossible scenario but somewhat hard to >>>> prevent. We have written a paper about this aspect some time ago and >>>> we were not sure whether this is really something to worry about: >>>> >>>> C. Aoun, et al.: "Securing Middlebox Discovery for Path-Directed >>>> Signaling in the Internet", in 5th Workshop on Applications and >>>> Services in Wireless Networks (ASWN), June 29th - July 1st, 2005. >>>> >>>> >>>> There is also a draft that talks about some of the issues listed in >>>> the paper (e.g., 3GPP GBA). >>>> http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-gist-security-00.txt >>>> >>>> >>>> >>>>> - a malicious NSIS node redirects signaling messages to an off-path >>>>> NSIS node >>>>> This is clearly what i was thinking about. Such nodes that >>>>> redirects messages, in a way that it will break the end-to-end >>>>> security are dangerous. >>>> >>>> >>>> >>>> This threat is actually prevented with the help of cookies if the >>>> off-path node is not aware of this re-direction attempt. >>>> >>>> Note that the term "end-to-end" security basically means between >>>> neighboring GIST hops (since this is the end of the communication). >>>> >>>> >>>>> As far as i have seen, there are nothing to authenticate GIST nodes. >>>> >>>> >>>> >>>> Actually, Transport Layer Security provides the ability to >>>> authenticate GIST nodes. >>>> >>>> >>>>> If still there could be authorization tokens at the NSIS level, >>>>> there is nothing similar for GIST, once again as far as i know. >>>> >>>> >>>> >>>> True, there are no authorization tokens at the GIST layer. The >>>> authorization tokens typically need to have some content to ensure >>>> that the authorization token are meaningful. This semantic is >>>> available at the signaling application layer. Hence, we have the >>>> tokens there. >>>> >>>> >>>> >>>> >>>>> - an NSIS node along the path becomes malicious? >>>>> In some kinds of way this is the same problem. How to be sure that >>>>> they will act correctly ? >>>> >>>> >>>> >>>> Detecting that a node acts malicious is difficult: Try to compile a >>>> complete list of incorrect behavior for, e.g., a QoS NSLP node. >>>> >>>> Ciao >>>> Hannes >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Marganne Etienne >>>>> ----- Original Message ----- From: "Hannes Tschofenig" >>>>> >>>>> To: "marganne etienne" >>>>> Cc: >>>>> Sent: Tuesday, March 28, 2006 9:40 AM >>>>> Subject: Re: [NSIS] GIST authentication >>>>> >>>>> >>>>>> Hi Etienne, >>>>>> >>>>>> please find my comments inline: >>>>>> >>>>>> marganne etienne wrote: >>>>>> >>>>>>> Hello everybody, >>>>>>> I currently am a student ending my informatic engineer studies >>>>>>> and i am studying NSIS and GIST through my end of study project. >>>>>>> The topic is the use of NSIS to provide VoIP with a signaling >>>>>>> protocol to correctly configure the bindings in NAT's and >>>>>>> Firewalls. The question i have is about authentication of GIST >>>>>>> adjacent nodes in a NSIS path, i did not see any mechanisms to >>>>>>> ensure we do not add unthrustable nodes. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Let me try to phrase what I think you are saying. You are >>>>>> concerned that >>>>>> - an ordinary router (i.e., non-NSIS node) claims to be an NSIS node >>>>>> - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or >>>>>> vice versas) >>>>>> - a malicious NSIS node redirects signaling messages to an >>>>>> off-path NSIS node >>>>>> - an NSIS node along the path becomes malicious? >>>>>> >>>>>> Maybe you could elaborate a little bit more about your concern. >>>>>> >>>>>>> I could be wrong and the answer could just be lying aroung. >>>>>>> Anyway it think this is a big concern in security to be sure of >>>>>>> the list of nodes member of the NSIS data path. >>>>>>> Thank you for reading, i hope to hear from you soon, >>>>>>> Marganne Etienne. >>>>>>> >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 28 08:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEft-0001Bh-E8; Tue, 28 Mar 2006 08:55:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEfs-0001Bc-Hp for nsis@ietf.org; Tue, 28 Mar 2006 08:55:56 -0500 Received: from outmx023.isp.belgacom.be ([195.238.4.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOEfq-0003NK-OI for nsis@ietf.org; Tue, 28 Mar 2006 08:55:56 -0500 Received: from outmx023.isp.belgacom.be (localhost [127.0.0.1]) by outmx023.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k2SDtiSD010854 for ; Tue, 28 Mar 2006 15:55:45 +0200 (envelope-from ) Received: from unicornia1dd09 (194.100-200-80.adsl.skynet.be [80.200.100.194]) by outmx023.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with SMTP id k2SDtVnx010629; Tue, 28 Mar 2006 15:55:34 +0200 (envelope-from ) Message-ID: <00a201c6526f$506c9a60$0401a8c0@unicornia1dd09> From: "marganne etienne" To: "Hannes Tschofenig" References: <01c101c65231$d656dd90$0401a8c0@unicornia1dd09> <4428E865.5080201@gmx.net> <01d101c6523d$393d28f0$0401a8c0@unicornia1dd09> <4428F404.1020301@gmx.net> <01de01c65246$5b9cf840$0401a8c0@unicornia1dd09> <442903D9.7050704@gmx.net> <020201c6524f$ffa56040$0401a8c0@unicornia1dd09> <44292D4E.9030708@gmx.net> Subject: Re: [NSIS] GIST authentication Date: Tue, 28 Mar 2006 15:55:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 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 Hello, I was indeed refering to http://www.ietf.org/internet-drafts/draft-wing-session-auth-00.txt when talking about Media Session Authorization (MSA). I would like to thank you for your help. You made things clearer. Marganne Etienne. ----- Original Message ----- From: "Hannes Tschofenig" To: "marganne etienne" Cc: Sent: Tuesday, March 28, 2006 2:34 PM Subject: Re: [NSIS] GIST authentication > Hi Etienne, > > please find a few comments below: > > marganne etienne wrote: >> Hi everybody, >> >> Here is the discussion with Hannes about GIST. Some part of the content >> were already posted by not all, so now it is done. >> >> So as Mr Tschofenig said, there are no need of GIST nodes over the >> Internet to be present to get a NSIS session work properly. I agree with >> this.The problem now is this one : >> >> There is, however, an authorization question. Take a look at the figure >> below: >> >> +----------------------+ +--------------------------+ >> | Network A | | Network B | >> | | | | >> | +---------+ +---------+ | >> | +-///-+ Middle- | | Middle- +-///-+ | >> | | | box 1 | No TLS | box 2 | | | >> | | +---------+ +---------+ | | >> | | | | | | >> | | | | | | >> | | TLS | | | TLS | >> | +--+---+ | | +--+---+ | >> | | Host | | | | Host | | >> | | A | | | | B | | >> | +------+ | | +------+ | >> +----------------------+ +--------------------------+ >> >> The following question arises: Why should Middlebox 2 authorize the >> signaling message to traverse the firewall towards Host B? >> >> To what Mr Tschofenig answered : >> We came up with a few solutions (a deployment issue, however): >> - Delayed authorization (described in the main NATFW NSLP draft) >> - Authorization Tokens (described in a separate draft) >> - AAA interaction: Diameter has been used by a few SDOs to authorize the >> firewall request based on previous SIP interaction (in the same >> fashion as proposed for QoS signaling). >> >> >> Now what i think is : if there is no need of GIST hops between a NSIS >> communication work and transmitting an authorization token could solve >> the authorization question, what could be the role of GIST in such cases >> ? > > From a GIST point of view Middlebox 2 appears to be the next GIST node > along the path when Middlebox 1 sends a discovery message. > > The authorization token, if you want to use something like this, is > provided by the QoS and the NATFW NSLP node. > >> Also this scheme : >> - Two end hosts trying to communicate and open bindings in Firewall with >> the help of NSIS but without and GIST hops on the Internet between them. >> - The authorization problem solved by an authorization token delivered, >> let's say by SIP. >> - The authentication problem solved by TLS or something similar (i.e. >> adding an authentication part to NSIS messages at the beginning of >> session, to authenticate a particular session ID wich is supposed to be >> unique) >> >> This scheme, then, is a least a bit similar to ICE with the Media Session >> Authorization. > > Are you referring to draft-wing-session-auth-00? > >> There are of course differences, but i think at least it looks similar. > > Looks similar? Hmmm. > > Ping Pan and Henning Schulzrinne proposed YESSIR many years ago that > suggested to use a path-coupled signaling protocol (namely RTCP) as a QoS > and Firewall signaling protocol with the same characteristics. The > authorization token usage is also known for many-many years. > >> ICE provides the connectivity and MSA a way to authenticate and authorize >> the session data flow. > > What is the MSA? > >> One of the differences is that ICE do not use something similar to GIST, >> i mean there is only one layer... also i could be wrong. > It is true that ICE does not use GIST. It does not use a layering concept > because it was not meant to be used for different usage scenarios. > > ICE itself is only an algorithm that uses different protocols. In fact it > would make sense to use the NAT/FW protocol as one of the protocols that > ICE could make use for traversing NATs and Firewalls. > >> >> Another little question : is there a way to re-use GIST states built by >> QOS NSLP with NAT/FW NSLP and the opposite ? > > You can reuse state established by GIST for other signaling applications. > For example, if there is a messaging association between two GIST nodes > then there is no need to setup a new one if the characteristics are the > same. > >> >> Thank you for reading, >> > > Ciao > Hannes > >> Marganne Etienne. >> >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: "marganne etienne" >> Sent: Tuesday, March 28, 2006 11:37 AM >> Subject: Re: [NSIS] GIST authentication >> >> >>> Hi Etienne, >>> >>> marganne etienne wrote: >>> >>>> Hi Hannes, >>>> >>>> So since there are TLS and the cookies, the GIST hops can be >>>> authenticate. Now i have another question : >>>> Let's say we use NSIS NAT/FW NSLP to open bindings in Firewalls located >>>> at the edges of two subnets. Let's say there are no GIST aware nodes to >>>> create a path between both sides. Somthing like this : >>>> >>>> NSIS Proxy -- Firewall 1 ---- Internet ---- Firewall 2 --- NSIS Proxy >>>> >>>> Will it be possible to open the bindings, if both knows their IP >>>> adresses ? Or is it absolutly necessary to have some GIST nodes on the >>>> internet to create a path ? >>> >>> >>> No, that's not necessary. >>> >>> >>> Btw, in your figure above it would be possible to have something like: >>> >>> End Host -- Firewall 1 ---- Internet ---- Firewall 2 --- End Host >>> >>> >>> (there are supposed to have several hops on >>> >>>> the Internet between the two sides.) If there is a need for several >>>> GIST/NSIS nodes to be present on the net then there could be some >>>> problems with the installation of NSIS because one could have to >>>> install a lot of those GIST aware hops over the Internet. >>> >>> This would indeed be a deployment problem. Hence, it is not necessary. >>> >>> There is, however, an authorization question. Take a look at the figure >>> below: >>> >>> +----------------------+ +--------------------------+ >>> | Network A | | Network B | >>> | | | | >>> | +---------+ +---------+ | >>> | +-///-+ Middle- | | Middle- +-///-+ | >>> | | | box 1 | No TLS | box 2 | | | >>> | | +---------+ +---------+ | | >>> | | | | | | >>> | | | | | | >>> | | TLS | | | TLS | >>> | +--+---+ | | +--+---+ | >>> | | Host | | | | Host | | >>> | | A | | | | B | | >>> | +------+ | | +------+ | >>> +----------------------+ +--------------------------+ >>> >>> The following question arises: Why should Middlebox 2 authorize the >>> signaling message to traverse the firewall towards Host B? >>> We came up with a few solutions (a deployment issue, however): >>> - Delayed authorization (described in the main NATFW NSLP draft) >>> - Authorization Tokens (described in a separate draft) >>> - AAA interaction: Diameter has been used by a few SDOs to authorize the >>> firewall request based on previous SIP interaction (in the same fashion >>> as proposed for QoS signaling). >>> >>> Ciao >>> Hannes >>> >>>> >>>> Thank you, >>>> >>>> Marganne Etienne. >>>> >>>> ----- Original Message ----- From: "Hannes Tschofenig" >>>> >>>> To: "marganne etienne" >>>> Sent: Tuesday, March 28, 2006 10:29 AM >>>> Subject: Re: [NSIS] GIST authentication >>>> >>>> >>>>> Hi Etienne, >>>>> >>>>> marganne etienne wrote: >>>>> >>>>>> Hi Hannes, >>>>>> >>>>>> Well, indeed i was thinking about all cases that could let a >>>>>> GIST/NSIS node being unthrustable. >>>>> >>>>> >>>>> >>>>> I try to avoid the term "trust" in the meanwhile since it turns out to >>>>> be a placeholder for many other terms. >>>>> >>>>> >>>>>> If such a node gets added to a NSIS path through a GIST exchange >>>>>> (i.e. while the path is being built), it will be hard to dectect it >>>>>> and therefore hard to remove. >>>>> >>>>> >>>>> >>>>> With the path-coupled MRM a node is only added if >>>>> - it supports the signaling application in question >>>>> - it sees the signaling messages (discovery messages) >>>>> >>>>> >>>>>> That could happen for example in the cases you talked about : >>>>>> >>>>>> - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice >>>>>> versas) >>>>>> Is it impossible ? I do not think so, but it is not really important >>>>>> if we can be sure that it will act correctly according to what it >>>>>> claims to be. >>>>> >>>>> >>>>> >>>>> This is certainly not an impossible scenario but somewhat hard to >>>>> prevent. We have written a paper about this aspect some time ago and >>>>> we were not sure whether this is really something to worry about: >>>>> >>>>> C. Aoun, et al.: "Securing Middlebox Discovery for Path-Directed >>>>> Signaling in the Internet", in 5th Workshop on Applications and >>>>> Services in Wireless Networks (ASWN), June 29th - July 1st, 2005. >>>>> >>>>> >>>>> There is also a draft that talks about some of the issues listed in >>>>> the paper (e.g., 3GPP GBA). >>>>> http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-gist-security-00.txt >>>>> >>>>> >>>>>> - a malicious NSIS node redirects signaling messages to an off-path >>>>>> NSIS node >>>>>> This is clearly what i was thinking about. Such nodes that redirects >>>>>> messages, in a way that it will break the end-to-end security are >>>>>> dangerous. >>>>> >>>>> >>>>> >>>>> This threat is actually prevented with the help of cookies if the >>>>> off-path node is not aware of this re-direction attempt. >>>>> >>>>> Note that the term "end-to-end" security basically means between >>>>> neighboring GIST hops (since this is the end of the communication). >>>>> >>>>> >>>>>> As far as i have seen, there are nothing to authenticate GIST nodes. >>>>> >>>>> >>>>> >>>>> Actually, Transport Layer Security provides the ability to >>>>> authenticate GIST nodes. >>>>> >>>>> >>>>>> If still there could be authorization tokens at the NSIS level, there >>>>>> is nothing similar for GIST, once again as far as i know. >>>>> >>>>> >>>>> >>>>> True, there are no authorization tokens at the GIST layer. The >>>>> authorization tokens typically need to have some content to ensure >>>>> that the authorization token are meaningful. This semantic is >>>>> available at the signaling application layer. Hence, we have the >>>>> tokens there. >>>>> >>>>> >>>>> >>>>> >>>>>> - an NSIS node along the path becomes malicious? >>>>>> In some kinds of way this is the same problem. How to be sure that >>>>>> they will act correctly ? >>>>> >>>>> >>>>> >>>>> Detecting that a node acts malicious is difficult: Try to compile a >>>>> complete list of incorrect behavior for, e.g., a QoS NSLP node. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Marganne Etienne >>>>>> ----- Original Message ----- From: "Hannes Tschofenig" >>>>>> >>>>>> To: "marganne etienne" >>>>>> Cc: >>>>>> Sent: Tuesday, March 28, 2006 9:40 AM >>>>>> Subject: Re: [NSIS] GIST authentication >>>>>> >>>>>> >>>>>>> Hi Etienne, >>>>>>> >>>>>>> please find my comments inline: >>>>>>> >>>>>>> marganne etienne wrote: >>>>>>> >>>>>>>> Hello everybody, >>>>>>>> I currently am a student ending my informatic engineer studies and >>>>>>>> i am studying NSIS and GIST through my end of study project. The >>>>>>>> topic is the use of NSIS to provide VoIP with a signaling protocol >>>>>>>> to correctly configure the bindings in NAT's and Firewalls. The >>>>>>>> question i have is about authentication of GIST adjacent nodes in a >>>>>>>> NSIS path, i did not see any mechanisms to ensure we do not add >>>>>>>> unthrustable nodes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Let me try to phrase what I think you are saying. You are concerned >>>>>>> that >>>>>>> - an ordinary router (i.e., non-NSIS node) claims to be an NSIS node >>>>>>> - a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice >>>>>>> versas) >>>>>>> - a malicious NSIS node redirects signaling messages to an off-path >>>>>>> NSIS node >>>>>>> - an NSIS node along the path becomes malicious? >>>>>>> >>>>>>> Maybe you could elaborate a little bit more about your concern. >>>>>>> >>>>>>>> I could be wrong and the answer could just be lying aroung. Anyway >>>>>>>> it think this is a big concern in security to be sure of the list >>>>>>>> of nodes member of the NSIS data path. >>>>>>>> Thank you for reading, i hope to hear from you soon, >>>>>>>> Marganne Etienne. >>>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 28 12:36:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOI7C-0001kK-ME; Tue, 28 Mar 2006 12:36:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOI7C-0001kF-2B for nsis@ietf.org; Tue, 28 Mar 2006 12:36:22 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOI7A-00058Y-G6 for nsis@ietf.org; Tue, 28 Mar 2006 12:36:22 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2SHa4TG010399; Tue, 28 Mar 2006 18:36:06 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Mar 2006 18:36:04 +0100 Message-ID: <44245138.8010705@roke.co.uk> Date: Fri, 24 Mar 2006 20:06:16 +0000 From: Andrew McDonald User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gash@att.com, nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2006 17:36:04.0385 (UTC) FILETIME=[168D9910:01C6528E] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [NSIS] Version number in QSpec 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 noticed that the QSpec Template defines a version number as part of the QSpec definition. However, the draft does not specify what to do if you receive a QSpec for a different version than the one you support. Also, what criteria should be used when defining a new QSpec version? Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Mar 28 13:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIwF-00065x-VW; Tue, 28 Mar 2006 13:29:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIwE-00065s-NW for nsis@ietf.org; Tue, 28 Mar 2006 13:29:06 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIwC-0008BH-G6 for nsis@ietf.org; Tue, 28 Mar 2006 13:29:06 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 28 Mar 2006 13:28:52 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006032813285215955 ; Tue, 28 Mar 2006 13:28:52 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 13:28:52 -0500 Message-Id: From: "Roy, Radhika R." To: Andrew McDonald , gash@att.com, nsis@ietf.org Subject: RE: [NSIS] Version number in QSpec Date: Tue, 28 Mar 2006 13:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: john.loughney@nokia.com 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 Andrew: In addition, I also provided some comments. BR/Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Andrew McDonald Sent: Friday, March 24, 2006 3:06 PM To: gash@att.com; nsis@ietf.org Subject: [NSIS] Version number in QSpec Hi, I noticed that the QSpec Template defines a version number as part of the QSpec definition. However, the draft does not specify what to do if you receive a QSpec for a different version than the one you support. Also, what criteria should be used when defining a new QSpec version? 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 28 13:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJFe-0001Qc-MV; Tue, 28 Mar 2006 13:49:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJFd-0001QX-CO for nsis@ietf.org; Tue, 28 Mar 2006 13:49:09 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOJFc-0000kM-18 for nsis@ietf.org; Tue, 28 Mar 2006 13:49:09 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1143571722!9853323!12 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24243 invoked from network); 28 Mar 2006 18:49:06 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 28 Mar 2006 18:49:06 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE0004A5B1; Tue, 28 Mar 2006 13:49:06 -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] Version number in QSpec Date: Tue, 28 Mar 2006 12:49:05 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC75BC@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Version number in QSpec Thread-Index: AcZSlYKVCbToV0SnQfKMBwYNDUsuFgAAMWIw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "Ash, Gerald R \(Jerry\), ALABS" 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, See comments in line below. Thanks, Jerry > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of > Andrew McDonald > Sent: Friday, March 24, 2006 3:06 PM > To: gash@att.com; nsis@ietf.org > Subject: [NSIS] Version number in QSpec >=20 > Hi, >=20 > I noticed that the QSpec Template defines a version number as part of=20 > the QSpec definition. However, the draft does not specify what to do > if you receive a QSpec for a different version than the one you > support. Jerry> Good point, this should be added. This may require another error code if the version sent supersedes version supported, or requirement for backward compatibility with earlier versions if version supported supersedes version sent. > Also, what criteria should be used when defining a new QSpec version? Jerry> The following is specified in Section 9 (IANA Considerations) of http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt: "QSPEC Version (4 bits): The following value is allocated by this specification: 0: assigned to Version 0 QSPEC The allocation policies for further values are as follows: 1-15: Standards Action" Is something more required here? > Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 29 04:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOX8v-0004J5-L7; Wed, 29 Mar 2006 04:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOX8t-0004J0-Vj for nsis@ietf.org; Wed, 29 Mar 2006 04:39:07 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOX8p-0004Rs-Ij for nsis@ietf.org; Wed, 29 Mar 2006 04:39:07 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2T9csTG020357; Wed, 29 Mar 2006 10:38:54 +0100 Received: from [193.118.197.86] ([193.118.197.86]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 10:38:53 +0100 Message-ID: <442A55AD.8010304@roke.co.uk> Date: Wed, 29 Mar 2006 10:38:53 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] Version number in QSpec References: <9473683187ADC049A855ED2DA739ABCA0DDC75BC@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC75BC@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2006 09:38:54.0022 (UTC) FILETIME=[97F0A660:01C65314] X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 noticed that the QSpec Template defines a version number as part of >> the QSpec definition. However, the draft does not specify what to do >> if you receive a QSpec for a different version than the one you >> support. > > Jerry> Good point, this should be added. This may require another error > code if the version sent supersedes version supported, or requirement > for backward compatibility with earlier versions if version supported > supersedes version sent. > >> Also, what criteria should be used when defining a new QSpec version? > > Jerry> The following is specified in Section 9 (IANA Considerations) of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt: > > "QSPEC Version (4 bits): > The following value is allocated by this specification: > 0: assigned to Version 0 QSPEC > The allocation policies for further values are as follows: > 1-15: Standards Action" > > Is something more required here? That defines the formal actions that have to take place. I was also looking for some text that gives guidance to someone extending this in the future. When do I actually need to define a new version? do I have to define a new version whenever I add a new parameter? when I add a new mandatory parameter? for some other reason? Also, do new versions have to be backward compatible with old versions? e.g. do the mandatory parameters in a new version have to be a superset of those in the previous version? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Mar 29 07:48:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOa5o-0000Yo-Vs; Wed, 29 Mar 2006 07:48:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOa5o-0000Yj-6x for nsis@ietf.org; Wed, 29 Mar 2006 07:48:08 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOa5k-0002M9-T7 for nsis@ietf.org; Wed, 29 Mar 2006 07:48:08 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 29 Mar 2006 04:48:04 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2TCm3Gv002090; Wed, 29 Mar 2006 04:48:03 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id k2TCmZph028095; Wed, 29 Mar 2006 04:48:35 -0800 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A04D@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D0186A04D@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Can we do without Q-spec stacking? Date: Wed, 29 Mar 2006 07:47:59 -0500 To: "" X-Mailer: Apple Mail (2.746.3) DKIM-Signature: a=rsa-sha1; q=dns; l=2713; t=1143636516; x=1144068716; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Can=20we=20do=20without=20Q-spec=20stacking? |To:=20=20; X=v=3Dmtcc.com=3B=20h=3DQCabuVskNNyUexr0K4+ab0zdZgw=3D; b=Pe5PelwSGOwbA+JDxwCsQWFEyzW4mqQVdHmDhS/EZrxgkibceXs09dYHQ+1TXwM5AMgvJuBK KdBHfF8Qbgl5vXHb1NErYcxwrSxufuy79cPyNmpRChGFhWhh2evhgy7/kJmyH0+ZQtV73217nRh OhDXwelrDknzQcpWl9cP7HOQ=; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nsis@ietf.org, robert.hancock@roke.co.uk 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 19, 2006, at 11:21 AM, wrote: > Robert, > > Your suggestion seems like a very good simplification. I guess we > would need some text, but how do others feel. I think this would > make the QoS NSLP a good deal simpler. > > Comments? I think you might be able to predict where I'd come down on this design question :-) > John > >> -----Original Message----- >> From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk] >> Sent: 19 March, 2006 17:43 >> To: nsis@ietf.org >> Subject: [NSIS] Can we do without Q-spec stacking? >> >> Hi, >> >> I reviewed the QoS-NSLP on the flight yesterday and the above >> question occurred to me about half-way across. >> >> We introduced stacking [see below for historical background] >> as a means for accommodating localisation of the QoS >> specification within particular domains. I think that's still >> a legitimate goal. However, the specification now has another >> way to achieve the same thing, namely by creating a local >> signalling session and using the BOUND_SESSION_ID to correlate >> the two at the edges, with the e2e session ignored in the interior. >> >> I don't think it would take much work to eliminate the concept >> from the qos-nslp (I haven't checked the qspec yet). And I'm >> sure there would be tears of joy in some quarters. >> >> r. >> >> Background: >> For a trip down memory lane, check out section 4.4 of >> http://www.watersprings.org/pub/id/draft-hancock-nsis- >> framework-00.txt >> (from 2002...). At the time, the main advantage of the >> stacking approach was that domain boundary nodes could do all >> their processing on a single message rather than having to >> correlate messages of multiple sessions. However, it now turns >> out that we can't avoid that type of complexity for other >> reasons, including >> - any sort of aggregation (where you have to handle 1+N messages) >> - where the interior session needs uses different GIST transport >> characteristics (RMD) >> - where it is natural to hide the e2e session in the interior >> (tunnel e.g. for mobility/vpn scenarios) Given that session >> correlation is needed in all these other cases, the advantage >> of being able to do without it in a particular case basically >> vanishes. It's probably simpler to use a single mechanism to >> handle everything. >> >> >> _______________________________________________ >> 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