From nsis-bounces@ietf.org Wed Feb 01 04:22:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ECH-00011s-7v; Wed, 01 Feb 2006 04:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ECE-00010m-Pz; Wed, 01 Feb 2006 04:22:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25353; Wed, 1 Feb 2006 04:20:52 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ENC-0005c4-2X; Wed, 01 Feb 2006 04:34:00 -0500 Received: from [10.0.2.71] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 209AA1BAC4D; Wed, 1 Feb 2006 10:22:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) To: internet-drafts@ietf.org Message-Id: <693F04CA-6D96-4341-A14A-209FB3FCD751@netlab.nec.de> From: Martin Stiemerling Date: Wed, 1 Feb 2006 10:22:10 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: John Loughney , nsis Subject: [NSIS] Please post draft-ietf-nsis-nslp-natfw-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: , Content-Type: multipart/mixed; boundary="===============0525123508==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0525123508== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-68--582742727; protocol="application/pkcs7-signature" --Apple-Mail-68--582742727 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Please post the following document as working group Internet draft: ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp- natfw-09.txt Please announce the I-D Action also to the NSIS mailing list at nsis@ietf.org Thank you, Martin Stiemerling NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg WWW: http://www.netlab.nec.de --Apple-Mail-68--582742727 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMTA5MjIxMFowIwYJKoZIhvcNAQkEMRYEFJiD9B5G6wQ7WR7nNRoJ EK3MfwpDMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAHF8PmjlBzUrWV01zoUX JeeFJ0ow7mspXkqmeo7gA3+gPpTAiBeITBCOzvFBUzG4i/YWdfYRRRlMqA5Zsyow/S7ACITeLDQL V5QRNhC1icR3QlJEOxsiFyryvLH9KCEO00sND4CwQJKCm3+1yz1e/Bwg5fnVqJCBAoypWcFaAoWS 2LZfMfY+1vdTsM/5a7YqzZts/B+Npfn9lmByy12//6CZd7RLolvcpmthiudZOMrg3JC5mreaxeTo zT7wfdblEJNfIJ7Rrs63bRZmuxqJjnGdu8+R6O27kze/PX7EP3T7OGyomRYJkSgEy7Mud/qfUcDE 2hwErmpSXSwVFdm62HwAAAAAAAA= --Apple-Mail-68--582742727-- --===============0525123508== 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 --===============0525123508==-- From nsis-bounces@ietf.org Wed Feb 01 05:01:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Eo0-000797-VI; Wed, 01 Feb 2006 05:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Emx-0006iC-Ae; Wed, 01 Feb 2006 05:00:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27884; Wed, 1 Feb 2006 04:58:47 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Exw-0006tA-KH; Wed, 01 Feb 2006 05:11:56 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0E4DE1BAC9E; Wed, 1 Feb 2006 11:00:15 +0100 (CET) Date: Wed, 01 Feb 2006 11:00:23 +0100 From: Juergen Quittek To: Martin Stiemerling , internet-drafts@ietf.org Subject: Re: [NSIS] Please post draft-ietf-nsis-nslp-natfw-09.txt Message-ID: <8DEC580CD1B6F88A1407B5EF@[10.1.1.171]> In-Reply-To: <693F04CA-6D96-4341-A14A-209FB3FCD751@netlab.nec.de> References: <693F04CA-6D96-4341-A14A-209FB3FCD751@netlab.nec.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: John Loughney , 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Martin, der Link in Deiner E-mail is nicht brauchbar. Vielleicht solltest Du sie noch einmal schicken? Juergen --On 2/1/06 10:22 AM +0100 Martin Stiemerling wrote: > Please post the following document as working group Internet draft: > > ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp- natfw-09.txt > > Please announce the I-D Action also to the NSIS mailing list at > nsis@ietf.org > > Thank you, > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de > PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg > WWW: http://www.netlab.nec.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 01 05:48:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4FXF-0007LC-GZ; Wed, 01 Feb 2006 05:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4FLQ-0005eM-L9 for nsis@megatron.ietf.org; Wed, 01 Feb 2006 05:36:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00281 for ; Wed, 1 Feb 2006 05:34:25 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4FWP-0007sa-KJ for nsis@ietf.org; Wed, 01 Feb 2006 05:47:34 -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 k11AZTRw026491; Wed, 1 Feb 2006 10:35:29 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] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 10:35:29 -0000 Message-ID: Thread-Topic: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Thread-Index: AcYm6LATftUy1dHASdWJnOZ16VtQ4gAMB2+g From: "Hancock, Robert" To: "Henning Peters" , "Martin Stiemerling" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, i can imagine interesting ICMP policy rules like - i want to be able to ping other people - i want to allow other people to ping me - i want to be able to do traceroute (receive timex) note that the first ping case implies outgoing type=3D8 and incoming type=3D0 and the second ping case implies the opposite. (the ICMP code - in rfc792 speak - is 0 in all cases.) certainly i can imagine wanting to be able to signal multiple types/codes in a coordinated way (and differently for incoming/outgoing packets). in other cases, the handling of ICMP messages is much more dependent on existing flows (other firewall state); e.g. "i'd like to receive ICMP unreachable/timex messages but only about flows which exist". (in fact, the traceroute case probably comes into this category also.) the implication of that would be that the firewall had to apply the policy based on the ICMP payload (which contains the flow packet header) and not the ICMP header itself. is there an obvious set of requirements for how to configure to configure firewalls for ICMP? the midcom documents seem 'light' on the ICMP front.=20 r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Henning Peters > Sent: 31 January 2006 18:01 > To: Martin Stiemerling > Cc: nsis > Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules >=20 >=20 > Hi Martin, >=20 > can you specify an application for the signaling of ICMP=20 > policy rules? Don't ICMP messages already refer to a certain=20 > data flow? I don't see a reason why a firewall or NAT should=20 > deny or drop them. And if they are configured to behave like=20 > this, a different configuration might not be wanted in the=20 > first place?! But probably the 3GPP2 guys already have sth.=20 > particular in mind that I am currently not seeing. >=20 > How does the change affect NAT? As this might have impacts on=20 > the (de)multiplexing behavior of NATs. >=20 > If adding a new code object to NAT/FW NSLP, allowing multiple=20 > codes in a single message might be valuable to save=20 > unnecessary signaling traffic. >=20 > > - For REA and REA-F, the "Data Terminal Information Object" must be=20 > > modified to carry the ICMP code. >=20 > Why do you want to have a new code object _and_ an additional=20 > code field in the DTInfo object? Wouldn't it make sense to=20 > set the protocol to ICMP in DTInfo protocol field and add the=20 > new ICMP code object regularly? >=20 > Henning >=20 >=20 > Martin Stiemerling sagte Di, 31.01.2006, 13:10: > > Dear all, > > > > The NSIS working group has received some request from a=20 > 3GPP2 working=20 > > group to add features to the NATFW NSLP, as said in my email sent=20 > > before. > > > > One of the features is the ability to signaling for ICMP=20 > policy rules.=20 > > Up to now, the NATFW NSLP can signal for IP only, TCP, and=20 > UDP flows=20 > > by using the NTLP path-coupled MRM and the LE-MRM. It's possible to=20 > > signal for ICMP flows by using the PC-MRM and setting the=20 > 'protocol'=20 > > field to 'ICMP'. However, it is currently not possible to specify=20 > > anything beyond that, for instance, the ICMP code to be used. > > > > Here is the proposed extension to the NATFW NSLP: > > - Add a new object 'icmp' that carries solely the ICMP code > > - This object can be included in CREATE messages where the NTLP is=20 > > carrying a MRM with IP addresses only, protocol set to ICMP. > > - For REA and REA-F, the "Data Terminal Information Object" must be=20 > > modified to carry the ICMP code. > > > > This proposed change does *NOT* require any change to the NTLP but > > *ONLY* to the NATFW NSLP. > > > > Any view on this? > > > > Thanks, > > > > Martin_______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 01 07:11:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Gpm-0006o3-SU; Wed, 01 Feb 2006 07:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Gpk-0006mi-RV for nsis@megatron.ietf.org; Wed, 01 Feb 2006 07:11:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10080 for ; Wed, 1 Feb 2006 07:10:00 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4H0s-0002CG-4e for nsis@ietf.org; Wed, 01 Feb 2006 07:23:09 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8B3321BAC4D for ; Wed, 1 Feb 2006 13:11:23 +0100 (CET) Date: Wed, 01 Feb 2006 13:11:30 +0100 From: Juergen Quittek To: nsis Subject: Re: [NSIS] Please post draft-ietf-nsis-nslp-natfw-09.txt Message-ID: In-Reply-To: <8DEC580CD1B6F88A1407B5EF@[10.1.1.171]> References: <693F04CA-6D96-4341-A14A-209FB3FCD751@netlab.nec.de> <8DEC580CD1B6F88A1407B5EF@[10.1.1.171]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, I'm sorry for posting the message below in German language to this mailing list. It was intended to be sent to Martin only. Sorry, Juergen --On 2/1/06 11:00 AM +0100 Juergen Quittek wrote: > Martin, > > der Link in Deiner E-mail is nicht brauchbar. > Vielleicht solltest Du sie noch einmal schicken? > > Juergen > > --On 2/1/06 10:22 AM +0100 Martin Stiemerling wrote: > >> Please post the following document as working group Internet draft: >> >> ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp- natfw-09.txt >> >> Please announce the I-D Action also to the NSIS mailing list at >> nsis@ietf.org >> >> Thank you, >> >> Martin Stiemerling >> >> NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de >> PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg >> WWW: http://www.netlab.nec.de > > > > _______________________________________________ > 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 Feb 01 08:22:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4HwE-0008E7-U5; Wed, 01 Feb 2006 08:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4HwC-0008Cr-JD for nsis@megatron.ietf.org; Wed, 01 Feb 2006 08:22:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23481 for ; Wed, 1 Feb 2006 08:20:40 -0500 (EST) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4I7K-0004vG-6L for nsis@ietf.org; Wed, 01 Feb 2006 08:33:50 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1F4Hvo-0002fp-VU; Wed, 01 Feb 2006 13:21:57 +0000 Message-ID: <43E0B675.5000304@dial.pipex.com> Date: Wed, 01 Feb 2006 13:24:05 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules 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: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi. v6ops has work in progress on this issue. I am editing a proposed BCP on ICMP filtering for IPv6 which is a bit more complex than the v4 case. http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt The next version (due out shortly) will provide an Appendix with example filtering rules. For looking at the v4 case it might be useful to review either Appendix A or the previous version of this document (available (e.g.) as http://www.watersprings.org/pub/id/draft-davies-v6ops-icmpv6-filtering-bcp-00.txt) which was structured differently, discussing the messages individually rather than looking at their the required treatment in the firewall. The discussion of why ICMP messages need to be passed or dropped provides requirements: the v4 case could be derived quite easily but is more about administrative policy than the v6 case, where the network will assuredly break if some ICMPv6 messages are dropped inappropriately, and the size of the addressing space makes ICMP-based scanning less attractive to hackers than for v4 networks. A major consideration for ICMP filtering is that many error messages are what are classified as 'any-to-end' as the source address can be any router on the path Sophisticated filtering needs to look at the addresses of the embedded errored packet, as mentioned by Robert, but that depends on the capabilities of the firewall. Regards, Elwyn Hancock, Robert wrote: >hi all, > >i can imagine interesting ICMP policy rules like >- i want to be able to ping other people >- i want to allow other people to ping me >- i want to be able to do traceroute (receive timex) > >note that the first ping case implies outgoing type=8 and incoming >type=0 and the second ping case implies the opposite. (the ICMP >code - in rfc792 speak - is 0 in all cases.) certainly i can imagine >wanting to be able to signal multiple types/codes in a coordinated >way (and differently for incoming/outgoing packets). > >in other cases, the handling of ICMP messages is much more dependent >on existing flows (other firewall state); e.g. "i'd like to receive >ICMP unreachable/timex messages but only about flows which exist". >(in fact, the traceroute case probably comes into this category also.) >the implication of that would be that the firewall had to apply the >policy based on the ICMP payload (which contains the flow packet header) >and not the ICMP header itself. > >is there an obvious set of requirements for how to configure to >configure firewalls for ICMP? the midcom documents seem 'light' >on the ICMP front. > >r. > > > >>-----Original Message----- >>From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>Behalf Of Henning Peters >>Sent: 31 January 2006 18:01 >>To: Martin Stiemerling >>Cc: nsis >>Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules >> >> >>Hi Martin, >> >>can you specify an application for the signaling of ICMP >>policy rules? Don't ICMP messages already refer to a certain >>data flow? I don't see a reason why a firewall or NAT should >>deny or drop them. And if they are configured to behave like >>this, a different configuration might not be wanted in the >>first place?! But probably the 3GPP2 guys already have sth. >>particular in mind that I am currently not seeing. >> >>How does the change affect NAT? As this might have impacts on >>the (de)multiplexing behavior of NATs. >> >>If adding a new code object to NAT/FW NSLP, allowing multiple >>codes in a single message might be valuable to save >>unnecessary signaling traffic. >> >> >> >>>- For REA and REA-F, the "Data Terminal Information Object" must be >>>modified to carry the ICMP code. >>> >>> >>Why do you want to have a new code object _and_ an additional >>code field in the DTInfo object? Wouldn't it make sense to >>set the protocol to ICMP in DTInfo protocol field and add the >>new ICMP code object regularly? >> >>Henning >> >> >>Martin Stiemerling sagte Di, 31.01.2006, 13:10: >> >> >>>Dear all, >>> >>>The NSIS working group has received some request from a >>> >>> >>3GPP2 working >> >> >>>group to add features to the NATFW NSLP, as said in my email sent >>>before. >>> >>>One of the features is the ability to signaling for ICMP >>> >>> >>policy rules. >> >> >>>Up to now, the NATFW NSLP can signal for IP only, TCP, and >>> >>> >>UDP flows >> >> >>>by using the NTLP path-coupled MRM and the LE-MRM. It's possible to >>>signal for ICMP flows by using the PC-MRM and setting the >>> >>> >>'protocol' >> >> >>>field to 'ICMP'. However, it is currently not possible to specify >>>anything beyond that, for instance, the ICMP code to be used. >>> >>>Here is the proposed extension to the NATFW NSLP: >>>- Add a new object 'icmp' that carries solely the ICMP code >>>- This object can be included in CREATE messages where the NTLP is >>>carrying a MRM with IP addresses only, protocol set to ICMP. >>>- For REA and REA-F, the "Data Terminal Information Object" must be >>>modified to carry the ICMP code. >>> >>>This proposed change does *NOT* require any change to the NTLP but >>>*ONLY* to the NATFW NSLP. >>> >>>Any view on this? >>> >>>Thanks, >>> >>> 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 >> >> >> > >_______________________________________________ >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 Feb 01 09:00:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IWl-0005LX-Iy; Wed, 01 Feb 2006 09:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IWh-0005Hm-8H for nsis@megatron.ietf.org; Wed, 01 Feb 2006 09:00:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01231 for ; Wed, 1 Feb 2006 08:58:18 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Ihj-0006l5-Pz for nsis@ietf.org; Wed, 01 Feb 2006 09:11:28 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8FA121BAC4D; Wed, 1 Feb 2006 14:59:44 +0100 (CET) In-Reply-To: <36694.134.76.81.25.1138730439.squirrel@mail.piranho.net> References: <36694.134.76.81.25.1138730439.squirrel@mail.piranho.net> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: <55FAA859-8EAD-4715-8828-FF799DCFA956@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 14:59:39 +0100 To: Henning Peters X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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: , Content-Type: multipart/mixed; boundary="===============1106620034==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1106620034== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--566093552; protocol="application/pkcs7-signature" --Apple-Mail-3--566093552 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Henning, all, by the way this issue has made it in the NATFW NSLP issue tracker: https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue60 More inline. Am 31.01.2006 um 19:00 schrieb Henning Peters: > Hi Martin, > > can you specify an application for the signaling of ICMP policy rules? > Don't ICMP messages already refer to a certain data flow? I don't > see a > reason why a firewall or NAT should deny or drop them. And if they are > configured to behave like this, a different configuration might not be > wanted in the first place?! But probably the 3GPP2 guys already > have sth. > particular in mind that I am currently not seeing. I do not know about the application 3GPP2 has in mind but in general it is a good idea to allow or deny ICMP messages in middleboxes. Focussing on the 3GPP2 case first: 3GPP2 assumes only firewalls in their network ('cause it is IPv6) and these firewalls are default-to-allow. All traffic is allowed to go in and out unhindered. A 3GPP2 mobile terminal will use the NATFW NSLP to request the blocking of particular data traffic coming out of the Internet towards the terminal, causing costs to the terminal user (it's all running wireless and you pay byte by byte, or feel directly when the link is filled with garbage). An unwanted traffic can be ICMP ECHO request messages sent by some to your terminal, in the worst case flooding your wireless link. This kind of traffic may not come from a single source, so that blocking of a single IP address would not solve the issue. Therefore, you will request to block all ICMP traffic in your upstream firewalls for any host, but let TCP and UDP through. Second, for hosts behind firewalls running default-to-deny and NATs. a) The host wants to send ICMP messages to other hosts but does not have a transport layer connection/state on the firewall, i.e., you ping a host to see if it is alive. In this case, the NATFW NSLP will request the downstream firewalls to open for ICMP traffic. This would bring back the old-style ICMP diagnosis to some people that are located behind very strictly configured firewalls and NATs b) A server located behind a NAT/firewalls running some sort of service, for instance, FTP, would like to be reachable for ICMP ECHO REQUEST packets. Some people running servers still like them to be reachable by ICMP, since this sometimes the only way to test remotely if the server is up and running. > > How does the change affect NAT? As this might have impacts on the > (de)multiplexing behavior of NATs. Right, but either the NAT can multiplex ICMP packets or it cannot. But this is not something the NATFW NSLP can change. For instance, OpenBSD's pf as NAT can do ICMP demultiplexing. Some other NATs probably can't do. > > If adding a new code object to NAT/FW NSLP, allowing multiple codes > in a > single message might be valuable to save unnecessary signaling > traffic. Could by a good way to aggregate. I have thing about it. Do you mind adding this to the issue 60 in the tracker? > >> - For REA and REA-F, the "Data Terminal Information Object" must be >> modified to carry the ICMP code. > > Why do you want to have a new code object _and_ an additional code > field > in the DTInfo object? Wouldn't it make sense to set the protocol to > ICMP > in DTInfo protocol field and add the new ICMP code object regularly? Yes, good idea. Do you mind adding this to the issue 60 in the tracker, so it does not get forgotten? Thanks, Martin > > Henning > > > Martin Stiemerling sagte Di, 31.01.2006, 13:10: >> Dear all, >> >> The NSIS working group has received some request from a 3GPP2 working >> group to add features to the NATFW NSLP, as said in my email sent >> before. >> >> One of the features is the ability to signaling for ICMP policy >> rules. Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP >> flows by using the NTLP path-coupled MRM and the LE-MRM. It's >> possible to signal for ICMP flows by using the PC-MRM and setting the >> 'protocol' field to 'ICMP'. However, it is currently not possible to >> specify anything beyond that, for instance, the ICMP code to be used. >> >> Here is the proposed extension to the NATFW NSLP: >> - Add a new object 'icmp' that carries solely the ICMP code >> - This object can be included in CREATE messages where the NTLP is >> carrying a MRM with IP addresses only, protocol set to ICMP. >> - For REA and REA-F, the "Data Terminal Information Object" must be >> modified to carry the ICMP code. >> >> This proposed change does *NOT* require any change to the NTLP but >> *ONLY* to the NATFW NSLP. >> >> Any view on this? >> >> Thanks, >> >> Martin_______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > --Apple-Mail-3--566093552 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMTEzNTkzOVowIwYJKoZIhvcNAQkEMRYEFASilYBCm3zw3HqXpJ6M UzIEpmMMMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAGa3N0t3GlVdBdcxw1uF b/3whSe6Ke4VEbDijLUfZ0YwPB4ShiWxSdi3nSTQ+VRLYaToEk+wMB/3/lED5WtNbwQbPtyz/6UU E79E5ZjyeymL7mbkyPH9y/bNKLHwCK2vcd8L14bX65Dfcn8NJwAtI2WxovyMcuhqt8rZzR0ER2od CBDsKiNpJxRgAuvCaPNwVdKZbb+YLOfLH9gH1Fb+rSZOaZO6qa5PwrKZH3ofidgCu3tRy7+BIbVL enZ5+zDdJjCt+tjRQUjSQwZKhTyjDA4LB8KWEkUg9bd49M2QO63qXoVoxdmDKW/wwJrKzTgrXOCh LFhNCRtj8YgOTwYL6GsAAAAAAAA= --Apple-Mail-3--566093552-- --===============1106620034== 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 --===============1106620034==-- From nsis-bounces@ietf.org Wed Feb 01 09:23:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ith-00045F-UH; Wed, 01 Feb 2006 09:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ite-0003yK-RJ for nsis@megatron.ietf.org; Wed, 01 Feb 2006 09:23:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03309 for ; Wed, 1 Feb 2006 09:22:09 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4J4q-0007gA-25 for nsis@ietf.org; Wed, 01 Feb 2006 09:35:20 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 02F891BAC4D; Wed, 1 Feb 2006 15:23:36 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <1907B700-1CE5-433C-A943-C775ABBAF956@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 15:23:32 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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: , Content-Type: multipart/mixed; boundary="===============1786086525==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1786086525== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--564661052; protocol="application/pkcs7-signature" --Apple-Mail-4--564661052 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Robert, all, Am 01.02.2006 um 11:35 schrieb Hancock, Robert: > hi all, > > i can imagine interesting ICMP policy rules like > - i want to be able to ping other people > - i want to allow other people to ping me > - i want to be able to do traceroute (receive timex) Right, plus the case(s) I have described in my answer to Henning, when the firewall is letting everything in by default (default-to- allow). In these cases you are blocking specifically ICMP traffic. > > note that the first ping case implies outgoing type=8 and incoming > type=0 and the second ping case implies the opposite. (the ICMP > code - in rfc792 speak - is 0 in all cases.) certainly i can imagine > wanting to be able to signal multiple types/codes in a coordinated > way (and differently for incoming/outgoing packets). This goes along with Hennig's thoughts on aggregating different ICMP codes in a single message. Taking your example, I assume this will require two signaling sessions (outbound (type=8) and inbound (type=0)) to get the ICMP request/reply running. Probably, there is not much to aggregate for outbound/inbound pairs, but saying "I want codes {0,8}". > > in other cases, the handling of ICMP messages is much more dependent > on existing flows (other firewall state); e.g. "i'd like to receive > ICMP unreachable/timex messages but only about flows which exist". > (in fact, the traceroute case probably comes into this category also.) > the implication of that would be that the firewall had to apply the > policy based on the ICMP payload (which contains the flow packet > header) > and not the ICMP header itself. I see this separately from the ICMP policy rule discussion, but it is an interesting issue. Until now, I have assumed this ICMP messages coupled to some other firewall/NAT state (e.g., TCP, UDP, etc) as you have said. Whenever the middlebox is able to have this coupling (like pf of OpenBSD) it will automatically do so, even for NSLP signaling TCP,UDP, etc flows. This behaviour is the desired one, since having ICMP messages for TCP sessions (and others too) makes life much easier. There is no way out, if the middlebox cannot do this coupling or the sysadmin does not like it for any reason. Adding a flag (or similar thing) saying please let for this TCP, UDP, etc flow ICMP messages through as well is one possibility. But whenever this signaling message is hitting a middlebox that does not support this type of ICMP handling, an error response must be sent back. This is going to stop the whole signalling and will make the NATFW NSLP signalling less generic, i.e., it less "fire and forget" as it is today. > > is there an obvious set of requirements for how to configure to > configure firewalls for ICMP? the midcom documents seem 'light' > on the ICMP front. Probably, there is such requirement but I'm not aware of. In MIDCOM we assumed the same as for NSIS: If the middlebox can do so, it will do so. If the middlebox cannot do so, it won't do it. I see this "coupled ICMP" should go into the appendix A "Firewall and NAT Resources". I have added it to issue 26: https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue26 Martin > > r. > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of Henning Peters >> Sent: 31 January 2006 18:01 >> To: Martin Stiemerling >> Cc: nsis >> Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules >> >> >> Hi Martin, >> >> can you specify an application for the signaling of ICMP >> policy rules? Don't ICMP messages already refer to a certain >> data flow? I don't see a reason why a firewall or NAT should >> deny or drop them. And if they are configured to behave like >> this, a different configuration might not be wanted in the >> first place?! But probably the 3GPP2 guys already have sth. >> particular in mind that I am currently not seeing. >> >> How does the change affect NAT? As this might have impacts on >> the (de)multiplexing behavior of NATs. >> >> If adding a new code object to NAT/FW NSLP, allowing multiple >> codes in a single message might be valuable to save >> unnecessary signaling traffic. >> >>> - For REA and REA-F, the "Data Terminal Information Object" must be >>> modified to carry the ICMP code. >> >> Why do you want to have a new code object _and_ an additional >> code field in the DTInfo object? Wouldn't it make sense to >> set the protocol to ICMP in DTInfo protocol field and add the >> new ICMP code object regularly? >> >> Henning >> >> >> Martin Stiemerling sagte Di, 31.01.2006, 13:10: >>> Dear all, >>> >>> The NSIS working group has received some request from a >> 3GPP2 working >>> group to add features to the NATFW NSLP, as said in my email sent >>> before. >>> >>> One of the features is the ability to signaling for ICMP >> policy rules. >>> Up to now, the NATFW NSLP can signal for IP only, TCP, and >> UDP flows >>> by using the NTLP path-coupled MRM and the LE-MRM. It's possible to >>> signal for ICMP flows by using the PC-MRM and setting the >> 'protocol' >>> field to 'ICMP'. However, it is currently not possible to specify >>> anything beyond that, for instance, the ICMP code to be used. >>> >>> Here is the proposed extension to the NATFW NSLP: >>> - Add a new object 'icmp' that carries solely the ICMP code >>> - This object can be included in CREATE messages where the NTLP is >>> carrying a MRM with IP addresses only, protocol set to ICMP. >>> - For REA and REA-F, the "Data Terminal Information Object" must be >>> modified to carry the ICMP code. >>> >>> This proposed change does *NOT* require any change to the NTLP but >>> *ONLY* to the NATFW NSLP. >>> >>> Any view on this? >>> >>> Thanks, >>> >>> 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 >> --Apple-Mail-4--564661052 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMTE0MjMzMlowIwYJKoZIhvcNAQkEMRYEFGjFoisWXaInlNoKJ4LK vGoCTAAxMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAMAIoXoJi4lovIjZco2B Q/GTVKXKJQe8LQdKhVkfRThlfU+m618ExpETBJDmExnVpxraEDNwt53zH71CdS9MJJQVvyBzCFno +vHlw4SHx7lNS0KTDDFNPkLO45n7VVAwJAPeNImTbfUhOw3V/s+zmzg98ZmF12raxNiXbdFgdRIq obwbXfXqSaPa3ZRNaeDMrzMMQB4g0BAZuDIemAQnVb4RWCT8WIwIvyaIxZbxQeKcbvfp3Vmyqv00 +Qc+qC17cs2TitBOqCC1XTr0injcoF/VuW9I0AcWnP3Zl8MXLB1wkULeOUJ8Qo50pUX4Ey2sYXnm yUcPpqeNct2VIojUjpUAAAAAAAA= --Apple-Mail-4--564661052-- --===============1786086525== 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 --===============1786086525==-- From nsis-bounces@ietf.org Wed Feb 01 09:26:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ivv-0005YP-1F; Wed, 01 Feb 2006 09:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ivn-0005Vs-3d for nsis@megatron.ietf.org; Wed, 01 Feb 2006 09:26:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03444 for ; Wed, 1 Feb 2006 09:24:14 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4J6o-0007k2-Fj for nsis@ietf.org; Wed, 01 Feb 2006 09:37:25 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 510B91BAC4D; Wed, 1 Feb 2006 15:25:39 +0100 (CET) In-Reply-To: <43E0B675.5000304@dial.pipex.com> References: <43E0B675.5000304@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 15:25:34 +0100 To: Elwyn Davies X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: nsis , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1831126075==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1831126075== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--564538642; protocol="application/pkcs7-signature" --Apple-Mail-5--564538642 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Elwyn, Am 01.02.2006 um 14:24 schrieb Elwyn Davies: > Hi. > > v6ops has work in progress on this issue. I am editing a proposed > BCP on ICMP filtering for IPv6 which is a bit more complex than the > v4 case. > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6- > filtering-bcp-00.txt Good to know about this document. > > The next version (due out shortly) will provide an Appendix with > example filtering rules. For looking at the v4 case it might be > useful to review either Appendix A or the previous version of this > document (available (e.g.) as http://www.watersprings.org/pub/id/ > draft-davies-v6ops-icmpv6-filtering-bcp-00.txt) which was > structured differently, discussing the messages individually > rather than looking at their the required treatment in the firewall. > > The discussion of why ICMP messages need to be passed or dropped > provides requirements: the v4 case could be derived quite easily > but is more about administrative policy than the v6 case, where the > network will assuredly break if some ICMPv6 messages are dropped > inappropriately, and the size of the addressing space makes ICMP- > based scanning less attractive to hackers than for v4 networks. > > A major consideration for ICMP filtering is that many error > messages are what are classified as 'any-to-end' as the source > address can be any router on the path Sophisticated filtering > needs to look at the addresses of the embedded errored packet, as > mentioned by Robert, but that depends on the capabilities of the > firewall. I have to second, that the ICMP filtering depends on the capabilities of the firewall. Martin > > Regards, > Elwyn > > Hancock, Robert wrote: > >> hi all, >> >> i can imagine interesting ICMP policy rules like >> - i want to be able to ping other people >> - i want to allow other people to ping me >> - i want to be able to do traceroute (receive timex) >> >> note that the first ping case implies outgoing type=8 and incoming >> type=0 and the second ping case implies the opposite. (the ICMP >> code - in rfc792 speak - is 0 in all cases.) certainly i can imagine >> wanting to be able to signal multiple types/codes in a coordinated >> way (and differently for incoming/outgoing packets). >> >> in other cases, the handling of ICMP messages is much more dependent >> on existing flows (other firewall state); e.g. "i'd like to receive >> ICMP unreachable/timex messages but only about flows which exist". >> (in fact, the traceroute case probably comes into this category >> also.) >> the implication of that would be that the firewall had to apply the >> policy based on the ICMP payload (which contains the flow packet >> header) >> and not the ICMP header itself. >> >> is there an obvious set of requirements for how to configure to >> configure firewalls for ICMP? the midcom documents seem 'light' >> on the ICMP front. >> r. >> >> >>> -----Original Message----- >>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>> Behalf Of Henning Peters >>> Sent: 31 January 2006 18:01 >>> To: Martin Stiemerling >>> Cc: nsis >>> Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules >>> >>> >>> Hi Martin, >>> >>> can you specify an application for the signaling of ICMP policy >>> rules? Don't ICMP messages already refer to a certain data flow? >>> I don't see a reason why a firewall or NAT should deny or drop >>> them. And if they are configured to behave like this, a different >>> configuration might not be wanted in the first place?! But >>> probably the 3GPP2 guys already have sth. particular in mind that >>> I am currently not seeing. >>> >>> How does the change affect NAT? As this might have impacts on the >>> (de)multiplexing behavior of NATs. >>> >>> If adding a new code object to NAT/FW NSLP, allowing multiple >>> codes in a single message might be valuable to save unnecessary >>> signaling traffic. >>> >>> >>>> - For REA and REA-F, the "Data Terminal Information Object" must >>>> be modified to carry the ICMP code. >>>> >>> Why do you want to have a new code object _and_ an additional >>> code field in the DTInfo object? Wouldn't it make sense to set >>> the protocol to ICMP in DTInfo protocol field and add the new >>> ICMP code object regularly? >>> >>> Henning >>> >>> >>> Martin Stiemerling sagte Di, 31.01.2006, 13:10: >>> >>>> Dear all, >>>> >>>> The NSIS working group has received some request from a >>> 3GPP2 working >>>> group to add features to the NATFW NSLP, as said in my email >>>> sent before. >>>> >>>> One of the features is the ability to signaling for ICMP >>> policy rules. >>>> Up to now, the NATFW NSLP can signal for IP only, TCP, and >>> UDP flows >>>> by using the NTLP path-coupled MRM and the LE-MRM. It's possible >>>> to signal for ICMP flows by using the PC-MRM and setting the >>> 'protocol' >>>> field to 'ICMP'. However, it is currently not possible to >>>> specify anything beyond that, for instance, the ICMP code to be >>>> used. >>>> >>>> Here is the proposed extension to the NATFW NSLP: >>>> - Add a new object 'icmp' that carries solely the ICMP code >>>> - This object can be included in CREATE messages where the NTLP >>>> is carrying a MRM with IP addresses only, protocol set to ICMP. >>>> - For REA and REA-F, the "Data Terminal Information Object" must >>>> be modified to carry the ICMP code. >>>> >>>> This proposed change does *NOT* require any change to the NTLP but >>>> *ONLY* to the NATFW NSLP. >>>> >>>> Any view on this? >>>> >>>> Thanks, >>>> >>>> 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 >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> --Apple-Mail-5--564538642 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMTE0MjUzNVowIwYJKoZIhvcNAQkEMRYEFFH4GrG6fB6jUmxpjNEg bbHWbR31MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBALcio1PnqlpYk6Uhlbcr OI1T/Hnpk439NbH3SQwpFzxrkbpSDCIP6L4Qv6V9hIwFWFjcudbE0G+Ay2dcnTHzdXYUMRjrZw4j IOTUzMi6j1g1c9hVLGOnh7p7c0Y7whlkRcq0SOIi+sTWW44FWzMcaTKSdp7T76cCjLSgpdos+0I/ v1iXN5+Cn/sbUf/nu89RrNDLu5JaQDim9zaRwJ1cGdoXxI8J9Vcel2KZQIaFZx6mqTSdCv0tnsve iY3g+tWNnIb9PmcAX0/VIw5HjfMPpqo92NikobHCsIisIee3CJNTaBqUQHJKa28+/XuYjnTLQPzd Ctrvqqq/F9ajCg1DGVIAAAAAAAA= --Apple-Mail-5--564538642-- --===============1831126075== 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 --===============1831126075==-- From nsis-bounces@ietf.org Wed Feb 01 09:28:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IyG-0007Pt-MF; Wed, 01 Feb 2006 09:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IyF-0007Mp-1R for nsis@megatron.ietf.org; Wed, 01 Feb 2006 09:28:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03646 for ; Wed, 1 Feb 2006 09:26:49 -0500 (EST) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4J9L-0007q6-Le for nsis@ietf.org; Wed, 01 Feb 2006 09:40:00 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1F4Ixr-0005Fk-QF; Wed, 01 Feb 2006 14:28:08 +0000 Message-ID: <43E0C5FC.9020807@dial.pipex.com> Date: Wed, 01 Feb 2006 14:30:20 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules References: <36694.134.76.81.25.1138730439.squirrel@mail.piranho.net> <55FAA859-8EAD-4715-8828-FF799DCFA956@netlab.nec.de> In-Reply-To: <55FAA859-8EAD-4715-8828-FF799DCFA956@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Two extra points come to mind with regard to ICMP filtering: - In many cases (e.g., ping responses and error messages), what would be ideal would be to allow exactly one error message relevant to the flow or ping response if the firewall is capable of counting (actually counting to 1 is easy - just destroy the rule after it has been invoked ;-) ). - Some of the rules are not related to a specific flow but really are administrative setups targeted on a particular firewall. Do we envisage using NATFW NSLP for this? In practice, you would have to install quite a number of filters per data flow to cope with all the ICMP messages that you might want to allow in response to a particular data flow setup. There may be performance issues here. Maybe what is needed is a way to create a filter set rather than a simple tuple for one filter. Regards, Elwyn Martin Stiemerling wrote: > Hi Henning, all, > > by the way this issue has made it in the NATFW NSLP issue tracker: > > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue60 > > More inline. > > Am 31.01.2006 um 19:00 schrieb Henning Peters: > >> Hi Martin, >> >> can you specify an application for the signaling of ICMP policy rules? >> Don't ICMP messages already refer to a certain data flow? I don't see a >> reason why a firewall or NAT should deny or drop them. And if they are >> configured to behave like this, a different configuration might not be >> wanted in the first place?! But probably the 3GPP2 guys already have >> sth. >> particular in mind that I am currently not seeing. > > > I do not know about the application 3GPP2 has in mind but in general > it is > a good idea to allow or deny ICMP messages in middleboxes. Focussing > on the 3GPP2 case first: > > 3GPP2 assumes only firewalls in their network ('cause it is IPv6) and > these > firewalls are default-to-allow. All traffic is allowed to go in and > out unhindered. > A 3GPP2 mobile terminal will use the NATFW NSLP to request the blocking > of particular data traffic coming out of the Internet towards the > terminal, causing > costs to the terminal user (it's all running wireless and you pay > byte by byte, or > feel directly when the link is filled with garbage). An unwanted > traffic can be > ICMP ECHO request messages sent by some to your terminal, in the worst > case flooding your wireless link. This kind of traffic may not come > from a single > source, so that blocking of a single IP address would not solve the > issue. Therefore, > you will request to block all ICMP traffic in your upstream firewalls > for any host, > but let TCP and UDP through. > > Second, for hosts behind firewalls running default-to-deny and NATs. > a) The host wants to send ICMP messages to other hosts but does not > have a transport layer connection/state on the firewall, i.e., you > ping a > host to see if it is alive. In this case, the NATFW NSLP will request > the > downstream firewalls to open for ICMP traffic. This would bring back > the old-style ICMP diagnosis to some people that are located behind > very strictly configured firewalls and NATs > > b) A server located behind a NAT/firewalls running some sort of service, > for instance, FTP, would like to be reachable for ICMP ECHO REQUEST > packets. Some people running servers still like them to be reachable by > ICMP, since this sometimes the only way to test remotely if the server > is up and running. > > >> >> How does the change affect NAT? As this might have impacts on the >> (de)multiplexing behavior of NATs. > > > Right, but either the NAT can multiplex ICMP packets or it cannot. > But this > is not something the NATFW NSLP can change. For instance, OpenBSD's > pf as NAT can do ICMP demultiplexing. Some other NATs probably can't do. > >> >> If adding a new code object to NAT/FW NSLP, allowing multiple codes >> in a >> single message might be valuable to save unnecessary signaling traffic. > > > Could by a good way to aggregate. I have thing about it. > Do you mind adding this to the issue 60 in the tracker? > >> >>> - For REA and REA-F, the "Data Terminal Information Object" must be >>> modified to carry the ICMP code. >> >> >> Why do you want to have a new code object _and_ an additional code >> field >> in the DTInfo object? Wouldn't it make sense to set the protocol to >> ICMP >> in DTInfo protocol field and add the new ICMP code object regularly? > > > Yes, good idea. > Do you mind adding this to the issue 60 in the tracker, so it does > not get forgotten? > > Thanks, > > Martin > >> >> Henning >> >> >> Martin Stiemerling sagte Di, 31.01.2006, 13:10: >> >>> Dear all, >>> >>> The NSIS working group has received some request from a 3GPP2 working >>> group to add features to the NATFW NSLP, as said in my email sent >>> before. >>> >>> One of the features is the ability to signaling for ICMP policy >>> rules. Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP >>> flows by using the NTLP path-coupled MRM and the LE-MRM. It's >>> possible to signal for ICMP flows by using the PC-MRM and setting the >>> 'protocol' field to 'ICMP'. However, it is currently not possible to >>> specify anything beyond that, for instance, the ICMP code to be used. >>> >>> Here is the proposed extension to the NATFW NSLP: >>> - Add a new object 'icmp' that carries solely the ICMP code >>> - This object can be included in CREATE messages where the NTLP is >>> carrying a MRM with IP addresses only, protocol set to ICMP. >>> - For REA and REA-F, the "Data Terminal Information Object" must be >>> modified to carry the ICMP code. >>> >>> This proposed change does *NOT* require any change to the NTLP but >>> *ONLY* to the NATFW NSLP. >>> >>> Any view on this? >>> >>> Thanks, >>> >>> 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 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 01 09:58:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JQv-0001Kb-Ju; Wed, 01 Feb 2006 09:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JQu-0001Hc-Fp for nsis@megatron.ietf.org; Wed, 01 Feb 2006 09:58:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05571 for ; Wed, 1 Feb 2006 09:56:31 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Jc5-0000LI-8b for nsis@ietf.org; Wed, 01 Feb 2006 10:09:42 -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 k11EvdRw023029; Wed, 1 Feb 2006 14:57:40 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] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 14:57:39 -0000 Message-ID: Thread-Topic: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Thread-Index: AcYnOx4tw0MrM0hYQ1iw0s9gX1B9HAAAz8BA From: "Hancock, Robert" To: "Martin Stiemerling" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi, replies to a snipped subset: > > note that the first ping case implies outgoing type=3D8 and incoming = > > type=3D0 and the second ping case implies the opposite. (the=20 > ICMP code -=20 > > in rfc792 speak - is 0 in all cases.) certainly i can=20 > imagine wanting=20 > > to be able to signal multiple types/codes in a coordinated way (and=20 > > differently for incoming/outgoing packets). >=20 > This goes along with Hennig's thoughts on aggregating=20 > different ICMP codes in a single message. Taking your=20 > example, I assume this will require two signaling sessions=20 > (outbound (type=3D8) and inbound (type=3D0)) to get the ICMP=20 > request/reply running. Probably, there is not much to=20 > aggregate for outbound/inbound pairs, but saying "I want codes {0,8}". i could say {0 in, 8 out} or {0 out, 8 in} - if i regard there as being a difference between being able to ping and being pingable. (and it's *type* not *code*!) for the other types of messages, it may be that there is no point in there being anything other than a default policy associated with the state of the corresponding flow, so there is nothing to signal. that would be a reasonable point of view. i think the analysis needs to be done [maybe Elwyn has already done it ;-) ] r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 01 10:32:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Jxz-00035V-D0; Wed, 01 Feb 2006 10:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Jxx-00034j-GS for nsis@megatron.ietf.org; Wed, 01 Feb 2006 10:32:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07830 for ; Wed, 1 Feb 2006 10:30:25 -0500 (EST) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4K8t-0001St-DW for nsis@ietf.org; Wed, 01 Feb 2006 10:43:37 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1F4JxO-00047B-OD; Wed, 01 Feb 2006 15:31:42 +0000 Message-ID: <43E0D4E3.8040309@dial.pipex.com> Date: Wed, 01 Feb 2006 15:33:55 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules 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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org The considerations for error messages and info messages in ICMP (both versions) are different. To state the fairly obvious: Error messages need to be associated with another flow (which could of course be an ICMP info flow!) Info messages are part of some sub-protocol of ICMP For error messages, the prospective errored flow *has* to do the setup for the error messages - you can't expect an arbitrary router to set up the pinholes before sending an ICMP! Just talking about the ping or traceroute info case, an echo request needs to set up a a one time pinhole for the echo reply - basically like TCP or UDP replies and this is mostly handled automatically today. The question is, I guess, should the flow specification liaise with this set up of the return path (by having a flag or some such) or should we expect to get the return path set up separately? Asymmetric routing? Elwyn Hancock, Robert wrote: >hi, > >replies to a snipped subset: > > > >>>note that the first ping case implies outgoing type=8 and incoming >>>type=0 and the second ping case implies the opposite. (the >>> >>> >>ICMP code - >> >> >>>in rfc792 speak - is 0 in all cases.) certainly i can >>> >>> >>imagine wanting >> >> >>>to be able to signal multiple types/codes in a coordinated way (and >>>differently for incoming/outgoing packets). >>> >>> >>This goes along with Hennig's thoughts on aggregating >>different ICMP codes in a single message. Taking your >>example, I assume this will require two signaling sessions >>(outbound (type=8) and inbound (type=0)) to get the ICMP >>request/reply running. Probably, there is not much to >>aggregate for outbound/inbound pairs, but saying "I want codes {0,8}". >> >> > >i could say {0 in, 8 out} or {0 out, 8 in} - if i regard there as >being a difference between being able to ping and being pingable. >(and it's *type* not *code*!) > >for the other types of messages, it may be that there is no point >in there being anything other than a default policy associated with >the state of the corresponding flow, so there is nothing to signal. >that would be a reasonable point of view. i think the analysis needs >to be done [maybe Elwyn has already done it ;-) ] > >r. > >_______________________________________________ >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 Feb 01 11:57:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4LIO-0007RH-DE; Wed, 01 Feb 2006 11:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4LIK-0007PV-IT for nsis@megatron.ietf.org; Wed, 01 Feb 2006 11:57:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14789 for ; Wed, 1 Feb 2006 11:55:38 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4LTP-0004g4-7n for nsis@ietf.org; Wed, 01 Feb 2006 12:08:52 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 32A8D1BAC4D; Wed, 1 Feb 2006 17:57:06 +0100 (CET) In-Reply-To: <43E0C5FC.9020807@dial.pipex.com> References: <36694.134.76.81.25.1138730439.squirrel@mail.piranho.net> <55FAA859-8EAD-4715-8828-FF799DCFA956@netlab.nec.de> <43E0C5FC.9020807@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <759C6815-0BA6-44BB-92AC-7DD76EEC5AAE@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 17:57:00 +0100 To: Elwyn Davies X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 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: , Content-Type: multipart/mixed; boundary="===============0486264592==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0486264592== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--555452162; protocol="application/pkcs7-signature" --Apple-Mail-10--555452162 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Am 01.02.2006 um 15:30 schrieb Elwyn Davies: > Two extra points come to mind with regard to ICMP filtering: > - In many cases (e.g., ping responses and error messages), what > would be ideal would be to allow exactly one error message relevant > to the flow or ping response if the firewall is capable of counting > (actually counting to 1 is easy - just destroy the rule after it > has been invoked ;-) ). This could be done on the middlebox. But in some cases you will receive more than one reply and you could use this for diagnosis as well. The NI could do the same, simply tear the session down after having received one reply, if desired. This will keep the protocol and the implementation lightweight. > - Some of the rules are not related to a specific flow but really > are administrative setups targeted on a particular firewall. Do we > envisage using NATFW NSLP for this? Are you referring to management of middleboxes? If yes, than this is out of scope for the NATFW NSLP. Long-term administrative setups are done by CLI or some other management interface. > > In practice, you would have to install quite a number of filters > per data flow to cope with all the ICMP messages that you might > want to allow in response to a particular data flow setup. There > may be performance issues here. Maybe what is needed is a way to > create a filter set rather than a simple tuple for one filter. I do not think so. ICMP messages belonging to a particular data flow are not configurable by the NATFW NSLP. They are subject to the local middlebox implementation, how the NATFW daemon feeds rules into the engines, and what the administrator thinks about his allowed configuration. My point is just about independent ICMP packets, e.g., for ping or traceroute applications. Regards, Martin > > Regards, > Elwyn > > Martin Stiemerling wrote: > >> Hi Henning, all, >> >> by the way this issue has made it in the NATFW NSLP issue tracker: >> >> https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue60 >> >> More inline. >> >> Am 31.01.2006 um 19:00 schrieb Henning Peters: >> >>> Hi Martin, >>> >>> can you specify an application for the signaling of ICMP policy >>> rules? >>> Don't ICMP messages already refer to a certain data flow? I >>> don't see a >>> reason why a firewall or NAT should deny or drop them. And if >>> they are >>> configured to behave like this, a different configuration might >>> not be >>> wanted in the first place?! But probably the 3GPP2 guys already >>> have sth. >>> particular in mind that I am currently not seeing. >> >> >> I do not know about the application 3GPP2 has in mind but in >> general it is >> a good idea to allow or deny ICMP messages in middleboxes. Focussing >> on the 3GPP2 case first: >> >> 3GPP2 assumes only firewalls in their network ('cause it is IPv6) >> and these >> firewalls are default-to-allow. All traffic is allowed to go in >> and out unhindered. >> A 3GPP2 mobile terminal will use the NATFW NSLP to request the >> blocking >> of particular data traffic coming out of the Internet towards the >> terminal, causing >> costs to the terminal user (it's all running wireless and you pay >> byte by byte, or >> feel directly when the link is filled with garbage). An unwanted >> traffic can be >> ICMP ECHO request messages sent by some to your terminal, in the >> worst >> case flooding your wireless link. This kind of traffic may not >> come from a single >> source, so that blocking of a single IP address would not solve >> the issue. Therefore, >> you will request to block all ICMP traffic in your upstream >> firewalls for any host, >> but let TCP and UDP through. >> >> Second, for hosts behind firewalls running default-to-deny and NATs. >> a) The host wants to send ICMP messages to other hosts but does not >> have a transport layer connection/state on the firewall, i.e., >> you ping a >> host to see if it is alive. In this case, the NATFW NSLP will >> request the >> downstream firewalls to open for ICMP traffic. This would bring back >> the old-style ICMP diagnosis to some people that are located behind >> very strictly configured firewalls and NATs >> >> b) A server located behind a NAT/firewalls running some sort of >> service, >> for instance, FTP, would like to be reachable for ICMP ECHO REQUEST >> packets. Some people running servers still like them to be >> reachable by >> ICMP, since this sometimes the only way to test remotely if the >> server >> is up and running. >> >> >>> >>> How does the change affect NAT? As this might have impacts on the >>> (de)multiplexing behavior of NATs. >> >> >> Right, but either the NAT can multiplex ICMP packets or it >> cannot. But this >> is not something the NATFW NSLP can change. For instance, OpenBSD's >> pf as NAT can do ICMP demultiplexing. Some other NATs probably >> can't do. >> >>> >>> If adding a new code object to NAT/FW NSLP, allowing multiple >>> codes in a >>> single message might be valuable to save unnecessary signaling >>> traffic. >> >> >> Could by a good way to aggregate. I have thing about it. >> Do you mind adding this to the issue 60 in the tracker? >> >>> >>>> - For REA and REA-F, the "Data Terminal Information Object" must be >>>> modified to carry the ICMP code. >>> >>> >>> Why do you want to have a new code object _and_ an additional >>> code field >>> in the DTInfo object? Wouldn't it make sense to set the protocol >>> to ICMP >>> in DTInfo protocol field and add the new ICMP code object regularly? >> >> >> Yes, good idea. >> Do you mind adding this to the issue 60 in the tracker, so it >> does not get forgotten? >> >> Thanks, >> >> Martin >> >>> >>> Henning >>> >>> >>> Martin Stiemerling sagte Di, 31.01.2006, 13:10: >>> >>>> Dear all, >>>> >>>> The NSIS working group has received some request from a 3GPP2 >>>> working >>>> group to add features to the NATFW NSLP, as said in my email sent >>>> before. >>>> >>>> One of the features is the ability to signaling for ICMP policy >>>> rules. Up to now, the NATFW NSLP can signal for IP only, TCP, >>>> and UDP >>>> flows by using the NTLP path-coupled MRM and the LE-MRM. It's >>>> possible to signal for ICMP flows by using the PC-MRM and >>>> setting the >>>> 'protocol' field to 'ICMP'. However, it is currently not >>>> possible to >>>> specify anything beyond that, for instance, the ICMP code to be >>>> used. >>>> >>>> Here is the proposed extension to the NATFW NSLP: >>>> - Add a new object 'icmp' that carries solely the ICMP code >>>> - This object can be included in CREATE messages where the NTLP is >>>> carrying a MRM with IP addresses only, protocol set to ICMP. >>>> - For REA and REA-F, the "Data Terminal Information Object" must be >>>> modified to carry the ICMP code. >>>> >>>> This proposed change does *NOT* require any change to the NTLP but >>>> *ONLY* to the NATFW NSLP. >>>> >>>> Any view on this? >>>> >>>> Thanks, >>>> >>>> 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 >> --Apple-Mail-10--555452162 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMTE2NTcwMVowIwYJKoZIhvcNAQkEMRYEFLxM2oiaKxqmp9i1gBzr iIQOBbQxMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAK+nsDL/DFUiHCkB2z22 V0szI9hiJr5w5iZ3PwwKSrZnwobFndCnMYFYp4yRAbbNe3WsGxxNW1RQ3qWuOPFEwHmrK55HXtb4 SFQMOp1GadOXmqLFhhIit4XAJDG5YcGF7zsqiSy5QgKZ51fv2TSThiYpPrTBVgfDjL9MGPwmsRZc 14BgM+v4YqWODjJht5QNLiN6gY+nF5B9x9VO8JXJm/2gMOvtF5cG8AI1RNWm+ENshUF9VNLHFRTr ShJ5k+POwx1hKn/Y50rohJzk2JY/AmYBE3gk1C7SSFYKfjGYkmoBfH56c6aMaFyBoNuIA7nZhxUy lGyarWAyC6R05N6jPskAAAAAAAA= --Apple-Mail-10--555452162-- --===============0486264592== 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 --===============0486264592==-- From nsis-bounces@ietf.org Wed Feb 01 15:44:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Opl-0007C3-O0; Wed, 01 Feb 2006 15:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Opj-00078c-G8 for nsis@megatron.ietf.org; Wed, 01 Feb 2006 15:44:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04013 for ; Wed, 1 Feb 2006 15:42:30 -0500 (EST) Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4P0x-0005BG-ES for nsis@ietf.org; Wed, 01 Feb 2006 15:55:44 -0500 Received: (qmail 25998 invoked from network); 1 Feb 2006 18:18:43 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 1 Feb 2006 18:18:43 -0000 Received: from 84.132.240.135 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Wed, 1 Feb 2006 19:18:43 +0100 (CET) Message-ID: <17981.84.132.240.135.1138817923.squirrel@mail.piranho.net> In-Reply-To: References: Date: Wed, 1 Feb 2006 19:18:43 +0100 (CET) Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 8bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, just to avoid misunderstandings: the ICMP field is called "type" as already stated in Roberts mail. The ICMP "code" field is its subtype. We are currently talking about the type, are we? ;) Henning Martin Stiemerling sagte Di, 31.01.2006, 13:10: [...] > Here is the proposed extension to the NATFW NSLP: > - Add a new object 'icmp' that carries solely the ICMP code [...] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 01 15:50:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ovr-0003vQ-5s; Wed, 01 Feb 2006 15:50:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4OvV-0003TM-Gm; Wed, 01 Feb 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04306; Wed, 1 Feb 2006 15:48:27 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4P6i-0005SS-Gn; Wed, 01 Feb 2006 16:01:41 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F4OvS-0007D3-7d; Wed, 01 Feb 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: Wed, 01 Feb 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-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: , Sender: nsis-bounces@ietf.org 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 signalling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-09.txt Pages : 80 Date : 2006-2-1 This draft describes an NSIS Signalling Layer Protocol (NSLP) for signalling 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-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-qos-nslp-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-qos-nslp-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-2-1134703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-1134703.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Feb 01 17:09:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4QA4-0006f7-Nu; Wed, 01 Feb 2006 17:09:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4QA3-0006dn-Gm for nsis@megatron.ietf.org; Wed, 01 Feb 2006 17:09:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17342 for ; Wed, 1 Feb 2006 17:07:25 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4QLA-0002NS-0W for nsis@ietf.org; Wed, 01 Feb 2006 17:20:41 -0500 Received: from [192.168.178.22] (p54ACABC8.dip0.t-ipconnect.de [84.172.171.200]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 505361BAC4D; Wed, 1 Feb 2006 23:08:52 +0100 (CET) In-Reply-To: <17981.84.132.240.135.1138817923.squirrel@mail.piranho.net> References: <17981.84.132.240.135.1138817923.squirrel@mail.piranho.net> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Message-Id: <889C0330-F3D9-496F-9198-D69B1C1DE325@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Wed, 1 Feb 2006 23:08:47 +0100 To: Henning Peters X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0707495204==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0707495204== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15--536745897; protocol="application/pkcs7-signature" --Apple-Mail-15--536745897 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Am 01.02.2006 um 19:18 schrieb Henning Peters: > Hi, > > just to avoid misunderstandings: the ICMP field is called "type" as > already stated in Roberts mail. The ICMP "code" field is its > subtype. We > are currently talking about the type, are we? ;) Yes, it is the 'type'! Sorry for the confusion, I know it is type and was switching to code because of my personal laziness Martin > > Henning > > > Martin Stiemerling sagte Di, 31.01.2006, 13:10: > [...] >> Here is the proposed extension to the NATFW NSLP: >> - Add a new object 'icmp' that carries solely the ICMP code > [...] > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-15--536745897 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMTIyMDg0N1owIwYJKoZIhvcNAQkEMRYEFFzuF1dsMbKIzk5b5oEt 1PQSEw4WMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBALASs9Pl3joEgFWsNtRt ceqbUMn7KruCEYiNAMvF/Ma8R2NJiTZjOwa/U8Wf5cB/Xxkl+zv11zaUmD22hkfzoW++tfTrkBBK 6fl6NmE7qTsTN9hVzt/OHY6HL4SB3x1l9VSbLgHxuele/W807BP82jq41HALErIUjvzsNpddecbM eLl7lmPl+8X82U5dcaEQ+f/GBcYQhHLz/ubROt1DjorFHWbBivXc2oQ4ODVB1blym2tnrhNAG3q5 FtodSrypfnAfhCpSCj2NI/RisisTr6uE8ycEBAip75xmNmWq2Njsl2AG7ImZJqT7+eGVxRi5EJgZ ANdUUFfM5JegoZjP49AAAAAAAAA= --Apple-Mail-15--536745897-- --===============0707495204== 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 --===============0707495204==-- From nsis-bounces@ietf.org Wed Feb 01 18:50:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Rjm-00044d-0I; Wed, 01 Feb 2006 18:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Rjf-00042S-4q; Wed, 01 Feb 2006 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28015; Wed, 1 Feb 2006 18:48:26 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Ruv-0006IU-9f; Wed, 01 Feb 2006 19:01:41 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F4Rjd-0006C4-P6; Wed, 01 Feb 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: Wed, 01 Feb 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-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: , Sender: nsis-bounces@ietf.org 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-09.txt Pages : 101 Date : 2006-2-1 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators and firewalls. This NSLP allows hosts to signal along a data path for Network Address Translators and firewalls to be configured according to the data flow needs. The network scenarios, problems and solutions for path-coupled Network Address Translator and firewall signaling are described. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-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-nslp-natfw-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-nslp-natfw-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-2-1160922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-1160922.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 Feb 02 02:56:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ZKE-0002Ov-D3; Thu, 02 Feb 2006 02:56:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ZJw-0002LI-0I for nsis@megatron.ietf.org; Thu, 02 Feb 2006 02:56:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08397 for ; Thu, 2 Feb 2006 02:54:23 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ZVG-0008Hv-B5 for nsis@ietf.org; Thu, 02 Feb 2006 03:07:43 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 223FF1BAC99 for ; Thu, 2 Feb 2006 08:55:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Message-Id: From: Martin Stiemerling Date: Thu, 2 Feb 2006 08:55:42 +0100 To: nsis X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Subject: [NSIS] Re: I-D ACTION:draft-ietf-nsis-nslp-natfw-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: , Content-Type: multipart/mixed; boundary="===============1598877910==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1598877910== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21--501529824; protocol="application/pkcs7-signature" --Apple-Mail-21--501529824 Content-Type: multipart/alternative; boundary=Apple-Mail-20--501531486 --Apple-Mail-20--501531486 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi all, You can find the diff to the -08 version here: http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-09- diff-to-08.html Changes are: - Editorial fixes - The 'sub_ports' field in 4.3.3 Extended Flow Information Object. This has been agreed at the last IETF meeting. We will submit a new version to the upcoming IETF submission deadline With best regards Martin, for the authors. Am 02.02.2006 um 00:50 schrieb : > 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-09.txt > Pages : 101 > Date : 2006-2-1 > > This memo defines the NSIS Signaling Layer Protocol (NSLP) for > Network Address Translators and firewalls. This NSLP allows > hosts to > signal along a data path for Network Address Translators and > firewalls to be configured according to the data flow needs. The > network scenarios, problems and solutions for path-coupled Network > Address Translator and firewall signaling are described. The > overall > architecture is given by the framework and requirements defined by > the Next Steps in Signaling (NSIS) working group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-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-nslp-natfw-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-nslp-natfw-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. > > > > --Apple-Mail-20--501531486 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

You can find the diff to = the -08 version here:


Changes are:
- = Editorial fixes
- The 'sub_ports' field in=A04.3.3=A0 Extended = Flow Information Object. This has been agreed at the last IETF = meeting.

We = will submit a new version to the upcoming IETF submission = deadline

With = best regards

=A0= Martin, for the authors.

Am 02.02.2006 um 00:50 = schrieb <Internet-Drafts@ietf.org> = <Internet-Drafts@ietf.org>:=

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.

= =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : NAT/Firewall = NSIS Signaling Layer Protocol (NSLP)
=A0=A0=A0=A0=A0=A0=A0 = Author(s)=A0=A0=A0=A0=A0=A0 : M. Stiemerling, et al.
=A0=A0=A0=A0=A0=A0= =A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-ietf-nsis-nslp-natfw-09.txt
=A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0 = =A0=A0=A0=A0=A0=A0=A0 : 101
=A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0 : 2006-2-1
=A0=A0=A0=A0=A0=A0=A0
This memo = defines the NSIS Signaling Layer Protocol (NSLP) for
=A0=A0 Network = Address Translators and firewalls.=A0 This NSLP allows hosts to
=A0=A0= signal along a data path for Network Address Translators and
=A0=A0 = firewalls to be configured according to the data flow needs.=A0 The
= =A0=A0 network scenarios, problems and solutions for path-coupled = Network
=A0=A0 Address Translator and firewall signaling are = described.=A0 The overall
=A0=A0 architecture is given by the = framework and requirements defined by
=A0=A0 the Next Steps in = Signaling (NSIS) working group.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-09.txt=

To remove yourself from the I-D Announcement list, send a = message to
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message.=A0
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
=A0=A0=A0=A0=A0=A0=A0 "get = draft-ietf-nsis-nslp-natfw-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:
=A0=A0=A0=A0=A0=A0=A0 = mailserv@ietf.org.
In the = body type:
=A0=A0=A0=A0=A0=A0=A0 "FILE = /internet-drafts/draft-ietf-nsis-nslp-natfw-09.txt".
=A0=A0=A0=A0=A0=A0= =A0
NOTE:=A0=A0 The mail server at ietf.org can return the document = in
=A0=A0=A0=A0=A0=A0=A0 MIME-encoded form by using the "mpack" = utility.=A0 To use this
=A0=A0=A0=A0=A0=A0=A0 feature, insert the = command "ENCODING mime" before the "FILE"
=A0=A0=A0=A0=A0=A0=A0 = command.=A0 To decode the response(s), you will need "munpack" or
= =A0=A0=A0=A0=A0=A0=A0 a MIME-compliant mail reader.=A0 Different = MIME-compliant mail readers
=A0=A0=A0=A0=A0=A0=A0 exhibit different = behavior, especially when dealing with
=A0=A0=A0=A0=A0=A0=A0 = "multipart" MIME messages (i.e. documents which have been split
= =A0=A0=A0=A0=A0=A0=A0 up into multiple messages), so check your local = documentation on
=A0=A0=A0=A0=A0=A0=A0 how to manipulate these = messages.
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
Below is the data which will enable = a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.

=
<ATT277590.TXT>
<draft-ietf-nsi= s-nslp-natfw-09.URL>
<ATT277591.txt>
=

= --Apple-Mail-20--501531486-- --Apple-Mail-21--501529824 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMjA3NTU0MlowIwYJKoZIhvcNAQkEMRYEFHcDzggMrS1syFSFYLbt GD8cxIpeMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAExynQxf2EtJftNSjF+b w0cKL7/tl5SoZwNCj963uTMYpB/BcpISfZlY9vS1NhbJzp88bO4Z0FsrqoaNOWyiEpZIbkPtrzzE NuumNymuIZhDvkuPmjf4KprUZekWEY4Qqb9yW9e4v66jumTxaidKoWh/0dy3N8+PxhsDIMzWxlF3 kPjO1c0gOaFcz1Vels3UrmhjExcPYB3uQeU/KrVlDw70Ufhm0eCecZ+bbZoIhJj4IelyWBJjsW2Y TT3KRI8/HPBVH5zyevXELYPCT0+vrbVXh2qfwTMtnaY/r2TYhuWYjH+RzQUP89veAM0h4cRXB+wV 5pAgiMkk4OROSOIWkpsAAAAAAAA= --Apple-Mail-21--501529824-- --===============1598877910== 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 --===============1598877910==-- From nsis-bounces@ietf.org Thu Feb 02 02:56:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ZKF-0002QD-6a; Thu, 02 Feb 2006 02:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ZJy-0002GR-QL for nsis@megatron.ietf.org; Thu, 02 Feb 2006 02:56:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08387 for ; Thu, 2 Feb 2006 02:54:16 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ZV9-0008HW-8t for nsis@ietf.org; Thu, 02 Feb 2006 03:07:36 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A38261BAC4D; Thu, 2 Feb 2006 08:55:42 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <4ED241B2-B030-4CC4-8E6F-7361A718FB04@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Thu, 2 Feb 2006 08:55:38 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: , Content-Type: multipart/mixed; boundary="===============1430544565==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1430544565== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19--501534550; protocol="application/pkcs7-signature" --Apple-Mail-19--501534550 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, Am 01.02.2006 um 15:57 schrieb Hancock, Robert: > hi, > > replies to a snipped subset: > >>> note that the first ping case implies outgoing type=8 and incoming >>> type=0 and the second ping case implies the opposite. (the >> ICMP code - >>> in rfc792 speak - is 0 in all cases.) certainly i can >> imagine wanting >>> to be able to signal multiple types/codes in a coordinated way (and >>> differently for incoming/outgoing packets). >> >> This goes along with Hennig's thoughts on aggregating >> different ICMP codes in a single message. Taking your >> example, I assume this will require two signaling sessions >> (outbound (type=8) and inbound (type=0)) to get the ICMP >> request/reply running. Probably, there is not much to >> aggregate for outbound/inbound pairs, but saying "I want codes >> {0,8}". > > i could say {0 in, 8 out} or {0 out, 8 in} - if i regard there as Yes, you could says so in the case you are signaling in proxy mode (for instance, CREATE-PROXY) and with the REAs. I will write some text for the ICMP support and send it to the list for comments. > being a difference between being able to ping and being pingable. > (and it's *type* not *code*!) It's type. I got it wrong when typing it. Thanks! > > for the other types of messages, it may be that there is no point > in there being anything other than a default policy associated with > the state of the corresponding flow, so there is nothing to signal. I share your view. > that would be a reasonable point of view. i think the analysis needs > to be done [maybe Elwyn has already done it ;-) ] I have no analysis at my hands, but I know from my past experience of firewall/NAT kernel hacking that either the box can do ICMP state to flow state matching or there is not much to configure. Cheers, Martin --Apple-Mail-19--501534550 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMjA3NTUzOVowIwYJKoZIhvcNAQkEMRYEFIE3sRpwCMNDzvgNkhMR o8Y4py1qMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAJBtnVPfs92aFCm75Idl m7eryBvvCXSUU27irAK3uF6A5zuUya8KZNyisrPMjwd53Zs8xq/fusFhl7JROmLD2C0TRAosd4kA sfyNrTZsQFH6ZAMGckeBuDdBkFw7RFxvUUNZX+mHSgmG5XVLgC7cMWBWfgHbK/YadVudwbzXxStg S/6FqlXEPxKxZNQWy7xRCD+qWpJvKGB/fFWwEUpEZE+E7O82mb0pHUiEdSvY5sLSSOxbapnzXNHB DPM80DsjXuSyyYWFCRHjG3cjBvYVvdIm36nuPgfxbmpu8s/z2dZTanYOOvDDjsjN3PVbNwP4YZ7F ikSeExJrxRO1cjJRZz8AAAAAAAA= --Apple-Mail-19--501534550-- --===============1430544565== 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 --===============1430544565==-- From nsis-bounces@ietf.org Thu Feb 02 03:04:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ZS9-0007Sa-Or; Thu, 02 Feb 2006 03:04:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ZS5-0007Ri-JN for nsis@megatron.ietf.org; Thu, 02 Feb 2006 03:04:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09060 for ; Thu, 2 Feb 2006 03:02:40 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ZdI-0000A3-Er for nsis@ietf.org; Thu, 02 Feb 2006 03:16:01 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E7E741BAC4D; Thu, 2 Feb 2006 09:04:07 +0100 (CET) In-Reply-To: <43E0D4E3.8040309@dial.pipex.com> References: <43E0D4E3.8040309@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Date: Thu, 2 Feb 2006 09:04:02 +0100 To: Elwyn Davies X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Content-Type: multipart/mixed; boundary="===============0368413350==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0368413350== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22--501030046; protocol="application/pkcs7-signature" --Apple-Mail-22--501030046 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Elwyn, Am 01.02.2006 um 16:33 schrieb Elwyn Davies: > The considerations for error messages and info messages in ICMP > (both versions) are different. > > To state the fairly obvious: > Error messages need to be associated with another flow (which could > of course be an ICMP info flow!) > Info messages are part of some sub-protocol of ICMP > > For error messages, the prospective errored flow *has* to do the > setup for the error messages - you can't expect an arbitrary router > to set up the pinholes before sending an ICMP! > > Just talking about the ping or traceroute info case, an echo > request needs to set up a a one time pinhole for the echo reply - > basically like TCP or UDP replies and this is mostly handled > automatically today. The question is, I guess, The same of automatic state setup for the return traffic holds true for ICMP (originated as ICPM) as well. Given you have a modern middlebox, for which I count all the open source implementations (IPTables, PF, IPFW, IPF). I assume other vendors have the same functionality. > should the flow specification liaise with this set up of the return > path (by having a flag or some such) or should we expect to get the > return path set up separately? Asymmetric routing? In my opinion, each path must be set up independently when we are in end-to-end NSIS operations, since we have a path-coupled protocol. This is when both ends support NSIS NATFW NSLP. In the case of only one side having NSIS NATFW support, you can use the proxy mode to set up both paths from one end. This holds true for the case, when you like to configure your local middleboxes only. So there is no extra flag needed anymore. Martin > > Elwyn > > Hancock, Robert wrote: > >> hi, >> >> replies to a snipped subset: >> >> >>>> note that the first ping case implies outgoing type=8 and >>>> incoming type=0 and the second ping case implies the opposite. (the >>> ICMP code - >>>> in rfc792 speak - is 0 in all cases.) certainly i can >>> imagine wanting >>>> to be able to signal multiple types/codes in a coordinated way >>>> (and differently for incoming/outgoing packets). >>>> >>> This goes along with Hennig's thoughts on aggregating different >>> ICMP codes in a single message. Taking your example, I assume >>> this will require two signaling sessions (outbound (type=8) and >>> inbound (type=0)) to get the ICMP request/reply running. >>> Probably, there is not much to aggregate for outbound/inbound >>> pairs, but saying "I want codes {0,8}". >>> >> >> i could say {0 in, 8 out} or {0 out, 8 in} - if i regard there as >> being a difference between being able to ping and being pingable. >> (and it's *type* not *code*!) >> >> for the other types of messages, it may be that there is no point >> in there being anything other than a default policy associated with >> the state of the corresponding flow, so there is nothing to signal. >> that would be a reasonable point of view. i think the analysis needs >> to be done [maybe Elwyn has already done it ;-) ] >> >> r. >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> --Apple-Mail-22--501030046 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIwMjA4MDQwM1owIwYJKoZIhvcNAQkEMRYEFIcjdtjKtBQJ32wGbAoc EQRvLPaeMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAH+yW1EvOQdXcyztacaW vakq3FvWxckxHAvfe0AHL2IBgb8kaW4Z/l5SEPhXlx15VP5VexFGsSRkszmyjY8d5nthZZ+kZb0l VmHzkXuwcmmyScAMj8UyOgnf9yiIhyTR1gujBCaLSd1drBY0FntOd+f2UHZXK+5HBs8w+zMUXRcD vnrzTGOTAdkATnrMcukOKD+jeiTOckI9zJ2TQIZ2emMI6wJMgbEo04nqmGijEt1rKgMFT+bxCKS9 F5lRUmxyzgAwXLzBHXAu1CBuI8erWHAdFvzXDhpcBOKIDm3nMl5gCjSPL/3lYOqBRUVRqJXrDsaB CwWd9EElODLupzXtYD4AAAAAAAA= --Apple-Mail-22--501030046-- --===============0368413350== 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 --===============0368413350==-- From nsis-bounces@ietf.org Thu Feb 02 08:25:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4eSU-0006P0-9Q; Thu, 02 Feb 2006 08:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4eSQ-0006JM-AS for nsis@megatron.ietf.org; Thu, 02 Feb 2006 08:25:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02175 for ; Thu, 2 Feb 2006 08:23:19 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19spuHhuLJpsWVz1wxK+qdJhmxnGfZH3kY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4edd-0002v8-7u for nsis@ietf.org; Thu, 02 Feb 2006 08:36:42 -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 1F4eRl-00012a-Eh; Thu, 02 Feb 2006 14:24:35 +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 13F93A1C4; Thu, 2 Feb 2006 14:24:24 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F4eRj-00081p-HJ; Thu, 02 Feb 2006 14:24:23 +0100 Message-ID: <43E20806.2020304@tm.uka.de> Date: Thu, 02 Feb 2006 14:24: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] Yet a new diff of the QoS NSLP 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: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jukka, > updated text to discuss the issues and effects of mobility - this should > answer some of your earlier comments in various emails. > > http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html > > If I have missed some of your comments, please let me know (again). This is just an "isComposing" notification, so feedback is coming :-) I'll hack up some more notes. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 02 09:48:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4flO-00019P-Sp; Thu, 02 Feb 2006 09:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4flM-00013i-3I for nsis@megatron.ietf.org; Thu, 02 Feb 2006 09:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08793 for ; Thu, 2 Feb 2006 09:47:01 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4fwd-0006Kf-Ar for nsis@ietf.org; Thu, 02 Feb 2006 10:00:25 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id k12EmKom010063; Thu, 2 Feb 2006 15:48:20 +0100 (MET) Message-ID: <00e501c62807$b6c4f100$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Ash, Gerald R \(Jerry\), ALABS" References: <9473683187ADC049A855ED2DA739ABCA09FA9A19@KCCLUST06EVS1.ugd.att.com> Subject: Re: [NSIS] RE: QSPEC - admission priority parameter Date: Thu, 2 Feb 2006 15:48:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.499 () ALL_TRUSTED, BAYES_00, FVGT_s_OBFU_Q1, 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]); Thu, 02 Feb 2006 15:48:23 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id k12EmKom010063 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Nsis \(E-mail\)" , 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry Please see bellow: > The procedures for the 16-bit admission priority parameter defined in=20 > http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.= txt=20 > appears to derive heavily on procedures specified for RSVP Preemption=20 > Priority: > [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element= ",=20 > RFC 3181, October 2001. > > The QSPEC I-D specifies preemption/defending priority parameters in=20 > Section 7.2.7.1 (Preemption Priority> & Parameters= =20 > [RFC 3181]). > But the=20 http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t=20 draft specifies that: " [RSVP-POLICY] defines extensions for supporting generic policy based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events. The POLICY_DATA object contains one or more of Policy Elements, each representing a different (and perhaps orthogonal) policy. As an example [RSVP-PREEMP] specifies the Preemption Priority Policy Element. This document defines a new Policy Element called the Admission Priority Policy Element. -//- skip Admission Priority: 16 bit (unsigned) The admission control priority of the flow, in terms of access to resources set aside in order to provide higher probability of call completion to selected flows. Higher values represent higher Priority. A reservation established without an Admission Priority policy element is equivalent to a reservation established with an Admission Priority policy element whose Admission Priority value is 0. " Thus the semantics of the =20 parameter, defined in RFC3181, are different than the semantics required for the admission priority=20 parameter. Furthermore, suppose that one will use the " Parameter", I = am=20 not sure how a router, during the admission control process will be able to=20 distinguish between the different priorities that are differently specified for the different RPH namespaces. How a=20 router will know when to use the DRSN namespace and when to use the ETS name space. See also the e-mail from Percy: "Within a DRSN domain, having multiple priority levels is permitted by th= e=20 SIP RPH header. However, DRSN messages if carried over public IP networks= ,=20 would be considered to be a single High priority class of traffic over th= e=20 public domain." Thus it is not clear to me how we could use the and parameters during the admission control process? It will be better if we could have just one Admission priority parameter=20 that could be used during the admission control process. This means that we should have the possibility to use the sematincs of th= e=20 Admission Priority policy element given in: http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t That is: The admission control priority of the flow, in terms of access to resources set aside in order to provide higher probability of call completion to selected flows. Higher values represent higher Priority. A reservation established without an Admission Priority policy element is equivalent to a reservation established with an Admission Priority policy element whose Admission Priority value is 0. " As starting point we should currently allow at least 6 priorities instead= of=20 the current 3 priorities! Best regards, Georgios ----- Original Message -----=20 From: "Ash, Gerald R (Jerry), ALABS" To: "Georgios Karagiannis" Cc: "Ash, Gerald R (Jerry), ALABS" ;=20 ; "Nsis (E-mail)" ; "Attila=20 B=E1der (IJ/ETH)" Sent: Tuesday, January 31, 2006 1:04 PM Subject: RE: [NSIS] RE: QSPEC - admission priority parameter > Hi Georgios, > >> Yes I agree that the " can provide this mapping, but >> what I would like to have is the possibility to use more than three >> priorities in the Admission Priority parameter. >> For more info, please see: >> http://www.watersprings.org/pub/id/draft-lefaucheur-emergency-rsvp-00.= txt > > We specified 3 levels of admission priority in the QSPEC I-D=20 > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based on t= he=20 > requirements agreed to in several standards bodies, for example: > [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels for= IP=20 > Networks and Services," T1A1/2003-196 R3, November 2004. > > Furthermore, Section 9 "IANA Considerations" in the QSPEC I-D specifies= : > > Admission Priority Parameter (8 bits): > The following values are allocated by this specification: > 0-2: assigned as specified in Section 7.2.6.2 > The allocation policies for further values are as follows: > 3-63: Standards Action > 64-255: Reserved > > Therefore, ample space (256 possible admission priority parameter value= s)=20 > is allocated for additional admission priority parameters to be defined= ,=20 > should requirements arise. > > The procedures for the 16-bit admission priority parameter defined in=20 > http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.= txt=20 > appears to derive heavily on procedures specified for RSVP Preemption=20 > Priority: > [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element= ",=20 > RFC 3181, October 2001. > > The QSPEC I-D specifies preemption/defending priority parameters in=20 > Section 7.2.7.1 (Preemption Priority> & Parameters= =20 > [RFC 3181]). > > Thanks, > Regards, > Jerry > > _______________________________________________ > 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 Feb 02 10:19:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4gEi-00059M-CE; Thu, 02 Feb 2006 10:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4gEc-00054V-GA for nsis@megatron.ietf.org; Thu, 02 Feb 2006 10:19:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11669 for ; Thu, 2 Feb 2006 10:17:10 -0500 (EST) Received: from athena.hosts.co.uk ([212.84.175.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4gPk-0007YH-Ix for nsis@ietf.org; Thu, 02 Feb 2006 10:30:35 -0500 Received: from [200.28.197.39] (helo=[200.28.197.39]) by athena.hosts.co.uk with esmtpa (Exim 4.52) id 1F4gED-00065R-8Q; Thu, 02 Feb 2006 15:18:37 +0000 In-Reply-To: <00e501c62807$b6c4f100$4c0d5982@dynamic.ewi.utwente.nl> References: <9473683187ADC049A855ED2DA739ABCA09FA9A19@KCCLUST06EVS1.ugd.att.com> <00e501c62807$b6c4f100$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <19C3990C-5CE0-401D-99F0-BE4B3F7FD3CA@g11.org.uk> Content-Transfer-Encoding: quoted-printable From: ken carlberg Subject: Re: [NSIS] RE: QSPEC - admission priority parameter Date: Thu, 2 Feb 2006 12:18:19 -0300 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 2.1 (++) X-Spam-Score: 0.2 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(\(Jerry\)\), ALABS" , cornelia.kappler@siemens.com, "Nsis \(\(E-mail\)\)" , =?ISO-8859-1?Q? Attila_B=E1der_=28IJ/ETH=29 ?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org just a thought, but it may be good to wait for the next version of =20 the Le Faucheur draft comes out before digging deeply into a detailed =20= discussion between it and the QSPEC. Francois' -00 draft was =20 presented in TSWG for the first time at the last IETF and I know he =20 received some feedback since then, so it will be of interest to see =20 how the draft evolves. note: I don't wish to muzzle discussion, but just ask that we keep =20 Francois's draft in perspective. I would assume a new version will =20 come out in the next month or so regards, -ken On Feb 2, 2006, at 11:48 AM, Georgios Karagiannis wrote: > Hi Jerry > > Please see bellow: >> The procedures for the 16-bit admission priority parameter defined =20= >> in http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-=20 >> rsvp-00.txt appears to derive heavily on procedures specified for =20 >> RSVP Preemption Priority: >> [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy =20 >> Element", RFC 3181, October 2001. >> >> The QSPEC I-D specifies preemption/defending priority parameters =20 >> in Section 7.2.7.1 (Preemption Priority> & =20 >> Parameters [RFC 3181]). >> > > But the http://www.ietf.org/internet-drafts/draft-lefaucheur-=20 > emergency-rsvp-00.txt draft specifies that: > " > [RSVP-POLICY] defines extensions for supporting generic policy based > admission control in RSVP. These extensions include the standard > format of POLICY_DATA objects and a description of RSVP handling of > policy events. > > The POLICY_DATA object contains one or more of Policy Elements, each > representing a different (and perhaps orthogonal) policy. As an > example [RSVP-PREEMP] specifies the Preemption Priority Policy > Element. > This document defines a new Policy Element called the Admission > Priority Policy Element. > > -//- skip > Admission Priority: 16 bit (unsigned) > The admission control priority of the flow, in terms of access > to resources set aside in order to provide higher probability of > call completion to selected flows. Higher values represent > higher Priority. A reservation established without an Admission > Priority policy element is equivalent to a reservation > established with an Admission Priority policy element whose > Admission Priority value is 0. " > > Thus the semantics of the priority> parameter, defined in RFC3181, > are different than the semantics required for the admission =20 > priority parameter. > > Furthermore, suppose that one will use the " =20 > Parameter", I am not sure > how a router, during the admission control process will be able to =20 > distinguish between the different priorities > that are differently specified for the different RPH namespaces. =20 > How a router will know when to use the DRSN namespace and when to use > the ETS name space. See also the e-mail from Percy: > > "Within a DRSN domain, having multiple priority levels is permitted =20= > by the SIP RPH header. However, DRSN messages if carried over =20 > public IP networks, would be considered to be a single High =20 > priority class of traffic over the public domain." > > Thus it is not clear to me how we could use the and > > parameters during the admission control process? > > It will be better if we could have just one Admission priority =20 > parameter that could be used during the admission control process. > This means that we should have the possibility to use the sematincs =20= > of the Admission Priority policy element > given in: > http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-=20 > rsvp-00.txt > That is: > The admission control priority of the flow, in terms of access > to resources set aside in order to provide higher probability of > call completion to selected flows. Higher values represent > higher Priority. A reservation established without an Admission > Priority policy element is equivalent to a reservation > established with an Admission Priority policy element whose > Admission Priority value is 0. " > > As starting point we should currently allow at least 6 priorities =20 > instead of the current 3 priorities! > > Best regards, > Georgios > > > > > > > > ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" =20 > > To: "Georgios Karagiannis" > Cc: "Ash, Gerald R (Jerry), ALABS" ; =20 > ; "Nsis (E-mail)" ; =20 > "Attila B=E1der (IJ/ETH)" > Sent: Tuesday, January 31, 2006 1:04 PM > Subject: RE: [NSIS] RE: QSPEC - admission priority parameter > > >> Hi Georgios, >> >>> Yes I agree that the " can provide this mapping, but >>> what I would like to have is the possibility to use more than three >>> priorities in the Admission Priority parameter. >>> For more info, please see: >>> http://www.watersprings.org/pub/id/draft-lefaucheur-emergency-=20 >>> rsvp-00.txt >> >> We specified 3 levels of admission priority in the QSPEC I-D =20 >> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based =20= >> on the requirements agreed to in several standards bodies, for =20 >> example: >> [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority =20 >> Levels for IP Networks and Services," T1A1/2003-196 R3, November =20 >> 2004. >> >> Furthermore, Section 9 "IANA Considerations" in the QSPEC I-D =20 >> specifies: >> >> Admission Priority Parameter (8 bits): >> The following values are allocated by this specification: >> 0-2: assigned as specified in Section 7.2.6.2 >> The allocation policies for further values are as follows: >> 3-63: Standards Action >> 64-255: Reserved >> >> Therefore, ample space (256 possible admission priority parameter =20 >> values) is allocated for additional admission priority parameters =20 >> to be defined, should requirements arise. >> >> The procedures for the 16-bit admission priority parameter defined =20= >> in http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-=20 >> rsvp-00.txt appears to derive heavily on procedures specified for =20 >> RSVP Preemption Priority: >> [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy =20 >> Element", RFC 3181, October 2001. >> >> The QSPEC I-D specifies preemption/defending priority parameters =20 >> in Section 7.2.7.1 (Preemption Priority> & =20 >> Parameters [RFC 3181]). >> >> Thanks, >> Regards, >> Jerry >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 02 11:09:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4h15-0002CB-Q3; Thu, 02 Feb 2006 11:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4h0z-00028b-N2 for nsis@megatron.ietf.org; Thu, 02 Feb 2006 11:09:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16187 for ; Thu, 2 Feb 2006 11:07:11 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4hCG-0001BQ-JR for nsis@ietf.org; Thu, 02 Feb 2006 11:20:37 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id k12G8PZp014769; Thu, 2 Feb 2006 17:08:25 +0100 (MET) Message-ID: <039f01c62812$e669e5e0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "ken carlberg" References: <9473683187ADC049A855ED2DA739ABCA09FA9A19@KCCLUST06EVS1.ugd.att.com><00e501c62807$b6c4f100$4c0d5982@dynamic.ewi.utwente.nl> <19C3990C-5CE0-401D-99F0-BE4B3F7FD3CA@g11.org.uk> Subject: Re: [NSIS] RE: QSPEC - admission priority parameter Date: Thu, 2 Feb 2006 17:08:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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: -5.499 () ALL_TRUSTED, BAYES_00, FVGT_s_OBFU_Q1, 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]); Thu, 02 Feb 2006 17:08:32 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id k12G8PZp014769 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(\(Jerry\)\), ALABS" , =?iso-8859-1?Q?_Attila_B=E1der_=28IJ/ETH=29_?= , "Nsis \(\(E-mail\)\)" , 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ken The problem that I have is related to the fact that it is not easy to use the and parameters for admission control. It should be possible to have a common parameter that could be used for=20 admission priority. I thought that the common parameter is the Parameter. The only point that I am asking is to allow to have instead of three=20 priorities, at least seven priorities in the Parameter: 0 - best-effort priority flow 1 - normal priority flow 2 - high priority flow 3- high2 priority flow 4 - high3 priority flow 5 - high4 priority flow 6 - high5 priority flow Furthermore, the following sentence is required in Section 7.2.7.2 : "A reservation established without an Admission Priority policy element is equivalent to a reservation established with an Admission Priority policy element whose Admission Priority value is 1. " Best Regards, Georgios ----- Original Message -----=20 From: "ken carlberg" To: "Georgios Karagiannis" Cc: "Ash, Gerald R ((Jerry)), ALABS" ;=20 ; "Nsis ((E-mail))" ; " Atti= la=20 B=E1der (IJ/ETH) " Sent: Thursday, February 02, 2006 4:18 PM Subject: Re: [NSIS] RE: QSPEC - admission priority parameter > just a thought, but it may be good to wait for the next version of the= Le=20 > Faucheur draft comes out before digging deeply into a detailed discuss= ion=20 > between it and the QSPEC. Francois' -00 draft was presented in TSWG f= or=20 > the first time at the last IETF and I know he received some feedback=20 > since then, so it will be of interest to see how the draft evolves. > > note: I don't wish to muzzle discussion, but just ask that we keep=20 > Francois's draft in perspective. I would assume a new version will co= me=20 > out in the next month or so > > regards, > > -ken > > On Feb 2, 2006, at 11:48 AM, Georgios Karagiannis wrote: > >> Hi Jerry >> >> Please see bellow: >>> The procedures for the 16-bit admission priority parameter defined i= n=20 >>> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-=20 >>> rsvp-00.txt appears to derive heavily on procedures specified for RS= VP=20 >>> Preemption Priority: >>> [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy=20 >>> Element", RFC 3181, October 2001. >>> >>> The QSPEC I-D specifies preemption/defending priority parameters in=20 >>> Section 7.2.7.1 (Preemption Priority> & Paramet= ers=20 >>> [RFC 3181]). >>> >> >> But the http://www.ietf.org/internet-drafts/draft-lefaucheur-=20 >> emergency-rsvp-00.txt draft specifies that: >> " >> [RSVP-POLICY] defines extensions for supporting generic policy based >> admission control in RSVP. These extensions include the standard >> format of POLICY_DATA objects and a description of RSVP handling of >> policy events. >> >> The POLICY_DATA object contains one or more of Policy Elements, each >> representing a different (and perhaps orthogonal) policy. As an >> example [RSVP-PREEMP] specifies the Preemption Priority Policy >> Element. >> This document defines a new Policy Element called the Admission >> Priority Policy Element. >> >> -//- skip >> Admission Priority: 16 bit (unsigned) >> The admission control priority of the flow, in terms of access >> to resources set aside in order to provide higher probability of >> call completion to selected flows. Higher values represent >> higher Priority. A reservation established without an Admission >> Priority policy element is equivalent to a reservation >> established with an Admission Priority policy element whose >> Admission Priority value is 0. " >> >> Thus the semantics of the =20 >> parameter, defined in RFC3181, >> are different than the semantics required for the admission priority=20 >> parameter. >> >> Furthermore, suppose that one will use the " Parameter"= , I=20 >> am not sure >> how a router, during the admission control process will be able to=20 >> distinguish between the different priorities >> that are differently specified for the different RPH namespaces. How = a=20 >> router will know when to use the DRSN namespace and when to use >> the ETS name space. See also the e-mail from Percy: >> >> "Within a DRSN domain, having multiple priority levels is permitted b= y=20 >> the SIP RPH header. However, DRSN messages if carried over public IP=20 >> networks, would be considered to be a single High priority class of=20 >> traffic over the public domain." >> >> Thus it is not clear to me how we could use the and >> >> parameters during the admission control process? >> >> It will be better if we could have just one Admission priority parame= ter=20 >> that could be used during the admission control process. >> This means that we should have the possibility to use the sematincs o= f=20 >> the Admission Priority policy element >> given in: >> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-=20 >> rsvp-00.txt >> That is: >> The admission control priority of the flow, in terms of access >> to resources set aside in order to provide higher probability of >> call completion to selected flows. Higher values represent >> higher Priority. A reservation established without an Admission >> Priority policy element is equivalent to a reservation >> established with an Admission Priority policy element whose >> Admission Priority value is 0. " >> >> As starting point we should currently allow at least 6 priorities=20 >> instead of the current 3 priorities! >> >> Best regards, >> Georgios >> >> >> >> >> >> >> >> ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS"=20 >> >> To: "Georgios Karagiannis" >> Cc: "Ash, Gerald R (Jerry), ALABS" ;=20 >> ; "Nsis (E-mail)" ; "Att= ila=20 >> B=E1der (IJ/ETH)" >> Sent: Tuesday, January 31, 2006 1:04 PM >> Subject: RE: [NSIS] RE: QSPEC - admission priority parameter >> >> >>> Hi Georgios, >>> >>>> Yes I agree that the " can provide this mapping, but >>>> what I would like to have is the possibility to use more than three >>>> priorities in the Admission Priority parameter. >>>> For more info, please see: >>>> http://www.watersprings.org/pub/id/draft-lefaucheur-emergency-=20 >>>> rsvp-00.txt >>> >>> We specified 3 levels of admission priority in the QSPEC I-D=20 >>> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based o= n=20 >>> the requirements agreed to in several standards bodies, for example: >>> [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels = for=20 >>> IP Networks and Services," T1A1/2003-196 R3, November 2004. >>> >>> Furthermore, Section 9 "IANA Considerations" in the QSPEC I-D=20 >>> specifies: >>> >>> Admission Priority Parameter (8 bits): >>> The following values are allocated by this specification: >>> 0-2: assigned as specified in Section 7.2.6.2 >>> The allocation policies for further values are as follows: >>> 3-63: Standards Action >>> 64-255: Reserved >>> >>> Therefore, ample space (256 possible admission priority parameter=20 >>> values) is allocated for additional admission priority parameters to= be=20 >>> defined, should requirements arise. >>> >>> The procedures for the 16-bit admission priority parameter defined i= n=20 >>> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-=20 >>> rsvp-00.txt appears to derive heavily on procedures specified for RS= VP=20 >>> Preemption Priority: >>> [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy=20 >>> Element", RFC 3181, October 2001. >>> >>> The QSPEC I-D specifies preemption/defending priority parameters in=20 >>> Section 7.2.7.1 (Preemption Priority> & Paramet= ers=20 >>> [RFC 3181]). >>> >>> Thanks, >>> Regards, >>> Jerry >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > 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 Feb 02 12:53:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ie1-0007aF-9m; Thu, 02 Feb 2006 12:53:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4idz-0007Yv-HH for nsis@megatron.ietf.org; Thu, 02 Feb 2006 12:53:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24243 for ; Thu, 2 Feb 2006 12:51:41 -0500 (EST) From: Gabor.Bajko@nokia.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ipP-0004qD-3w for nsis@ietf.org; Thu, 02 Feb 2006 13:05:08 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by mx2.foretec.com with esmtp (Exim 4.24) id 1F4idw-0006ko-6x for nsis@ietf.org; Thu, 02 Feb 2006 12:53:16 -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 k12Hjv9a015942; Thu, 2 Feb 2006 19:50:04 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 19:48:11 +0200 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 11:48:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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 NSLP: Signaling for ICMP policy rules Date: Thu, 2 Feb 2006 09:48:07 -0800 Message-ID: <84CA64E50179964E8EF67403019ABB94019C18D1@sdebe101.NOE.Nokia.com> In-Reply-To: <36694.134.76.81.25.1138730439.squirrel@mail.piranho.net> Thread-Topic: [NSIS] NATFW NSLP: Signaling for ICMP policy rules Thread-Index: AcYm6P79hjjmgp4qRgqhXaq5aNn/tQBM9r/w To: , , X-OriginalArrivalTime: 02 Feb 2006 17:48:09.0211 (UTC) FILETIME=[D446C4B0:01C62820] X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hello, The requirement in 3GPP2 came from real use case scenarios. What currently happens in wireless networks is, that in the IPv4 address space ICMP traffic is ongoing (either initiated by users or e.g. routers). As also pointed out in http://www.watersprings.org/pub/id/draft-davies-v6ops-icmpv6-filtering-b cp-00.txt, ICMP is a useful auxiliary in IPv4, but life could go on fine without it too.=20 ICMP traffic hurts wireless mobiles in two ways: one ICMP may wake up a mobile, thus sending periodic ICMP to it may result in the battery going flat even if the mobile is not used. Also, a ping -t type of traffic targeted to the mobile would not only harm the mobile but the wireless network operator too (by consuming a significant % of the available resource). The firewalls in 3GPP2 are regular 'deny by default' FWs. But when a pinhole is opened, that can allow unwanted ICMP traffic too. So what 3GPP2 wanted was something similar to 'open a pinhole to my IP address and allow everything except ICMP'. For IPv4 this seems trivial as a rule saying 'deny ICMP' would solve the issue. And the other way around, when pinholes are opened by applications making use of ICMP (e.g. SIP), then ICMP traffic should be allowed. The use cases described by Robert could also be valid. For ICMPv6 things are not so simple. The mobile should not receive unwanted ICMPv6, but its connection should not be altered, i.e. ICMPv6 messages that are needed to maintain the functioning of the network should not be dropped while the rest could. The granularity of the rule to be defined for ICMP is a tradeoff. We need some granularity, but too much of it would be an overhead and burden. Gabor >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Henning Peters >Sent: Tuesday, January 31, 2006 10:01 AM >To: Martin Stiemerling >Cc: nsis >Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules > >Hi Martin, > >can you specify an application for the signaling of ICMP policy rules? >Don't ICMP messages already refer to a certain data flow? I=20 >don't see a reason why a firewall or NAT should deny or drop=20 >them. And if they are configured to behave like this, a=20 >different configuration might not be wanted in the first=20 >place?! But probably the 3GPP2 guys already have sth. >particular in mind that I am currently not seeing. > >How does the change affect NAT? As this might have impacts on=20 >the (de)multiplexing behavior of NATs. > >If adding a new code object to NAT/FW NSLP, allowing multiple=20 >codes in a single message might be valuable to save=20 >unnecessary signaling traffic. > >> - For REA and REA-F, the "Data Terminal Information Object" must be=20 >> modified to carry the ICMP code. > >Why do you want to have a new code object _and_ an additional=20 >code field in the DTInfo object? Wouldn't it make sense to set=20 >the protocol to ICMP in DTInfo protocol field and add the new=20 >ICMP code object regularly? > >Henning > > >Martin Stiemerling sagte Di, 31.01.2006, 13:10: >> Dear all, >> >> The NSIS working group has received some request from a=20 >3GPP2 working=20 >> group to add features to the NATFW NSLP, as said in my email sent=20 >> before. >> >> One of the features is the ability to signaling for ICMP=20 >policy rules.=20 >> Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP flows=20 >> by using the NTLP path-coupled MRM and the LE-MRM. It's possible to=20 >> signal for ICMP flows by using the PC-MRM and setting the 'protocol'=20 >> field to 'ICMP'. However, it is currently not possible to specify=20 >> anything beyond that, for instance, the ICMP code to be used. >> >> Here is the proposed extension to the NATFW NSLP: >> - Add a new object 'icmp' that carries solely the ICMP code >> - This object can be included in CREATE messages where the NTLP is=20 >> carrying a MRM with IP addresses only, protocol set to ICMP. >> - For REA and REA-F, the "Data Terminal Information Object" must be=20 >> modified to carry the ICMP code. >> >> This proposed change does *NOT* require any change to the NTLP but >> *ONLY* to the NATFW NSLP. >> >> Any view on this? >> >> Thanks, >> >> 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 02 14:45:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kOO-0001Ss-Ni; Thu, 02 Feb 2006 14:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kOM-0001RV-Q7 for nsis@megatron.ietf.org; Thu, 02 Feb 2006 14:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03379 for ; Thu, 2 Feb 2006 14:43:39 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4kZi-0000Uf-Ry for nsis@ietf.org; Thu, 02 Feb 2006 14:57:05 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-126.messagelabs.com!1138909495!9212916!6 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8955 invoked from network); 2 Feb 2006 19:45:02 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-126.messagelabs.com with SMTP; 2 Feb 2006 19:45:02 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 43D3BB520018E8D9; Thu, 2 Feb 2006 14:45:00 -0500 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: Thu, 2 Feb 2006 13:45:00 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9A60@KCCLUST06EVS1.ugd.att.com> Thread-Topic: QSPEC - admission priority parameter Thread-Index: AcYoB7yIDX4n7NMwRCyM+CcLJ5esBwAHonOg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Nsis \(E-mail\)" , cornelia.kappler@siemens.com Subject: [NSIS] RE: QSPEC - admission priority parameter X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios, I agree with Ken Carlberg that that we should keep the RSVP-priority = draft = http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t in perspective. It is a new draft, in progress. Furthermore, I = believe the RSVP-priority draft was inspired by suggestions from An = Nguyen of NCS (see acknowledgements), to align RSVP priority = capabilities with NSIS capabilities in the 'priority signaling' area. = So perhaps comments should be directed to the RSVP-priority draft to = align it with NSIS/QSPEC (if you think they're not aligned). IMO there is no functionality proposed in the RSVP-priority document = that is not already possible in the NSIS/QSPEC. > > The procedures for the 16-bit admission priority parameter defined > > in = http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t=20 > > appears to derive heavily on procedures specified for RSVP = Preemption=20 > > Priority: > > [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy = Element",=20 > > RFC 3181, October 2001. > > > > The QSPEC I-D specifies preemption/defending priority parameters in=20 > > Section 7.2.7.1 (Preemption Priority> & = Parameters=20 > > [RFC 3181]). =20 > But the=20 > = http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t=20 > draft specifies that: > " > [RSVP-POLICY] defines extensions for supporting generic policy based > admission control in RSVP. These extensions include the standard > format of POLICY_DATA objects and a description of RSVP handling of > policy events. >=20 > The POLICY_DATA object contains one or more of Policy=20 > Elements, each > representing a different (and perhaps orthogonal) policy. As an > example [RSVP-PREEMP] specifies the Preemption Priority Policy > Element. > This document defines a new Policy Element called the Admission > Priority Policy Element. >=20 > -//- skip > Admission Priority: 16 bit (unsigned) > The admission control priority of the flow, in terms of access > to resources set aside in order to provide higher=20 > probability of > call completion to selected flows. Higher values represent > higher Priority. A reservation established without an Admission > Priority policy element is equivalent to a reservation > established with an Admission Priority policy element whose > Admission Priority value is 0. " >=20 > Thus the semantics of the =20 > parameter, defined in RFC3181, > are different than the semantics required for the admission priority=20 > parameter. Of course the semantics are different. The comment about the = relationship to [RSVP-PREEMP] comes from the RSVP-priority document = itself (see Acknowledgements "this document borrows heavily from some of = the work of S. Herzog on Preemption Priority Policy Element = [RSVP-PREEMP]"). =20 > Furthermore, suppose that one will use the "=20 > Parameter", I am not sure how a router, during the admission > control process will be able to distinguish between the > different priorities that are differently specified for the > different RPH namespaces. How a router will know when to use > the DRSN namespace and when to use the ETS name space. See also > the e-mail from Percy: >=20 > "Within a DRSN domain, having multiple priority levels is=20 > permitted by the SIP RPH header. However, DRSN messages if carried > over public IP networks, would be considered to be a single High > priority class of traffic over the public domain." >=20 > Thus it is not clear to me how we could use the and > parameters during the > admission control process? As you know, detailed behaviors and procedures are defined in QOSM = drafts. =20 General behaviors are discussed in the QSPEC I-D = http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt.=20 Section 5.2.1 specifies: " =3D is the priority of the new flow compared with the defending priority of previously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. is used to compare with the preemption priority of new flows. For any specific flow, its preemption priority MUST always be less than or equal to the defending priority. and provide an essential way to differentiate flows for emergency services, ETS, E911, etc., and assign them a higher admission priority than normal priority flows and best-effort priority flows." Section 7.2.7 specifies: "7.2.7.1 & Parameters [RFC 3181] Preemption Priority: The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority. Defending Priority: Once a flow is admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows. As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the parameter is used. 7.2.7.2 Parameter [PRIORITY-RQMTS] High priority flows, normal priority flows, and best-effort priority flows can have access to resources depending on their admission priority value, as described in [PRIORITY-RQMTS], as follows: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow 7.2.7.3 Parameter [SIP-PRIORITY] [SIP-PRIORITY] defines a resource priority header (RPH) with parameters "RPH Namespace" and "RPH Priority" combination, and if populated is applicable only to flows with high reservation priority, as follows: RPH Namespace: 0 - dsn 1 - drsn 2 - q735 3 - ets 4 - wps 5 - not populated RPH Priority: Each namespace has a finite list of relative priority-values. Each is listed here in the order of lowest priority to highest priority: 4 - dsn.routine 3 - dsn.priority 2 - dsn.immediate 1 - dsn.flash 0 - dsn.flash-override 5 - drsn.routine 4 - drsn.priority 3 - drsn.immediate 2 - drsn.flash 1 - drsn.flash-override 0 - drsn.flash-override-override 4 - q735.4 3 - q735.3 2 - q735.2 1 - q735.1 0 - q735.0 4 - ets.4 3 - ets.3 2 - ets.2 1 - ets.1 0 - ets.0 4 - wps.4 =20 3 - wps.3 2 - wps.2 1 - wps.1 0 - wps.0" Hence, & behaviors are = specified in [RFC3181], and are required for backward compatibility with = [RFC3181]. (high, normal, best-effort) behaviors = are specified in published standards/requirements from ATIS/ITU and = other SDOs (e.g., see [PRIORITY-RQMTS]). behaviors are = specified in [SIP-PRIORITY] and if populated are applicable only to = flows with high admission priority. For example, values may be used to modify queuing or = other behaviors of high-priority admissions, where an E911 voice call = and an ETS data session are marked high priority, but different QoS = mechanisms are used to support them. Once again, this is a hypothetical = example, specific behaviors for services are specified in = NSIS/QSPEC-QOSM documents. =20 > It will be better if we could have just one Admission priority > parameter that could be used during the admission control > process. > This means that we should have the possibility to use the=20 > sematincs of the Admission Priority policy element given in: > = http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t > That is: > The admission control priority of the flow, in terms of access > to resources set aside in order to provide higher=20 > probability of > call completion to selected flows. Higher values represent > higher Priority. A reservation established without an Admission > Priority policy element is equivalent to a reservation > established with an Admission Priority policy element whose > Admission Priority value is 0. " >=20 > As starting point we should currently allow at least 6 priorities = instead > of the current 3 priorities! Note that RSVP-priority is not doing away with & = , but adding admission priority. So far, no RSVP = mechanisms have been proposed to support . If more (e.g., 6) admission priority elements are defined, this would = have to modify current requirements for 3 admission priority elements. = If you wish to undertake such an effort, I think it should be done in = concert with the other SDOs that have generated the current = requirements. Furthermore, [RFC3181]-specified & = , and [SIP-PRIORITY]-specified need = to be maintained for backward compatibility. Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 02 16:30:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4m2K-0007Xr-0X; Thu, 02 Feb 2006 16:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4m2E-0007Qo-BR for nsis@megatron.ietf.org; Thu, 02 Feb 2006 16:30:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14333 for ; Thu, 2 Feb 2006 16:28:47 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18zR9VTuEv24GpCqqvZDvbvyZ8DZToH2jg=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4mDT-0005IH-Rd for nsis@ietf.org; Thu, 02 Feb 2006 16:42:15 -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 1F4m1q-0000dH-FF; Thu, 02 Feb 2006 22:30:16 +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 0435AA240; Thu, 2 Feb 2006 22:30:10 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F4m1p-0008R0-Kr; Thu, 02 Feb 2006 22:30:09 +0100 Message-ID: <43E279FA.3040304@tm.uka.de> Date: Thu, 02 Feb 2006 22:30:34 +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> In-Reply-To: <43CE14CD.9030604@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: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew, sorry, unfortunately I had no time to reply earlier...so I'm too late draft-..-nslp-09 was published today. [Warning, long E-Mail, see comments inline] > I did a review of the rerouting aspects of the QoS NSLP, and came across > some potential problems. (NB: some of these also relate to the "GIST > Refresh Mechanism eventually breaks upstream pathonCrossover Router" > thread). Which was initiated by Thomas IIRC... > A summary of the issues is below, followed by proposed updates to the > draft. > > - There isn't currently a mechanism for a node to tell its upstream peer > that it thinks its upstream route has changed (this concept is > referenced in the GIST draft, but didn't exist in the QoS NSLP). This > requires an additional notification code, and some rules for propagating > such a message upstream. Yep. > - There is possibly an issue where the old path continues to send > refreshes after a route change. Some extra text is needed to avoid > oscillating between the old/new paths (i.e. need to look at SIIs), > which should also ensure that it will fall back to the old path if > rerouting back to the old path really does occur (e.g. fall back if > continue to get refreshes after some time, though you do have to be > careful about this). Yep. > - Another issue is that of making sure that a TEAR down the old path > doesn't go too far (and tear down reservations at nodes that should > still exist because they are on the common path). The solution is that > the TEAR shouldn't be sent until you've received an end-to-end ack of > the RESERVE on the new path. Earlier versions of the draft also had a This is right. Markus and I discovered the same problem. So in this case it is always required to send a RESERVE with an RII. > mechanism to do with counting backwards (RSN-1) for the TEAR to sort out > problems where a route change wasn't really a route change (but, e.g., a > change in the interfaces between the same two nodes). This got removed > (the need for it looked like it had gone away), but I think it is still > needed (though restricted to a particular use). Ok, need to check this one. > I also came some editorial issues in the rerouting text. In my proposed > updates, I've created a new section in section 5 on processing related > to rerouting. This includes the changes described above, and also > includes some normative text from 3.2.10 (which is meant to be an > informative section). > > 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. > 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). 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. > 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. > 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 > 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. > 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. > 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. > .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. > .sh 4 "Route change oscillation" > > In some circumstances a route change may occur, but the path than typo: then > 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 ??? > - or, it stops receiving refreshes from the new upstream peer for at > least the soft state timeout period Ok. > GIST routing state keeps track of the latest upstream peer it has > seen, and so may spuriously indicate route changes occur when the old > upstream peer refreshes its routing state until the state at that node > is explicitly torn down or times out. > Any comments? Thanks for trying to improve the spec. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 02 17:08:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mcz-0006Cv-Ea; Thu, 02 Feb 2006 17:08:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mcv-0006Bm-Gb for nsis@megatron.ietf.org; Thu, 02 Feb 2006 17:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19612 for ; Thu, 2 Feb 2006 17:06:43 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19tUqPogPxQHpghADTMmkR/Q1lSI29whEc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4moF-0007WA-0c for nsis@ietf.org; Thu, 02 Feb 2006 17:20:12 -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 1F4mcb-0002WA-7c; Thu, 02 Feb 2006 23:08: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 E25AB8EB6; Thu, 2 Feb 2006 23:08:08 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F4mca-0008SC-K8; Thu, 02 Feb 2006 23:08:08 +0100 Message-ID: <43E282E1.3040306@tm.uka.de> Date: Thu, 02 Feb 2006 23:08:33 +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: nsis , Andrew McDonald , Jukka MJ Manner , Georgios Karagiannis X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] QoS NSLP: ACK flag has no effect? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, a quick question: Currently, a RESERVE with an ACK flag will trigger an immediate RESPONSE, but... this will have no effect on the state machine, e.g. no timer is started, no retransmission triggered if the response is missing etc. Therefore the provisional RESPONSE triggered by the ACK flag will have no effect, so currently it is pretty useless?! Furthermore, the RESPONSE codes for the ACK triggered responses are inconsistent: If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state installation action. It does so by sending a RESPONSE with an INFO_SPEC indicating that the reservation is installed at the QNE (code 0x03). ... 5.4.3. RESPONSE Messages ... In this case a successful RESPONSE carries the INFO_SPEC with success code 0x01 and the received message is forwarded further along the path towards the QNR. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 03 04:23:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4x9l-0000go-MO; Fri, 03 Feb 2006 04:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4x9f-0000eu-Cw for nsis@megatron.ietf.org; Fri, 03 Feb 2006 04:23:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08610 for ; Fri, 3 Feb 2006 04:21:13 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4xL3-0005dK-Ce for nsis@ietf.org; Fri, 03 Feb 2006 04:34:47 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id k139McVL001819; Fri, 3 Feb 2006 10:22:38 +0100 (MET) Message-ID: <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Roland Bless" , "nsis" , "Andrew McDonald" , "Jukka MJ Manner" References: <43E282E1.3040306@tm.uka.de> Date: Fri, 3 Feb 2006 10:22:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=original 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: -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]); Fri, 03 Feb 2006 10:22:41 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] Re: QoS NSLP: ACK flag has no effect? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland Your observations are right! Could you please propose the text that solves these problems! Best Regards, Georgios ----- Original Message ----- From: "Roland Bless" To: "nsis" ; "Andrew McDonald" ; "Jukka MJ Manner" ; "Georgios Karagiannis" Sent: Thursday, February 02, 2006 11:08 PM Subject: QoS NSLP: ACK flag has no effect? > Hi, > > a quick question: Currently, a RESERVE with an ACK flag > will trigger an immediate RESPONSE, but... > this will have no effect on the state machine, e.g. > no timer is started, no retransmission triggered if the > response is missing etc. > Therefore the provisional RESPONSE triggered by the > ACK flag will have no effect, so currently it is pretty > useless?! > > > Furthermore, the RESPONSE codes for the ACK triggered responses > are inconsistent: > > If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state > installation action. It does so by sending a RESPONSE with an > INFO_SPEC indicating that the reservation is installed at the QNE > (code 0x03). > > ... > > 5.4.3. RESPONSE Messages > ... > > In this case a successful RESPONSE carries > the INFO_SPEC with success code 0x01 and the received message is > forwarded further along the path towards the QNR. > > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 03 09:06:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51ZY-0003iY-O7; Fri, 03 Feb 2006 09:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51Tw-0001KS-BB for nsis@megatron.ietf.org; Fri, 03 Feb 2006 09:00:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23162 for ; Fri, 3 Feb 2006 08:05:00 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F50Sv-0004mq-2t for nsis@ietf.org; Fri, 03 Feb 2006 07:55:05 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id k13Ch1Nh015846 for ; Fri, 3 Feb 2006 13:43:01 +0100 (MET) Message-ID: <00d501c628bf$5f293b00$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Nsis \(E-mail\)" Date: Fri, 3 Feb 2006 13:42:57 +0100 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: -5.563 () ALL_TRUSTED, BAYES_00, FVGT_s_OBFU_Q0, HTML_40_50, HTML_MESSAGE 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]); Fri, 03 Feb 2006 13:43:04 +0100 (MET) X-Spam-Score: 0.6 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Subject: [NSIS] CFP: IEEE Int'l Workshop on QoS (IWQoS 2006) X-BeenThere: nsis@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="===============2052022246==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2052022246== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01C628C7.BDCA42F0" This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C628C7.BDCA42F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear colleague: We would like to bring to your attention the upcoming deadlines of IWQoS 2006. Our sincere apologies if you receive multiple copies of this message. Paper registration and submission deadlines are 2/20 and 2/27/2006. -- IWQoS organizing committee ---------------------------------- CALL FOR PAPERS Fourteenth IEEE International Workshop on Quality of Service (IWQoS 2006) June 19-21, 2006 Yale University, New Haven, CT, USA OVERVIEW Since 1994, IWQoS has evolved into a premier workshop providing an international forum for the presentation and discussion of cutting edge research on quality of service (QoS). Building on the successes of = previous workshops, the objective of IWQoS 2006 is to bring together researchers, developers, and practitioners working in the area to discuss timely = research results, and to identify future directions and challenges in developing practical computer/networking systems where predictable, controlled, and = robust performance is a central requirement. The workshop's scope will broadly=20 cover all the important aspects of QoS research: in networking (wireline,=20 wireless, and sensor networks), distributed systems, operating systems, servers, = and middleware (such as grid computing and peer-to-peer systems), where = relevant technical issues include availability, reliability, security, pricing, incentive, resource management, and performance guarantees. Topics of interest include (but are not limited to): o QoS in grid, peer-to-peer, overlay, and wireless mesh = networks o QoS in large-scale distributed systems o System dependability, availability, resilience, and = robustness o Security as a QoS parameter o Rationality, incentive, microeconomics, and self-interest = in decentralized networks o QoS in wireless, mobile, ad hoc, and sensor networks o QoS specification, translation, and adaptation o Measurement-based QoS estimation and verification o QoS in intranets and VoIP systems We also solicit papers in the following areas: o QoS architectures and protocols o QoS analysis and modeling o Resource management and admission control o QoS routing o QoS pricing and billing o Evaluation metrics and methodologies for QoS o Content delivery networks with service/performance = guarantees o QoS in web systems and storage systems o Programmability and language features supporting QoS o QoS in multimedia systems o Service Level Agreements and QoS o Server-side QoS and its roles in end-to-end QoS = provisioning o QoS-aware middleware frameworks and services o Integrated and differentiated services in wide-area = networks The workshop is a single track forum of two and a half days. It is cross-disciplinary and well focused, with an emphasis on innovation. As = a result, a considerable amount of the meeting time will be devoted to=20 informal discussions. The workshop values both theoretical and practical research contributions. BEST STUDENT PAPER AWARD Award will be given at the conference to the best student paper, whose = first author is a current student. IMPORTANT DATES Paper abstract deadline: February 20, 2006 Paper submission deadline: February 27, 2006 Notification of acceptance: March 31, 2006 Camera-ready papers due: April 20, 2006 Workshop dates: June 19-21, 2006 ORGANIZINIG COMMITTEE TPC co-chairs Yang Richard Yang, Yale University (yry@cs.yale.edu) David K Y Yau, Purdue University (yau@cs.purdue.edu) Publicity chair Jelena Mirkovic, Univ of Delaware (sunshine@cis.udel.edu) Steering Committee Nina Bhatti, Hewlett Packard Laboratories, USA Hermann De Meer, University of Passau, Germany Kevin Jeffay, University of North Carolina, Chapel Hill, USA Baochun Li, University of Toronto, Canada Ion Stoica, University of California, Berkeley, USA Zhi-Li Zhang, University of Minnesota, Twin Cities, USA FOR FURTHER INFORMATION Please visit http://www-net.cs.yale.edu/iwqos06 ------=_NextPart_000_00D0_01C628C7.BDCA42F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 colleague:

We would like to bring to your attention the upcoming=20 deadlines
of IWQoS 2006.

Our sincere apologies if you receive = multiple=20 copies of this message.

Paper registration and submission = deadlines are=20 2/20 and 2/27/2006.

-- IWQoS organizing=20 committee

----------------------------------
   =             &= nbsp;   =20 CALL FOR PAPERS
     Fourteenth IEEE = International=20 Workshop on Quality of=20 Service
          &n= bsp;           &nb= sp;    =20 (IWQoS=20 2006)

          =             &= nbsp;   =20 June 19-21,=20 2006
           = ;    =20 Yale University, New Haven, CT, USA

OVERVIEW

Since 1994, = IWQoS has=20 evolved into a premier workshop providing an
international forum for = the=20 presentation and discussion of cutting edge
research on quality of = service=20 (QoS). Building on the successes of previous
workshops, the objective = of=20 IWQoS 2006 is to bring together researchers,
developers, and = practitioners=20 working in the area to discuss timely research
results, and to = identify=20 future directions and challenges in developing
practical = computer/networking=20 systems where predictable, controlled, and
robust
performance is = a=20 central requirement. The workshop's scope will broadly
cover
all = the=20 important aspects of QoS research: in networking (wireline, =
wireless,
and=20 sensor networks), distributed systems, operating systems, servers,=20 and
middleware (such as grid computing and peer-to-peer systems), = where=20 relevant
technical issues include availability, reliability, = security,=20 pricing,
incentive, resource management, and performance=20 guarantees.

Topics of interest include (but are not limited=20 to):

           = o QoS=20 in grid, peer-to-peer, overlay, and wireless mesh=20 networks
           = o QoS=20 in large-scale distributed=20 systems
           = o System=20 dependability, availability, resilience, and=20 robustness
          = ; o=20 Security as a QoS=20 parameter
          = o=20 Rationality, incentive, microeconomics, and self-interest=20 in
           &= nbsp;=20 decentralized=20 networks
           = o QoS=20 in wireless, mobile, ad hoc, and sensor=20 networks
           = o QoS=20 specification, translation, and=20 adaptation
          = ; o=20 Measurement-based QoS estimation and=20 verification
         &nb= sp; o=20 QoS in intranets and VoIP systems

We also solicit papers in the = following=20 areas:

          = ; o QoS=20 architectures and=20 protocols
          = o QoS=20 analysis and=20 modeling
           = o=20 Resource management and admission=20 control
           = o QoS=20 routing
           = o QoS=20 pricing and=20 billing
           = o=20 Evaluation metrics and methodologies for=20 QoS
           o = Content=20 delivery networks with service/performance=20 guarantees
          = ; o QoS=20 in web systems and storage=20 systems
           = o=20 Programmability and language features supporting=20 QoS
           o = QoS in=20 multimedia=20 systems
           = o=20 Service Level Agreements and=20 QoS
           o=20 Server-side QoS and its roles in end-to-end QoS=20 provisioning
         &nb= sp; o=20 QoS-aware middleware frameworks and=20 services
           = o=20 Integrated and differentiated services in wide-area networks

The = workshop=20 is a single track forum of two and a half days. It = is
cross-disciplinary and=20 well focused, with an emphasis on innovation. As a
result, a = considerable=20 amount of the meeting time will be devoted to =
informal
discussions. The=20 workshop values both theoretical and practical=20 research
contributions.

BEST STUDENT PAPER AWARD

Award = will be=20 given at the conference to the best student paper, whose first
author = is a=20 current student.

IMPORTANT DATES

Paper abstract deadline: = February=20 20, 2006
Paper submission deadline: February 27, 2006
Notification = of=20 acceptance: March 31, 2006
Camera-ready papers due: April 20,=20 2006
Workshop dates: June 19-21, 2006

ORGANIZINIG = COMMITTEE

TPC=20 co-chairs
       Yang Richard Yang, = Yale=20 University (yry@cs.yale.edu)
       David K Y Yau, Purdue = University (yau@cs.purdue.edu)

Publicity = chair
       Jelena=20 Mirkovic, Univ of Delaware (sunshine@cis.udel.edu)

Steering = Committee
       Nina=20 Bhatti, Hewlett Packard Laboratories,=20 USA
       Hermann De Meer, University = of=20 Passau, Germany
       Kevin Jeffay, = University=20 of North Carolina, Chapel Hill, = USA
      =20 Baochun Li, University of Toronto,=20 Canada
       Ion Stoica, University of = California, Berkeley, USA
       Zhi-Li = Zhang,=20 University of Minnesota, Twin Cities, USA

FOR FURTHER=20 INFORMATION

Please visit http://www-net.cs.yale.edu/iwqos06
------=_NextPart_000_00D0_01C628C7.BDCA42F0-- --===============2052022246== 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 --===============2052022246==-- From nsis-bounces@ietf.org Wed Feb 08 05:45:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6mpF-0003Ci-5w; Wed, 08 Feb 2006 05:45:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6mpD-00039C-0P for nsis@megatron.ietf.org; Wed, 08 Feb 2006 05:45:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09297 for ; Wed, 8 Feb 2006 05:43:44 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6n1k-0007CK-SF for nsis@ietf.org; Wed, 08 Feb 2006 05:58: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 1F6moe-0006Eo-IF; Wed, 08 Feb 2006 11:44:55 +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 673619FBC; Wed, 8 Feb 2006 11:44:52 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F6moe-0001oJ-5s; Wed, 08 Feb 2006 11:44:52 +0100 Message-ID: <43E9CBA3.1030603@tm.uka.de> Date: Wed, 08 Feb 2006 11:44:51 +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: Georgios Karagiannis Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <43E282E1.3040306@tm.uka.de> <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Andrew McDonald , Jukka MJ Manner , nsis , "Geib, Ruediger" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, > Your observations are right! > Could you please propose the text that solves these problems! I can try to send text, but I'm not really sure about the purpose of this ACK mechanism. I guess Ruediger Geib wanted it (that's why I put him into the CC). Maybe he can shed some light on it. My observations so far: - the ACK flag is currently set by default. I'm not sure whether this is _really_ required if we have a GIST reliable transport below QoS NSLP. So similar to SIP we could make it default in case of unreliable transport, but otherwise it's not used. It will only have a benefit in case that a notification of a broken connection by GIST takes a long time, e.g. until TCP reports connections failure. - If ACK should have any effect, we probably want to retransmit the RESERVE after a very short time if the RESPONSE is missing. However, we have a lot of options: * How long should we make the (default) timeout? * 200ms, 500ms? (it's only the "next" hop) * Exponential backoff? How many retries? * Should we signal the expected reply period to the peer? * The timeout could be made adaptive so that we measure the average time until an ACK usually arrives. - In case something will go wrong (state installation did not succeed), a negative RESPONSE is sent back immediately anyway. - In sec. 3.2.5 it is mentioned that reduced refreshes require an ACK "to ensure that the RSN will be understood". However, in case we have reliable transport and the RSN is not understood, we get a response indicating the problem anyway. My conclusion: - We probably need the ACK only when GIST is used in an unreliable transport mode, otherwise it's not required. - We must determine some timeout value. I would suggest to set it to 0.5s, 1s and 1.5s by default, i.e. at most 3 retransmissions. Retransmitting the RESERVE would do no harm because the next QNE can use the RSN to check for duplicates. >> a quick question: Currently, a RESERVE with an ACK flag >> will trigger an immediate RESPONSE, but... >> this will have no effect on the state machine, e.g. >> no timer is started, no retransmission triggered if the >> response is missing etc. >> Therefore the provisional RESPONSE triggered by the >> ACK flag will have no effect, so currently it is pretty >> useless?! >> Furthermore, the RESPONSE codes for the ACK triggered responses >> are inconsistent: >> >> If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state >> installation action. It does so by sending a RESPONSE with an >> INFO_SPEC indicating that the reservation is installed at the QNE >> (code 0x03). >> >> ... >> >> 5.4.3. RESPONSE Messages >> ... >> >> In this case a successful RESPONSE carries >> the INFO_SPEC with success code 0x01 and the received message is >> forwarded further along the path towards the QNR. I would suggest to use code 0x01 in both cases. However, 0x01 has the actual meaning of "State installation/refresh/modification succeeded" Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 06:19:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nLg-000340-NI; Wed, 08 Feb 2006 06:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nLf-00033u-83 for nsis@megatron.ietf.org; Wed, 08 Feb 2006 06:18:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12481 for ; Wed, 8 Feb 2006 06:17:18 -0500 (EST) 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 1F6nYE-0008S6-2B for nsis@ietf.org; Wed, 08 Feb 2006 06:31: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; Wed, 08 Feb 2006 13:18:51 +0200 id 0007019F.43E9D39B.000036E1 Date: Wed, 8 Feb 2006 13:18:50 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? In-Reply-To: <43E9CBA3.1030603@tm.uka.de> Message-ID: References: <43E282E1.3040306@tm.uka.de> <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> <43E9CBA3.1030603@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: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: Andrew McDonald , Georgios Karagiannis , nsis , "Geib, Ruediger" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Sounds good to me. Retransmissions are traditionally exponential and not very agressive to not cause DoS attacks, so if we start with 500ms, then the next will happen after 1000ms, then 2000ms, and so on if more than three are sent. Also, some random parameter in the retransmission helps to protect from network synchronization. GIST leaves the retransmission parameters to implementations, though. Jukka On Wed, 8 Feb 2006, Roland Bless wrote: > Hi Georgios, > > Your observations are right! > > Could you please propose the text that solves these problems! > > I can try to send text, but I'm not really sure about > the purpose of this ACK mechanism. I guess Ruediger > Geib wanted it (that's why I put him into the CC). > Maybe he can shed some light on it. > > My observations so far: > - the ACK flag is currently set by default. > I'm not sure whether this is _really_ required > if we have a GIST reliable transport below QoS NSLP. > So similar to SIP we could make it default in case > of unreliable transport, but otherwise it's not used. > It will only have a benefit in case that a notification > of a broken connection by GIST takes a long time, e.g. > until TCP reports connections failure. > - If ACK should have any effect, we probably want to > retransmit the RESERVE after a very short time > if the RESPONSE is missing. However, we have a lot > of options: > * How long should we make the (default) timeout? > * 200ms, 500ms? (it's only the "next" hop) > * Exponential backoff? How many retries? > * Should we signal the expected reply period to the peer? > * The timeout could be made adaptive so that we measure > the average time until an ACK usually arrives. > - In case something will go wrong (state installation did > not succeed), a negative RESPONSE is sent back immediately > anyway. > - In sec. 3.2.5 it is mentioned that reduced refreshes > require an ACK "to ensure that the RSN will be understood". > However, in case we have reliable transport > and the RSN is not understood, we get a response indicating > the problem anyway. > > My conclusion: > - We probably need the ACK only when GIST is used in an > unreliable transport mode, otherwise it's not required. > - We must determine some timeout value. I would > suggest to set it to 0.5s, 1s and 1.5s by default, i.e. > at most 3 retransmissions. Retransmitting the RESERVE would > do no harm because the next QNE can use the RSN to check > for duplicates. > > >> a quick question: Currently, a RESERVE with an ACK flag > >> will trigger an immediate RESPONSE, but... > >> this will have no effect on the state machine, e.g. > >> no timer is started, no retransmission triggered if the > >> response is missing etc. > >> Therefore the provisional RESPONSE triggered by the > >> ACK flag will have no effect, so currently it is pretty > >> useless?! > > >> Furthermore, the RESPONSE codes for the ACK triggered responses > >> are inconsistent: > >> > >> If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state > >> installation action. It does so by sending a RESPONSE with an > >> INFO_SPEC indicating that the reservation is installed at the QNE > >> (code 0x03). > >> > >> ... > >> > >> 5.4.3. RESPONSE Messages > >> ... > >> > >> In this case a successful RESPONSE carries > >> the INFO_SPEC with success code 0x01 and the received message is > >> forwarded further along the path towards the QNR. > > I would suggest to use code 0x01 in both cases. However, 0x01 has > the actual meaning of > "State installation/refresh/modification succeeded" > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 06:19:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nMX-0003CB-N9; Wed, 08 Feb 2006 06:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nMV-00037s-KF for nsis@megatron.ietf.org; Wed, 08 Feb 2006 06:19:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12504 for ; Wed, 8 Feb 2006 06:17:40 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6nYa-0008SH-JV for nsis@ietf.org; Wed, 08 Feb 2006 06:32:22 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 8 Feb 2006 12:17:10 +0100 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <1MK77ZT0>; Wed, 8 Feb 2006 12:17:09 +0100 Message-Id: <5F9130612D07074EB0A0CE7E69FD7A0308127444@S4DE8PSAAGS.blf.telekom.de> From: "Geib, Ruediger" To: bless@tm.uka.de Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Wed, 8 Feb 2006 12:17:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland, thanks for your analyisis and your proposal. The timer is=20 required indeed and I'm happy to go with your suggestion=20 on the timer value and simple repeat mechanism. |My conclusion: |- We probably need the ACK only when GIST is used in an | unreliable transport mode, otherwise it's not required. If GIST is able to detect a broken reliable transport connection=20 by its own (i.e. GIST functionalities), I agree. I recall a=20 bad TCP implementation below MPLS LDP some years ago. LDP had no=20 facilities to detect this. The result was service disruption=20 without possibility to recognise the event or the location=20 where it happened. NSLP/GIST should not repeat this design error. If GIST is not able to detect a broken reliable transport mechanism=20 by a GIST mechanism, I'd like to propose the ACK also in reliable=20 transport mode. |- We must determine some timeout value. I would | suggest to set it to 0.5s, 1s and 1.5s by default, i.e. | at most 3 retransmissions. Retransmitting the RESERVE would | do no harm because the next QNE can use the RSN to check | for duplicates. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 07:43:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6of6-0001Id-MX; Wed, 08 Feb 2006 07:43:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6of4-0001IG-EA for nsis@megatron.ietf.org; Wed, 08 Feb 2006 07:43:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18005 for ; Wed, 8 Feb 2006 07:41:25 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19+FiV+zKR5BQ0FT+H1vkyMmEDSylyzibs=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6ore-0002eD-88 for nsis@ietf.org; Wed, 08 Feb 2006 07:56:07 -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 1F6odw-0003V3-Vf; Wed, 08 Feb 2006 13:42:52 +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 D04878799; Wed, 8 Feb 2006 13:41:55 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F6odv-0001up-Ht; Wed, 08 Feb 2006 13:41:55 +0100 Message-ID: <43E9E712.7020701@tm.uka.de> Date: Wed, 08 Feb 2006 13:41:54 +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: <43E282E1.3040306@tm.uka.de> <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> <43E9CBA3.1030603@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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Andrew McDonald , Georgios Karagiannis , nsis , "Geib, Ruediger" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jukka, > Sounds good to me. Currently I have the impression that we have specified a solution for a problem that isn't clearly defined. Therefore it would be helpful to describe the problem that the ACK mechanism is intended to solve. > Retransmissions are traditionally exponential and not very agressive to > not cause DoS attacks, so if we start with 500ms, then the next will > happen after 1000ms, then 2000ms, and so on if more than three are sent. Sure, I know that. However, maybe we have also a retransmission from end-to-end when an RII is given, so the retransmission between two hops should be faster than the end-to-end retransmission. That's why I did not strictly follow the exponential backoff scheme. However, if we decide to actually measure the "RTT" then we should use an exponential backoff scheme, but we need some extra state for the estimated RTT and I'm not sure whether we really need the additional complexity. > Also, some random parameter in the retransmission helps to protect from > network synchronization. Yep. so the above mentioned values are upper bounds or average values... > GIST leaves the retransmission parameters to implementations, though. I'm not sure whether we should do it the same way... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 08:29:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pOQ-0008A7-AM; Wed, 08 Feb 2006 08:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pON-00088h-EW for nsis@megatron.ietf.org; Wed, 08 Feb 2006 08:29:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22197 for ; Wed, 8 Feb 2006 08:28:05 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/M5dVE69TnLhD0ROoqGL6B0B0f2i1BDi8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6pap-0004Zk-N4 for nsis@ietf.org; Wed, 08 Feb 2006 08:42:49 -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 1F6pO9-0006Os-CB; Wed, 08 Feb 2006 14:29:43 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 28E3C8BF3; Wed, 8 Feb 2006 14:29:41 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F6pO8-0001yu-Q8; Wed, 08 Feb 2006 14:29:40 +0100 Message-ID: <43E9F243.6040100@tm.uka.de> Date: Wed, 08 Feb 2006 14:29:39 +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: "Geib, Ruediger" Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <5F9130612D07074EB0A0CE7E69FD7A0308127444@S4DE8PSAAGS.blf.telekom.de> In-Reply-To: <5F9130612D07074EB0A0CE7E69FD7A0308127444@S4DE8PSAAGS.blf.telekom.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ruediger, > thanks for your analyisis and your proposal. The timer is > required indeed and I'm happy to go with your suggestion > on the timer value and simple repeat mechanism. Currently, I have the impression that we have specified a solution for a problem that isn't clearly defined. Therefore it would be helpful to clearly describe the problem that the ACK mechanism is intended to solve. Then we are probably better in designing a minimal mechanism that actually solves the particular problem and prevent to design a rather generic ACK scheme for a set of (nonrelevant) problems. > |My conclusion: > |- We probably need the ACK only when GIST is used in an > | unreliable transport mode, otherwise it's not required. > > If GIST is able to detect a broken reliable transport connection > by its own (i.e. GIST functionalities), I agree. I recall a > bad TCP implementation below MPLS LDP some years ago. LDP had no > facilities to detect this. The result was service disruption > without possibility to recognise the event or the location > where it happened. NSLP/GIST should not repeat this design error. > > If GIST is not able to detect a broken reliable transport mechanism > by a GIST mechanism, I'd like to propose the ACK also in reliable > transport mode. There is the MA-Hello mechanism in GIST which also allows to detect a failed messaging association (though this is not the main intention of MA Hellos, right?). The MA-Hold-Time is indicated to a peer during the setup phase. Thus, one is basically able to react faster than TCP would detect a dead peer if the NoHello Timeout is small enough. > |- We must determine some timeout value. I would > | suggest to set it to 0.5s, 1s and 1.5s by default, i.e. > | at most 3 retransmissions. Retransmitting the RESERVE would > | do no harm because the next QNE can use the RSN to check > | for duplicates. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 09:11:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6q2r-0004ES-FF; Wed, 08 Feb 2006 09:11:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6q2q-0004DS-3d for nsis@megatron.ietf.org; Wed, 08 Feb 2006 09:11:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25461 for ; Wed, 8 Feb 2006 09:10:02 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6qFP-000624-SC for nsis@ietf.org; Wed, 08 Feb 2006 09:24:46 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 8 Feb 2006 15:07:59 +0100 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <1MK787CJ>; Wed, 8 Feb 2006 15:07:57 +0100 Message-Id: <5F9130612D07074EB0A0CE7E69FD7A030812744A@S4DE8PSAAGS.blf.telekom.de> From: "Geib, Ruediger" To: bless@tm.uka.de Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect? Date: Wed, 8 Feb 2006 15:07:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hello Roland, |There is the MA-Hello mechanism in GIST which also allows to detect |a failed messaging association (though this is not the main intention |of MA Hellos, right?). The MA-Hold-Time is indicated |to a peer during the setup phase. Thus, one is basically able to react |faster than TCP would detect a dead peer if the NoHello=20 |Timeout is small enough. My point was whether GIST would detect a loss of connectivity if the=20 reliable transport below it is broken, but not aware that it is broken. The LDP example I mentioned was caused by such a problem.=20 Would NSLP detect that the GIST layer below it is dead if GIST in that=20 situation is not aware that it is dead? If yes, the above ack mechanism = will indicate the problem on NSLP level. The idea behind the proposed ACK mechanism on NSLP level despite = reliable=20 transport is a "lesson learned". Always make sure that a communication=20 layer in itself is able to detect a broken communication, if that is=20 relevant for the service offered. The result of that lesson for LDP was the specification of MPLS OAM=20 (MPLS PING, MPLS Traceroute). NSLP PING would be another possibility to = achieve what I mean. It is reactive (you do that after discovering an=20 issue), while an ACK mechanism could be used for pro-active problem=20 detection (log or alert if RESV wasn't acked after beeing resent n = times). Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 09:22:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qDN-00021W-5O; Wed, 08 Feb 2006 09:22:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qDJ-00020x-Iy for nsis@megatron.ietf.org; Wed, 08 Feb 2006 09:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26270 for ; Wed, 8 Feb 2006 09:20:43 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+Cn2EdaO9+X24TIQZcA+6g6xMbyKQbCHs=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6qPm-0006QS-Fg for nsis@ietf.org; Wed, 08 Feb 2006 09:35: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 1F6qCw-0001Dz-DU; Wed, 08 Feb 2006 15:22:19 +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 1B3278790; Wed, 8 Feb 2006 15:22:06 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F6qCr-00024C-Q4; Wed, 08 Feb 2006 15:22:05 +0100 Message-ID: <43E9FE8D.6030401@tm.uka.de> Date: Wed, 08 Feb 2006 15:22:05 +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> In-Reply-To: <43E279FA.3040304@tm.uka.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: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, > 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 Hmm, I'm sorry. I forgot that the current spec also allows to send a refreshing RESERVE with an RII. However, is there a reason for doing this? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 08 09:27:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qHs-0003FM-3V; Wed, 08 Feb 2006 09:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qHn-0003Es-RT for nsis@megatron.ietf.org; Wed, 08 Feb 2006 09:27:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26494 for ; Wed, 8 Feb 2006 09:25:21 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX180czkB4Q8NGmTKr9P/C01z2b3JQ2jtf3k=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6qUG-0006ZA-Ib for nsis@ietf.org; Wed, 08 Feb 2006 09:40:06 -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 1F6qHT-0001YQ-FV; Wed, 08 Feb 2006 15:26: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 05A278790; Wed, 8 Feb 2006 15:26:48 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1F6qHP-00024K-PH; Wed, 08 Feb 2006 15:26:47 +0100 Message-ID: <43E9FFA6.4000905@tm.uka.de> Date: Wed, 08 Feb 2006 15:26: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: "Geib, Ruediger" Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <5F9130612D07074EB0A0CE7E69FD7A030812744A@S4DE8PSAAGS.blf.telekom.de> In-Reply-To: <5F9130612D07074EB0A0CE7E69FD7A030812744A@S4DE8PSAAGS.blf.telekom.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 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 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ruediger, > |There is the MA-Hello mechanism in GIST which also allows to detect > |a failed messaging association (though this is not the main intention > |of MA Hellos, right?). The MA-Hold-Time is indicated > |to a peer during the setup phase. Thus, one is basically able to react > |faster than TCP would detect a dead peer if the NoHello > |Timeout is small enough. > > My point was whether GIST would detect a loss of connectivity if the > reliable transport below it is broken, but not aware that it is broken. > > The LDP example I mentioned was caused by such a problem. > > Would NSLP detect that the GIST layer below it is dead if GIST in that > situation is not aware that it is dead? If yes, the above ack mechanism > will indicate the problem on NSLP level. Ok, if the point is to detect a dead GIST, then the ACK feature may be useful indeed. > The idea behind the proposed ACK mechanism on NSLP level despite reliable > transport is a "lesson learned". Always make sure that a communication > layer in itself is able to detect a broken communication, if that is > relevant for the service offered. > > The result of that lesson for LDP was the specification of MPLS OAM > (MPLS PING, MPLS Traceroute). NSLP PING would be another possibility to > achieve what I mean. It is reactive (you do that after discovering an > issue), while an ACK mechanism could be used for pro-active problem > detection (log or alert if RESV wasn't acked after beeing resent n times). Ok, thanks for the motivation. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 09 01:06:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74wa-000568-SC; Thu, 09 Feb 2006 01:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74wY-00050t-RT; Thu, 09 Feb 2006 01:06:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18768; Thu, 9 Feb 2006 01:04:33 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F759H-0000aC-Ey; Thu, 09 Feb 2006 01:19:24 -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 k1966Arn022766; Thu, 9 Feb 2006 08:06:11 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 08:06:11 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 08:06:10 +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, 9 Feb 2006 08:06:09 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01A566CA@esebe100.NOE.Nokia.com> Thread-Topic: WGLC on NSLP for Quality-of-Service signalling & QoS-NSLP QSPEC Template Thread-Index: AcYtPuvkJF4sdzekR52ACg2f3YMeWA== To: X-OriginalArrivalTime: 09 Feb 2006 06:06:10.0832 (UTC) FILETIME=[ECA86900:01C62D3E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] WGLC on NSLP for Quality-of-Service signalling & QoS-NSLP QSPEC Template X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, (Note: TSVWG WG is BCC:ed on this announcement, please respond on the NSIS mailing list.) I would like to start WGLC on these two documents together. The WGLC will run for two weeks until February 24th. The documents can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-09.txt http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt The authors have received a few mails on the drafts, so please consider those mails as part of the Last Call comments. =20 Could the authors keep track of all last call comments, and if you are planning to use an issue tracker, please send the link to the issue list. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 09 04:00:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F77er-0003q1-FQ; Thu, 09 Feb 2006 04:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F77ep-0003pl-QB for nsis@megatron.ietf.org; Thu, 09 Feb 2006 04:00:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00839 for ; Thu, 9 Feb 2006 03:58:25 -0500 (EST) 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 1F77rY-0006xB-Ch for nsis@ietf.org; Thu, 09 Feb 2006 04:13:19 -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 Feb 2006 11:00:02 +0200 id 000702AF.43EB0492.00006244 Date: Thu, 9 Feb 2006 11:00:02 +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: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [NSIS] QoS NSLP WGLC issue tracker X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, We will be using the Roke QoS NSLP issue tracker to store your comments. It would be good to also suggest a solution to an identified problem. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/ Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 09 10:31:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DlR-0003KK-7J; Thu, 09 Feb 2006 10:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DlJ-0003GN-JQ; Thu, 09 Feb 2006 10:31:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00959; Thu, 9 Feb 2006 10:29:20 -0500 (EST) Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Dxs-0003df-Jo; Thu, 09 Feb 2006 10:44:18 -0500 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (8.12.11/Switch-3.1.0) with ESMTP id k19FUVok026887; Thu, 9 Feb 2006 10:30:32 -0500 (EST) In-Reply-To: Subject: RE: [NSIS] QSPEC - admission priority parameter To: "Roy, Radhika R." X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Thu, 9 Feb 2006 10:30:28 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 02/09/2006 10:29:44 AM 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: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , "Nsis \(E-mail\)" , "Attila =?ISO-8859-1?Q?B=E1der?= \(IJ/ETH\)" , "Nguyen, An P CIV NCS NC2" , nsis-bounces@ietf.org, 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Sorry for the late response. The RPH document contains the following statement, in the Introduction.= " While the 'Resource-Priority' header field does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header field to cause such influence may b= e defined in other documents." Janet = "Roy, Radhika R." = = To Sent by: "Tarapore, Percy S, ALABS" = nsis-bounces@ietf , "Nguyen, An = P .org CIV NCS NC2" , Georgios Karagiannis = , "Ash, = 01/31/2006 10:04 Gerald R (Jerry), ALABS" = AM , = cornelia.kappler@siemens.com, = Attila B=E1der (IJ/ETH) = = = cc "Nsis \(E-mail\)" Subj= ect RE: [NSIS] QSPEC - admission = priority parameter = = = = = = = Folks: SIP provides the indication for "PRIORITY" how a call (indication in signaling messages) will be handled for admission in the network. However, a SIP call may transfer more than one media: Audio (real-time)= , video (real-time), and/or data (non-real-time). The call level priority= in signaling messages does NOT explain how each media (audio, video, data)= payload type will be handled to provide QoS in terms of PRIORITIES. It may so happen audio may have to be treated with highest priority, wh= ile video may have the lowest priority, etc. In the light of the above, let us synthesize where the chips fall in te= rms of providing "priority treatments" of different traffic over the IP net= work from the call level to the IP packet/media payload level. Cheers, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of= Tarapore, Percy S, ALABS Sent: Tuesday, January 31, 2006 9:29 AM To: Nguyen, An P CIV NCS NC2; Georgios Karagiannis; Ash, Gerald R (Jerr= y), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter The critical point to note is this. Within a DRSN domain, having multip= le priority levels is permitted by the SIP RPH header. However, DRSN messa= ges if carried over public IP networks, would be considered to be a single = High priority class of traffic over the public domain. The same is true for = ETS services. The rationale is that the total volume of High priority traff= ic (whether it is ETS or WPS or DRSN) is dwarfed by the rest of the traffi= c over public IP networks, especially Best Effort traffic. Percy -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of= Nguyen, An P CIV NCS NC2 Sent: Tuesday, January 31, 2006 9:11 AM To: 'Georgios Karagiannis'; Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter Georgeois, I think you are talking about three levels of admission priority in the= public networks with ETS being the highest. And DRSN is a private network. Six levels of admission control for DRSN= should be allowed. Regards, An -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of Georgios Karagiannis Sent: Tuesday, January 31, 2006 5:21 AM To: Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: [NSIS] QSPEC - admission priority parameter Hello Jerry, Attila and Cornelia In section 7.2.7.2 of the QSPEC template draft you mention that the Admission Priority parameter should have only three priorities, see below: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow Why is that? Three admission priorities are not enough! Suppose that we would like to map the 6 priorities required by Defense Red Switched Network (DRSN) ([SIP-PRIORITY]) into the admission priority parameter. Then this will not be possible! My proposal will be to allow the specification of a higher number of admission priorities! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ 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 Feb 10 11:10:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aqs-00040k-2J; Fri, 10 Feb 2006 11:10:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aqq-00040P-LP for nsis@megatron.ietf.org; Fri, 10 Feb 2006 11:10:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02715 for ; Fri, 10 Feb 2006 11:08:44 -0500 (EST) 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 1F7b3r-0006Ri-6Q for nsis@ietf.org; Fri, 10 Feb 2006 11:23:56 -0500 Received: from [10.3.1.136] (din-cisuc136.dei.uc.pt [10.3.1.136]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k1AG9spP010071 for ; Fri, 10 Feb 2006 16:09:54 GMT Message-ID: <43ECBAEF.6030008@student.dei.uc.pt> Date: Fri, 10 Feb 2006 16:10:23 +0000 From: David Palma User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) 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-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=-4.399, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [NSIS] Problem in QoSNSLP/NSISNTLP 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org 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 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. 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? Regards, David Palma _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 10 15:50:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7fDc-0007dt-Dd; Fri, 10 Feb 2006 15:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7fDP-0007Vi-NZ; Fri, 10 Feb 2006 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26977; Fri, 10 Feb 2006 15:48:20 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7fQT-0007wS-GY; Fri, 10 Feb 2006 16:03:34 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F7fDO-0008Et-6f; Fri, 10 Feb 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: Fri, 10 Feb 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST: General Internet Signaling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-09.txt Pages : 132 Date : 2006-2-10 This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signaling Transport (GIST), which provides a universal service for diverse signaling applications. GIST does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signaling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-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-ntlp-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-ntlp-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-2-10154229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-10154229.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 Sun Feb 12 06:37:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8FXm-0002Uc-DR; Sun, 12 Feb 2006 06:37:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8FXl-0002UP-5G for nsis@megatron.ietf.org; Sun, 12 Feb 2006 06:37:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09958 for ; Sun, 12 Feb 2006 06:35:43 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Fl4-000834-CM for nsis@ietf.org; Sun, 12 Feb 2006 06:51:20 -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 k1CBaxoh030984; Sun, 12 Feb 2006 11:36:59 GMT Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Sun, 12 Feb 2006 11:36:58 +0000 From: "Robert Hancock" To: "'David Palma'" , Subject: RE: [NSIS] Problem in QoSNSLP/NSISNTLP draft Date: Sun, 12 Feb 2006 11:37:05 -0000 Message-ID: <010701c62fc8$a691de60$1402a8c0@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: <43ECBAEF.6030008@student.dei.uc.pt> Importance: Normal X-OriginalArrivalTime: 12 Feb 2006 11:36:59.0072 (UTC) FILETIME=[A25EBC00:01C62FC8] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi david, 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 :-) cheers, r. > -----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 > > 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. > > 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? > > Regards, > > David Palma > > > _______________________________________________ > 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 Feb 12 22:54:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8UnY-0004O3-KX; Sun, 12 Feb 2006 22:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F820n-000593-Ug; Sat, 11 Feb 2006 16:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29436; Sat, 11 Feb 2006 16:08:50 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F82E4-0000Hw-Ha; Sat, 11 Feb 2006 16:24:17 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Sat, 11 Feb 2006 16:10:22 -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 M2006021116102223176 ; Sat, 11 Feb 2006 16:10:22 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <1WK2AJQK>; Sat, 11 Feb 2006 16:10:22 -0500 Message-Id: From: "Roy, Radhika R." To: Janet P Gunn Subject: RE: [NSIS] QSPEC - admission priority parameter Date: Sat, 11 Feb 2006 16:10:17 -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" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 12 Feb 2006 22:54:46 -0500 Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , "Nsis \(E-mail\)" , =?iso-8859-1?Q?Attila_B=E1der?= , "Nguyen, An P CIV NCS NC2" , nsis-bounces@ietf.org, 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org It is understood. =20 NSIS is dealing with QoS "signaling." The question that remains is as follows: What kinds QoS they in NSIS?=20 =20 Is it about the handling of a call admission with different "priority levels" of applications, and is NOT about the QoS of media that is = being handled by the calls? =20 If it is so, what does it mean by "Priority" in SIP signaling in the = context of "Priority" in NSIS QoS signaling protocol ? =20 Can anyone help us here? =20 Best regards, Radhika _____ =20 From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: Thu 2/9/2006 10:30 AM To: Roy, Radhika R. Cc: Nguyen, An P CIV NCS NC2; Attila B=E1der; = cornelia.kappler@siemens.com; Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; Nsis (E-mail); nsis-bounces@ietf.org; Tarapore, Percy S, ALABS Subject: RE: [NSIS] QSPEC - admission priority parameter Sorry for the late response. The RPH document contains the following statement, in the Introduction. " While the 'Resource-Priority' header field does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header field to cause such influence may = be defined in other documents." Janet = =20 "Roy, Radhika R." = =20 = To Sent by: "Tarapore, Percy S, ALABS" = =20 nsis-bounces@ietf , "Nguyen, An = P =20 .org CIV NCS NC2" = , Georgios Karagiannis = =20 , "Ash, = =20 01/31/2006 10:04 Gerald R (Jerry), ALABS" = =20 AM , = =20 cornelia.kappler@siemens.com, = =20 Attila B=E1der (IJ/ETH) = =20 = =20 = cc "Nsis \(E-mail\)" = =20 = Subject RE: [NSIS] QSPEC - admission = =20 priority parameter = =20 = =20 = =20 = =20 = =20 = =20 = =20 Folks: SIP provides the indication for "PRIORITY" how a call (indication in signaling messages) will be handled for admission in the network. However, a SIP call may transfer more than one media: Audio = (real-time), video (real-time), and/or data (non-real-time). The call level priority = in signaling messages does NOT explain how each media (audio, video, data) payload type will be handled to provide QoS in terms of PRIORITIES. It may so happen audio may have to be treated with highest priority, = while video may have the lowest priority, etc. In the light of the above, let us synthesize where the chips fall in = terms of providing "priority treatments" of different traffic over the IP = network from the call level to the IP packet/media payload level. Cheers, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org ] On Behalf Of Tarapore, Percy S, ALABS Sent: Tuesday, January 31, 2006 9:29 AM To: Nguyen, An P CIV NCS NC2; Georgios Karagiannis; Ash, Gerald R = (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter The critical point to note is this. Within a DRSN domain, having = multiple priority levels is permitted by the SIP RPH header. However, DRSN = messages if carried over public IP networks, would be considered to be a single = High priority class of traffic over the public domain. The same is true for = ETS services. The rationale is that the total volume of High priority = traffic (whether it is ETS or WPS or DRSN) is dwarfed by the rest of the = traffic over public IP networks, especially Best Effort traffic. Percy -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org ] On Behalf Of Nguyen, An P CIV NCS NC2 Sent: Tuesday, January 31, 2006 9:11 AM To: 'Georgios Karagiannis'; Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter Georgeois, I think you are talking about three levels of admission priority in the public networks with ETS being the highest. And DRSN is a private network. Six levels of admission control for DRSN should be allowed. Regards, An -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org ]On Behalf Of Georgios Karagiannis Sent: Tuesday, January 31, 2006 5:21 AM To: Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: [NSIS] QSPEC - admission priority parameter Hello Jerry, Attila and Cornelia In section 7.2.7.2 of the QSPEC template draft you mention that the Admission Priority parameter should have only three priorities, see below: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow Why is that? Three admission priorities are not enough! Suppose that we would like to map the 6 priorities required by Defense Red Switched Network (DRSN) ([SIP-PRIORITY]) into the admission priority parameter. Then this will not be possible! My proposal will be to allow the specification of a higher number of admission priorities! Best Regards, Georgios _______________________________________________ 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 =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 Feb 12 22:54:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8UnZ-0004Og-W1; Sun, 12 Feb 2006 22:54:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8MDI-0000oe-JZ for nsis@megatron.ietf.org; Sun, 12 Feb 2006 13:44:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06389 for ; Sun, 12 Feb 2006 13:43:03 -0500 (EST) From: ttw_chien@yahoo.com.tw Received: from www.nabble.com ([72.21.53.35] helo=talk.nabble.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8MQl-0002WS-9Y for nsis@ietf.org; Sun, 12 Feb 2006 13:58:43 -0500 Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1F8MDG-0007OC-PA for nsis@ietf.org; Sun, 12 Feb 2006 10:44:46 -0800 Message-ID: <7144644.18431139769886771.JavaMail.nabble@talk.nabble.com> To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 12 Feb 2006 10:44:46 -0800 X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Feb 2006 22:54:45 -0500 Subject: [NSIS] can NSIS implement in home network? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi can NSIS just implement in home network but not region-wide network? Because I think maybe it can solve the mobility in a digital home network,include the admission control and dynamic resource management. Cardigan _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Feb 12 22:54:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8UnZ-0004OF-9L; Sun, 12 Feb 2006 22:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8LYO-0005IV-Gh for nsis@megatron.ietf.org; Sun, 12 Feb 2006 13:02:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03994 for ; Sun, 12 Feb 2006 13:00:47 -0500 (EST) From: ttw_chien@yahoo.com.tw Received: from www.nabble.com ([72.21.53.35] helo=talk.nabble.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Lll-0001NI-En for nsis@ietf.org; Sun, 12 Feb 2006 13:16:27 -0500 Received: from localhost ([127.0.0.1] helo=talk.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1F8LYH-0000Xc-3q for nsis@ietf.org; Sun, 12 Feb 2006 10:02:25 -0800 Message-ID: <1558146.18201139767345056.JavaMail.nabble@talk.nabble.com> To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 12 Feb 2006 10:02:25 -0800 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Feb 2006 22:54:45 -0500 Subject: [NSIS] Can I use the GIST independently? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all: Now I want to use the ns2 to simulate the Qos environment combine with the RMD-RODA and Diffserv, I want to use the RMD-RODA to do the admission control, but in ns2 seems no module for it , but I found that the NSIS could do that , but I don't know how to depart the functionalities from the whole NSIS, could I just seperate the GIST functions from NSIS into my DiffServ architecture to do the RSVP-like functions? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 13 03:48:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZO1-0007oM-IQ; Mon, 13 Feb 2006 03:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZO0-0007oE-Nc for nsis@megatron.ietf.org; Mon, 13 Feb 2006 03:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26244 for ; Mon, 13 Feb 2006 03:47:00 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8ZbZ-0007r7-Bf for nsis@ietf.org; Mon, 13 Feb 2006 04:02:47 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1D8mXWI025647; Mon, 13 Feb 2006 09:48:33 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1D8mVUW005760; Mon, 13 Feb 2006 09:48:32 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 09:48:31 +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] can NSIS implement in home network? Date: Mon, 13 Feb 2006 09:48:31 +0100 Message-ID: Thread-Topic: [NSIS] can NSIS implement in home network? Thread-Index: AcYwUXA4SiP40HPCTVi3cSQWF/Z98QAJphkQ From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 13 Feb 2006 08:48:31.0745 (UTC) FILETIME=[4458C710:01C6307A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi,=20 there are no restrictions with regard to the deployment.=20 the used security mechanisms might vary from network environment to = network environment. ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > Auftrag von ttw_chien@yahoo.com.tw > Gesendet: Sonntag, 12. Februar 2006 19:45 > An: nsis@ietf.org > Betreff: [NSIS] can NSIS implement in home network? >=20 > Hi=20 > can NSIS just implement in home network but not=20 > region-wide network? Because I think maybe it can solve > the mobility in a digital home network,include the admission > control and dynamic resource management. >=20 > Cardigan >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 13 05:07:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8acR-0005wf-Ee; Mon, 13 Feb 2006 05:07:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8acQ-0005wX-IK for nsis@megatron.ietf.org; Mon, 13 Feb 2006 05:07:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02121 for ; Mon, 13 Feb 2006 05:05:57 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8apv-0001uu-UO for nsis@ietf.org; Mon, 13 Feb 2006 05:21:45 -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 k1DA7Loh011523 for ; Mon, 13 Feb 2006 10:07:22 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] I-D ACTION:draft-ietf-nsis-ntlp-09.txt Date: Mon, 13 Feb 2006 10:07:21 -0000 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-09.txt Thread-Index: AcYuhiMu9TXd+1MjQT6eItoM+71yZQB/kz7A From: "Hancock, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, Please see (at last!) the release of GIST-09. This version takes into account all the WGLC comments, as well as various other clarifications and issues that have been brought up during the update period. Many thanks to everyone who has contributed during the development of the spec; it's a long list of names and I think the document is all the better for the many people who have taken part.=20 While we await the next stages of the process, the issue tracker remains open for further comments, but is currently (blissfully) empty :-) http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index Cheers, Robert H. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Internet-Drafts@ietf.org > Sent: 10 February 2006 21:50 > To: i-d-announce@ietf.org > Cc: nsis@ietf.org > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Next Steps in Signaling=20 > Working Group of the IETF. >=20 > Title : GIST: General Internet Signaling Transport > Author(s) : H. Schulzrinne, R. Hancock > Filename : draft-ietf-nsis-ntlp-09.txt > Pages : 132 > Date : 2006-2-10 > =09 > This document specifies protocol stacks for the routing and transport > of per-flow signaling messages along the path taken by that flow > through the network. The design uses existing transport and security > protocols under a common messaging layer, the General Internet > Signaling Transport (GIST), which provides a universal service for > diverse signaling applications. GIST does not handle signaling > application state itself, but manages its own internal state and the > configuration of the underlying transport and security protocols to > enable the transfer of messages in both directions along the flow > path. The combination of GIST and the lower layer transport and > security protocols provides a solution for the base protocol > component of the "Next Steps in Signaling" framework. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-09.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nsis-ntlp-09.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > 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-ietf-nsis-ntlp-09.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 13 21:37:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8q4U-0005XO-Ms; Mon, 13 Feb 2006 21:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8q4S-0005XD-D7 for nsis@megatron.ietf.org; Mon, 13 Feb 2006 21:37:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18247 for ; Mon, 13 Feb 2006 21:35:53 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8qIA-0000oL-0K for nsis@ietf.org; Mon, 13 Feb 2006 21:51:52 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1E2baki023456 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 21:37:37 -0500 (EST) 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@ietf.org From: Henning Schulzrinne Date: Mon, 13 Feb 2006 21:37:36 -0500 X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 2.2 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [NSIS] GIST extensibility concern (IANA considerations) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org On re-reading the extensibility section in the IANA considerations, I have a concern that the mechanism as specified will lead to interoperability problems. In several cases, e.g., for object types and message types, there is a range for "private/experimental use". However, in all these cases, the range is small. For example, for GIST Message Type, only 8 values are available. Thus, if there are two experiments going on in the Internet, it is extremely likely that the two experiments will clash accidentally. In other words, such experiments are rather unsafe unless you operate a very tightly controlled, closed network. It certainly wouldn't be suitable for, say, Internet2-scale experiments or a vendor-specific experiment. In other protocols, private extensions are usually designed so that it is *un*likely that two entities would pick the same identifier. As an example, header names (e.g., X- headers in email) are designed so that two parties can build new extensions, with only a modest likelihood of accidental collisions. DHCP also has vendor-specific codes that have a similar design. I don't think we want to extend the GIST Message Type, for example, beyond 8 bits, as this is likely wasteful. The only alternative is to have an escape mechanism that adds a message type object with a long, random identifier (e.g., a GUID) for such private message types or uses the DHCP-style mechanism. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 14 10:44:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92Ls-0004wp-55; Tue, 14 Feb 2006 10:44:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92Lq-0004t9-2k for nsis@megatron.ietf.org; Tue, 14 Feb 2006 10:44:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06060 for ; Tue, 14 Feb 2006 10:42:40 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92Zb-0006GA-5z for nsis@ietf.org; Tue, 14 Feb 2006 10:58:44 -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 k1EFemoh029034; Tue, 14 Feb 2006 15:40:48 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] GIST extensibility concern (IANA considerations) Date: Tue, 14 Feb 2006 15:40:48 -0000 Message-ID: Thread-Topic: [NSIS] GIST extensibility concern (IANA considerations) Thread-Index: AcYxD+2tHZY9THgfQbuTHgDkbLIl4gAXU05A From: "Hancock, Robert" To: "Henning Schulzrinne" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 2.0 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Henning, This is a good question. I imagine we can continue to fine-tune the assignment ranges (and indeed policies) independently of the technical development of the specificiation, but if we actually need different message formats or to define escape mechanisms that should be done now. At least part of this discussion overlaps with the scope of the overall NSIS extensibility draft (draft-loughney-nsis-ext),=20 because experiments are likely to be about NSIS (e.g. an experimental signalling application) rather than pure GIST experiments. It would be good to know how that draft was going to progress. My thinking on private/experimental ranges was mainly driven by rfc3692 (Thomas Narten's document). That seems to recommend specifically against large ranges, apparently mainly to avoid people abusing=20 experimental allocations for long term use. I'm not sure how any sort of large scale experiment on the open Internet could be=20 accommodated when those types of concerns are taken into account. (I've also sensed vibes from some quarters that making too much allowance for extensibility is a Bad Thing, but I don't know how to turn that into concrete requirements for protocol specification.) In other words, the current IANA text is deliberately conservative=20 on what sort of extensibility is allowed, and maybe we need to=20 address that fundamental point first. A practical point is that (I suspect) most experiments will be in the context of a new signalling application, rather than GIST extensions per se. And the GIST design largely insulates NSLPs from each other, so we could use a larger range of private/ experimental NSLPIDs as part of a solution. (The current IANA considerations allow 16 out of 64k, and I was queried even on=20 why that number was so large ...). There is some discussion on what=20 RAO value to use for such applications in the thread starting here: http://www1.ietf.org/mail-archive/web/nsis/current/msg05111.html The "message type object" could also be a possible approach. If we want it, I think it has to be included in the base specification; I don't see how to add it as an extension. (I think you basically want an object which says "If you don't understand me, ignore or forward the whole message containing me unchanged" which we can't describe currently, although there are flag bits available to denote this.) However, I'm not clear whether we really need this (or indeed whether it would be seen as an example of "excessive extensibility" as noted above). r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Henning Schulzrinne > Sent: 14 February 2006 02:38 > To: nsis@ietf.org > Subject: [NSIS] GIST extensibility concern (IANA considerations) >=20 >=20 > On re-reading the extensibility section in the IANA=20 > considerations, I =20 > have a concern that the mechanism as specified will lead to =20 > interoperability problems. In several cases, e.g., for object types =20 > and message types, there is a range for "private/experimental use". =20 > However, in all these cases, the range is small. For example, for =20 > GIST Message Type, only 8 values are available. Thus, if there are =20 > two experiments going on in the Internet, it is extremely=20 > likely that =20 > the two experiments will clash accidentally. In other words, such =20 > experiments are rather unsafe unless you operate a very tightly =20 > controlled, closed network. It certainly wouldn't be suitable for, =20 > say, Internet2-scale experiments or a vendor-specific experiment. >=20 > In other protocols, private extensions are usually designed so that =20 > it is *un*likely that two entities would pick the same=20 > identifier. As =20 > an example, header names (e.g., X- headers in email) are designed so =20 > that two parties can build new extensions, with only a modest =20 > likelihood of accidental collisions. DHCP also has vendor-specific =20 > codes that have a similar design. >=20 > I don't think we want to extend the GIST Message Type, for example, =20 > beyond 8 bits, as this is likely wasteful. The only=20 > alternative is to =20 > have an escape mechanism that adds a message type object with=20 > a long, =20 > random identifier (e.g., a GUID) for such private message types or =20 > uses the DHCP-style mechanism. >=20 > Henning >=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 Feb 14 11:01:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92cn-0003Ck-QH; Tue, 14 Feb 2006 11:01:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92cm-0003Ce-Hv for nsis@megatron.ietf.org; Tue, 14 Feb 2006 11:01:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06932 for ; Tue, 14 Feb 2006 11:00:10 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92qc-0006js-TO for nsis@ietf.org; Tue, 14 Feb 2006 11:16:15 -0500 Received: from lion.cs.columbia.edu (IDENT:6hc1bKyzYWLNhjgQEAgl/ybjdn3J3MTA@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k1EG0NdB014942 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 14 Feb 2006 11:01:52 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k1EG0NnE018520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Feb 2006 11:00:23 -0500 Message-ID: <43F1FE92.1050100@cs.columbia.edu> Date: Tue, 14 Feb 2006 11:00:18 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LEO_OBFU_DATE_0500 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 2.0 (++) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org I'm not in favor of excessive, non-standardized extensibility. I believe, however, that we need to either have a mechanism that allows non-interfering experiments or to have a strong statement that these are a BAD THING. I'm afraid that we have a dangerous middle ground here: There is a mechanism that kind of allows experiments, but is likely to fail badly and unpredictably if actually used. This is not about rejecting unknown code points, but rather of two experiments colliding, with vendor A and vendor B assigning contradictory meanings to the same message type, for example. If suddenly, equipment from vendor B is introduced, things break badly, but probably only for some paths. This is the worst kind of failure since it is almost impossible to debug. If all you want to support are truly private-network experiments, no extension mechanism is needed. People will just use any unassigned code point (unassigned for their current use) since they know all the devices that are going to see the packets. I think GIST and NSIS are somewhat different from other protocols since they are much more likely to cross administrative and vendor boundaries than simple client-server protocols. In summary, I think we probably need to look at each of the IANA assignments and make a "discourage random experiments" vs. "facilitate experimentation" decision. Henning Hancock, Robert wrote: > Hi Henning, > > This is a good question. I imagine we can continue to fine-tune > the assignment ranges (and indeed policies) independently of the > technical development of the specificiation, but if we actually > need different message formats or to define escape mechanisms that > should be done now. > > At least part of this discussion overlaps with the scope of the > overall NSIS extensibility draft (draft-loughney-nsis-ext), > because experiments are likely to be about NSIS (e.g. an > experimental signalling application) rather than pure GIST > experiments. It would be good to know how that draft was going > to progress. > > My thinking on private/experimental ranges was mainly driven by > rfc3692 (Thomas Narten's document). That seems to recommend specifically > against large ranges, apparently mainly to avoid people abusing > experimental allocations for long term use. I'm not sure how any > sort of large scale experiment on the open Internet could be > accommodated when those types of concerns are taken into account. > (I've also sensed vibes from some quarters that making too much > allowance for extensibility is a Bad Thing, but I don't know how > to turn that into concrete requirements for protocol specification.) > In other words, the current IANA text is deliberately conservative > on what sort of extensibility is allowed, and maybe we need to > address that fundamental point first. > > A practical point is that (I suspect) most experiments will be > in the context of a new signalling application, rather than GIST > extensions per se. And the GIST design largely insulates NSLPs > from each other, so we could use a larger range of private/ > experimental NSLPIDs as part of a solution. (The current IANA > considerations allow 16 out of 64k, and I was queried even on > why that number was so large ...). There is some discussion on what > RAO value to use for such applications in the thread starting here: > http://www1.ietf.org/mail-archive/web/nsis/current/msg05111.html > > The "message type object" could also be a possible approach. If > we want it, I think it has to be included in the base specification; > I don't see how to add it as an extension. (I think you basically > want an object which says "If you don't understand me, ignore or > forward the whole message containing me unchanged" which we can't > describe currently, although there are flag bits available to > denote this.) However, I'm not clear whether we really need this > (or indeed whether it would be seen as an example of "excessive > extensibility" as noted above). > > r. > > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of Henning Schulzrinne >> Sent: 14 February 2006 02:38 >> To: nsis@ietf.org >> Subject: [NSIS] GIST extensibility concern (IANA considerations) >> >> >> On re-reading the extensibility section in the IANA >> considerations, I >> have a concern that the mechanism as specified will lead to >> interoperability problems. In several cases, e.g., for object types >> and message types, there is a range for "private/experimental use". >> However, in all these cases, the range is small. For example, for >> GIST Message Type, only 8 values are available. Thus, if there are >> two experiments going on in the Internet, it is extremely >> likely that >> the two experiments will clash accidentally. In other words, such >> experiments are rather unsafe unless you operate a very tightly >> controlled, closed network. It certainly wouldn't be suitable for, >> say, Internet2-scale experiments or a vendor-specific experiment. >> >> In other protocols, private extensions are usually designed so that >> it is *un*likely that two entities would pick the same >> identifier. As >> an example, header names (e.g., X- headers in email) are designed so >> that two parties can build new extensions, with only a modest >> likelihood of accidental collisions. DHCP also has vendor-specific >> codes that have a similar design. >> >> I don't think we want to extend the GIST Message Type, for example, >> beyond 8 bits, as this is likely wasteful. The only >> alternative is to >> have an escape mechanism that adds a message type object with >> a long, >> random identifier (e.g., a GUID) for such private message types or >> uses the DHCP-style mechanism. >> >> Henning >> >> _______________________________________________ >> 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 Feb 15 02:44:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9HKZ-0000FB-0A; Wed, 15 Feb 2006 02:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9HKX-0000F6-P2 for nsis@megatron.ietf.org; Wed, 15 Feb 2006 02:44:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16973 for ; Wed, 15 Feb 2006 02:42:18 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9HYW-0006wN-9F for nsis@ietf.org; Wed, 15 Feb 2006 02:58:32 -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 k1F7gFH9028024; Wed, 15 Feb 2006 09:42:16 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 09:42:03 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 09:42:02 +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: Wed, 15 Feb 2006 09:42:03 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869C01@esebe100.NOE.Nokia.com> In-Reply-To: <43F1FE92.1050100@cs.columbia.edu> Thread-Topic: [NSIS] GIST extensibility concern (IANA considerations) Thread-Index: AcYxghqVnG5YUFPOTOKw1PLNh0baSQAgMs6w To: , X-OriginalArrivalTime: 15 Feb 2006 07:42:02.0153 (UTC) FILETIME=[4F30D990:01C63203] X-Spam-Score: 2.3 (++) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org 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 proposal, it might be easier to follow. I'm basically following the extensibility model proposed in=20 rfc3692. Also, I think that GIST will be a more 'standard' transport protocol, where open extesibility is discouraged (as in TCP, SCTP, DCCP, etc). John >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Henning Schulzrinne >Sent: 14 February, 2006 18:00 >To: Hancock, Robert >Cc: nsis@ietf.org >Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) > >I'm not in favor of excessive, non-standardized extensibility.=20 >I believe, however, that we need to either have a mechanism=20 >that allows non-interfering experiments or to have a strong=20 >statement that these are a BAD THING. I'm afraid that we have=20 >a dangerous middle ground here:=20 >There is a mechanism that kind of allows experiments, but is=20 >likely to fail badly and unpredictably if actually used. > >This is not about rejecting unknown code points, but rather of=20 >two experiments colliding, with vendor A and vendor B=20 >assigning contradictory meanings to the same message type, for=20 >example. If suddenly, equipment from vendor B is introduced,=20 >things break badly, but probably only for some paths. This is=20 >the worst kind of failure since it is almost impossible to debug. > >If all you want to support are truly private-network=20 >experiments, no extension mechanism is needed. People will=20 >just use any unassigned code point (unassigned for their=20 >current use) since they know all the devices that are going to=20 >see the packets. > >I think GIST and NSIS are somewhat different from other=20 >protocols since they are much more likely to cross=20 >administrative and vendor boundaries than simple client-server=20 >protocols. > >In summary, I think we probably need to look at each of the=20 >IANA assignments and make a "discourage random experiments"=20 >vs. "facilitate experimentation" decision. > >Henning > > >Hancock, Robert wrote: >> Hi Henning, >>=20 >> This is a good question. I imagine we can continue to fine-tune the=20 >> assignment ranges (and indeed policies) independently of the=20 >technical=20 >> development of the specificiation, but if we actually need different=20 >> message formats or to define escape mechanisms that should be done=20 >> now. >>=20 >> At least part of this discussion overlaps with the scope of the=20 >> overall NSIS extensibility draft (draft-loughney-nsis-ext), because=20 >> experiments are likely to be about NSIS (e.g. an experimental=20 >> signalling application) rather than pure GIST experiments.=20 >It would be=20 >> good to know how that draft was going to progress. >>=20 >> My thinking on private/experimental ranges was mainly driven by >> rfc3692 (Thomas Narten's document). That seems to recommend=20 >> specifically against large ranges, apparently mainly to avoid people=20 >> abusing experimental allocations for long term use. I'm not sure how=20 >> any sort of large scale experiment on the open Internet could be=20 >> accommodated when those types of concerns are taken into account. >> (I've also sensed vibes from some quarters that making too much=20 >> allowance for extensibility is a Bad Thing, but I don't know how to=20 >> turn that into concrete requirements for protocol specification.) In=20 >> other words, the current IANA text is deliberately conservative on=20 >> what sort of extensibility is allowed, and maybe we need to address=20 >> that fundamental point first. >>=20 >> A practical point is that (I suspect) most experiments will=20 >be in the=20 >> context of a new signalling application, rather than GIST extensions=20 >> per se. And the GIST design largely insulates NSLPs from each other,=20 >> so we could use a larger range of private/ experimental NSLPIDs as=20 >> part of a solution. (The current IANA considerations allow 16 out of=20 >> 64k, and I was queried even on why that number was so large ...).=20 >> There is some discussion on what RAO value to use for such=20 >> applications in the thread starting here: >> http://www1.ietf.org/mail-archive/web/nsis/current/msg05111.html >>=20 >> The "message type object" could also be a possible approach. If we=20 >> want it, I think it has to be included in the base specification; I=20 >> don't see how to add it as an extension. (I think you basically want=20 >> an object which says "If you don't understand me, ignore or forward=20 >> the whole message containing me unchanged" which we can't describe=20 >> currently, although there are flag bits available to denote this.)=20 >> However, I'm not clear whether we really need this (or=20 >indeed whether=20 >> it would be seen as an example of "excessive extensibility" as noted=20 >> above). >>=20 >> r. >>=20 >>=20 >>> -----Original Message----- >>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 >On Behalf=20 >>> Of Henning Schulzrinne >>> Sent: 14 February 2006 02:38 >>> To: nsis@ietf.org >>> Subject: [NSIS] GIST extensibility concern (IANA considerations) >>> >>> >>> On re-reading the extensibility section in the IANA=20 >considerations, I=20 >>> have a concern that the mechanism as specified will lead to=20 >>> interoperability problems. In several cases, e.g., for object types=20 >>> and message types, there is a range for "private/experimental use". >>> However, in all these cases, the range is small. For example, for=20 >>> GIST Message Type, only 8 values are available. Thus, if there are=20 >>> two experiments going on in the Internet, it is extremely=20 >likely that=20 >>> the two experiments will clash accidentally. In other words, such=20 >>> experiments are rather unsafe unless you operate a very tightly=20 >>> controlled, closed network. It certainly wouldn't be suitable for,=20 >>> say, Internet2-scale experiments or a vendor-specific experiment. >>> >>> In other protocols, private extensions are usually designed so that=20 >>> it is *un*likely that two entities would pick the same=20 >identifier. As=20 >>> an example, header names (e.g., X- headers in email) are=20 >designed so=20 >>> that two parties can build new extensions, with only a modest=20 >>> likelihood of accidental collisions. DHCP also has vendor-specific=20 >>> codes that have a similar design. >>> >>> I don't think we want to extend the GIST Message Type, for example,=20 >>> beyond 8 bits, as this is likely wasteful. The only=20 >alternative is to=20 >>> have an escape mechanism that adds a message type object=20 >with a long,=20 >>> random identifier (e.g., a GUID) for such private message types or=20 >>> uses the DHCP-style mechanism. >>> >>> Henning >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 15 09:32:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Nhv-0001Qw-Fh; Wed, 15 Feb 2006 09:32:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Nht-0001Pi-6N for nsis@megatron.ietf.org; Wed, 15 Feb 2006 09:32:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13583 for ; Wed, 15 Feb 2006 09:30:49 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Nvj-00049c-Eq for nsis@ietf.org; Wed, 15 Feb 2006 09:46:55 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1FEWCpc012723 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 15 Feb 2006 09:32:22 -0500 (EST) In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869C01@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01869C01@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: Henning Schulzrinne Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) Date: Wed, 15 Feb 2006 09:32:09 -0500 To: X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org John, Let me try to make some suggestions: NSLP Identifier: Seems likely to need experiments and there's a pretty-well defined mechanism for ignoring unknown NSLPs. I would suggest an escape code and a new TLV field. One possibility that avoids registration is to use a UUID, which is 128 bits. See RFC 4122 for the text version. An alternative is to use the enterprise codes and an enterprise-specific 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 enough for an enterprise number. GIST Message Type: Seems less likely to need experiments and experiments seem more dangerous, as it is unclear how well nodes that don't understand message types can deal with them. I would suggest dropping private/ experimental use, given that there is an expert review space that should make getting an identifier reasonably easy. Object Types: Similar to NSLP identifier. Define an extension object that always starts with a UUID or the enterprise code/type. Message Routing Methods: Again, experiments seem likely to be disruptive. What do I do with an unknown MRI? Thus, I'd suggest dropping the experimental range. MA-Protocol-ID same I think a basic issue is as to how well a system can deal with unknown values. In some cases, it can, at best, generate an error and terminate the flow of GIST messages. In others, such as the NSLP identifier, it can ignore the value. Is this a bit less vague? Henning On Feb 15, 2006, at 2:42 AM, wrote: > Hi Henning, > > Its unclear what kind of extensibility you'd like and the usage > model of the extensiblity. If you had a more concrete proposal, > it might be easier to follow. > > I'm basically following the extensibility model proposed in > rfc3692. Also, I think that GIST will be a more 'standard' > transport protocol, where open extesibility is discouraged > (as in TCP, SCTP, DCCP, etc). > > John >>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 15 18:50:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WPc-0002B7-6C; Wed, 15 Feb 2006 18:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WPT-00023d-Uk; Wed, 15 Feb 2006 18:50:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18886; Wed, 15 Feb 2006 18:48:24 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Wda-0007aP-7b; Wed, 15 Feb 2006 19:04:47 -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 k1FNo19W023864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9WPJ-0001Ud-FG; Wed, 15 Feb 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: Wed, 15 Feb 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-06.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-06.txt Pages : 65 Date : 2006-2-15 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-rmd-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rmd-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-15155605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-15155605.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 Feb 16 04:14:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9fCK-0000Un-Rb; Thu, 16 Feb 2006 04:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9fCG-0000TJ-FT for nsis@megatron.ietf.org; Thu, 16 Feb 2006 04:13:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01641 for ; Thu, 16 Feb 2006 04:11:20 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9fQM-0003hp-SD for nsis@ietf.org; Thu, 16 Feb 2006 04:27: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 k1G99Zoh011788; Thu, 16 Feb 2006 09:09:36 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] GIST extensibility concern (IANA considerations) Date: Thu, 16 Feb 2006 09:09:35 -0000 Message-ID: Thread-Topic: [NSIS] GIST extensibility concern (IANA considerations) Thread-Index: AcYyPKywB7NeaKkCTVWntP1TtMeKggAmdBoA From: "Hancock, Robert" To: "Henning Schulzrinne" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org 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=20 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=20 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.=20 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=20 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=20 experiments, especially in the protocol ID and MRM cases, because actually I can think of some very interesting experiments to do there. cheers, r. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > 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 pretty-well=20 > 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=20 > http://www.iana.org/assignments/enterprise-=20 > 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 I=20 > 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 with =20 > unknown values. In some cases, it can, at best, generate an=20 > 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 > > model of the extensiblity. If you had a more concrete proposal, > > it might be easier to follow. > > > > I'm basically following the extensibility model proposed in > > rfc3692. Also, I think that GIST will be a more 'standard' > > transport protocol, where open extesibility is discouraged > > (as in TCP, SCTP, DCCP, etc). > > > > John > >>> >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 16 06:42:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hWt-0002i7-0M; Thu, 16 Feb 2006 06:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hWr-0002i2-0d for nsis@megatron.ietf.org; Thu, 16 Feb 2006 06:42:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13718 for ; Thu, 16 Feb 2006 06:40:46 -0500 (EST) 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 1F9hl4-0000v0-7e for nsis@ietf.org; Thu, 16 Feb 2006 06:57:14 -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 k1GBg8xJ002052; Thu, 16 Feb 2006 20:42:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k1GBg7B02429; Thu, 16 Feb 2006 20:42:07 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id k1GBg6m28920; Thu, 16 Feb 2006 20:42:07 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 16 Feb 2006 19:41:23 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDAC6912@pslexc01.psl.local> Thread-Topic: Suggestions on Multi-homing section of Mobility Draft Thread-Index: AcYy7QoDkbwJQG09Q5SeWl1QNrInTwAAKQ5w From: "Shivanajay Marwaha" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: fu@cs.uni-goettingen.de, jmanner@cs.helsinki.fi, Seong-Ho Jeong , Hannes.Tschofenig@siemens.com Subject: [NSIS] Suggestions on Multi-homing section of Mobility 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other NSIS WG members,=20 =20 We have been studying the NSIS Mobility Applicability draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobili ty-signaling-03.txt and have some suggestions.=20 =20 Here are few of the Comments/suggestion on section 5 in the NSIS mobility applicability draft:- (More to follow in the subsequent emails :) ------------------------------------------------------------ Suggestion 1 - General introduction of multihoming seems to be lacking =20 Discussion - In section 5.2, current text lacks a general introduction to multihoming. The first two sentences talk only about a specific issue concerning multihomed host. Therefore it would be better to include some general description of multihoming environment to give readers a complete picture. In our view, the text from section 5.2.1 of version 02 suits the Purpose better. So, we suggest that the first two sentences of section 5.2 be replaced with the following text (from section 5.2.1 of version 02):- =20 Suggested Text - "Multihoming refers to a situation where an end node has several parallel communication paths to use. An end node (e.g., an MN in mobile environments) may have multiple homogeneous/heterogeneous interfaces. Multiple interfaces can be used in order to increase bandwidth availability or to select the most appropriate interface according to the type of flow or choices of the user [17]. =20 Basically, each network interface has different performance, bandwidth, access range, and reliability. Users may want to select the most appropriate set of network interface(s) depending on the network environment, particularly in wireless networks which are less reliable than wired networks. Users may also want to select the most appropriate interface based on certain criteria or to combine a set of interfaces to get sufficient bandwidth [17]. =20 In multihomed environments, multiple addresses can be allocated to either a single interface or multiple interfaces to provide ubiquitous and fault-tolerant access to the Internet. Other benefits of having multiple interfaces include load balancing, bi-casting, load sharing, and etc." =20 ------------------------------------------------------------------ =20 Suggestion 2 - Section 5.2.1, Para below Figure 14: (homogenous interface vs. multiple interfaces) Current text: - (Section 5.2.1) " We assumed homogeneous wireless interfaces in this draft although multihoming with multiple interfaces would be more efficient on heterogeneous interfaces due to the increased path diversity. The issues on heterogeneous interfaces are for further study. " Discussion - According to the diagram the issue discussed in this section is about using one connection for communication (although multiple connections may be available/possible). This does not even depends on the number of interfaces available on the MN, since in a site multihoming environment, MN can still have multiple address (in turn multiple connections to CN) on one interface. Therefore, the use of "homogeneous" and "heterogeneous" in the above text does not reflect the actual issue. It would be better to clarify the difference.=20 Furthermore, in section 5.2.5, some discussion was provided about the case of using mulitple connections. This should be also reflected in the text. So we suggest to replace the 4th paragraph of section 5.2.1 with following text: Suggested Text - "This section deals with the scenario where only one connection is used for data traffic at a time. In some case multiple connections via heterogeneous interfaces may be necessary and more efficient. Discussion about host multihoming issues is included in section 5.2.5 of this draft" =20 Regards, Shivanajay Marwaha (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 16 06:50:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9heY-0005gA-GA; Thu, 16 Feb 2006 06:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9heW-0005fi-DS for nsis@megatron.ietf.org; Thu, 16 Feb 2006 06:50:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14309 for ; Thu, 16 Feb 2006 06:48:41 -0500 (EST) 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 1F9hsj-00018r-Ln for nsis@ietf.org; Thu, 16 Feb 2006 07:05:10 -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 k1GBo0IV028916; Thu, 16 Feb 2006 20:50:00 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k1GBo3918455; Thu, 16 Feb 2006 20:50:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id k1GBo3119111; Thu, 16 Feb 2006 20:50:03 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 16 Feb 2006 19:49:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDAC6914@pslexc01.psl.local> Thread-Topic: Some More Suggestions on Multi-homing (section 5.2.5) of Mobility Draft Thread-Index: AcYy7v+HT+4uGE3WTlCMLM1J6SWp1Q== From: "Shivanajay Marwaha" To: "Seong-Ho Jeong" , "Sung-Hyuck Lee" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org Subject: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) of Mobility 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other NSIS WG members,=20 =20 Some more comments on Multi-homing section in Mobility draft:- =20 -------------------------------------------------------------------- Comment 1:- Section 5.2.5, Change title to "Host multihoming" =20 Discussion -=20 We think that the above title would be more meaningful if it's changed to Host Multihoming, since Issue discussed here applies to host multihoming in general (where multiple connection between MN and CN are possible, either via different physical interfaces or a single interface). So, the discussion in this section should not be limited to load balancing, which is just a use case of multihoming. In view of this, the title "Host multihoming" would be more suitable. =20 ------------------------------------------------------------------- =20 Comment 2:- Section 5.2.5, reference to external drafts =20 Original Text -=20 "There may be a situation where an MN may need to distribute its traffic load to multiple paths via multiple interfaces. In this case, the MN can send multiple QUERY messages to multiple interfaces to establish NSIS state on multiple paths." =20 Discussion -=20 As load balancing represents only one of the many reasons for doing multihoming, for better understanding, it is better to refer to the draft "Goals and Benefits of Multihoming" (draft-ernst-generic-goals-and-benefits-02). So we suggest to replace the above paragraph of section 5.2.5 with following text:- Suggested Text:- "There may be a situation where an MN may need to distribute its traffic load to multiple paths via multiple interfaces. In this case, the MN can send multiple QUERY messages to multiple interfaces to establish NSIS state on multiple paths. There are many other scenarios and applications in multi-homing as mentioned in [x] ". [x] Goals and Benefits of Multihoming draft-ernst-generic-goals-and-benefits-02=20 =20 -------------------------------------------------------------------- =20 Comment 3:- Section 5.2.5, 2nd para: add description on mobility problem with multihoming =20 Original Text -=20 " Suppose that an MN wants to set up NSIS state on a path which is able to support the specific bandwidth requirement for a certain application in the multihomed environment. It may not be possible to find a feasible path for such a requirement. In this case, multiple paths can be used at the same time so that the bandwidth requirement=20 can be met. Note that the flow identifier on each path may be different although the session identifier is unchanged. " =20 Discussion -=20 With the scenario described above, there would be a problem for NSIS signalling when mobility happens. Please refer to draft "Path type support for NSIS signalling" (draft-sanda-nsis-path-type-03.txt) for details of the problem analysis. So we suggest inserting the following paragraph after the 2nd paragraph of section 5.2.5:- =20 Suggested Text:- "When multiple paths are used for the same session, mobility support may pose a problem for the NSIS signalling. For example, if Path-1 and Path-2 are used for the same session, signalling for these two paths would use different flow identifier, say FID-1 and FID-2, with the same session identifier, say SID. In the case a mobility event causes the Path-1 to be replaced by Path-3 for communication, signalling for the Path-3 will be also using a different flow identifier, say FID-3, and the same session identifier, SID. With this, current NSIS signalling may fail, e.g. CRN discovery, and tearing of the old path. This is due to the lack of information to differentiate Path-1 from Path-2. Detail analysis of the problem can be find in draft [x] [x] "Path type support for NSIS signalling" (draft-sanda-nsis-path-type-03.txt)=20 =20 Regards, Shivanajay=20 (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 16 07:00:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hoc-00027Y-Dd; Thu, 16 Feb 2006 07:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9hoZ-00027L-Gg for nsis@megatron.ietf.org; Thu, 16 Feb 2006 07:00:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15146 for ; Thu, 16 Feb 2006 06:59:04 -0500 (EST) 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 1F9i2k-0001Wu-4E for nsis@ietf.org; Thu, 16 Feb 2006 07:15:33 -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 k1GC0LcO009266; Thu, 16 Feb 2006 21:00:21 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k1GC0O921152; Thu, 16 Feb 2006 21:00:24 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k1GC0Mm08629; Thu, 16 Feb 2006 21:00:22 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 16 Feb 2006 19:59:14 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDAC691A@pslexc01.psl.local> Thread-Topic: Section 3 of Mobility Applicability Draft Thread-Index: AcYy8GfI8XS/aiqxRsiiHMrNuzVHQg== From: "Shivanajay Marwaha" To: "Seong-Ho Jeong" , "Sung-Hyuck Lee" , , , X-Spam-Score: 0.8 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: nsis@ietf.org Subject: [NSIS] Section 3 of Mobility 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: , Content-Type: multipart/mixed; boundary="===============1971701355==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1971701355== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C632F0.681A6806" This is a multi-part message in MIME format. ------_=_NextPart_001_01C632F0.681A6806 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other NSIS WG members,=20 =20 Some comments/suggestions on section 3 in the NSIS mobility applicability draft.=20 =20 Suggestion 1:-=20 =20 Following three sub-topics are not adequately covered in the main body and some elaboration regarding the problem should be provided or it should be in the open-issue list.=20 =20 (i) Sub-section 3.1 (11):- "Key exchange:- When a handover happens, nodes on the new path must be able to verify the signaling messages of the MN, and vice versa. "=20 (ii) Sub-section 3.2.3 (1):- "Update of firewall rules and NAT bindings" (iii) Sub-section 3.2.3 (2) "Re-use of NAT/FW-NSLP's old state"=20 =20 ----------------------------------------------------- =20 Suggestion 2:-=20 =20 Current Text - In Section 3.1 (3) -> " For example, Mobile IP may use the routing headers to define explicit routes, which diverts the traffic from an expected path." =20 Comment/Suggestion - Kindly elaborate how this is done -> MIP does not require special support at the intermediate routers. Any address change or tunnelling, is done at the MIP supported nodes for eg. Home Agent or the MN. So we would like to seek clarfication on how MIP affects explicit routes? =20 ----------------------------------------------------- =20 Suggestion 3:-=20 =20 Section 3.1 (6) Upstream State Update vs. Downstream State Update:-=20 =20 Current Text - " Since the upstream and downstream paths are likely not to be the=20 same, the upstream and downstream CRNs may not coincide, either. Therefore, the State Update needs to be handled independently for =20 the upstream and the downstream, including the discovery of upstream and downstream CRNs." =20 Comment/Suggestion - Does the above "upstream and downstream" flow refer to data or signalling? As such in path coupled signalling, there shouldn't be any difference between upstream and downstream paths. So, if it is directly addressed there may be an issue, if it is hop-hop address, there may not be any issue as they should follow the same path. =20 ------------------------------------------------------- =20 Suggestion 4:-=20 =20 Following 3 sub-topics do not seem to be problems, rather they seem more like requirements:- =20 (i) Sub-section 3.1 (10) "Identification of the crossover node" - seems to be a requirement derived from the previous point (9). (ii) Sub-section 3.2.1. (1) "Interfaces between Mobile IP and NSIS protocols" (iii) Sub-section 3.2.1 (2) "Localized State Update" =20 Regards, Shivanajay Marwaha (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) ------_=_NextPart_001_01C632F0.681A6806 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sung-Hyuck, Seong-Ho, = Mobility=20 Applicabilty Draft Authors and other NSIS WG = members, 
 
Some comments/suggestions=20 on section 3 in the NSIS mobility applicability draft.
 
Suggestion 1:-
 
Following three sub-topics are not adequately = covered in=20 the main body
and some elaboration regarding the problem should be = provided=20 or it
should be in the open-issue list.
 
(i)=20 Sub-section 3.1 (11):- "Key exchange:- When a handover happens,=20 nodes
on the new path must be able to verify the signaling messages = of=20 the
MN, and vice versa.  " 
(ii)=20 Sub-section 3.2.3 (1):- "Update of firewall rules and NAT=20 bindings" 
(iii) = Sub-section=20 3.2.3  (2) "Re-use of NAT/FW-NSLP's old state"
 
-----------------------------------------------------
 
Suggestion 2:-
 
Current Text - =20 In Section 3.1 (3) -> " For example, Mobile IP may use the=20 routing
headers to define explicit routes, which diverts the traffic = from=20 an
expected path."
 
Comment/Suggestion - Kindly elaborate how this is done ->  = MIP does=20 not require special
support at the intermediate routers. Any address = change=20 or
tunnelling, is done at the MIP supported nodes for eg. Home Agent=20 or
the MN. So we would like to seek clarfication on how MIP=20 affects
explicit routes?
 
-----------------------------------------------------
 
Suggestion 3:- 
 
Section 3.1  (6) Upstream State = Update vs.=20 Downstream State
Update:-
 
Current Text -=20  " Since the upstream and downstream paths are likely not to = be the=20
same, the upstream and downstream CRNs may not coincide,=20 either.
Therefore, the State Update needs to be handled independently = for 
the upstream and the downstream, including the discovery = of =20 upstream
and downstream CRNs."
 
Comment/Suggestion -=20 Does the above "upstream and downstream" flow refer to data=20 or
signalling? As such in path coupled signalling, there shouldn't = be
any=20 difference between upstream and downstream paths. So, if it = is
directly=20 addressed there may be an issue, if it is hop-hop address,
there may = not be=20 any issue as they should follow the same path.
 
-------------------------------------------------------
 
Suggestion 4:-
 
Following 3 sub-topics do not seem to = be problems,=20 rather they seem
more like requirements:-
 
(i)=20 Sub-section 3.1 (10) "Identification of the crossover node" - = seems
to=20 be a requirement derived from the previous point (9).
(ii) Sub-section 3.2.1.  (1) = "Interfaces=20 between Mobile IP and NSIS
protocols"
(iii)=20 Sub-section 3.2.1 (2)  "Localized State = Update"
 
Regards,
Shivanajay Marwaha
(On = Behalf of=20 Takako Sanda, Toyoki Ue and Cheng=20 Hong)
------_=_NextPart_001_01C632F0.681A6806-- --===============1971701355== 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 --===============1971701355==-- From nsis-bounces@ietf.org Thu Feb 16 07:06:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9htw-0003Nm-QT; Thu, 16 Feb 2006 07:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9htv-0003Lm-Dn for nsis@megatron.ietf.org; Thu, 16 Feb 2006 07:06:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15629 for ; Thu, 16 Feb 2006 07:04:36 -0500 (EST) 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 1F9i88-0001ir-Ft for nsis@ietf.org; Thu, 16 Feb 2006 07:21:05 -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 k1GC6BcO013732 for ; Thu, 16 Feb 2006 21:06:11 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k1GC6CB08893 for ; Thu, 16 Feb 2006 21:06:12 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k1GC6Ca04989 for ; Thu, 16 Feb 2006 21:06:12 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 16 Feb 2006 20:05:20 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDAC691C@pslexc01.psl.local> Thread-Topic: Section 3 of Mobility Applicability Draft Thread-Index: AcYy8GfI8XS/aiqxRsiiHMrNuzVHQgAAKmLA From: "Shivanajay Marwaha" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Subject: [NSIS] Section 3 of Mobility 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: , Content-Type: multipart/mixed; boundary="===============0722120051==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0722120051== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C632F1.425D1C9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C632F1.425D1C9A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other NSIS WG members,=20 =20 Some comments/suggestions on section 3 in the NSIS mobility applicability draft.=20 =20 Suggestion 1:-=20 =20 Following three sub-topics are not adequately covered in the main body and some elaboration regarding the problem should be provided or it should be in the open-issue list.=20 =20 (i) Sub-section 3.1 (11):- "Key exchange:- When a handover happens, nodes on the new path must be able to verify the signaling messages of the MN, and vice versa. "=20 (ii) Sub-section 3.2.3 (1):- "Update of firewall rules and NAT bindings" (iii) Sub-section 3.2.3 (2) "Re-use of NAT/FW-NSLP's old state"=20 =20 ----------------------------------------------------- =20 Suggestion 2:-=20 =20 Current Text - In Section 3.1 (3) -> " For example, Mobile IP may use the routing headers to define explicit routes, which diverts the traffic from an expected path." =20 Comment/Suggestion - Kindly elaborate how this is done -> MIP does not require special support at the intermediate routers. Any address change or tunnelling, is done at the MIP supported nodes for eg. Home Agent or the MN. So we would like to seek clarfication on how MIP affects explicit routes? =20 ----------------------------------------------------- =20 Suggestion 3:-=20 =20 Section 3.1 (6) Upstream State Update vs. Downstream State Update:-=20 =20 Current Text - " Since the upstream and downstream paths are likely not to be the=20 same, the upstream and downstream CRNs may not coincide, either. Therefore, the State Update needs to be handled independently for =20 the upstream and the downstream, including the discovery of upstream and downstream CRNs." =20 Comment/Suggestion - Does the above "upstream and downstream" flow refer to data or signalling? As such in path coupled signalling, there shouldn't be any difference between upstream and downstream paths. So, if it is directly addressed there may be an issue, if it is hop-hop address, there may not be any issue as they should follow the same path. =20 ------------------------------------------------------- =20 Suggestion 4:-=20 =20 Following 3 sub-topics do not seem to be problems, rather they seem more like requirements:- =20 (i) Sub-section 3.1 (10) "Identification of the crossover node" - seems to be a requirement derived from the previous point (9). (ii) Sub-section 3.2.1. (1) "Interfaces between Mobile IP and NSIS protocols" (iii) Sub-section 3.2.1 (2) "Localized State Update" =20 Regards, Shivanajay=20 (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) ------_=_NextPart_001_01C632F1.425D1C9A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sung-Hyuck, Seong-Ho, = Mobility=20 Applicabilty Draft Authors and other NSIS WG = members, 
 
Some comments/suggestions=20 on section 3 in the NSIS mobility applicability draft.
 
Suggestion 1:- =
 
Following three sub-topics are not adequately = covered in=20 the main body
and some elaboration regarding the problem should be = provided=20 or it
should be in the open-issue list.
 
(i) Sub-section 3.1 (11):- "Key = exchange:- When=20 a handover happens, nodes
on the new path must be able to verify the=20 signaling messages of the
MN, and vice versa.  " 
(ii) Sub-section 3.2.3 (1):- "Update = of firewall=20 rules and NAT bindings" 
(iii)=20 Sub-section 3.2.3  (2) "Re-use of NAT/FW-NSLP's old state"=20
 
-----------------------------------------------------
 
Suggestion 2:- =
 
Current Text -  In Section 3.1 = (3) -> "=20 For example, Mobile IP may use the routing
headers to define explicit = routes,=20 which diverts the traffic from an
expected path."
 
Comment/Suggestion - Kindly elaborate how this is done ->  = MIP does=20 not require special
support at the intermediate routers. Any address = change=20 or
tunnelling, is done at the MIP supported nodes for eg. Home Agent=20 or
the MN. So we would like to seek clarfication on how MIP=20 affects
explicit routes?
 
-----------------------------------------------------
 
Suggestion = 3:- 
 
Section 3.1  (6) = Upstream State=20 Update vs. Downstream State
Update:-
 
Current Text -  " Since the = upstream and=20 downstream paths are likely not to be the
same, the upstream and = downstream=20 CRNs may not coincide, either.
Therefore, the State Update needs to = be=20 handled independently for 
the upstream and the downstream, = including=20 the discovery of  upstream
and downstream=20 CRNs."
 
Comment/Suggestion - Does the above = "upstream=20 and downstream" flow refer to data or
signalling? As such in path = coupled=20 signalling, there shouldn't be
any difference between upstream and = downstream=20 paths. So, if it is
directly addressed there may be an issue, if it = is=20 hop-hop address,
there may not be any issue as they should follow the = same=20 path.
 
-------------------------------------------------------
 
Suggestion 4:- =
 
Following 3 sub-topics = do not seem to=20 be problems, rather they seem
more like requirements:-
 
(i) Sub-section 3.1 (10) = "Identification of the=20 crossover node" - seems
to be a requirement derived from the previous = point=20 (9).
(ii) Sub-section = 3.2.1.  (1)=20 "Interfaces between Mobile IP and NSIS
protocols"
(iii) Sub-section 3.2.1 (2)  = "Localized=20 State Update"
 
Regards,
Shivanajay =
(On Behalf=20 of Takako Sanda, Toyoki Ue and Cheng=20 Hong)
------_=_NextPart_001_01C632F1.425D1C9A-- --===============0722120051== 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 --===============0722120051==-- From nsis-bounces@ietf.org Thu Feb 16 09:35:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9kEd-00031F-KO; Thu, 16 Feb 2006 09:35:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9kEc-0002yQ-1m for nsis@megatron.ietf.org; Thu, 16 Feb 2006 09:35:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28268 for ; Thu, 16 Feb 2006 09:34:06 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9kSp-0007gk-2s for nsis@ietf.org; Thu, 16 Feb 2006 09:50:37 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1GEYfMV026672 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 16 Feb 2006 09:35:33 -0500 (EST) In-Reply-To: References: 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: Henning Schulzrinne Subject: Re: [NSIS] GIST extensibility concern (IANA considerations) Date: Thu, 16 Feb 2006 09:34:32 -0500 To: "Hancock, Robert" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org 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 Sat Feb 18 05:25:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAPHC-0007po-6P; Sat, 18 Feb 2006 05:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAPHA-0007pA-Mq for nsis@megatron.ietf.org; Sat, 18 Feb 2006 05:25:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06048 for ; Sat, 18 Feb 2006 05:23:27 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAPVm-0000Df-KY for nsis@ietf.org; Sat, 18 Feb 2006 05:40:23 -0500 Received: from [192.168.178.22] (p54ACBD69.dip0.t-ipconnect.de [84.172.189.105]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6A26C1BAC4D; Sat, 18 Feb 2006 11:26:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <4F7447C4-78CA-4E08-84C5-A6D521084AD6@netlab.nec.de> To: nsis From: Martin Stiemerling Date: Sat, 18 Feb 2006 11:25:03 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [NSIS] Thoughts on unifying REA and REA-F without proxy X-BeenThere: nsis@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="===============1135965188==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1135965188== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-889830622; protocol="application/pkcs7-signature" --Apple-Mail-5-889830622 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here are some thoughts on unifying REA and the REA-F w/o proxy part (the REA-F part to tell upstream firewalls about the willingness to accept NSLP messages). REA and REA-F do actually share most of their semantics; both run upstream, need to find the edge-device (i.e., edge-NAT or edge- firewall) and tell the edge-device about their willingness to receive NATFW NSLP signaling. Note that REA-F can do a blocking of data traffic as well. REA reserves an IP address and, if applicable, a port number, at the edge-NAT, in addition to letting corresponding NSLP signaling through. The main difference between REA and REA-F is the message routing part: - REA uses LE-MRM, where the signaling destination is not necessary the data sender's IP address. This supports SIP-based communication where a publicly reachable IP address/port is needed right at the beginning without knowing the other side's contact data. In general, the LE-MRM's destination-address is set to an arbitrary address somewhere in the Internet. The message is routed downstream. REA reserves at NAT resource and allows incoming NSLP messages to be forwarded to NI+/NR. - REA-F uses PC-MRM routed upstream and needs a specific sender's IP address in most cases (in the case of one default route from the Internet to the end host, this address can be a wildcard). REA-F faces tough challenges in multihoming environments, in environments with no default route from the Internet to the end-host, or with asymmetric routes (this will be addressed in an applicability statement, issue 52). REA-F allows incoming NSLP messages to be forwarded to NI+/NR or blocks incoming data traffic (for allow-all firewalls) Pros of separated REA and REA-F - clear separation between firewall and NAT functionality (which is not the case for CREATEs and actually nodes should not care about whether to see a NAT or firewall when they start signaling) - clear separation of message routing method Cons of separated REA and REA-F - end host needs to know about its situation, whether it is located behind a firewall and NAT - end host needs to know whether the edge-device is a firewall or NAT, depending on this he must send REA-F or REA. In the case of an edge-firewall, a NI+ must first use REA to edge-NAT, to get the NAT bindings and the forwarding (multiplexing) information for the NSLP. Afterwards, the NI+ must use REA-F to signal to the edge- firewall The separation has more cons than pros -- so lets unify them. The proposal: - Only a RESERVE-EXTERNAL-ADDRESS (REA, because the name is nice and even in the firewall case you are reserving (in a broad scope) an external address. - REA is doing this: - At edge-NATs: Reserving external IP address/port and allowing NSLP messages to be forwarded. - At edge-Firewalls: Either allowing NSLP messages to be forwarded or blocking incoming data traffic (semantics depend on the extended flow information object). - REA for edge-NATs can be transported over LE-MRM or PC-MRM. (LE-MRM if DS is not known, PC-MRM if DS is known) - REA for edge-Firewalls must be transported over upstream PC-MRM. Corner-case: You are in NAT-ed network and the edge-device is not a NAT but an edge-firewall (of course you do not know as NI+ :). Processing rule for the NAT: Forward REA to the edge-firewall. If routing fails, because there two or more boxes and you do not which of them is the right one: Return error. Martin --Apple-Mail-5-889830622 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIxODEwMjUwNFowIwYJKoZIhvcNAQkEMRYEFHGw0DAn42T8rx8/FCnB UueODrcrMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAFt/WkbuSy8Mn4tKVJCv LcKquu5BOAaqt3fuXreVbXVvEVBIf2FRFuzAioxTPp6SUtYyZkFhRE+9pqlHODEVp0waEfsvHR08 oyIr+7GOlqj17fm2m3lAg/pPI8YafPaZ0PUNHXWMXbQfLVkMgj7+w3yrdw6QdRUqJTrT33946WPE aLV9JSvTHg6pgJb7YCg994qtHGeIxWX//rNCxhpbgvw9FYXxYoXtWINogXMJzwbv9b/aSlIDJmc2 z10JLN3nDfccn6lwDh760KvHMosdF+pFXlviiGLxwW634YHz6nOdlJG5fx6cJzdNmxOn6/A0TP1W 0hLlH2mo5M+GJgfqDJsAAAAAAAA= --Apple-Mail-5-889830622-- --===============1135965188== 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 --===============1135965188==-- From nsis-bounces@ietf.org Sat Feb 18 06:36:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAQOK-0005Jv-V7; Sat, 18 Feb 2006 06:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAQOJ-0005Jq-SG for nsis@megatron.ietf.org; Sat, 18 Feb 2006 06:36:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10045 for ; Sat, 18 Feb 2006 06:34:54 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAQcw-0003qt-5V for nsis@ietf.org; Sat, 18 Feb 2006 06:51:51 -0500 Received: from [192.168.178.22] (p54ACBD69.dip0.t-ipconnect.de [84.172.189.105]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 56F541BAC4D for ; Sat, 18 Feb 2006 12:38:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) To: nsis Message-Id: <7E1A7C54-C955-48CF-801B-AE3DD3E29A5A@netlab.nec.de> From: Martin Stiemerling Date: Sat, 18 Feb 2006 12:36:31 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Subject: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms X-BeenThere: nsis@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="===============1178631272==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1178631272== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-894118031; protocol="application/pkcs7-signature" --Apple-Mail-10-894118031 Content-Type: multipart/alternative; boundary=Apple-Mail-9-894117593 --Apple-Mail-9-894117593 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi all, Elwyn has raised an issue at the last IETF meeting about the possibility of notification storms. See also issue 66 in the issue tracker at https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66. The issue has been described with pictures in the slide set shown at the last NSIS session in Vancouver (IETF-64): http://www.stiemerling.org/ietf/ietf64/ietf64_nsis_natfw_nslp_v1.ppt Short summary of this issue: - A given NATFW NSLP forwarder (NF1) has installed NATFW stated for many flows - NF2 is a upstream forwarded of NF1 - NF2 fails in operation and drops out (for whatever reason) +------+ +------+ +------+ | | | | | | | NIs |========| NF1 |--------| NF2 |----> | | | | | | +------+ +------+ +------+ <~~~~~~~~ "Storm" In the case NF2 is shut down/drops out, but is still able to generate NATFW NSLP messages, NF1 will receive, possibly, as many NOTIFY messages as session are installed between NF1 and NF2. This is what Elwyn calls a "notification storm". Things to know about the "relationship" of NF1 and NF2: The NATFW NSLP requires using the C-MODE of the NTLP. The C-MODE offers reliable, congestion controlled, transport of NTLP and NSLP messages between two adjacent peers. Further, NATFW NSLP MAY send NOTIFY messages but the MUST not send them, i.e., NSLP nodes can send them but the do not need to send them. My conclusions about this issue, which has partially been discussed with Robert and Andrew at the last meeting: Yes, there is a risk that a node is generating many NOTIFY messages upon an error condition (either node failure or an upstream link is going down). But there are several, already existing, measures to avoid a storm towards upstream nodes: - Using the C-MODE: The transport protocol (currently TCP) takes care of some sort of rate limiting, since the receiver (here NF1) would not be able to read all NOTIFY messages at once. NF2 would be blocked by the TCP socket in sending new messages, unless NF1 has read more from its sockets (I do not go into TCP details for that). - This could lead to a growing NSLP sending queue at NF2, which in turn gets stuck. In the case, the node fails anyway, this queue will lengthen the shutdown process or the queue will be flushed by the shutdown process. - NF2 does not need to send all NOTIFY messages, due to the fact, that NOTIFY MAY be send. Therefore, in such an error condition, NF can refrain from sending so many NOTIFY messages (see also below for the countermeasure section) Countermeasure: A good way to avoid a NF generating many NOTIFY messages is to not generate these messages ;-) Instead of generating these messages, the NF can solely close the TCP connection (here NF2 is closing the connection) and does not need to send as many NOTIFY messages as sessions. NF1 must interpret the closing of the TCP connection as NOTIFY messages for all the associated sessions. This behaviour has not yet been described in the draft, but if accepted, it would go in an applicability statement on how to treat this case. --Apple-Mail-9-894117593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Elwyn has raised an issue at = the last IETF meeting about the possibility of notification storms. See = also issue 66 in the issue tracker at=A0https:= //kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66.=A0
<= DIV>
The issue has been described = with pictures in the slide set shown at the last NSIS session in = Vancouver (IETF-64):









= --Apple-Mail-9-894117593-- --Apple-Mail-10-894118031 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIxODExMzYzMVowIwYJKoZIhvcNAQkEMRYEFNXhbSg3PdArIX9t9nE8 LZUHFngFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAFUqk6EHtZP3jKfWtPY8 sM169YyI6N+Qmb5rS+6gKPsSCKRSohX/uvD9Y3hLQ7llO/deAGZKP8rNozdTPxinGNaNXrerX5Ts sakJePbzhUHLy76TyrYzDchgE4OhrQBJX0OVQJnbhb2KlEVHizGkYthk33z6mVdzX95013c03V25 FvJA0bt9JQlvzjkauIpootDZmk75K9S9W3IbLrLh1snhbPF4am9LAQEsvFsATFI2/4kYT/fNM6Tj P6PssACcllEmFdL3JVSJvNCCdHdmX5IrvCjAmTEXPvM6vvMLQFdmwehCiR9sgo10yAphpXbrgvUu l2cJVjCz3nqauYcNm+AAAAAAAAA= --Apple-Mail-10-894118031-- --===============1178631272== 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 --===============1178631272==-- From nsis-bounces@ietf.org Sun Feb 19 17:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAwkh-0001iZ-As; Sun, 19 Feb 2006 17:09:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAwkg-0001iN-6u for nsis@ietf.org; Sun, 19 Feb 2006 17:09:58 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAwkc-0006wI-8X for nsis@ietf.org; Sun, 19 Feb 2006 17:09:58 -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 k1JM9Soj023185; Sun, 19 Feb 2006 22:09:29 GMT Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DF4421BC; Sun, 19 Feb 2006 22:16:30 -0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Date: Sun, 19 Feb 2006 22:09:25 -0000 Message-ID: <000501c635a1$26002bb0$6500000a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Thread-Index: AcY1oiKjKO2sd/n+RGaungx4KQEG/w== From: "Hancock, Robert" To: "Martin Stiemerling" , "nsis" X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1420905805==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1420905805== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C635A2.221DF300" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C635A2.221DF300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, a couple of comments from the GIST perspective: *) [maybe not directly relevant here but worth mentioning]:=20 rate control applies to all GIST messages, not just the C-mode ones. It's just that the D-mode rate control is more primitive (it's non-adaptive, for example). Part of the rationale for the=20 existence of GIST to ensure that no signalling application can cause this sort of problem for other users of the network, no matter how it is designed. *) [different from what I said in Vancouver, but hey ...]: it's true that dropping out the C-mode connection could be taken as a signal that a node was shutting down (which would avoid the storm altogether). There's nothing to stop cooperating implementations adopting this convention; however, I think it would probably need some non-obvious changes to the GIST API to achieve it (because essentially you want the signalling application to start manipulating GIST MAs). Fundamentally what one wants is for the NATFW NSLP to be able to send a message to a specific *peer* (rather than about a specific *flow*). In theory, that's tricky because GIST messages are usually routed on MRI a.k.a. flow-id. However, it is possible for an NSLP to bypass GIST routing and just say 'send the message to that person'; this capability was introduced to allow state teardown on an old path, but is equally applicable here. The NATFW NSLP can define a shutdown message, which would be sent with a zero SID and an MRI describing the flows which are affected (typically but not necessarily all of them). See sections 5.2.1 and 7.1.4 for more discussion. The difference between this functionality and NSLPs randomly choosing which peers they want to talk to is that GIST only allows this to be done in relation to state which has previously been created; the NSLP gets told an opaque ID for the peer which accepts the state, and can explicitly route a message back to that peer. AFAICT GIST already has precisely the right functionality here, packaged in precisely the right way (which is quite reassuring). r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Martin Stiemerling > Sent: 18 February 2006 11:37 > To: nsis > Subject: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms >=20 >=20 > Hi all, >=20 >=20 > Elwyn has raised an issue at the last IETF meeting about the=20 > possibility of notification storms. See also issue 66 in the=20 > issue tracker at=20 > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66.=20 >=20 >=20 > The issue has been described with pictures in the slide set=20 > shown at the last NSIS session in Vancouver (IETF-64): > http://www.stiemerling.org/ietf/ietf64/ietf64_nsis_natfw_nslp_v1.ppt >=20 >=20 > Short summary of this issue: > - A given NATFW NSLP forwarder (NF1) has installed NATFW=20 > stated for many flows > - NF2 is a upstream forwarded of NF1 > - NF2 fails in operation and drops out (for whatever reason) >=20 >=20 > +------+ +------+ +------+ > | | | | | | > | NIs |=3D=3D=3D=3D=3D=3D=3D| NF1 |--------| NF2 |----> > | | | | | | > +------+ +------+ +------+ >=20 >=20 > <~~~~~~~~ "Storm" >=20 >=20 > In the case NF2 is shut down/drops out, but is still able to=20 > generate NATFW NSLP messages, NF1 will receive, possibly, as=20 > many NOTIFY messages as session are installed between NF1 and=20 > NF2. This is what Elwyn calls a "notification storm". >=20 >=20 > Things to know about the "relationship" of NF1 and NF2: The=20 > NATFW NSLP requires using the C-MODE of the NTLP. The C-MODE=20 > offers reliable, congestion controlled, transport of NTLP and=20 > NSLP messages between two adjacent peers. Further, NATFW NSLP=20 > MAY send NOTIFY messages but the MUST not send them, i.e.,=20 > NSLP nodes can send them but the do not need to send them. >=20 >=20 > My conclusions about this issue, which has partially been=20 > discussed with Robert and Andrew at the last meeting: > Yes, there is a risk that a node is generating many NOTIFY=20 > messages upon an error condition=20 > (either node failure or an upstream link is going down). But=20 > there are several, already existing, measures to avoid a=20 > storm towards upstream nodes: > - Using the C-MODE: The transport protocol (currently TCP)=20 > takes care of some sort of rate limiting, since the receiver=20 > (here NF1) would not be able to read all NOTIFY messages at=20 > once. NF2 would be blocked by the TCP socket in sending new=20 > messages, unless NF1 has read more from its sockets (I do not=20 > go into TCP details for that). > - This could lead to a growing NSLP sending queue at NF2,=20 > which in turn gets stuck. In the case, the node fails anyway,=20 > this queue will lengthen the shutdown process or the queue=20 > will be flushed by the shutdown process.=20 > - NF2 does not need to send all NOTIFY messages, due to the=20 > fact, that NOTIFY MAY be send. Therefore, in such an error=20 > condition, NF can refrain from sending so many NOTIFY=20 > messages (see also below for the countermeasure section) >=20 >=20 >=20 >=20 > Countermeasure: > A good way to avoid a NF generating many NOTIFY messages is=20 > to not generate these messages ;-) Instead of generating=20 > these messages, the NF can solely close the TCP connection=20 > (here NF2 is closing the connection) and does not need to=20 > send as many NOTIFY messages as sessions. NF1 must interpret=20 > the closing of the TCP connection as NOTIFY messages for all=20 > the associated sessions.=20 >=20 >=20 > This behaviour has not yet been described in the draft, but=20 > if accepted, it would go in an applicability statement on how=20 > to treat this case. >=20 ------_=_NextPart_001_01C635A2.221DF300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY = storms

hi all,

a couple of comments from the GIST perspective:

*) [maybe not directly relevant here but worth = mentioning]:
rate control applies to all GIST messages, not just = the C-mode ones.
It's just that the D-mode rate control is more = primitive (it's
non-adaptive, for example). Part of the rationale for = the
existence of GIST to ensure that no signalling = application
can cause this sort of problem for other users of the = network,
no matter how it is designed.

*) [different from what I said in Vancouver, but hey = ...]:
it's true that dropping out the C-mode connection = could be
taken as a signal that a node was shutting down = (which would
avoid the storm altogether). There's nothing to stop = cooperating
implementations adopting this convention; however, I = think it
would probably need some non-obvious changes to the = GIST API
to achieve it (because essentially you want the = signalling
application to start manipulating GIST MAs).

Fundamentally what one wants is for the NATFW NSLP to = be able
to send a message to a specific *peer* (rather than = about a
specific *flow*). In theory, that's tricky because = GIST messages
are usually routed on MRI a.k.a. flow-id. However, it = is possible
for an NSLP to bypass GIST routing and just say 'send = the message
to that person'; this capability was introduced to = allow state
teardown on an old path, but is equally applicable = here. The
NATFW NSLP can define a shutdown message, which would = be sent
with a zero SID and an MRI describing the flows which = are affected
(typically but not necessarily all of them). See = sections 5.2.1
and 7.1.4 for more discussion.

The difference between this functionality and NSLPs = randomly choosing
which peers they want to talk to is that GIST only = allows this to
be done in relation to state which has previously = been created;
the NSLP gets told an opaque ID for the peer which = accepts the
state, and can explicitly route a message back to = that peer.
AFAICT GIST already has precisely the right = functionality here,
packaged in precisely the right way (which is quite = reassuring).

r.

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Martin Stiemerling
> Sent: 18 February 2006 11:37
> To: nsis
> Subject: [NSIS] NATFW NSLP Issue 66: Possibility = of NOTIFY storms
>
>
> Hi all,
>
>
> Elwyn has raised an issue at the last IETF = meeting about the
> possibility of notification storms. See also = issue 66 in the
> issue tracker at
> https= ://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66.
>
>
> The issue has been described with pictures in = the slide set
> shown at the last NSIS session in Vancouver = (IETF-64):
> http://www.stiemerling.org/ietf/ietf64/ietf64_nsis_natfw_nslp_v1.ppt=
>
>
> Short summary of this issue:
> - A given NATFW NSLP forwarder (NF1) has = installed NATFW
> stated for many flows
> - NF2 is a upstream forwarded of NF1
> - NF2 fails in operation and drops out (for = whatever reason)
>
>
> +------+       = +------+        +------+
> |      = |       |      = |        = |      |
> | NIs  |=3D=3D=3D=3D=3D=3D=3D| NF1  = |--------| NF2  |---->
> |      = |       |      = |        = |      |
> +------+       = +------+        +------+
>
>
>          =              = <~~~~~~~~ "Storm"
>
>
> In the case NF2 is shut down/drops out, but is = still able to
> generate NATFW NSLP messages, NF1 will receive, = possibly, as
> many NOTIFY messages as session are installed = between NF1 and
> NF2. This is what Elwyn calls a = "notification storm".
>
>
> Things to know about the = "relationship" of NF1 and NF2: The
> NATFW NSLP requires using the C-MODE of the = NTLP. The C-MODE
> offers reliable, congestion controlled, = transport of NTLP and
> NSLP messages between two adjacent peers. = Further, NATFW NSLP
> MAY send NOTIFY messages but the MUST not send = them, i.e.,
> NSLP nodes can send them but the do not need to = send them.
>
>
> My conclusions about this issue, which has = partially been
> discussed with Robert and Andrew at the last = meeting:
> Yes, there is a risk that a node is generating = many NOTIFY
> messages upon an error condition
> (either node failure or an upstream link is = going down). But
> there are several, already existing, measures to = avoid a
> storm towards upstream nodes:
> - Using the C-MODE: The transport protocol = (currently TCP)
> takes care of some sort of rate limiting, since = the receiver
> (here NF1) would not be able to read all NOTIFY = messages at
> once. NF2 would be blocked by the TCP socket in = sending new
> messages, unless NF1 has read more from its = sockets (I do not
> go into TCP details for that).
> - This could lead to a growing NSLP sending = queue at NF2,
> which in turn gets stuck. In the case, the node = fails anyway,
> this queue will lengthen the shutdown process or = the queue
> will be flushed by the shutdown process.
> - NF2 does not need to send all NOTIFY messages, = due to the
> fact, that NOTIFY MAY be send. Therefore, in = such an error
> condition, NF can refrain from sending so many = NOTIFY
> messages (see also below for the countermeasure = section)
>
>
>
>
> Countermeasure:
> A good way to avoid a NF generating many NOTIFY = messages is
> to not generate these messages ;-) Instead of = generating
> these messages, the NF can solely close the TCP = connection
> (here NF2 is closing the connection) and does = not need to
> send as many NOTIFY messages as sessions. NF1 = must interpret
> the closing of the TCP connection as NOTIFY = messages for all
> the associated sessions.
>
>
> This behaviour has not yet been described in the = draft, but
> if accepted, it would go in an applicability = statement on how
> to treat this case.
>

------_=_NextPart_001_01C635A2.221DF300-- --===============1420905805== 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 --===============1420905805==-- From nsis-bounces@ietf.org Mon Feb 20 05:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB8Xk-0000Oe-A9; Mon, 20 Feb 2006 05:45:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB8Xj-0000OW-QB for nsis@ietf.org; Mon, 20 Feb 2006 05:45:23 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB8Xj-0002MM-3x for nsis@ietf.org; Mon, 20 Feb 2006 05:45:23 -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 <0IUZ00JSFF7MSI@mailout2.samsung.com> for nsis@ietf.org; Mon, 20 Feb 2006 19:45:22 +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 <0IUZ00HK0F7M9S@mmp2.samsung.com> for nsis@ietf.org; Mon, 20 Feb 2006 19:45:22 +0900 (KST) Date: Mon, 20 Feb 2006 19:45:21 +0900 From: Sung-Hyuck Lee To: Shivanajay Marwaha , nsis@ietf.org Message-id: <01c401c6360a$bfa93c70$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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Toyoki Ue , Pek Yew Tan Subject: [NSIS] Re: Suggestions on Multi-homing section of Mobility 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 Dear Shivanajay, Thank you for your interests. Please refer to my comments in line. Warm regards, Sung-Hyuck ----- Original Message ----- From: "Shivanajay Marwaha" > Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other > NSIS WG members, > > We have been studying the NSIS Mobility Applicability draft > http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobili > ty-signaling-03.txt and have some suggestions. > > Here are few of the Comments/suggestion on section 5 in the NSIS > mobility applicability draft:- > (More to follow in the subsequent emails :) > > ------------------------------------------------------------ > Suggestion 1 - > General introduction of multihoming seems to be lacking > > Discussion - > In section 5.2, current text lacks a general introduction to > multihoming. The first two sentences talk only about a specific issue > concerning multihomed host. Therefore it would be better to include > some general description of multihoming environment to give readers a > complete picture. In our view, the text from section 5.2.1 of version 02 > suits the > Purpose better. So, we suggest that the first two sentences of section > 5.2 be > replaced with the following text (from section 5.2.1 of version 02):- > > Suggested Text - > "Multihoming refers to a situation where an end node has several > parallel communication paths to use. An end node (e.g., an MN in > mobile environments) may have multiple homogeneous/heterogeneous > interfaces. Multiple interfaces can be used in order to increase > bandwidth availability or to select the most appropriate interface > according to the type of flow or choices of the user [17]. > > Basically, each network interface has different performance, > bandwidth, access range, and reliability. Users may want to select > the most appropriate set of network interface(s) depending on the > network environment, particularly in wireless networks which are less > reliable than wired networks. Users may also want to select the most > appropriate interface based on certain criteria or to combine a set > of interfaces to get sufficient bandwidth [17]. > > In multihomed environments, multiple addresses can be allocated to > either a single interface or multiple interfaces to provide > ubiquitous and fault-tolerant access to the Internet. Other benefits > of having multiple interfaces include load balancing, bi-casting, > load sharing, and etc." [SHL] It is not easy to evaluate which introduction is better because we need to consider various views on editing of drafts: The way of editing can be different dependent on what preference is, simpler or more detailed expression. Till now, the mobility authors have tried to make the mobility draft simpler with clearer text. However, the authors will refer to your valuable comments. > ------------------------------------------------------------------ > > Suggestion 2 - > Section 5.2.1, Para below Figure 14: (homogenous interface vs. multiple > interfaces) > > Current text: - (Section 5.2.1) > " We assumed homogeneous wireless interfaces in this draft although > multihoming with multiple interfaces would be more efficient on > heterogeneous interfaces due to the increased path diversity. The > issues on heterogeneous interfaces are for further study. " > > Discussion - > According to the diagram the issue discussed in this section is about > using one connection for communication (although multiple connections > may be available/possible). This does not even depends on the number > of interfaces available on the MN, since in a site multihoming > environment, MN can still have multiple address (in turn multiple > connections to CN) on one interface. Therefore, the use of > "homogeneous" and "heterogeneous" in the above text does not reflect > the actual issue. It would be better to clarify the difference. > Furthermore, in section 5.2.5, some discussion was provided about the > case of using mulitple connections. This should be also reflected in > the text. So we suggest to replace the 4th paragraph of section 5.2.1 > with > following text: [SHL] You seem to misunderstand the terms, "homogeneous" and "heterogeneous". Homogeneous interfaces mean that the interfaces consist just same physical air interface, for example, only IEEE 802.11. Heterogeneous interfaces mean that the interfaces simultaneously consist different physical air interfaces, for example, WIFI and 3G, WIFI and WIMAX/WiBro, etc. > Suggested Text - > "This section deals with the scenario where only one connection is > used for data traffic at a time. In some case multiple connections > via heterogeneous interfaces may be necessary and more efficient. > Discussion about host multihoming issues is included in section 5.2.5 > of this draft" > > Regards, > Shivanajay Marwaha > (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 20 05:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB8jv-0001IF-W8; Mon, 20 Feb 2006 05:57:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB8ju-0001IA-NM for nsis@ietf.org; Mon, 20 Feb 2006 05:57:58 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB8jt-0002Xk-1j for nsis@ietf.org; Mon, 20 Feb 2006 05:57:58 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 208F21BAC4D; Mon, 20 Feb 2006 11:59:31 +0100 (CET) In-Reply-To: <000501c635a1$26002bb0$6500000a@comm.ad.roke.co.uk> References: <000501c635a1$26002bb0$6500000a@comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <749A141B-F09F-4B63-880E-666A7CF1EC67@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Date: Mon, 20 Feb 2006 11:57:53 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 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: , Content-Type: multipart/mixed; boundary="===============1243349934==" Errors-To: nsis-bounces@ietf.org --===============1243349934== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16-1064600466; protocol="application/pkcs7-signature" --Apple-Mail-16-1064600466 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi Robert, all, Am 19.02.2006 um 23:09 schrieb Hancock, Robert: > hi all, > > a couple of comments from the GIST perspective: > > *) [maybe not directly relevant here but worth mentioning]: > rate control applies to all GIST messages, not just the C-mode ones. > It's just that the D-mode rate control is more primitive (it's > non-adaptive, for example). Part of the rationale for the > existence of GIST to ensure that no signalling application > can cause this sort of problem for other users of the network, > no matter how it is designed. Good job! :-) That is good to remember, since there will be no harm whatever mode is finally used. > > *) [different from what I said in Vancouver, but hey ...]: > it's true that dropping out the C-mode connection could be > taken as a signal that a node was shutting down (which would > avoid the storm altogether). There's nothing to stop cooperating > implementations adopting this convention; however, I think it > would probably need some non-obvious changes to the GIST API > to achieve it (because essentially you want the signalling > application to start manipulating GIST MAs). Good point raised. Especially, tearing down an MA could hurt other NSLPs which probably have no problem, since they could share the same MA. > > Fundamentally what one wants is for the NATFW NSLP to be able > to send a message to a specific *peer* (rather than about a > specific *flow*). In theory, that's tricky because GIST messages > are usually routed on MRI a.k.a. flow-id. However, it is possible > for an NSLP to bypass GIST routing and just say 'send the message > to that person'; this capability was introduced to allow state > teardown on an old path, but is equally applicable here. The > NATFW NSLP can define a shutdown message, which would be sent > with a zero SID and an MRI describing the flows which are affected > (typically but not necessarily all of them). See sections 5.2.1 > and 7.1.4 for more discussion. > > The difference between this functionality and NSLPs randomly choosing > which peers they want to talk to is that GIST only allows this to > be done in relation to state which has previously been created; > the NSLP gets told an opaque ID for the peer which accepts the > state, and can explicitly route a message back to that peer. > AFAICT GIST already has precisely the right functionality here, > packaged in precisely the right way (which is quite reassuring). I have to check sections 5.2.1 and 7.1.4 and will come back. Right now, this looks like an excellent way to do the complete teardown. To the QoS people: Does this notification storm apply to the QoS NSLP as well? Thanks, Martin > > r. > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of Martin Stiemerling >> Sent: 18 February 2006 11:37 >> To: nsis >> Subject: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms >> >> >> Hi all, >> >> >> Elwyn has raised an issue at the last IETF meeting about the >> possibility of notification storms. See also issue 66 in the >> issue tracker at >> https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66. >> >> >> The issue has been described with pictures in the slide set >> shown at the last NSIS session in Vancouver (IETF-64): >> http://www.stiemerling.org/ietf/ietf64/ietf64_nsis_natfw_nslp_v1.ppt >> >> >> Short summary of this issue: >> - A given NATFW NSLP forwarder (NF1) has installed NATFW >> stated for many flows >> - NF2 is a upstream forwarded of NF1 >> - NF2 fails in operation and drops out (for whatever reason) >> >> >> +------+ +------+ +------+ >> | | | | | | >> | NIs |=======| NF1 |--------| NF2 |----> >> | | | | | | >> +------+ +------+ +------+ >> >> >> <~~~~~~~~ "Storm" >> >> >> In the case NF2 is shut down/drops out, but is still able to >> generate NATFW NSLP messages, NF1 will receive, possibly, as >> many NOTIFY messages as session are installed between NF1 and >> NF2. This is what Elwyn calls a "notification storm". >> >> >> Things to know about the "relationship" of NF1 and NF2: The >> NATFW NSLP requires using the C-MODE of the NTLP. The C-MODE >> offers reliable, congestion controlled, transport of NTLP and >> NSLP messages between two adjacent peers. Further, NATFW NSLP >> MAY send NOTIFY messages but the MUST not send them, i.e., >> NSLP nodes can send them but the do not need to send them. >> >> >> My conclusions about this issue, which has partially been >> discussed with Robert and Andrew at the last meeting: >> Yes, there is a risk that a node is generating many NOTIFY >> messages upon an error condition >> (either node failure or an upstream link is going down). But >> there are several, already existing, measures to avoid a >> storm towards upstream nodes: >> - Using the C-MODE: The transport protocol (currently TCP) >> takes care of some sort of rate limiting, since the receiver >> (here NF1) would not be able to read all NOTIFY messages at >> once. NF2 would be blocked by the TCP socket in sending new >> messages, unless NF1 has read more from its sockets (I do not >> go into TCP details for that). >> - This could lead to a growing NSLP sending queue at NF2, >> which in turn gets stuck. In the case, the node fails anyway, >> this queue will lengthen the shutdown process or the queue >> will be flushed by the shutdown process. >> - NF2 does not need to send all NOTIFY messages, due to the >> fact, that NOTIFY MAY be send. Therefore, in such an error >> condition, NF can refrain from sending so many NOTIFY >> messages (see also below for the countermeasure section) >> >> >> >> >> Countermeasure: >> A good way to avoid a NF generating many NOTIFY messages is >> to not generate these messages ;-) Instead of generating >> these messages, the NF can solely close the TCP connection >> (here NF2 is closing the connection) and does not need to >> send as many NOTIFY messages as sessions. NF1 must interpret >> the closing of the TCP connection as NOTIFY messages for all >> the associated sessions. >> >> >> This behaviour has not yet been described in the draft, but >> if accepted, it would go in an applicability statement on how >> to treat this case. >> --Apple-Mail-16-1064600466 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIyMDEwNTc1NFowIwYJKoZIhvcNAQkEMRYEFPlCpbYVPign1u1nztKi VAmLMmMZMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAGAvrahClo0xScE0iMZR Z4Vny1Fy9h11fSokUeaWFxbl3/wLaQiUixLfK5AnPYgDUk6F/Ir0mdE8D+H5PwoY2Z/KCVjyFaF8 9BEN77JT5rvykmrsmyc77o6yUkgrJhyRRH1KOSXFO77p5mjYiyoCibNyqXI8BtGFGbiqNENA+53a qFknhNjmSwTLDqNWSG3YEPUBPGN81rCfYDjwb5Okt+34EF0RBxvI1jJiC9Sk90sIoCm1fh4V1Op4 1ddN6/Xu5bBd4ZmDTCZ14kqY0Kfh4lIHKavhck2gHNLZObGIAOUClOncZsogbwgAHoBJNAiHHdM9 Zlut3l3yOJ+6yfWBr+UAAAAAAAA= --Apple-Mail-16-1064600466-- --===============1243349934== 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 --===============1243349934==-- From nsis-bounces@ietf.org Mon Feb 20 06:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB9Vn-0003SH-Gc; Mon, 20 Feb 2006 06:47:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB9Vm-0003S9-JA for nsis@ietf.org; Mon, 20 Feb 2006 06:47:26 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB9Vl-00042l-QX for nsis@ietf.org; Mon, 20 Feb 2006 06:47:26 -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 <0IUZ00F6ZI2ZH0@mailout1.samsung.com> for nsis@ietf.org; Mon, 20 Feb 2006 20:47:23 +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 <0IUZ00D5DI2ZIB@mmp1.samsung.com> for nsis@ietf.org; Mon, 20 Feb 2006 20:47:23 +0900 (KST) Date: Mon, 20 Feb 2006 20:47:22 +0900 From: Sung-Hyuck Lee To: Cheng Hong , Shivanajay Marwaha , nsis@ietf.org Message-id: <021e01c63613$69a24ac0$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: <5F09D220B62F79418461A978CA0921BDB234DC@pslexc01.psl.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: Toyoki Ue , Pek Yew Tan Subject: [NSIS] Re: Suggestions on Multi-homing section of Mobility 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 Cheng, ----- Original Message ----- From: "Cheng Hong" To: "Sung-Hyuck Lee" ; "Shivanajay Marwaha" ; Cc: "Takako Sanda" ; "Toyoki Ue" ; "Pek Yew Tan" ; "Seong-Ho Jeong" ; "Xiaoming Fu" ; "Hannes Tschofenig" ; "Jukka MJ Manner" Sent: Monday, February 20, 2006 7:57 PM Subject: RE: Suggestions on Multi-homing section of Mobility Draft > Hi Sung-Hyuck, > > Thanks a lot for your reply. Since Shivanajay is on leave today, I would > like to repond one of the comment for him: > > > [SHL] You seem to misunderstand the terms, "homogeneous" and > > "heterogeneous". Homogeneous interfaces mean that the interfaces > > consist just same physical air interface, for example, only > > IEEE 802.11. > > Heterogeneous interfaces mean that the interfaces > > simultaneously consist > > different physical air interfaces, for example, WIFI and 3G, WIFI and > > WIMAX/WiBro, etc. > > That is exactly the point Shiv wants to make. Having "homogeneous" > interface does not necessary mean that only one connection is being used > at one time (which is what section 5.2.1 is discussing about: selecting > the best connection for communication). [SHL] Selecting the best connection is just one example which shows the use case for multihoming in NSIS scenarios. > It is possible for the terminal to have multiple "homogeneous" > interface, e.g. my laptop can have two wireless LAN connections (one > through integrated card -- thanks to Centreno :), one through external > card). > > Also, it is possible for a terminal with a single "homogeneous" > interface to have multiple addresses in a site multihoming environment, > e.g. several prefixs are offered. [SHL] Yes. > Therefore, we think that it would be better to avoid use of the > "homogeneous" to describe the problem discussed in section 5.2.1. [SHL] The use of terms, "homogeneous" and "heterogeneous" is needed to identify the differences between multihoming scenarios in homogeneous and heterogeneous environments. That is why the terms were used in the mobility draft. Warm regards, Sung-Hyuck > -----Original Message----- > From: Sung-Hyuck Lee [mailto:starsu.lee@samsung.com] > Sent: Monday, February 20, 2006 6:43 PM > To: Shivanajay Marwaha; nsis@ietf.org > Cc: Takako Sanda; Toyoki Ue; Cheng Hong; Pek Yew Tan; > Seong-Ho Jeong; 'Xiaoming Fu'; 'Hannes Tschofenig'; 'Jukka MJ Manner' > Subject: Re: Suggestions on Multi-homing section of Mobility Draft > > Dear Shivanajay, > > Thank you for your interests. > Please refer to my comments in line. > > > Warm regards, > > Sung-Hyuck > > ----- Original Message ----- > From: "Shivanajay Marwaha" > > > > Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft > Authors and other > > NSIS WG members, > > > > We have been studying the NSIS Mobility Applicability draft > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicabil > ity-mobili > > ty-signaling-03.txt and have some suggestions. > > > > Here are few of the Comments/suggestion on section 5 in the NSIS > > mobility applicability draft:- > > (More to follow in the subsequent emails :) > > > > ------------------------------------------------------------ > > Suggestion 1 - > > General introduction of multihoming seems to be lacking > > > > Discussion - > > In section 5.2, current text lacks a general introduction to > > multihoming. The first two sentences talk only about a > specific issue > > concerning multihomed host. Therefore it would be better to include > > some general description of multihoming environment to give > readers a > > complete picture. In our view, the text from section 5.2.1 > of version 02 > > suits the > > Purpose better. So, we suggest that the first two sentences > of section > > 5.2 be > > replaced with the following text (from section 5.2.1 of > version 02):- > > > > Suggested Text - > > "Multihoming refers to a situation where an end node has several > > parallel communication paths to use. An end node (e.g., an MN in > > mobile environments) may have multiple homogeneous/heterogeneous > > interfaces. Multiple interfaces can be used in order to increase > > bandwidth availability or to select the most appropriate interface > > according to the type of flow or choices of the user [17]. > > > > Basically, each network interface has different performance, > > bandwidth, access range, and reliability. Users may want to select > > the most appropriate set of network interface(s) depending on the > > network environment, particularly in wireless networks > which are less > > reliable than wired networks. Users may also want to > select the most > > appropriate interface based on certain criteria or to combine a set > > of interfaces to get sufficient bandwidth [17]. > > > > In multihomed environments, multiple addresses can be allocated to > > either a single interface or multiple interfaces to provide > > ubiquitous and fault-tolerant access to the Internet. > Other benefits > > of having multiple interfaces include load balancing, bi-casting, > > load sharing, and etc." > > [SHL] It is not easy to evaluate which introduction is better because > we need to consider various views on editing of drafts: The way of > editing can be different dependent on what preference is, simpler or > more detailed expression. Till now, the mobility authors have > tried to > make the mobility draft simpler with clearer text. However, > the authors > will refer to your valuable comments. > > > ------------------------------------------------------------------ > > > > Suggestion 2 - > > Section 5.2.1, Para below Figure 14: (homogenous interface > vs. multiple > > interfaces) > > > > Current text: - (Section 5.2.1) > > " We assumed homogeneous wireless interfaces in this draft although > > multihoming with multiple interfaces would be more efficient on > > heterogeneous interfaces due to the increased path diversity. The > > issues on heterogeneous interfaces are for further study. " > > > > Discussion - > > According to the diagram the issue discussed in this > section is about > > using one connection for communication (although multiple > connections > > may be available/possible). This does not even depends on the number > > of interfaces available on the MN, since in a site multihoming > > environment, MN can still have multiple address (in turn multiple > > connections to CN) on one interface. Therefore, the use of > > "homogeneous" and "heterogeneous" in the above text does not reflect > > the actual issue. It would be better to clarify the difference. > > Furthermore, in section 5.2.5, some discussion was provided > about the > > case of using mulitple connections. This should be also reflected in > > the text. So we suggest to replace the 4th paragraph of > section 5.2.1 > > with > > following text: > > [SHL] You seem to misunderstand the terms, "homogeneous" and > "heterogeneous". Homogeneous interfaces mean that the interfaces > consist just same physical air interface, for example, only > IEEE 802.11. > Heterogeneous interfaces mean that the interfaces > simultaneously consist > different physical air interfaces, for example, WIFI and 3G, WIFI and > WIMAX/WiBro, etc. > > > Suggested Text - > > "This section deals with the scenario where only one connection is > > used for data traffic at a time. In some case multiple connections > > via heterogeneous interfaces may be necessary and more efficient. > > Discussion about host multihoming issues is included in > section 5.2.5 > > of this draft" > > > > Regards, > > Shivanajay Marwaha > > (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 20 08:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAiP-0007Z9-3h; Mon, 20 Feb 2006 08:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAiO-0007Yw-Gu for nsis@ietf.org; Mon, 20 Feb 2006 08:04:32 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBAiN-0006Dc-Ub for nsis@ietf.org; Mon, 20 Feb 2006 08:04:32 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B43E51BAC4D for ; Mon, 20 Feb 2006 14:06:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4F7447C4-78CA-4E08-84C5-A6D521084AD6@netlab.nec.de> References: <4F7447C4-78CA-4E08-84C5-A6D521084AD6@netlab.nec.de> Message-Id: <1D362D2C-1458-4353-A504-E9D1C2420751@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] Thoughts on unifying REA and REA-F without proxy Date: Mon, 20 Feb 2006 14:04:27 +0100 To: nsis X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-BeenThere: nsis@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="===============1780749800==" Errors-To: nsis-bounces@ietf.org --===============1780749800== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-23-1072194174; protocol="application/pkcs7-signature" --Apple-Mail-23-1072194174 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, I will assume lazy consensus on this item, if there is no response until Tuesday, Feb 21th, 2pm CET. Martin Am 18.02.2006 um 11:25 schrieb Martin Stiemerling: > Dear all, > > Here are some thoughts on unifying REA and the REA-F w/o proxy part > (the REA-F part to tell upstream firewalls about the willingness to > accept NSLP messages). > > REA and REA-F do actually share most of their semantics; both > run upstream, need to find the edge-device (i.e., edge-NAT or edge- > firewall) > and tell the edge-device about their willingness to receive NATFW NSLP > signaling. Note that REA-F can do a blocking of data traffic as well. > REA reserves an IP address and, if applicable, a port number, at the > edge-NAT, in addition to letting corresponding NSLP signaling through. > > The main difference between REA and REA-F is the message routing > part: > - REA uses LE-MRM, where the signaling destination is not necessary > the data sender's IP address. This supports SIP-based communication > where a publicly reachable IP address/port is needed right at the > beginning without knowing the other side's contact data. In general, > the LE-MRM's destination-address is set to an arbitrary address > somewhere in the Internet. The message is routed downstream. > REA reserves at NAT resource and allows incoming NSLP messages to > be forwarded to NI+/NR. > > - REA-F uses PC-MRM routed upstream and needs a specific sender's > IP address in most cases (in the case of one default route from the > Internet to the end host, this address can be a wildcard). REA-F > faces tough challenges in multihoming environments, in environments > with no default route from the Internet to the end-host, or > with asymmetric routes (this will be addressed in an applicability > statement, issue 52). > REA-F allows incoming NSLP messages to be forwarded to NI+/NR > or blocks incoming data traffic (for allow-all firewalls) > > Pros of separated REA and REA-F > - clear separation between firewall and NAT functionality (which is > not > the case for CREATEs and actually nodes should not care about > whether to see a NAT or firewall when they start signaling) > - clear separation of message routing method > > Cons of separated REA and REA-F > - end host needs to know about its situation, whether it is located > behind a firewall and NAT > - end host needs to know whether the edge-device is a firewall or NAT, > depending on this he must send REA-F or REA. In the case of > an edge-firewall, a NI+ must first use REA to edge-NAT, to get the > NAT bindings and the forwarding (multiplexing) information for the > NSLP. Afterwards, the NI+ must use REA-F to signal to the edge- > firewall > > The separation has more cons than pros -- so lets unify them. > > The proposal: > - Only a RESERVE-EXTERNAL-ADDRESS (REA, because the name is nice > and even in the firewall case you are reserving (in a broad > scope) an external address. > - REA is doing this: > - At edge-NATs: Reserving external IP address/port and > allowing NSLP messages to be forwarded. > - At edge-Firewalls: Either allowing NSLP messages to be > forwarded or blocking incoming data traffic (semantics > depend on the extended flow information object). > - REA for edge-NATs can be transported over LE-MRM or PC-MRM. > (LE-MRM if DS is not known, PC-MRM if DS is known) > - REA for edge-Firewalls must be transported over upstream PC-MRM. > > Corner-case: You are in NAT-ed network and the edge-device is > not a NAT but an edge-firewall (of course you do not know as > NI+ :). Processing rule for the NAT: Forward REA to the edge-firewall. > If routing fails, because there two or more boxes and you do not which > of them is the right one: Return error. > > Martin > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-23-1072194174 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIyMDEzMDQyOFowIwYJKoZIhvcNAQkEMRYEFOYeTpER0uYuNZISu1iy nXBXW352MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAGxMl+cW/8KL0DzdVdww pF77TBngW2SixotoKhBR951jQnk0JeWTXrRJmSjTxKqts2tlDu9WRQZe7KSZkLRgfSBDoHTS0x4L TBG3dfAlZvLmhzJbhgO4qxZ+/zwEf2DVCiFqVf4Ngmub3d39+4qoKJauPa/nMyxJHZe9oS2LTxpP n1lKKDXgDLbKtLOWq4xIZ7qF8ddaPCQyTqkPi8SU1Nl258MU76jRsAmTEFSILKNRd2D+oAO8yTo+ eL9ageARsJkr5qSOpf41ePAqHC8oGf+jI5GfehnKn16+/m3DxVcgHiuCr0kKFMNVRbTYsdnWzkdb 0pnswUe5XNI8/roMUikAAAAAAAA= --Apple-Mail-23-1072194174-- --===============1780749800== 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 --===============1780749800==-- From nsis-bounces@ietf.org Mon Feb 20 18:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBK6k-000842-5P; Mon, 20 Feb 2006 18:06:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBK6i-00083m-V4 for nsis@ietf.org; Mon, 20 Feb 2006 18:06:16 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBK6h-0000hO-D8 for nsis@ietf.org; Mon, 20 Feb 2006 18:06:16 -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 1FBK6Y-0000sK-9k; Tue, 21 Feb 2006 00:06:11 +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 02B55A622; Tue, 21 Feb 2006 00:06:06 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1FBK6X-00067b-L1; Tue, 21 Feb 2006 00:06:05 +0100 Message-ID: <43FA4B8F.7030607@tm.uka.de> Date: Tue, 21 Feb 2006 00:06:55 +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: Georgios Karagiannis Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? References: <43E282E1.3040306@tm.uka.de> <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Andrew McDonald , Jukka MJ Manner , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Andrew, Jukka, > Your observations are right! > Could you please propose the text that solves these problems! Ok, after some discussion with Ruediger, now my proposal. -------- 3.2.4. Explicit state installation confirmation and responses A QoS NSLP instance MAY request an explicit confirmation of its state installation actions from the immediate upstream or downstream peer. This is achieved by using an ACKNOWLEDGE (A) flag in the message header. -------- ADD: 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. -------- 5.2.4. Retransmissions QoS-NSLP messages for which a response is requested 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. ------- 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 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 RESERVE, a failure should be indicated to the signaling application. 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. --------- Any objections? Roland > Best Regards, > Georgios > > ----- Original Message ----- From: "Roland Bless" > To: "nsis" ; "Andrew McDonald" > ; "Jukka MJ Manner" > ; "Georgios Karagiannis" > Sent: Thursday, February 02, 2006 11:08 PM > Subject: QoS NSLP: ACK flag has no effect? > > >> Hi, >> >> a quick question: Currently, a RESERVE with an ACK flag >> will trigger an immediate RESPONSE, but... >> this will have no effect on the state machine, e.g. >> no timer is started, no retransmission triggered if the >> response is missing etc. >> Therefore the provisional RESPONSE triggered by the >> ACK flag will have no effect, so currently it is pretty >> useless?! >> >> >> Furthermore, the RESPONSE codes for the ACK triggered responses >> are inconsistent: >> >> If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state >> installation action. It does so by sending a RESPONSE with an >> INFO_SPEC indicating that the reservation is installed at the QNE >> (code 0x03). >> >> ... >> >> 5.4.3. RESPONSE Messages >> ... >> >> In this case a successful RESPONSE carries >> the INFO_SPEC with success code 0x01 and the received message is >> forwarded further along the path towards the QNR. >> >> >> 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 Mon Feb 20 21:49:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBNam-0004Mz-0S; Mon, 20 Feb 2006 21:49:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBNak-0004Mt-V7 for nsis@ietf.org; Mon, 20 Feb 2006 21:49:30 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBNak-0006Qv-Em for nsis@ietf.org; Mon, 20 Feb 2006 21:49:30 -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 <0IV000309NUG2U@mailout2.samsung.com> for nsis@ietf.org; Tue, 21 Feb 2006 11:49:28 +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 <0IV0001J6NUG8H@mmp2.samsung.com> for nsis@ietf.org; Tue, 21 Feb 2006 11:49:28 +0900 (KST) Date: Tue, 21 Feb 2006 11:49:27 +0900 From: Sung-Hyuck Lee To: Shivanajay Marwaha Message-id: <007401c63691$6edca6b0$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: <5F09D220B62F79418461A978CA0921BDAC691A@pslexc01.psl.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: nsis@ietf.org Subject: [NSIS] Re: Section 3 of Mobility 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 Dear Shivanajay, Please refer to my comments in line. Sung-Hyuck ----- Original Message ----- From: "Shivanajay Marwaha" To: "Seong-Ho Jeong" ; "Sung-Hyuck Lee" ; ; ; Cc: Sent: Thursday, February 16, 2006 8:59 PM Subject: Section 3 of Mobility Applicability Draft > Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other > NSIS WG members, > > Some comments/suggestions on section 3 in the NSIS mobility > applicability draft. > > Suggestion 1:- > > Following three sub-topics are not adequately covered in the main body > and some elaboration regarding the problem should be provided or it > should be in the open-issue list. > > (i) Sub-section 3.1 (11):- "Key exchange:- When a handover happens, > nodes > on the new path must be able to verify the signaling messages of the > MN, and vice versa. " > (ii) Sub-section 3.2.3 (1):- "Update of firewall rules and NAT bindings" > > (iii) Sub-section 3.2.3 (2) "Re-use of NAT/FW-NSLP's old state" [SHL] Could you let me know why those three items are not proper in more detail? I guess "key exchange"-related issues need to further be described in Section 6. > ----------------------------------------------------- > > Suggestion 2:- > > Current Text - In Section 3.1 (3) -> " For example, Mobile IP may use > the routing > headers to define explicit routes, which diverts the traffic from an > expected path." > > Comment/Suggestion - Kindly elaborate how this is done -> MIP does not > require special > support at the intermediate routers. Any address change or > tunnelling, is done at the MIP supported nodes for eg. Home Agent or > the MN. So we would like to seek clarfication on how MIP affects > explicit routes? [SHL] As you know, Mobile IPv6 has a few specification different from Mobile IPv4. For example, Mobile IPv4 just routes packets to mobile nodes from CN via tunneling, but Mobile IPv6 can routes packets to mobile nodes from CN via both tunneling and source routing (using IPv6 routing header). > ----------------------------------------------------- > > Suggestion 3:- > > Section 3.1 (6) Upstream State Update vs. Downstream State > Update:- sp > > Current Text - " Since the upstream and downstream paths are likely not > to be the > same, the upstream and downstream CRNs may not coincide, either. > Therefore, the State Update needs to be handled independently for > the upstream and the downstream, including the discovery of upstream > and downstream CRNs." > > Comment/Suggestion - Does the above "upstream and downstream" flow refer > to data or > signalling? As such in path coupled signalling, there shouldn't be > any difference between upstream and downstream paths. So, if it is > directly addressed there may be an issue, if it is hop-hop address, > there may not be any issue as they should follow the same path. [SHL] This text describes the direction of NSIS signaling. The route of NSIS signaling initiated from sender may be different that of NSIS signaling initiated from receiver. This is also similar to the case of bidirectional reservation. > ------------------------------------------------------- > > Suggestion 4:- > > Following 3 sub-topics do not seem to be problems, rather they seem > more like requirements:- > > (i) Sub-section 3.1 (10) "Identification of the crossover node" - seems > to be a requirement derived from the previous point (9). > (ii) Sub-section 3.2.1. (1) "Interfaces between Mobile IP and NSIS > protocols" > (iii) Sub-section 3.2.1 (2) "Localized State Update" [SHL] The authors of the mobility draft have tried to address issues that need to be considered in interaction with NSIS protocols and mobile IP. The issues listed in Section 3. Is there any detailed comment/suggestion to appropriately place three items above? > Regards, > Shivanajay Marwaha > (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 20 22:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOHh-0005I6-8u; Mon, 20 Feb 2006 22:33:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOHg-0005Hx-2F for nsis@ietf.org; Mon, 20 Feb 2006 22:33:52 -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 1FBOHd-0008Bk-DY for nsis@ietf.org; Mon, 20 Feb 2006 22:33:52 -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 k1L3XkxT009892; Tue, 21 Feb 2006 12:33:46 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k1L3XmZ12307; Tue, 21 Feb 2006 12:33:48 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id k1L3Xmx24815; Tue, 21 Feb 2006 12:33:48 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml24) id k1L3XlI20900; Tue, 21 Feb 2006 12:33:47 +0900 (JST) Received: from [10.68.136.29] by soml24.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id k1L3XbJ20685; Tue, 21 Feb 2006 12:33:37 +0900 (JST) Date: Tue, 21 Feb 2006 12:33:52 +0900 From: Takako Sanda To: Sung-Hyuck Lee Subject: Re: [NSIS] Re: Section 3 of Mobility Applicability Draft In-Reply-To: <007401c63691$6edca6b0$f95b024b@LocalHost> References: <5F09D220B62F79418461A978CA0921BDAC691A@pslexc01.psl.local> <007401c63691$6edca6b0$f95b024b@LocalHost> Message-Id: <20060221122228.6F24.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: 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 Dear Sung-Hyuck, > > Comment/Suggestion - Does the above "upstream and downstream" flow refer > > to data or > > signalling? As such in path coupled signalling, there shouldn't be > > any difference between upstream and downstream paths. So, if it is > > directly addressed there may be an issue, if it is hop-hop address, > > there may not be any issue as they should follow the same path. > > [SHL] This text describes the direction of NSIS signaling. The route of NSIS > signaling initiated from sender may be different that of NSIS signaling > initiated from receiver. This is also similar to the case of bidirectional > reservation. We need to clarify the terms "upstream" and "downstream" for signaling. In the GIST draft (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-09.txt), the terms are defined as: Downstream: In the same direction as the data flow. Upstream: In the opposite direction to the data flow. But in the Applicability draft, these terms seem to be used as: Downstream: Signaling (or data) from CN to MN Upstream: Signaling (or data) from MN to CN This difference makes confusion. I think the terminologies should be unified in NSIS WG drafts. BR, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 21 04:32:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTsv-00027E-DF; Tue, 21 Feb 2006 04:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTsu-000279-P8 for nsis@ietf.org; Tue, 21 Feb 2006 04:32: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 1FBTss-0002Km-22 for nsis@ietf.org; Tue, 21 Feb 2006 04:32: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/kings) with ESMTP id k1L9Vos6003566; Tue, 21 Feb 2006 18:31:50 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k1L9VpZ15913; Tue, 21 Feb 2006 18:31:51 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id k1L9VkV09023; Tue, 21 Feb 2006 18:31:46 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 21 Feb 2006 17:30:33 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDB236AD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Suggestions on Multi-homing section of Mobility Draft Thread-Index: AcY2Cl1TvhhbJqMWTsGBLBEQuosILAAvjMqw From: "Shivanajay Marwaha" To: "Sung-Hyuck Lee" X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: fu@cs.uni-goettingen.de, Seong-Ho Jeong , jmanner@cs.helsinki.fi, nsis@ietf.org, Hannes.Tschofenig@siemens.com Subject: [NSIS] RE: Suggestions on Multi-homing section of Mobility 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 Dear Sung-Hyuck, Thanks for your feedback on our suggestions.=20 Here are some comments embedded in-line. Regards, Shivanajay=20 -----Original Message----- From: Sung-Hyuck Lee [mailto:starsu.lee@samsung.com]=20 Dear Shivanajay, Thank you for your interests. Please refer to my comments in line. Warm regards, Sung-Hyuck ----- Original Message ----- From: "Shivanajay Marwaha" > Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and=20 > other NSIS WG members, > =20 > We have been studying the NSIS Mobility Applicability draft=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mo > bili ty-signaling-03.txt and have some suggestions.=20 > =20 > Here are few of the Comments/suggestion on section 5 in the NSIS=20 > mobility applicability draft:- (More to follow in the subsequent=20 > emails :) >=20 > ------------------------------------------------------------ > Suggestion 1 - > General introduction of multihoming seems to be lacking >=20 > Discussion - > In section 5.2, current text lacks a general introduction to=20 > multihoming. The first two sentences talk only about a specific > issue concerning multihomed host. Therefore it would be better to > include some general description of multihoming environment to > give readers a complete picture. In our view, the text from > section > 5.2.1 of version 02 suits the > Purpose better. So, we suggest that the first two sentences of > section 5.2 be replaced with the following text (from section > 5.2.1 of version 02):- > =20 > Suggested Text - > "Multihoming refers to a situation where an end node has several=20 > parallel communication paths to use. An end node (e.g., an MN in=20 > mobile environments) may have multiple homogeneous/heterogeneous=20 > interfaces. Multiple interfaces can be used in order to increase=20 > bandwidth availability or to select the most appropriate interface=20 > according to the type of flow or choices of the user [17]. > =20 > Basically, each network interface has different performance,=20 > bandwidth, access range, and reliability. Users may want to select > the most appropriate set of network interface(s) depending on the > network environment, particularly in wireless networks which are > less reliable than wired networks. Users may also want to select > the most appropriate interface based on certain criteria or to > combine a set of interfaces to get sufficient bandwidth [17]. >=20 > In multihomed environments, multiple addresses can be allocated to=20 > either a single interface or multiple interfaces to provide > ubiquitous and fault-tolerant access to the Internet. Other > benefits of having multiple interfaces include load balancing, > bi-casting, load sharing, and etc." [SHL] It is not easy to evaluate which introduction is better because we need to consider various views on editing of drafts: The way of editing can be different dependent on what preference is, simpler or more detailed expression. Till now, the mobility authors have tried to make the mobility draft simpler with clearer text. However, the authors will refer to your valuable comments. ********************************************************************** [SHIV] Thanks. We understand your difficulty in carefully choosing the text so as to keep it simple :) In our opinion a general description of multihoming environment would be good for the sake of completeness and better clarity. If required we can contribute some brief text (2-3 sentences) for the same. =20 ********************************************************************** > ------------------------------------------------------------------ >=20 > Suggestion 2 - > Section 5.2.1, Para below Figure 14: (homogenous interface vs. > multiple interfaces) > > Current text: - (Section 5.2.1) > " We assumed homogeneous wireless interfaces in this draft although > multihoming with multiple interfaces would be more efficient on=20 > heterogeneous interfaces due to the increased path diversity. The=20 > issues on heterogeneous interfaces are for further study. " >=20 > Discussion - > According to the diagram the issue discussed in this section is > about using one connection for communication (although multiple > connections may be available/possible). This does not even depends > on the number of interfaces available on the MN, since in a site > multihoming=20 > environment, MN can still have multiple address (in turn multiple=20 > connections to CN) on one interface. Therefore, the use of=20 > "homogeneous" and "heterogeneous" in the above text does not > reflect the actual issue. It would be better to clarify the > difference. > Furthermore, in section 5.2.5, some discussion was provided about > the case of using mulitple connections. This should be also > reflected in the text. So we suggest to replace the 4th paragraph > of section 5.2.1 with following text: [SHL] You seem to misunderstand the terms, "homogeneous" and "heterogeneous". Homogeneous interfaces mean that the interfaces consist just same physical air interface, for example, only IEEE 802.11.=20 Heterogeneous interfaces mean that the interfaces simultaneously consist different physical air interfaces, for example, WIFI and 3G, WIFI and WIMAX/WiBro, etc. ********************************************************************** [SHIV] Actually what we meant was that, in our opinion the said problem is not limited to "homogenous" case only. Perhaps the reference of the problem to "homogenous" case can be amended/deleted so as to avoid any confusion in the minds of the readers (since the problem of selection of appropriate interface/s will also arise in "heterogenous" case.) ********************************************************************** > Suggested Text - > "This section deals with the scenario where only one connection is=20 > used for data traffic at a time. In some case multiple connections > via heterogeneous interfaces may be necessary and more efficient. > Discussion about host multihoming issues is included in section > 5.2.5 of this draft" >=20 > Regards, > Shivanajay Marwaha > (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 21 04:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTyf-0002aK-GM; Tue, 21 Feb 2006 04:38:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTye-0002aA-F7 for nsis@ietf.org; Tue, 21 Feb 2006 04:38:36 -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 1FBTyd-0002Z5-SG for nsis@ietf.org; Tue, 21 Feb 2006 04:38:36 -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 k1L9cGxT000628; Tue, 21 Feb 2006 18:38:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k1L9cIK10565; Tue, 21 Feb 2006 18:38:18 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id k1L9cDV13334; Tue, 21 Feb 2006 18:38:13 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 21 Feb 2006 17:36:59 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDB236B1@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Suggestions on Route Optimisation (Mobility Applicability Draft) Thread-Index: AcY2ylyslLvJ0QxYQnGL9bwlnY4jRg== From: "Shivanajay Marwaha" To: , , , "Seong-Ho Jeong" , "Sung-Hyuck Lee" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nsis@ietf.org Subject: [NSIS] Suggestions on Route Optimisation (Mobility 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 Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other NSIS WG members,=20 =20 Here are some suggestions on - "Route Optimisation (section 5.2.1)" sections of the mobility applicability draft.=20 =20 --------------------------- Comment 1 - Section 5.2.1, Second Para:" Route Optimisation issue discussed is not Multihoming specific =20 Current Text - "When a route optimization is used, a direct connection is established between an MN and a CN, in which case another reservation needs to be made while releasing the existing reservation engaged in the HA. In order to avoid this situation, the NSIS signaling for resource reservation needs to be performed only after finishing the route optimization, which is the way assumed in the following scenarios. On the other hand, without route optimization the resource reservation could be performed immediately after establishing the reverse tunnel."=20 =20 Suggestion - This section is regarding multihoming however the RO problem described above is a general MIP issue and is not specific to multihoming. Therefore it should be moved to the appropriate section. So our suggestion is to remove the above paragraph from section 5.2.1.=20 =20 ----------------------------- Comment 2: Sect. 5.2.1, Second Para: Clarifications/elaboration:=20 =20 Current text - " In order to avoid this situation, the NSIS signaling for resource reservation needs to be performed only after finishing the route optimization, which is the way assumed in the following scenarios. " =20 Discussions - In the above text, it suggests that the reservation be performed "only" after Route Optimisatio (RO). Does this mean that after RO, resource reservation is only carried out over RO path? In this case, how would the MN know that RO could be accomplished? =20 Suggestion - Provide some clarification regarding the issue above.=20 --------------------------------- =20 Regards, Shivanajay Marwaha (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 21 04:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBU4G-000347-ES; Tue, 21 Feb 2006 04:44:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBU4E-00033o-Sz for nsis@ietf.org; Tue, 21 Feb 2006 04:44:22 -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 1FBU4E-0002rQ-8j for nsis@ietf.org; Tue, 21 Feb 2006 04:44:22 -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 k1L9i4s6014594; Tue, 21 Feb 2006 18:44:04 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k1L9i5Z20864; Tue, 21 Feb 2006 18:44:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k1L9i3x06676; Tue, 21 Feb 2006 18:44:03 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 21 Feb 2006 17:42:49 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDB236B5@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Suggestions on Multi-homing Security section (Mobility Applicability Draft) Thread-Index: AcY2yy2IG+DXH8NtQXy6snMWdqSrag== From: "Shivanajay Marwaha" To: , , , "Seong-Ho Jeong" , "Sung-Hyuck Lee" X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: nsis@ietf.org Subject: [NSIS] Suggestions on Multi-homing Security section (Mobility 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: , Content-Type: multipart/mixed; boundary="===============0583158768==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0583158768== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C636CB.38CB4D0E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C636CB.38CB4D0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors & other NSIS WG members,=20 =20 Two comments on "Multi-homing Security (section 6.1.4.1)" section of the mobility applicability draft. =20 -----------------------------------------------=20 Comment 1 - Section 6.1.4.1, Second Para: Clarify flow ID. Current text - "Furthermore, it is an open issue whether reservation merging is allowed only for cases where one flow identifier is used at different interfaces or even with different flow identifiers." =20 Discussion - When multiple interfaces are used, unless the same CoA is allocated to them, the flow identifier should always be different. It seems that the above discussion is regarding Session Identifier instead of flow identifier.=20 =20 Suggestion - Kindly provide some elaboration/description for the above issue. ----------------------------------------------- =20 Comment 2: Section 6.1.4.1, Third para: Clarify what is the problem =20 Current text - "If the CN is the authorizing entity then, again, some message needs to be sent from the CN to the MN to trigger the exchange or to route the request backwards along the established path. The MN is reachable via the two paths." =20 Discussion - It is not clear what is the problem faced by NSIS. The above text sounds like some operation descriptions instead of problem definition.=20 =20 Suggestion - Some more elaboration/description of the problem for this scenario would be helpful.=20 -----------------------------------------------=20 =20 Regards, Shivanajay Marwaha (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) ------_=_NextPart_001_01C636CB.38CB4D0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sung-Hyuck, Seong-Ho, Mobility = Applicabilty=20 Draft Authors & other NSIS WG = members, 
 
Two comments on "Multi-homing = Security=20 (section 6.1.4.1)" section of = the mobility=20 applicability=20 draft.
 
----------------------------------------------- =
Comment=20 1 - Section 6.1.4.1, Second Para: Clarify flow ID.

Current text -  = "Furthermore, it is=20 an open issue whether reservation = merging=20 is allowed only for cases where one flow identifier is used at different interfaces or even with = different=20 flow identifiers."
 
Discussion -  When multiple = interfaces are=20 used, unless the same CoA is = allocated to=20 them, the flow identifier should always be different. It seems that the above discussion is = regarding=20 Session Identifier instead of = flow=20 identifier. 
 
Suggestion - Kindly provide some = elaboration/description for the above=20 issue.
-----------------------------------------------
 
Co= mment 2: Section 6.1.4.1, Third para: = Clarify what is=20 the problem
 
Current = text=20 -  "If the CN is the authorizing entity then, again, some message needs to be sent from = the CN to=20 the MN to trigger the exchange = or to route=20 the request backwards along the established=20 path.  The MN is reachable via the two=20 paths."
 
Discussion -  It is not clear what is the = problem=20 faced by NSIS. The above text = sounds like=20 some operation descriptions instead of problem=20 definition. 
 
Suggestion  - Some more=20 elaboration/description of the problem for this=20 scenario would be helpful.=20
-----------------------------------------------=20
 
Regards,
Shivanajay Marwaha
(On Behalf of Takako = Sanda,=20 Toyoki Ue and Cheng Hong)
------_=_NextPart_001_01C636CB.38CB4D0E-- --===============0583158768== 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 --===============0583158768==-- From nsis-bounces@ietf.org Tue Feb 21 05:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBVCb-0006vQ-Ax; Tue, 21 Feb 2006 05:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBVCa-0006vL-Hs for nsis@ietf.org; Tue, 21 Feb 2006 05:57:04 -0500 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBVCZ-0005Bb-7c for nsis@ietf.org; Tue, 21 Feb 2006 05:57:04 -0500 Received: from win2003.dickmann2003.home (p548A5414.dip.t-dialin.net [84.138.84.20]) by www.difra-computer.de (Postfix) with ESMTP id 42F9B3E4049 for ; Tue, 21 Feb 2006 13:05:08 +0100 (CET) Received: from dickmann.homeunix.org ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 11:47:36 +0100 MIME-Version: 1.0 Date: Tue, 21 Feb 2006 11:52:57 +0100 From: Christian Dickmann To: nsis@ietf.org Message-ID: X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2006 10:47:36.0451 (UTC) FILETIME=[3A3A6530:01C636D4] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [NSIS] Problem with NAT-Traversal object X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 have a question regarding NAT Traversal in GIST ID 09. Section 5.1 tells me "The objects following the common header MUST be carried in a fixed order, depending on message type." and for GIST-Reponse it states: GIST-Response = Common-Header Message-Routing-Information Session-Identification ... Now I had a look at section 7.2 regarding NAT Traversal and how to handle the NAT traversal object. There the draft states: "It MUST also include the NAT-Traversal object as the first object in the Response after the common header." I wonder, why you did not include the NAT-Traversal object in section 5.1. One reason might be, that you think of NAT-Traversal as an optional advanced feature of GIST. But I think if this is the case the NAT Traversal section should not change basic behaviour of section 5.1. Reading section 5.1 one could take for granted, that you can expect the MRI to be the first object in any case. I suggest to include NAT Traversal in section 5.1 as an optional object. I guess the rational for making the NAT traversal object the first one after the common header is that it is a kind of "replace" for the normal MRI? The spec would therefore look like: GIST-Response = Common-Header [ NAT-Traversal ] Message-Routing-Information Session-Identification ... Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 21 11:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBaIt-0001dF-P5; Tue, 21 Feb 2006 11:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBaIs-0001d5-Pe for nsis@ietf.org; Tue, 21 Feb 2006 11:23:54 -0500 Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBaIr-0003Nc-HZ for nsis@ietf.org; Tue, 21 Feb 2006 11:23:54 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FBaIq-0005Cd-Ng for nsis@ietf.org; Tue, 21 Feb 2006 16:23:52 +0000 Message-ID: <43FB3F25.7050607@dial.pipex.com> Date: Tue, 21 Feb 2006 16:26:13 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] GIST: Authentication API Discrepancy X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 NATFW NSLP may need to be able to access the authentication information that GIST obtains (e.g., to look at additional fields of certificates) and s8.2 of draft-ietf-nsis-ntlp-09 states: > > The abstract API of Appendix B leaves open such policy > and authentication interactions between GIST and the NSLP it is > serving. However, it does allow applications to inspect the > authenticated identity of the peer to which a message will be sent > before transmission. > The last sentence of this implies that the API has a means for passing the certificate or other authentication data to the NSLP. I take it that this would be a parameter of RecvMessage but it doesn't appear that it is available at present - the Transfer-Attributes have some info but not all of it seemingly. Is this a drop-off? Regards, Elwyn _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 21 12:54:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbiS-0006pZ-Rl; Tue, 21 Feb 2006 12:54:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbiS-0006pU-84 for nsis@ietf.org; Tue, 21 Feb 2006 12:54:24 -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 1FBbiR-0006mp-Nm for nsis@ietf.org; Tue, 21 Feb 2006 12:54:24 -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 Feb 2006 19:54:22 +0200 id 00070312.43FB53CE.00006B02 Date: Tue, 21 Feb 2006 19:54:22 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect? In-Reply-To: <43FA4B8F.7030607@tm.uka.de> Message-ID: References: <43E282E1.3040306@tm.uka.de> <003501c628a3$617c3c70$4c0d5982@dynamic.ewi.utwente.nl> <43FA4B8F.7030607@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: 68ba2b07ef271dba6ee42a93832cfa4c 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, No objections here. Jukka On Tue, 21 Feb 2006, Roland Bless wrote: > Hi Georgios, Andrew, Jukka, > > > Your observations are right! > > Could you please propose the text that solves these problems! > > Ok, after some discussion with Ruediger, now my proposal. > -------- > 3.2.4. Explicit state installation confirmation and responses > > A QoS NSLP instance MAY request an explicit confirmation of its state > installation actions from the immediate upstream or downstream peer. > This is achieved by using an ACKNOWLEDGE (A) flag in the message > header. > -------- > ADD: > 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. > -------- > 5.2.4. Retransmissions > > QoS-NSLP messages for which a response is requested 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. > ------- > 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 > 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 > RESERVE, a failure should be indicated to the signaling > application. > > 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. > --------- > > Any objections? > Roland > > > Best Regards, > > Georgios > > > > ----- Original Message ----- From: "Roland Bless" > > To: "nsis" ; "Andrew McDonald" > > ; "Jukka MJ Manner" > > ; "Georgios Karagiannis" > > Sent: Thursday, February 02, 2006 11:08 PM > > Subject: QoS NSLP: ACK flag has no effect? > > > > > >> Hi, > >> > >> a quick question: Currently, a RESERVE with an ACK flag > >> will trigger an immediate RESPONSE, but... > >> this will have no effect on the state machine, e.g. > >> no timer is started, no retransmission triggered if the > >> response is missing etc. > >> Therefore the provisional RESPONSE triggered by the > >> ACK flag will have no effect, so currently it is pretty > >> useless?! > >> > >> > >> Furthermore, the RESPONSE codes for the ACK triggered responses > >> are inconsistent: > >> > >> If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state > >> installation action. It does so by sending a RESPONSE with an > >> INFO_SPEC indicating that the reservation is installed at the QNE > >> (code 0x03). > >> > >> ... > >> > >> 5.4.3. RESPONSE Messages > >> ... > >> > >> In this case a successful RESPONSE carries > >> the INFO_SPEC with success code 0x01 and the received message is > >> forwarded further along the path towards the QNR. > >> > >> > >> 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 Tue Feb 21 15:17:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdwi-0006ON-Tg; Tue, 21 Feb 2006 15:17:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdwi-0006OI-5M for nsis@ietf.org; Tue, 21 Feb 2006 15:17:16 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdwe-0005r9-FL for nsis@ietf.org; Tue, 21 Feb 2006 15:17:16 -0500 Received: from [192.168.178.22] (p54ACC0DD.dip0.t-ipconnect.de [84.172.192.221]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8A55A1BAC4D for ; Tue, 21 Feb 2006 21:18:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <749A141B-F09F-4B63-880E-666A7CF1EC67@netlab.nec.de> References: <000501c635a1$26002bb0$6500000a@comm.ad.roke.co.uk> <749A141B-F09F-4B63-880E-666A7CF1EC67@netlab.nec.de> Message-Id: <83BC5798-72A1-4644-9575-7A23E1D08EE4@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Date: Tue, 21 Feb 2006 21:17:03 +0100 To: nsis X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-BeenThere: nsis@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="===============0455934606==" Errors-To: nsis-bounces@ietf.org --===============0455934606== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--962933075; protocol="application/pkcs7-signature" --Apple-Mail-1--962933075 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > >> >> *) [different from what I said in Vancouver, but hey ...]: >> it's true that dropping out the C-mode connection could be >> taken as a signal that a node was shutting down (which would >> avoid the storm altogether). There's nothing to stop cooperating >> implementations adopting this convention; however, I think it >> would probably need some non-obvious changes to the GIST API >> to achieve it (because essentially you want the signalling >> application to start manipulating GIST MAs). > > Good point raised. Especially, tearing down an MA could hurt other > NSLPs which probably have no problem, since they could share > the same MA. Robert's proposal works and here is the text proposal: NATFW NSLP forwarders, keeping multiple signaling sessions at the same time, can experience problems when shutting down service suddenly. This sudden shutdown can be result of node locale failure, for instance, due to a hardware failure. This NF generates NOTIFY messages for each of the signaling sessions and tries to send them upstream. Due to the amount of NOTIFY messages the shutdown of the node may be unnecessarily prolonged, since not all messages can be send at the same time. This case can be described as a NOTIFY storm, if a multitude of signaling sessions is involved. 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 and with the MRI completely wildcarded. The upstream NF receiving this type of NOTIFY immediately regards all signaling sessions bound to the messaging association where this NOTIFY has been received as null and void. Martin > >> >> Fundamentally what one wants is for the NATFW NSLP to be able >> to send a message to a specific *peer* (rather than about a >> specific *flow*). In theory, that's tricky because GIST messages >> are usually routed on MRI a.k.a. flow-id. However, it is possible >> for an NSLP to bypass GIST routing and just say 'send the message >> to that person'; this capability was introduced to allow state >> teardown on an old path, but is equally applicable here. The >> NATFW NSLP can define a shutdown message, which would be sent >> with a zero SID and an MRI describing the flows which are affected >> (typically but not necessarily all of them). See sections 5.2.1 >> and 7.1.4 for more discussion. >> >> The difference between this functionality and NSLPs randomly choosing >> which peers they want to talk to is that GIST only allows this to >> be done in relation to state which has previously been created; >> the NSLP gets told an opaque ID for the peer which accepts the >> state, and can explicitly route a message back to that peer. >> AFAICT GIST already has precisely the right functionality here, >> packaged in precisely the right way (which is quite reassuring). > > I have to check sections 5.2.1 and 7.1.4 and will come back. Right > now, this looks like an excellent way to do the complete teardown. > > To the QoS people: Does this notification storm apply to the QoS NSLP > as well? > > Thanks, > > Martin > >> >> r. >> >>> -----Original Message----- >>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>> Behalf Of Martin Stiemerling >>> Sent: 18 February 2006 11:37 >>> To: nsis >>> Subject: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms >>> >>> >>> Hi all, >>> >>> >>> Elwyn has raised an issue at the last IETF meeting about the >>> possibility of notification storms. See also issue 66 in the >>> issue tracker at >>> https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66. >>> >>> >>> The issue has been described with pictures in the slide set >>> shown at the last NSIS session in Vancouver (IETF-64): >>> http://www.stiemerling.org/ietf/ietf64/ietf64_nsis_natfw_nslp_v1.ppt >>> >>> >>> Short summary of this issue: >>> - A given NATFW NSLP forwarder (NF1) has installed NATFW >>> stated for many flows >>> - NF2 is a upstream forwarded of NF1 >>> - NF2 fails in operation and drops out (for whatever reason) >>> >>> >>> +------+ +------+ +------+ >>> | | | | | | >>> | NIs |=======| NF1 |--------| NF2 |----> >>> | | | | | | >>> +------+ +------+ +------+ >>> >>> >>> <~~~~~~~~ "Storm" >>> >>> >>> In the case NF2 is shut down/drops out, but is still able to >>> generate NATFW NSLP messages, NF1 will receive, possibly, as >>> many NOTIFY messages as session are installed between NF1 and >>> NF2. This is what Elwyn calls a "notification storm". >>> >>> >>> Things to know about the "relationship" of NF1 and NF2: The >>> NATFW NSLP requires using the C-MODE of the NTLP. The C-MODE >>> offers reliable, congestion controlled, transport of NTLP and >>> NSLP messages between two adjacent peers. Further, NATFW NSLP >>> MAY send NOTIFY messages but the MUST not send them, i.e., >>> NSLP nodes can send them but the do not need to send them. >>> >>> >>> My conclusions about this issue, which has partially been >>> discussed with Robert and Andrew at the last meeting: >>> Yes, there is a risk that a node is generating many NOTIFY >>> messages upon an error condition >>> (either node failure or an upstream link is going down). But >>> there are several, already existing, measures to avoid a >>> storm towards upstream nodes: >>> - Using the C-MODE: The transport protocol (currently TCP) >>> takes care of some sort of rate limiting, since the receiver >>> (here NF1) would not be able to read all NOTIFY messages at >>> once. NF2 would be blocked by the TCP socket in sending new >>> messages, unless NF1 has read more from its sockets (I do not >>> go into TCP details for that). >>> - This could lead to a growing NSLP sending queue at NF2, >>> which in turn gets stuck. In the case, the node fails anyway, >>> this queue will lengthen the shutdown process or the queue >>> will be flushed by the shutdown process. >>> - NF2 does not need to send all NOTIFY messages, due to the >>> fact, that NOTIFY MAY be send. Therefore, in such an error >>> condition, NF can refrain from sending so many NOTIFY >>> messages (see also below for the countermeasure section) >>> >>> >>> >>> >>> Countermeasure: >>> A good way to avoid a NF generating many NOTIFY messages is >>> to not generate these messages ;-) Instead of generating >>> these messages, the NF can solely close the TCP connection >>> (here NF2 is closing the connection) and does not need to >>> send as many NOTIFY messages as sessions. NF1 must interpret >>> the closing of the TCP connection as NOTIFY messages for all >>> the associated sessions. >>> >>> >>> This behaviour has not yet been described in the draft, but >>> if accepted, it would go in an applicability statement on how >>> to treat this case. >>> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis --Apple-Mail-1--962933075 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIyMTIwMTcwNFowIwYJKoZIhvcNAQkEMRYEFAPFZ/MYRL48C+lfHtlg zwTGvqX3MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAFOaUgvmm2i726K+hgGF f8RLCBx3m/HTAHnCe6kE0mjtPVfElJJ++QCNyXYbICjKT5+YENyOfUVy74JQU367whQgImceZho7 UzGFFYoBWtkdss9bUY/NhzSa+r2qeyoWGjyLYu1RIM/Rd6Sq2/M829x5lqegFYLcCIDlqmnjHFYl af53AHGok1p53YcvPiAbHo8YvzJ6X5lbmVaQkUDa98s6w6dieIVcbWptNo4VRVFg01L0BarBz84I ph6NbDE3I4dU+PcutePePIn75QoCesqL30HOQ9zPsKEamhCaX3GjLxsIjfKZWuYmLpPtqcScL5nQ V6vys/PUzQT85dG0KUEAAAAAAAA= --Apple-Mail-1--962933075-- --===============0455934606== 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 --===============0455934606==-- From nsis-bounces@ietf.org Tue Feb 21 20:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBiMV-0006kp-QI; Tue, 21 Feb 2006 20:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBgS2-0000wx-8G for nsis@ietf.org; Tue, 21 Feb 2006 17:57:46 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBgJz-0007K5-Px for nsis@ietf.org; Tue, 21 Feb 2006 17:49:29 -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 k1LMnLoh029975; Tue, 21 Feb 2006 22:49:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DF4421H8; Tue, 21 Feb 2006 22:56:25 -0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] GIST: Authentication API Discrepancy Date: Tue, 21 Feb 2006 22:49:09 -0000 Message-ID: <003501c63739$08e867b0$6500000a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST: Authentication API Discrepancy Thread-Index: AcY3Ogwtf3MKSJF8SoOuA3nfIxVYfA== From: "Hancock, Robert" To: "Elwyn Davies" , "Nsis" X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0392610760==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0392610760== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6373A.0A797280" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C6373A.0A797280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Elwyn, The intention is that you should be able to get at this information through the API. There are actually 2 places: - RecvMessage (to say how a message was received) - MessageStatus (to find out how a message is going to be sent) You can also specify how a message is to be sent in SendMessage. In each case, the information logically goes in the transfer attributes provided with the message. The security points are noted mainly in the SendMessage description, but the same points apply to the other two primitives. The description of the transfer attributes is deliberately left open. Especially in the security case, I think it likely that=20 these will be largely a pass through to whatever is provided by the underlying TLS implementation, whatever it is. The main goal of the API discussion is to indicate at what stage in a=20 signalling transaction the information becomes available to NSLPs and what they can do with it, rather than to specify how much detail and in what format it should be provided. Do you think the specification should say more? r. PS note that Pasi & Hannes' tls-in-gist draft indicates other reasons why one might want more detail in the API description, specifically to allow NSLPs to do channel bindings to the underlying security association. So that would require at least definition of the semantics of the information to be provided by the API, even if the syntax is left up to the channel binding specification. > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@dial.pipex.com]=20 > Sent: 21 February 2006 16:26 > To: Nsis > Subject: [NSIS] GIST: Authentication API Discrepancy >=20 >=20 > The NATFW NSLP may need to be able to access the authentication=20 > information that GIST obtains (e.g., to look at additional fields of=20 > certificates) and s8.2 of draft-ietf-nsis-ntlp-09 states: > > > > The abstract API of Appendix B leaves open such policy > > and authentication interactions between GIST and the NSLP it is > > serving. However, it does allow applications to inspect the > > authenticated identity of the peer to which a message=20 > will be sent > > before transmission. > > > The last sentence of this implies that the API has a means=20 > for passing=20 > the certificate or other authentication data to the NSLP. I take it=20 > that this would be a parameter of RecvMessage but it doesn't=20 > appear that=20 > it is available at present - the Transfer-Attributes have=20 > some info but=20 > not all of it seemingly. Is this a drop-off? >=20 >=20 > Regards, > Elwyn >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C6373A.0A797280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] GIST: Authentication API Discrepancy

Hi Elwyn,

The intention is that you should be able to get at = this information
through the API. There are actually 2 places:

- RecvMessage (to say how a message was = received)
- MessageStatus (to find out how a message is going = to be sent)

You can also specify how a message is to be sent in = SendMessage.

In each case, the information logically goes in the = transfer
attributes provided with the message. The security = points are noted
mainly in the SendMessage description, but the same = points apply
to the other two primitives.

The description of the transfer attributes is = deliberately left
open. Especially in the security case, I think it = likely that
these will be largely a pass through to whatever is = provided by
the underlying TLS implementation, whatever it is. = The main goal
of the API discussion is to indicate at what stage in = a
signalling transaction the information becomes = available to
NSLPs and what they can do with it, rather than to = specify how
much detail and in what format it should be = provided.

Do you think the specification should say more?

r.

PS note that Pasi & Hannes' tls-in-gist draft = indicates other
reasons why one might want more detail in the API = description,
specifically to allow NSLPs to do channel bindings to = the
underlying security association. So that would = require at least
definition of the semantics of the information to be = provided
by the API, even if the syntax is left up to the = channel binding
specification.

> -----Original Message-----
> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] =
> Sent: 21 February 2006 16:26
> To: Nsis
> Subject: [NSIS] GIST: Authentication API = Discrepancy
>
>
> The NATFW NSLP may need to be able to access the = authentication
> information that GIST obtains (e.g., to look at = additional fields of
> certificates) and s8.2 of = draft-ietf-nsis-ntlp-09 states:
> >
> > The abstract API of Appendix B leaves open = such policy
> >    and authentication = interactions between GIST and the NSLP it is
> >    serving.  However, = it does allow applications to inspect the
> >    authenticated identity of = the peer to which a message
> will be sent
> >    before = transmission.
> >
> The last sentence of this implies that the API = has a means
> for passing
> the certificate or other authentication data to = the NSLP.  I take it
> that this would be a parameter of RecvMessage = but it doesn't
> appear that
> it is available at present - the = Transfer-Attributes have
> some info but
> not all of it seemingly.  Is this a = drop-off?
>
>
> Regards,
> Elwyn
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C6373A.0A797280-- --===============0392610760== 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 --===============0392610760==-- From nsis-bounces@ietf.org Wed Feb 22 00:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmep-00023r-N4; Wed, 22 Feb 2006 00:35:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmeo-00023m-K7 for nsis@ietf.org; Wed, 22 Feb 2006 00:35:22 -0500 Received: from relaygw1.kornet.net ([61.74.75.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBmek-0008B1-Cw for nsis@ietf.org; Wed, 22 Feb 2006 00:35:22 -0500 Received: from [211.48.62.137] ([211.48.62.137]) by relaygw1.kornet.net ([61.74.75.196]) with ESMTP id 2006022214:34:42:604994.16620.91343792 for ; Wed, 22 Feb 2006 14:34:42 +0900 (KST) Received: from [203.253.70.47] ([203.253.70.47]) by relay9.kornet.net ([211.48.62.137]) with ESMTP id 2006022214:34:41:553329.7184.376552368 for ; Wed, 22 Feb 2006 14:34:41 +0900 (KST) From: "Seong-Ho Jeong" To: "'Shivanajay Marwaha'" , "'Sung-Hyuck Lee'" , , , Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Date: Wed, 22 Feb 2006 14:34:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <5F09D220B62F79418461A978CA0921BDAC6914@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYy7v+HT+4uGE3WTlCMLM1J6SWp1QEe9ByQ X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 Message-Id: Hi Shivanajay, Thanks for your comments. Please see my comments inline. Regards, Seong-Ho >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >Behalf Of Shivanajay Marwaha >Sent: Thursday, February 16, 2006 8:49 PM >To: Seong-Ho Jeong; Sung-Hyuck Lee; fu@cs.uni-goettingen.de; >Hannes.Tschofenig@siemens.com; jmanner@cs.helsinki.fi >Cc: nsis@ietf.org >Subject: [NSIS] Some More Suggestions on Multi-homing (section >5.2.5) ofMobility Draft > >Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors >and other NSIS WG members, > >Some more comments on Multi-homing section in Mobility draft:- > >-------------------------------------------------------------------- >Comment 1:- Section 5.2.5, Change title to "Host multihoming" > >Discussion - >We think that the above title would be more meaningful if it's >changed to Host Multihoming, since Issue discussed here >applies to host multihoming in general (where multiple >connection between MN and CN are possible, either via >different physical interfaces or a single interface). So, the >discussion in this section should not be limited to load >balancing, which is just a use case of multihoming. In view of >this, the title "Host multihoming" would be more suitable. This subsection is not the only one which discusses host multihoming. Other subsections in Section 5.2 are also related to host multihoming. > >------------------------------------------------------------------- > >Comment 2:- Section 5.2.5, reference to external drafts > >Original Text - > "There may be a situation where an MN may need to >distribute its traffic load to multiple paths via multiple >interfaces. In this case, the MN can send multiple QUERY >messages to multiple interfaces to establish NSIS state on >multiple paths." > >Discussion - >As load balancing represents only one of the many reasons for >doing multihoming, for better understanding, it is better to >refer to the draft "Goals and Benefits of Multihoming" >(draft-ernst-generic-goals-and-benefits-02). So we suggest to >replace the above paragraph of section 5.2.5 with following text:- > >Suggested Text:- > "There may be a situation where an MN may need to >distribute its traffic load to multiple paths via multiple >interfaces. In this case, the MN can send multiple QUERY >messages to multiple interfaces to establish NSIS state on >multiple paths. There are many other scenarios and >applications in multi-homing as mentioned in [x] ". >[x] Goals and Benefits of Multihoming >draft-ernst-generic-goals-and-benefits-02 I also think that it would be good to mention the draft as a relevant reference. We already have the reference in the References section although the version needs to be changed. > >-------------------------------------------------------------------- > >Comment 3:- Section 5.2.5, 2nd para: add description on >mobility problem with multihoming > >Original Text - > " Suppose that an MN wants to set up NSIS state on a path >which is able to support the specific bandwidth requirement >for a certain application in the multihomed environment. It >may not be possible to find a feasible path for such a >requirement. In this case, multiple paths can be used at the >same time so that the bandwidth requirement can be met. Note >that the flow identifier on each path may be different >although the session identifier is unchanged. " > >Discussion - >With the scenario described above, there would be a problem >for NSIS signalling when mobility happens. Please refer to >draft "Path type support for NSIS signalling" >(draft-sanda-nsis-path-type-03.txt) for details of the problem >analysis. So we suggest inserting the following paragraph >after the 2nd paragraph of section 5.2.5:- > >Suggested Text:- >"When multiple paths are used for the same session, mobility >support may pose a problem for the NSIS signalling. For >example, if Path-1 and Path-2 are used for the same session, >signalling for these two paths would use different flow >identifier, say FID-1 and FID-2, with the same session >identifier, say SID. In the case a mobility event causes the >Path-1 to be replaced by Path-3 for communication, signalling >for the Path-3 will be also using a different flow identifier, >say FID-3, and the same session identifier, SID. With this, >current NSIS signalling may fail, e.g. CRN discovery, and >tearing of the old path. This is due to the lack of >information to differentiate Path-1 from Path-2. Detail >analysis of the problem can be find in draft [x] [x] "Path >type support for NSIS signalling" >(draft-sanda-nsis-path-type-03.txt) Could you clarify further why the current CRN discovery may fail? > > >Regards, >Shivanajay >(On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) > >_______________________________________________ >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 Feb 22 00:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmqo-0002uk-MA; Wed, 22 Feb 2006 00:47:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmqn-0002uU-Qm for nsis@ietf.org; Wed, 22 Feb 2006 00:47:45 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBmqn-0000AU-Cv for nsis@ietf.org; Wed, 22 Feb 2006 00:47:45 -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 <0IV200KCSQRJ36@mailout1.samsung.com> for nsis@ietf.org; Wed, 22 Feb 2006 14:47:43 +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 <0IV200AVVQRJOW@mmp1.samsung.com> for nsis@ietf.org; Wed, 22 Feb 2006 14:47:43 +0900 (KST) Date: Wed, 22 Feb 2006 14:47:42 +0900 From: Sung-Hyuck Lee To: Shivanajay Marwaha Message-id: <035b01c63773$80005530$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: <5F09D220B62F79418461A978CA0921BDB236AD@pslexc01.psl.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nsis@ietf.org Subject: [NSIS] Re: Suggestions on Multi-homing section of Mobility 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 Shivanajay, ----- Original Message ----- From: "Shivanajay Marwaha" ----------------------- chopped -------------------------------------------------------------------- ? >> Suggestion 2 - >> Section 5.2.1, Para below Figure 14: (homogenous interface vs. >> multiple interfaces) >> >> Current text: - (Section 5.2.1) >> " We assumed homogeneous wireless interfaces in this draft although >> multihoming with multiple interfaces would be more efficient on >> heterogeneous interfaces due to the increased path diversity. The >> issues on heterogeneous interfaces are for further study. " >> >> Discussion - >> According to the diagram the issue discussed in this section is >> about using one connection for communication (although multiple >> connections may be available/possible). This does not even depends >> on the number of interfaces available on the MN, since in a site >> multihoming >> environment, MN can still have multiple address (in turn multiple >> connections to CN) on one interface. Therefore, the use of >> "homogeneous" and "heterogeneous" in the above text does not >> reflect the actual issue. It would be better to clarify the >> difference. >> Furthermore, in section 5.2.5, some discussion was provided about >> the case of using mulitple connections. This should be also >> reflected in the text. So we suggest to replace the 4th paragraph >> of section 5.2.1 with following text: > > [SHL] You seem to misunderstand the terms, "homogeneous" and > "heterogeneous". Homogeneous interfaces mean that the interfaces > consist just same physical air interface, for example, only IEEE > 802.11. > Heterogeneous interfaces mean that the interfaces simultaneously > consist different physical air interfaces, for example, WIFI and 3G, > WIFI and WIMAX/WiBro, etc. > > ********************************************************************** > [SHIV] Actually what we meant was that, in our opinion the said > problem is not limited to "homogenous" case only. Perhaps the > reference of the problem to "homogenous" case can be amended/deleted > so as to avoid any confusion in the minds of the readers (since the > problem of selection of appropriate interface/s will also arise in > "heterogenous" case.) > ********************************************************************** > >> Suggested Text - >> "This section deals with the scenario where only one connection is >> used for data traffic at a time. In some case multiple connections >> via heterogeneous interfaces may be necessary and more efficient. >> Discussion about host multihoming issues is included in section >> 5.2.5 of this draft" ? [SHL] Actually, in Section 5.2, the authors of the mobility draft have tried to mainly address host multihoming-related issues rather than site multihoming-related those according to feedbacks from NSIS folks. That is, the host multihoming with multiple interfaces/addresses was assumed in this section. The scenarios on heterogeneous interfaces may be different from those on homogeneous cases. Therefore, the authors thought that the heterogeneous-related issues needed to be for further study, and IMO, those issues may need to be discussed at separate documents. However, the authors can consider your comments on "homogenous" and "heterogeneous" terms Kind regards, Sung-Hyuck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 22 01:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBnG9-0004Ns-QE; Wed, 22 Feb 2006 01:13:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBnG8-0004Nh-Kd for nsis@ietf.org; Wed, 22 Feb 2006 01:13:56 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBnG7-0001T6-6b for nsis@ietf.org; Wed, 22 Feb 2006 01:13:56 -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 <0IV200KLERZ562@mailout1.samsung.com> for nsis@ietf.org; Wed, 22 Feb 2006 15:13:53 +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 <0IV200CHZRZ5IJ@mmp1.samsung.com> for nsis@ietf.org; Wed, 22 Feb 2006 15:13:53 +0900 (KST) Date: Wed, 22 Feb 2006 15:13:53 +0900 From: Sung-Hyuck Lee To: Shivanajay Marwaha Message-id: <036b01c63777$27d9aa10$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: <5F09D220B62F79418461A978CA0921BDB236B1@pslexc01.psl.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nsis@ietf.org Subject: [NSIS] Re: Suggestions on Route Optimisation (Mobility 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 Shivanajay, ----- Original Message ----- From: "Shivanajay Marwaha" > Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other > NSIS WG members, > > Here are some suggestions on - "Route Optimisation (section 5.2.1)" > sections of the mobility applicability draft. > > --------------------------- > Comment 1 - Section 5.2.1, Second Para:" Route Optimisation issue > discussed is not Multihoming specific > > Current Text - "When a route optimization is used, a direct connection > is established between an MN and a CN, in which case another reservation > needs to be made while releasing the existing reservation engaged in the > HA. In order to avoid this situation, the NSIS signaling for resource > reservation needs to be performed only after finishing the route > optimization, which is the way assumed in the following scenarios. On > the other hand, without route > optimization the resource reservation could be performed immediately > after establishing the reverse tunnel." > > Suggestion - This section is regarding multihoming however the RO > problem described above is a general MIP issue and is not specific to > multihoming. Therefore it should be moved to the appropriate section. So > our suggestion is to remove the above paragraph from section 5.2.1. [SHL] This paragraph can be removed if you feel it is redundant. > ----------------------------- > Comment 2: Sect. 5.2.1, Second Para: Clarifications/elaboration: > > Current text - " In order to avoid this situation, the NSIS signaling > for resource reservation needs to be performed only after finishing > the route optimization, which is the way assumed in the following > scenarios. " > > Discussions - In the above text, it suggests that the reservation be > performed "only" after Route Optimisatio (RO). Does this mean that after > RO, resource reservation is only carried out over RO path? In this case, > how would the MN know that RO could be accomplished? > > Suggestion - Provide some clarification regarding the issue above. > --------------------------------- [SHL] It is not difficult for an MN with NSIS protocols to monitor RO process (e.g., binding update). Use of some "primitives" between Mobile IP and NSIS protocols enables GIST or NSLP to detect the completeness of RO process. However, this issue seems to be the implementation-related issue like NSIS folks' feedbacks. Regards, Sung-Hyuck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 22 03:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBpg7-0003oR-Ku; Wed, 22 Feb 2006 03:48:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBp68-0001Qn-Ug for nsis@ietf.org; Wed, 22 Feb 2006 03:11:44 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBoyY-00069N-9v for nsis@ietf.org; Wed, 22 Feb 2006 03:04:00 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 00DC01BAC4D for ; Wed, 22 Feb 2006 09:05:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <83BC5798-72A1-4644-9575-7A23E1D08EE4@netlab.nec.de> References: <000501c635a1$26002bb0$6500000a@comm.ad.roke.co.uk> <749A141B-F09F-4B63-880E-666A7CF1EC67@netlab.nec.de> <83BC5798-72A1-4644-9575-7A23E1D08EE4@netlab.nec.de> Message-Id: From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Date: Wed, 22 Feb 2006 09:03:50 +0100 To: nsis X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 X-BeenThere: nsis@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="===============0187569466==" Errors-To: nsis-bounces@ietf.org --===============0187569466== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--920526341; protocol="application/pkcs7-signature" --Apple-Mail-6--920526341 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, I have noticed that the references to the appropriate sections in the NTLP were missing, after sending the text proposal for issue 66. Here is the reworked proposal: NATFW NSLP forwarders, keeping multiple signaling sessions at the same time, can experience problems when shutting down service suddenly. This sudden shutdown can be result of node locale failure, for instance, due to a hardware failure. This NF generates NOTIFY messages for each of the signaling sessions and tries to send them upstream. Due to the amount of NOTIFY messages the shutdown of the node may be unnecessarily prolonged, since not all messages can be send at the same time. This case can be described as a NOTIFY storm, if a multitude of signaling sessions is involved. 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 bound to the messaging association where this NOTIFY has been received as void. [1] refers to the NTLP. Regards, Martin Am 21.02.2006 um 21:17 schrieb Martin Stiemerling: > > >> >>> >>> *) [different from what I said in Vancouver, but hey ...]: >>> it's true that dropping out the C-mode connection could be >>> taken as a signal that a node was shutting down (which would >>> avoid the storm altogether). There's nothing to stop cooperating >>> implementations adopting this convention; however, I think it >>> would probably need some non-obvious changes to the GIST API >>> to achieve it (because essentially you want the signalling >>> application to start manipulating GIST MAs). >> >> Good point raised. Especially, tearing down an MA could hurt other >> NSLPs which probably have no problem, since they could share >> the same MA. > > Robert's proposal works and here is the text proposal: > > NATFW NSLP forwarders, keeping multiple signaling sessions at the > same time, can experience problems when shutting down service > suddenly. This sudden shutdown can be result of node locale > failure, > for instance, due to a hardware failure. This NF generates NOTIFY > messages for each of the signaling sessions and tries to send them > upstream. Due to the amount of NOTIFY messages the shutdown of the > node may be unnecessarily prolonged, since not all messages can be > send at the same time. This case can be described as a NOTIFY > storm, > if a multitude of signaling sessions is involved. > > 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 and with the MRI completely wildcarded. The > upstream NF receiving this type of NOTIFY immediately regards all > signaling sessions bound to the messaging association where this > NOTIFY has been received as null and void. > > > Martin > > >> >>> >>> Fundamentally what one wants is for the NATFW NSLP to be able >>> to send a message to a specific *peer* (rather than about a >>> specific *flow*). In theory, that's tricky because GIST messages >>> are usually routed on MRI a.k.a. flow-id. However, it is possible >>> for an NSLP to bypass GIST routing and just say 'send the message >>> to that person'; this capability was introduced to allow state >>> teardown on an old path, but is equally applicable here. The >>> NATFW NSLP can define a shutdown message, which would be sent >>> with a zero SID and an MRI describing the flows which are affected >>> (typically but not necessarily all of them). See sections 5.2.1 >>> and 7.1.4 for more discussion. >>> >>> The difference between this functionality and NSLPs randomly >>> choosing >>> which peers they want to talk to is that GIST only allows this to >>> be done in relation to state which has previously been created; >>> the NSLP gets told an opaque ID for the peer which accepts the >>> state, and can explicitly route a message back to that peer. >>> AFAICT GIST already has precisely the right functionality here, >>> packaged in precisely the right way (which is quite reassuring). >> >> I have to check sections 5.2.1 and 7.1.4 and will come back. Right >> now, this looks like an excellent way to do the complete teardown. >> >> To the QoS people: Does this notification storm apply to the QoS NSLP >> as well? >> >> Thanks, >> >> Martin >> >>> >>> r. >>> >>>> -----Original Message----- >>>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>>> Behalf Of Martin Stiemerling >>>> Sent: 18 February 2006 11:37 >>>> To: nsis >>>> Subject: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms >>>> >>>> >>>> Hi all, >>>> >>>> >>>> Elwyn has raised an issue at the last IETF meeting about the >>>> possibility of notification storms. See also issue 66 in the >>>> issue tracker at >>>> https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66. >>>> >>>> >>>> The issue has been described with pictures in the slide set >>>> shown at the last NSIS session in Vancouver (IETF-64): >>>> http://www.stiemerling.org/ietf/ietf64/ >>>> ietf64_nsis_natfw_nslp_v1.ppt >>>> >>>> >>>> Short summary of this issue: >>>> - A given NATFW NSLP forwarder (NF1) has installed NATFW >>>> stated for many flows >>>> - NF2 is a upstream forwarded of NF1 >>>> - NF2 fails in operation and drops out (for whatever reason) >>>> >>>> >>>> +------+ +------+ +------+ >>>> | | | | | | >>>> | NIs |=======| NF1 |--------| NF2 |----> >>>> | | | | | | >>>> +------+ +------+ +------+ >>>> >>>> >>>> <~~~~~~~~ "Storm" >>>> >>>> >>>> In the case NF2 is shut down/drops out, but is still able to >>>> generate NATFW NSLP messages, NF1 will receive, possibly, as >>>> many NOTIFY messages as session are installed between NF1 and >>>> NF2. This is what Elwyn calls a "notification storm". >>>> >>>> >>>> Things to know about the "relationship" of NF1 and NF2: The >>>> NATFW NSLP requires using the C-MODE of the NTLP. The C-MODE >>>> offers reliable, congestion controlled, transport of NTLP and >>>> NSLP messages between two adjacent peers. Further, NATFW NSLP >>>> MAY send NOTIFY messages but the MUST not send them, i.e., >>>> NSLP nodes can send them but the do not need to send them. >>>> >>>> >>>> My conclusions about this issue, which has partially been >>>> discussed with Robert and Andrew at the last meeting: >>>> Yes, there is a risk that a node is generating many NOTIFY >>>> messages upon an error condition >>>> (either node failure or an upstream link is going down). But >>>> there are several, already existing, measures to avoid a >>>> storm towards upstream nodes: >>>> - Using the C-MODE: The transport protocol (currently TCP) >>>> takes care of some sort of rate limiting, since the receiver >>>> (here NF1) would not be able to read all NOTIFY messages at >>>> once. NF2 would be blocked by the TCP socket in sending new >>>> messages, unless NF1 has read more from its sockets (I do not >>>> go into TCP details for that). >>>> - This could lead to a growing NSLP sending queue at NF2, >>>> which in turn gets stuck. In the case, the node fails anyway, >>>> this queue will lengthen the shutdown process or the queue >>>> will be flushed by the shutdown process. >>>> - NF2 does not need to send all NOTIFY messages, due to the >>>> fact, that NOTIFY MAY be send. Therefore, in such an error >>>> condition, NF can refrain from sending so many NOTIFY >>>> messages (see also below for the countermeasure section) >>>> >>>> >>>> >>>> >>>> Countermeasure: >>>> A good way to avoid a NF generating many NOTIFY messages is >>>> to not generate these messages ;-) Instead of generating >>>> these messages, the NF can solely close the TCP connection >>>> (here NF2 is closing the connection) and does not need to >>>> send as many NOTIFY messages as sessions. NF1 must interpret >>>> the closing of the TCP connection as NOTIFY messages for all >>>> the associated sessions. >>>> >>>> >>>> This behaviour has not yet been described in the draft, but >>>> if accepted, it would go in an applicability statement on how >>>> to treat this case. >>>> >> >> _______________________________________________ >> 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 --Apple-Mail-6--920526341 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIyMjA4MDM1MVowIwYJKoZIhvcNAQkEMRYEFJFgckrsaQT/LlC+/vd9 licgtSRXMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBALbivTl97/Vi6eRgsJvR ICpHWfK5THfjC7LmYO+5Sn1Wlwore0qKHnQ6DvRVLy79CfW9ncBIXg6gshiuzDBaSu7bUN34vWo1 GJu6i0EAVwAEaMb/KYoMdzbunnnctOGPTTFanyRNLwhIRltQr2hWa1PfXRyjuHQ5s1eZ/G1Urxga 0FSFJv15p5jXh+2nVJWuiowuYEux1ucmhg4DQPDO9uTLLgUnPXLQe25Jh2iqq5egzPzne9sWT+zf 1S/gy7u4XkK8/DShTVs/ak+Kia+rKJigQaKhUfd3udiVGKpA4RnTZQ6cg6h+ZGTQvitmBDOUyxgR tpPPN1Rp5WKa79tU8OsAAAAAAAA= --Apple-Mail-6--920526341-- --===============0187569466== 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 --===============0187569466==-- From nsis-bounces@ietf.org Wed Feb 22 04:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqO9-0007Gq-89; Wed, 22 Feb 2006 04:34:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqO7-0007Gi-7Y for nsis@ietf.org; Wed, 22 Feb 2006 04:34:23 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBqO5-0001YD-Jv for nsis@ietf.org; Wed, 22 Feb 2006 04:34:23 -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 k1M9YAoh019409; Wed, 22 Feb 2006 09:34:11 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] NATFW NSLP Issue 66: Possibility of NOTIFY storms Date: Wed, 22 Feb 2006 09:34:09 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Thread-Index: AcY3jRZ8BP/j5usrQDKc8UBecLRfhQABZE3g From: "Hancock, Robert" To: "Martin Stiemerling" , "nsis" 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: 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 martin, a tiny tweak: > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: 22 February 2006 08:04 > To: nsis > Subject: Re: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms >=20 >=20 > Hi, >=20 > I have noticed that the references to the appropriate=20 > sections in the =20 > NTLP were missing, after sending the text proposal for issue 66. >=20 > Here is the reworked proposal: >=20 > NATFW NSLP forwarders, keeping multiple signaling sessions at the > same time, can experience problems when shutting down service > suddenly. This sudden shutdown can be result of node locale failure, > for instance, due to a hardware failure. This NF generates NOTIFY > messages for each of the signaling sessions and tries to send them > upstream. Due to the amount of NOTIFY messages the shutdown of the > node may be unnecessarily prolonged, since not all messages can be > send at the same time. This case can be described as a NOTIFY storm, > if a multitude of signaling sessions is involved. >=20 > 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 bound to the messaging association where this ^^^^^^^^^^^^^^^^^^^^^ i think it would be better to phrase it as 'all signalling sessions from that peer matching the MRI'. the NSLP doesn't what what sessions are bound to the MA (indeed, sessions aren't really bound to MAs - indeed, NSLPs aren't even supposed to know that MAs exist in the first place). r. > NOTIFY has been received as void. >=20 > [1] refers to the NTLP. >=20 > Regards, >=20 > Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 22 05:41:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBrRT-0001ox-0W; Wed, 22 Feb 2006 05:41:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBrRR-0001op-DX for nsis@ietf.org; Wed, 22 Feb 2006 05:41:53 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBrRQ-0004XT-Vx for nsis@ietf.org; Wed, 22 Feb 2006 05:41: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 k1MAffoh005260; Wed, 22 Feb 2006 10:41:42 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] Problem with NAT-Traversal object Date: Wed, 22 Feb 2006 10:41:41 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Problem with NAT-Traversal object Thread-Index: AcY21fPpBS0q643hQV2FrE473D0CogAxm3+A From: "Hancock, Robert" To: "Christian Dickmann" , 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: 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 christian, you are probably right that this could be clarified, including the object as optional in 5.1 with a forward reference to 7.2. (this applies to both the query and response messages.) i've opened an new issue #104 to remind me of this when the time comes. cheers, robert h. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 21 February 2006 10:53 > To: nsis@ietf.org > Subject: [NSIS] Problem with NAT-Traversal object >=20 >=20 > Hi Robert, >=20 > I have a question regarding NAT Traversal in GIST ID 09.=20 > Section 5.1 tells me "The objects following the common header=20 > MUST be carried in a fixed order, depending on message type." > and for GIST-Reponse it states: >=20 > GIST-Response =3D Common-Header > Message-Routing-Information > Session-Identification > ... >=20 >=20 > Now I had a look at section 7.2 regarding NAT Traversal and > how to handle the NAT traversal object. There the draft states: > "It MUST also include the NAT-Traversal object as the first=20 > object in the Response after the common header." >=20 > I wonder, why you did not include the NAT-Traversal object > in section 5.1. One reason might be, that you think of=20 > NAT-Traversal as an optional advanced feature of GIST. > But I think if this is the case the NAT Traversal section > should not change basic behaviour of section 5.1. > Reading section 5.1 one could take for granted, that=20 > you can expect the MRI to be the first object in any=20 > case.=20 >=20 > I suggest to include NAT Traversal in section 5.1 as > an optional object. I guess the rational for making > the NAT traversal object the first one after the common > header is that it is a kind of "replace" for the normal > MRI? The spec would therefore look like: >=20 > GIST-Response =3D Common-Header > [ NAT-Traversal ] > Message-Routing-Information > Session-Identification > ... >=20 >=20 > Christian Dickmann >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 22 09:49:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvId-00084r-Hl; Wed, 22 Feb 2006 09:49:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvId-00084m-5g for nsis@ietf.org; Wed, 22 Feb 2006 09:49:03 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvIc-0006l1-MO for nsis@ietf.org; Wed, 22 Feb 2006 09:49:03 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5CA391BAC4D; Wed, 22 Feb 2006 15:50:36 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <3A068C4F-2474-48B9-965B-E2E019EABEEC@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms Date: Wed, 22 Feb 2006 15:48:58 +0100 To: "Hancock, Robert" X-Mailer: Apple Mail (2.746.2) 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: , Content-Type: multipart/mixed; boundary="===============0082920455==" Errors-To: nsis-bounces@ietf.org --===============0082920455== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14--896217817; protocol="application/pkcs7-signature" --Apple-Mail-14--896217817 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Robert, Am 22.02.2006 um 10:34 schrieb Hancock, Robert: [snip] > 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 bound to the messaging association where this > ^^^^^^^^^^^^^^^^^^^^^ > > i think it would be better to phrase it as 'all signalling sessions > from > that peer matching the MRI'. the NSLP doesn't what what sessions are > bound > to the MA (indeed, sessions aren't really bound to MAs - indeed, NSLPs > aren't > even supposed to know that MAs exist in the first place). Yes, true. I have replaced the phrase by your suggestion. It reads now: [...] '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. Thanks, Martin > > r. > >> NOTIFY has been received as void. >> >> [1] refers to the NTLP. >> >> Regards, >> >> Martin --Apple-Mail-14--896217817 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDIyMjE0NDg1OVowIwYJKoZIhvcNAQkEMRYEFM3Zerj4ai/6kpO83p1e Mb9r4cFmMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAHO7gUfrVWTMpojtaKW0 n/WOTuVeMqmJcKDWpjPcGIwhvK4LgnEreOkhi3vbhlX6xi+Nf6HC/Li3aZX/H1Zei1lncRg37fEi 64JAwJcUwbmAAB8+MPyEnNAChiNnGMbRuuCr4TfLC+NtQWkrbonqd74cCPh9kUKpYtpbpK2utoz2 OeHsZ7IM8UUAJlVtdkH3Xm17rU/pOjCAp3YKy5sECtHvsm/UKq9IniMtaM8eHwOv69E0hIVGJhpf l+4+awMwKEKZ4vnxrAXPV8YfRI0h4y+71sGjGrq7Yh/l1DBpoKWSHKQ0bsmT5fPM+Ch4Xverr0fW NTOFSpgtL6uXi6hu0hgAAAAAAAA= --Apple-Mail-14--896217817-- --===============0082920455== 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 --===============0082920455==-- From nsis-bounces@ietf.org Thu Feb 23 06:03:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCEGL-0001kA-Jr; Thu, 23 Feb 2006 06:03:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCEGL-0001k5-7k for nsis@ietf.org; Thu, 23 Feb 2006 06:03:57 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCEGI-0004kv-Ul for nsis@ietf.org; Thu, 23 Feb 2006 06:03:57 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 84F5A1BAC4D for ; Thu, 23 Feb 2006 12:05:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <73E6D045-BCDA-4312-A44F-6C06C58CF8F4@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Thu, 23 Feb 2006 12:03:50 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [NSIS] NATFW NSLP CLOSED Issue 66: Possibility of notification storms X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 NATFW NSLP Issue 66 "Possibility of notification storms" has been closed. https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66 Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 23 08:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCG5L-0006M5-Ee; Thu, 23 Feb 2006 08:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCG5K-0006Ls-J7 for nsis@ietf.org; Thu, 23 Feb 2006 08:00:42 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCG5K-0008KU-8E for nsis@ietf.org; Thu, 23 Feb 2006 08:00:42 -0500 Received: from elena (unknown [10.0.12.112]) by mailing.unile.it (Postfix) with SMTP id 548F2104B66 for ; Thu, 23 Feb 2006 14:00:41 +0100 (CET) Message-ID: <001301c63870$c3ab64c0$700c000a@elena> From: "Elena Scialpi" To: Date: Thu, 23 Feb 2006 13:00:10 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [NSIS] new draft "Semi-Proactive QoS Re-establishment" X-BeenThere: nsis@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="===============1355006445==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1355006445== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C63879.13D8A040" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C63879.13D8A040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We have submitted an a new draft "Semi-Proactive QoS Re-establishment". = It can be found at http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt Abstract Re-establishment of QoS after a Mobile Node handover must be done=20 as quickly as possible in order to reduce degradation or=20 interruption of QoS. It is specifically useful if real-time=20 applications are used. We propose a Semi-Proactive procedure for QoS re-establisment that=20 also avoids waste of resources.=20 Moreover, we propose a new point of buffering for the packets=20 destined to the Mobile Node during the handover. This is useful when=20 QoS is required for these packets. Any comments or suggestions are very much appreciated. Thanks and regards, Elena Scialpi ------=_NextPart_000_000C_01C63879.13D8A040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

Hi all,

We have submitted an a new draft "Semi-Proactive QoS = Re-establishment". It can be found at
http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.t= xt
 
 
Abstract

   Re-establishment of QoS after a Mobile = Node=20 handover must be done
   as quickly as possible in order = to reduce=20 degradation or
   interruption of QoS. It is specifically = useful=20 if real-time
   applications are used.
   We = propose=20 a Semi-Proactive procedure for QoS re-establisment that
   = also=20 avoids waste of resources.
   Moreover, we propose a new = point of=20 buffering for the packets
   destined to the Mobile Node = during=20 the handover. This is useful when
   QoS is required for = these=20 packets.


Any comments or = suggestions are very=20 much appreciated.

Thanks and regards,
Elena=20 Scialpi
------=_NextPart_000_000C_01C63879.13D8A040-- --===============1355006445== 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 --===============1355006445==-- From nsis-bounces@ietf.org Fri Feb 24 04:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZfi-00020q-7j; Fri, 24 Feb 2006 04:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZff-00020V-Iv for nsis@ietf.org; Fri, 24 Feb 2006 04:55:32 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZfc-0004wf-5i for nsis@ietf.org; Fri, 24 Feb 2006 04:55:31 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 837321BAC4D for ; Fri, 24 Feb 2006 10:57:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <10352744-54AB-4468-A301-EF165654A16C@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Fri, 24 Feb 2006 10:55:22 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [NSIS] NATFW Issue 60: Signaling for ICMP policy rules X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 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 From nsis-bounces@ietf.org Mon Feb 27 04:26:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDeeb-0002kd-Hr; Mon, 27 Feb 2006 04:26:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDeea-0002kJ-2j for nsis@ietf.org; Mon, 27 Feb 2006 04:26:52 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDeeX-0002Mf-7G for nsis@ietf.org; Mon, 27 Feb 2006 04:26:52 -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 <0IVC0058UA8NT3@mailout2.samsung.com> for nsis@ietf.org; Mon, 27 Feb 2006 18:26:47 +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 <0IVC004T0A8NA9@mmp1.samsung.com> for nsis@ietf.org; Mon, 27 Feb 2006 18:26:47 +0900 (KST) Date: Mon, 27 Feb 2006 18:26:46 +0900 From: Sung-Hyuck Lee To: "Kappler, Cornelia" Message-id: <000501c63b7f$ee3edb60$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: <391E6FBF5E786940B9E2F7CA6376C708012F526A@blns00fa.ww002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: nsis@ietf.org Subject: [NSIS] Re: NSIS & Mobility X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia, Sorry for too much late response. Thank you for your valuable comments. Please refer to my comments in line (SHL). Warm regards, Sung-Hyuck ----- Original Message ----- From: "Kappler, Cornelia" To: "Seong-Ho Jeong" ; Cc: Sent: Friday, January 13, 2006 3:20 AM Subject: NSIS & Mobility > > Hi Sung-Hyuck and Seong-Ho, and other "NSIS & Mobility" authors, > > recently I've been studying your draft > http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobili > ty-signaling-03.txt and have some questions: > > Apparently you are proposing three enhancement to the existing NSIS > protocols. I am not sure they are necessary, see below. Furthermore - > and this is another main feedback - it should be made very clear in the > draft where you are proposing new things, and where you are discussing > already existing NSIS features. Very helpful would be a conclusion > section that states "this draft proposes the following enhancements to > the GIST and NSLP specifications.. " > > - "CD flag bit" (Sec. 5.1.4.1). I think this is set by the Crossover > Node (CRN) when it discovers it is the CRN. Appart from the name (bit > AND flag is redundant), I dont understand what the use is of this flag. > (i) Is it to prevent other NEs to wrongly think they are the CRN? I dont > think so: To my understanding a CRN identifies itself as being the CRN > because it has two interfaces to which the same session seems to be > incoming/outgoing, with a different flow ID attached to each interface. > There is no danger of any NE wrongly thinking it might be the CRN. This > situation is not changed in tunnelling scenarios. [SHL] CD flag bit can be used to prevent NEs to unnecessarily perform CRN discovery processing, not to incorrectly perceive it is CRN. Actually, IMO, CRN Discovery flag is more useful in the case of multihoming. In the multihoming scenarios, several CRNs can be discovered because of multiple paths. In this case, which CRN is in charge of State Update should be considered. > (ii) Is it to inform the NI or NR (or NEs) that the CRN has been found? > I dont think NEs in general are interested in this information. The NI > may have use for this in order to start tearing down the reservation > along the old section of the path. However I am not sure we are at all > considering this scenario (the NI initiating the tear down), > particularly since the NI may not be able to access the old path anymore > because it moved to a new access router. [SHL] In the case of NI's handover, the old access router (AR) can be in charge of a role of proxying the NI (the mobile node). If the scenario that NI initiates teardown messages to remove the old state on the old path needs to be considered, the old AR as a proxy of the NI needs to tear down the old states on the old path. > - "NSLP_Br_ID" (Sec 4.2.2). This is an identifier for identifying > different branches of the same session on a given NE (i.e. a CRN). I > think this is redundant information. On GIST level, differnent branches > are already identified by different Message Routing State (i.e. the next > / previous NSIS peers are different). It is interesting though that for [SHL] You seem to misunderstand the identifier, NSLP_Br_ID. As you mentioned, the different branches were made by the processing of Message Routing State. We don't need to make an explicit identifier for CRN discovery. That is, NSLP_Br_ID is just a name representing those branches that are made by the processing of Message Routing State. > the CRN the table containing message routing state may need two entries > for next/previous NSIS peer for a single session, as long as the old > section of the path is not yet torn down. Even if the branch identifier [SHL] Yes. IMO, the table is also necessary to tear down the old state on the old path. > was useful it doesnt seem clear who sets it, i.e. which node determines > it is currently signaling along a new branch for an existing NSIS > session. Finally, it seems to me two branches for one session should be > a rather transient phenomenon. I.e. only one of them should really be > active at a given time. [SHL] As mentioned, the NSLP_Br_ID is created by the processing of Message Routing Association between two NSIS nodes. Which branch is new can be identified by the counter value of NSLP_Br_ID. For example, as shown in Figure 2 of the mobility draft, each NSLP_Br_ID has a value of counter: #1, or #2. This value enables which signaling messages are new or old. Flow_ID can also be used to distinguish signaling messages. If any explicit tear-down message is not used to remove the old states, there can exist two more states or signaling messages at CRN. > - "mobility object" (Sec 4.2.2). This is included (by the NI?) to alert > some other node (which?) that a mobility event took place. It is defined > to "expedite CRN discovery" - how? Why would the discovery be more > rapid? Such an object may indeed be useful, however the motivation given [SHL] In scenarios of ping-pong type handover, which node is CRN can more easily be determined if mobility_event_counter (MEC) field of Mobility Object is used. Eventually, it can expedite the CRN discovery and State Update in mobility environments. > relates mostly to solving the problem of ping-pong type handover which I > am not sure is such an urgent problem to solve. Another motivation is [SHL] Sure, the ping-pong type handover-related issues may not be critical. This is why the authors of the mobility draft think of the Mobility Object as optional parts. Please the see the last paragraph of Section 4.2.2. > (Sec. 5.5) apparently preventing time out of a session during the time a > mobile node is performing the handover. Is the idea that before handover > starts, the mobile node includes this object in order to inform all NEs > that they should not tear down the state even if the next refresh fails? > Probably it would be sufficient to inform the access router, because it > can reply to refreshes. No need to inform all NEs. But even if you > restrict it to the access router, I am sure there are security problems > with it (DoS attacks etc). Or may be I'be been misinterpreting your > intention. [SHL] As you mentioned, Handover_Init (HI) field of the Mobility identifier can be used to resolve the last node detection-related issue. IMO, the message including HI field needs to be sent to CRN from the old AR if adjusting the timer value of soft state is required. That is, If it is difficult to use any explicit teardown message due to the authorization-related issues with teardown described in Section 3.2.2 (3), an appropriate timer value of soft state needs to be set at nodes on the old path to alleviate the double reservation problem. Concerning DoS attacks, more clarification seems to be needed. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 27 05:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfOK-0003bP-2D; Mon, 27 Feb 2006 05:14:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfOJ-0003bK-9g for nsis@ietf.org; Mon, 27 Feb 2006 05:14:07 -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 1FDfOI-0003fx-IQ for nsis@ietf.org; Mon, 27 Feb 2006 05:14:07 -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 k1RAE5s6025851 for ; Mon, 27 Feb 2006 19:14:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k1RAE6p07150 for ; Mon, 27 Feb 2006 19:14:06 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id k1RAE5d16253 for ; Mon, 27 Feb 2006 19:14:05 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Date: Mon, 27 Feb 2006 18:13:02 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDB23EE2@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Thread-Index: AcYy7v+HT+4uGE3WTlCMLM1J6SWp1QEe9ByQAQafeTAAAD/2gA== From: "Shivanajay Marwaha" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 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.=20 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.=20 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.=20 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. Best regards, Shivanajay (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) -----Original Message----- From: Seong-Ho Jeong [mailto:shjeong@hufs.ac.kr] Sent: Wednesday, February 22, 2006 1:35 PM To: Shivanajay Marwaha; 'Sung-Hyuck Lee'; fu@cs.uni-goettingen.de; Hannes.Tschofenig@siemens.com; jmanner@cs.helsinki.fi Cc: nsis@ietf.org Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Hi Shivanajay, Thanks for your comments. Please see my comments inline. Regards, Seong-Ho >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of >Shivanajay Marwaha >Sent: Thursday, February 16, 2006 8:49 PM >To: Seong-Ho Jeong; Sung-Hyuck Lee; fu@cs.uni-goettingen.de;=20 >Hannes.Tschofenig@siemens.com; jmanner@cs.helsinki.fi >Cc: nsis@ietf.org >Subject: [NSIS] Some More Suggestions on Multi-homing (section >5.2.5) ofMobility Draft > >Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and=20 >other NSIS WG members, >=20 >Some more comments on Multi-homing section in Mobility draft:- >=20 >-------------------------------------------------------------------- >Comment 1:- Section 5.2.5, Change title to "Host multihoming" >=20 >Discussion - >We think that the above title would be more meaningful if it's changed=20 >to Host Multihoming, since Issue discussed here applies to host=20 >multihoming in general (where multiple connection between MN and CN are >possible, either via different physical interfaces or a single=20 >interface). So, the discussion in this section should not be limited to >load balancing, which is just a use case of multihoming. In view of=20 >this, the title "Host multihoming" would be more suitable. This subsection is not the only one which discusses host multihoming. Other subsections in Section 5.2 are also related to host multihoming.=20 >=20 >------------------------------------------------------------------- >=20 >Comment 2:- Section 5.2.5, reference to external drafts >=20 >Original Text -=20 > "There may be a situation where an MN may need to distribute its=20 >traffic load to multiple paths via multiple interfaces. In this case,=20 >the MN can send multiple QUERY messages to multiple interfaces to=20 >establish NSIS state on multiple paths." >=20 >Discussion - >As load balancing represents only one of the many reasons for doing=20 >multihoming, for better understanding, it is better to refer to the=20 >draft "Goals and Benefits of Multihoming" >(draft-ernst-generic-goals-and-benefits-02). So we suggest to replace=20 >the above paragraph of section 5.2.5 with following text:- > >Suggested Text:- > "There may be a situation where an MN may need to distribute its=20 >traffic load to multiple paths via multiple interfaces. In this case,=20 >the MN can send multiple QUERY messages to multiple interfaces to=20 >establish NSIS state on multiple paths. There are many other scenarios=20 >and applications in multi-homing as mentioned in [x] ". >[x] Goals and Benefits of Multihoming >draft-ernst-generic-goals-and-benefits-02 I also think that it would be good to mention the draft as a relevant reference. We already have the reference in the References section although the version needs to be changed. >=20 >-------------------------------------------------------------------- >=20 >Comment 3:- Section 5.2.5, 2nd para: add description on mobility=20 >problem with multihoming >=20 >Original Text -=20 > " Suppose that an MN wants to set up NSIS state on a path which is=20 >able to support the specific bandwidth requirement for a certain=20 >application in the multihomed environment. It may not be possible to=20 >find a feasible path for such a requirement. In this case, multiple=20 >paths can be used at the same time so that the bandwidth requirement=20 >can be met. Note that the flow identifier on each path may be=20 >different although the session identifier is unchanged. " >=20 >Discussion - >With the scenario described above, there would be a problem for NSIS=20 >signalling when mobility happens. Please refer to draft "Path type=20 >support for NSIS signalling" >(draft-sanda-nsis-path-type-03.txt) for details of the problem=20 >analysis. So we suggest inserting the following paragraph after the 2nd >paragraph of section 5.2.5:- >=20 >Suggested Text:- >"When multiple paths are used for the same session, mobility support=20 >may pose a problem for the NSIS signalling. For example, if Path-1 and >Path-2 are used for the same session, signalling for these two paths=20 >would use different flow identifier, say FID-1 and FID-2, with the same >session identifier, say SID. In the case a mobility event causes the >Path-1 to be replaced by Path-3 for communication, signalling for the >Path-3 will be also using a different flow identifier, say FID-3, and=20 >the same session identifier, SID. With this, current NSIS signalling=20 >may fail, e.g. CRN discovery, and tearing of the old path. This is due=20 >to the lack of information to differentiate Path-1 from Path-2. Detail=20 >analysis of the problem can be find in draft [x] [x] "Path type support >for NSIS signalling" >(draft-sanda-nsis-path-type-03.txt) Could you clarify further why the current CRN discovery may fail? > >=20 >Regards, >Shivanajay >(On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) > >_______________________________________________ >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 Feb 27 08:05:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDi4I-0004iw-8H; Mon, 27 Feb 2006 08:05:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfMK-0002L9-Vv for nsis@ietf.org; Mon, 27 Feb 2006 05:12:04 -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 1FDfMK-0003ar-8R for nsis@ietf.org; Mon, 27 Feb 2006 05:12:04 -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 k1RAAes6023096; Mon, 27 Feb 2006 19:10:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k1RAAfp05963; Mon, 27 Feb 2006 19:10:41 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k1RAAeT18273; Mon, 27 Feb 2006 19:10:40 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Date: Mon, 27 Feb 2006 18:09:26 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDB23EDF@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Thread-Index: AcYy7v+HT+4uGE3WTlCMLM1J6SWp1QEe9ByQAQafeTA= From: "Shivanajay Marwaha" To: "Seong-Ho Jeong" , "Sung-Hyuck Lee" , , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-Mailman-Approved-At: Mon, 27 Feb 2006 08:05:37 -0500 Cc: Takako Sanda , Toyoki Ue , Pek Yew Tan , nsis@ietf.org, Cheng Hong X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 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.=20 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.=20 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.=20 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. Best regards, Shivanajay=20 (On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) -----Original Message----- From: Seong-Ho Jeong [mailto:shjeong@hufs.ac.kr]=20 Sent: Wednesday, February 22, 2006 1:35 PM To: Shivanajay Marwaha; 'Sung-Hyuck Lee'; fu@cs.uni-goettingen.de; Hannes.Tschofenig@siemens.com; jmanner@cs.helsinki.fi Cc: nsis@ietf.org Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) ofMobility Draft Hi Shivanajay, Thanks for your comments. Please see my comments inline. Regards, Seong-Ho >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of >Shivanajay Marwaha >Sent: Thursday, February 16, 2006 8:49 PM >To: Seong-Ho Jeong; Sung-Hyuck Lee; fu@cs.uni-goettingen.de;=20 >Hannes.Tschofenig@siemens.com; jmanner@cs.helsinki.fi >Cc: nsis@ietf.org >Subject: [NSIS] Some More Suggestions on Multi-homing (section >5.2.5) ofMobility Draft > >Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and=20 >other NSIS WG members, >=20 >Some more comments on Multi-homing section in Mobility draft:- >=20 >-------------------------------------------------------------------- >Comment 1:- Section 5.2.5, Change title to "Host multihoming" >=20 >Discussion - >We think that the above title would be more meaningful if it's changed=20 >to Host Multihoming, since Issue discussed here applies to host=20 >multihoming in general (where multiple connection between MN and CN are >possible, either via different physical interfaces or a single=20 >interface). So, the discussion in this section should not be limited to >load balancing, which is just a use case of multihoming. In view of=20 >this, the title "Host multihoming" would be more suitable. This subsection is not the only one which discusses host multihoming. Other subsections in Section 5.2 are also related to host multihoming.=20 >=20 >------------------------------------------------------------------- >=20 >Comment 2:- Section 5.2.5, reference to external drafts >=20 >Original Text -=20 > "There may be a situation where an MN may need to distribute its=20 >traffic load to multiple paths via multiple interfaces. In this case,=20 >the MN can send multiple QUERY messages to multiple interfaces to=20 >establish NSIS state on multiple paths." >=20 >Discussion - >As load balancing represents only one of the many reasons for doing=20 >multihoming, for better understanding, it is better to refer to the=20 >draft "Goals and Benefits of Multihoming" >(draft-ernst-generic-goals-and-benefits-02). So we suggest to replace=20 >the above paragraph of section 5.2.5 with following text:- > >Suggested Text:- > "There may be a situation where an MN may need to distribute its=20 >traffic load to multiple paths via multiple interfaces. In this case,=20 >the MN can send multiple QUERY messages to multiple interfaces to=20 >establish NSIS state on multiple paths. There are many other scenarios=20 >and applications in multi-homing as mentioned in [x] ". >[x] Goals and Benefits of Multihoming >draft-ernst-generic-goals-and-benefits-02 I also think that it would be good to mention the draft as a relevant reference. We already have the reference in the References section although the version needs to be changed. >=20 >-------------------------------------------------------------------- >=20 >Comment 3:- Section 5.2.5, 2nd para: add description on mobility=20 >problem with multihoming >=20 >Original Text -=20 > " Suppose that an MN wants to set up NSIS state on a path which is=20 >able to support the specific bandwidth requirement for a certain=20 >application in the multihomed environment. It may not be possible to =20 >find a feasible path for such a requirement. In this case, multiple=20 >paths can be used at the same time so that the bandwidth requirement=20 >can be met. Note that the flow identifier on each path may be=20 >different although the session identifier is unchanged. " >=20 >Discussion - >With the scenario described above, there would be a problem for NSIS=20 >signalling when mobility happens. Please refer to draft "Path type=20 >support for NSIS signalling" >(draft-sanda-nsis-path-type-03.txt) for details of the problem=20 >analysis. So we suggest inserting the following paragraph after the 2nd >paragraph of section 5.2.5:- >=20 >Suggested Text:- >"When multiple paths are used for the same session, mobility support=20 >may pose a problem for the NSIS signalling. For example, if Path-1 and=20 >Path-2 are used for the same session, signalling for these two paths=20 >would use different flow identifier, say FID-1 and FID-2, with the same >session identifier, say SID. In the case a mobility event causes the >Path-1 to be replaced by Path-3 for communication, signalling for the=20 >Path-3 will be also using a different flow identifier, say FID-3, and=20 >the same session identifier, SID. With this, current NSIS signalling=20 >may fail, e.g. CRN discovery, and tearing of the old path. This is due=20 >to the lack of information to differentiate Path-1 from Path-2. Detail=20 >analysis of the problem can be find in draft [x] [x] "Path type support >for NSIS signalling" >(draft-sanda-nsis-path-type-03.txt) Could you clarify further why the current CRN discovery may fail? > >=20 >Regards, >Shivanajay >(On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong) > >_______________________________________________ >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 Feb 28 02:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDzdM-0005S0-OD; Tue, 28 Feb 2006 02:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDzdL-0005Rg-BG for nsis@ietf.org; Tue, 28 Feb 2006 02:50:59 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDzdJ-00013T-S1 for nsis@ietf.org; Tue, 28 Feb 2006 02:50:59 -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 <0IVE001IL0GVPN@mailout1.samsung.com> for nsis@ietf.org; Tue, 28 Feb 2006 16:50:55 +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 <0IVE00MRN0GVLH@mmp1.samsung.com> for nsis@ietf.org; Tue, 28 Feb 2006 16:50:55 +0900 (KST) Date: Tue, 28 Feb 2006 16:50:55 +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: <002901c63c3b$b481a490$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: <5F09D220B62F79418461A978CA0921BDB23EE2@pslexc01.psl.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Shivanajay, Please refer to my comments. Thanks, Sung-Hyuck ----- Original Message ----- From: "Shivanajay Marwaha" To: Sent: Monday, February 27, 2006 7:13 PM Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft > 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. > 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. What do you think differences between Path type and CD flag? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 28 03:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE0AO-0003aT-Kk; Tue, 28 Feb 2006 03:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE0AO-0003aO-1P for nsis@ietf.org; Tue, 28 Feb 2006 03:25:08 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE0AL-0002XI-Jd for nsis@ietf.org; Tue, 28 Feb 2006 03:25:08 -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 <0IVE008IA21P6I@mailout2.samsung.com> for nsis@ietf.org; Tue, 28 Feb 2006 17:25:01 +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 <0IVE002C721PJ6@mmp2.samsung.com> for nsis@ietf.org; Tue, 28 Feb 2006 17:25:01 +0900 (KST) Date: Tue, 28 Feb 2006 17:25:00 +0900 From: Sung-Hyuck Lee Subject: Re: [NSIS] Re: Section 3 of Mobility Applicability Draft To: Takako Sanda Message-id: <000b01c63c40$77d72600$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: <5F09D220B62F79418461A978CA0921BDAC691A@pslexc01.psl.local> <007401c63691$6edca6b0$f95b024b@LocalHost> <20060221122228.6F24.SANDA.TAKAKO@jp.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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, Thank you for your comment. The authors of the mobility draft will refer to your comment. I'm reviewing the mobility draft based on your comment again. Warm regards, Sung-Hyuck ----- Original Message ----- From: "Takako Sanda" To: "Sung-Hyuck Lee" Cc: "Shivanajay Marwaha" ; Sent: Tuesday, February 21, 2006 12:33 PM Subject: Re: [NSIS] Re: Section 3 of Mobility Applicability Draft > Dear Sung-Hyuck, > > > > Comment/Suggestion - Does the above "upstream and downstream" flow refer > > > to data or > > > signalling? As such in path coupled signalling, there shouldn't be > > > any difference between upstream and downstream paths. So, if it is > > > directly addressed there may be an issue, if it is hop-hop address, > > > there may not be any issue as they should follow the same path. > > > > [SHL] This text describes the direction of NSIS signaling. The route of NSIS > > signaling initiated from sender may be different that of NSIS signaling > > initiated from receiver. This is also similar to the case of bidirectional > > reservation. > > We need to clarify the terms "upstream" and "downstream" for signaling. > > In the GIST draft > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-09.txt), the > terms are defined as: > Downstream: In the same direction as the data flow. > Upstream: In the opposite direction to the data flow. > But in the Applicability draft, these terms seem to be used as: > Downstream: Signaling (or data) from CN to MN > Upstream: Signaling (or data) from MN to CN > This difference makes confusion. > I think the terminologies should be unified in NSIS WG drafts. > > BR, > Takako > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 28 05:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2M1-0003iD-9K; Tue, 28 Feb 2006 05:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2Lz-0003i2-PQ for nsis@ietf.org; Tue, 28 Feb 2006 05:45:15 -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 1FE2Lz-0006Sg-3I for nsis@ietf.org; Tue, 28 Feb 2006 05:45:15 -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 k1SAhns6002290; Tue, 28 Feb 2006 19:43:49 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k1SAhq901828; Tue, 28 Feb 2006 19:43:52 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id k1SAhpV26025; Tue, 28 Feb 2006 19:43:51 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft Date: Tue, 28 Feb 2006 18:42:27 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDB240F4@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft Thread-Index: AcY8O5KWpEMiM560TeicK0xUU7ZgKQAFvJEw From: "Shivanajay Marwaha" To: , "Seong-Ho Jeong" , "Sung-Hyuck Lee" X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: fu@cs.uni-goettingen.de, jmanner@cs.helsinki.fi, Pek Yew Tan , 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 Dear Sung-Hyuck, Thanks for your reply. Please see my comments inline [SHIV]. Thanks, Shivanajay =20 > -----Original Message----- > From: Sung-Hyuck Lee [mailto:starsu.lee@samsung.com]=20 > Sent: Tuesday, February 28, 2006 3:51 PM > To: Shivanajay Marwaha; nsis@ietf.org > Subject: Re: [NSIS] Some More Suggestions on Multi-homing=20 > (section 5.2.5)ofMobility Draft >=20 > Hi Shivanajay, > =20 > Please refer to my comments. > =20 > Thanks, > =20 > Sung-Hyuck > =20 > ----- Original Message ----- > From: "Shivanajay Marwaha" > To: > Sent: Monday, February 27, 2006 7:13 PM > Subject: RE: [NSIS] Some More Suggestions on Multi-homing=20 > (section 5.2.5)ofMobility Draft >=20 > > Dear Seong-Ho, > > > >Thanks for your reply. Regarding your question on CRN =20 > >operation/discovery failure, we are actually referring to=20 > the mobility =20 > >scenario when multiple interfaces are used for one session=20 > (e.g. load =20 > >balancing as indicated in section 5.2.5 of the mobility=20 > applicability =20 > >draft). Detailed description of the issue is as > > following: > >=20 > > As described in Section 5.2.5, 2nd paragraph of the mobility draft,=20 > > the MN is using two paths for the same session (i.e. Path 1=20 > and Path=20 > > 2). In this case, as suggested by section 5.2.5 of the=20 > mobility draft,=20 > > same Session ID with different Flow IDs will be used for=20 > the two paths. > >=20 > > When one of these paths (Path 2) experiences a mobiity event, e.g. > > one of the multiple interfaces of the MN handovers to=20 > another network,=20 > > a new path is resulted, i.e. Path 3. Yet, NSIS will use the same=20 > > Session ID with a new Flow ID for this path. Therefore, two=20 > types of=20 > > CRNs will now exist:- CRN for Path 1 and Path 3; and CRN=20 > for Path 2 and Path 3. > > > > If the NSIS signaling over Path 3 triggers a CRN discovery, the CRN=20 > > discovery may lead to discovery of a QNE which is a CRN for=20 > path 1 and=20 > > Path 3 only, instead of correctly identifying a QNE which=20 > is a CRN for=20 > > Path 2 and Path 3. This is because the current NSIS CRN Discovery=20 > > Procedure does not provide information about whether a CRN=20 > is caused=20 > > by the mobility event or multiple interfaces. >=20 > [SHL] "CD (CRN_Discovery) flag" described in Section 5.1.4.1=20 > can solve this issue because the CD flag can prevent NEs to=20 > incorrectly perform the process of CRN discovery. For=20 > example, once CRN between Path 2 and Path 3 is discovered,=20 > the CD flag is set and thus downstream NEs don't perform the=20 > process of CRN discovery. Therefore, the CRN discovery=20 > between Path 1 and Path 3 doesn't occur. > =20 > After handover, if a merging point between Path 1 and Path 3=20 > exists before the CRN between Path 2 and Path 3, the merging=20 > point between Path 1 and Path 3 becomes CRN and thus 'CD=20 > flag' is set. The existing CRN (as downstream NE of the CRN=20 > btw Path 1 and Path 3) between Path 1 and Path 2 can remove=20 > the old state on the Path 2 when it checks the CD flag=20 > included in NSIS signaling message from upstream NEs. In this=20 > case, the existing CRN needs to remove the old state through=20 > 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. 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. =20 >=20 > > The problem encountered in this case is that the discovered=20 > CRN would=20 > > have no information to decide its proper action (whether it is a=20 > > mobility event, or it's a multihoming case). There is a=20 > more thorough=20 > > 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=20 > > mobility draft as this scenario is very common and=20 > realistic. The text=20 > > sent earlier provides a brief description of this problem.=20 > If there=20 > > is a need for further clarification on this problem, we can provide=20 > > more/amended text for that. > =20 > [SHL] I think this issue needs to further be discussed in the=20 > 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.=20 > [SHL] What do you think differences between Path type and CD flag? >=20 =20 [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.=20 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.=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 28 17:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FED5m-0005m7-Ss; Tue, 28 Feb 2006 17:13:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FED5l-0005iY-De for nsis@ietf.org; Tue, 28 Feb 2006 17:13:13 -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 1FEC1l-00039M-NR for nsis@ietf.org; Tue, 28 Feb 2006 16:05:03 -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, 28 Feb 2006 23:05:00 +0200 id 0007018D.4404BAFC.0000065D Date: Tue, 28 Feb 2006 23:05:00 +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: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] 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 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