From owner-ietf-ppp-outgoing@merit.edu Fri Mar 2 06:54:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26410 for ; Fri, 2 Mar 2001 06:54:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE0705DDD8; Fri, 2 Mar 2001 06:54:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DC0E95DDD4; Fri, 2 Mar 2001 06:54:15 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 0ECEF5DDD2 for ; Fri, 2 Mar 2001 06:54:14 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26263; Fri, 2 Mar 2001 06:54:12 -0500 (EST) Message-Id: <200103021154.GAA26263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-srp-01.txt Date: Fri, 02 Mar 2001 06:54:12 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP SRP-SHA1 Authentication Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-eap-srp-01.txt Pages : 15 Date : 01-Mar-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an Extensible Authentication Protocol (EAP) [2] framework to allow the use of multiple authentication mechanisms without fixing the mechanism to be used during initial link negotiation. This document defines an authentication mechanism for EAP called SRP-SHA1, and allows the use of the Secure Remote Password (SRP) [3] protocol as a PPP link authentication method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-srp-01.txt 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-pppext-eap-srp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-srp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010301141827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-srp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-srp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141827.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Tue Mar 6 06:58:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08575 for ; Tue, 6 Mar 2001 06:58:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5BAE5DE5A; Tue, 6 Mar 2001 06:51:25 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8DC965DE8C; Tue, 6 Mar 2001 06:51:25 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 0AC345DE5A for ; Tue, 6 Mar 2001 06:51:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07935; Tue, 6 Mar 2001 06:51:21 -0500 (EST) Message-Id: <200103061151.GAA07935@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt Date: Tue, 06 Mar 2001 06:51:21 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over AAL2 Author(s) : B. Thompson, b. Buffam, T. Koren Filename : draft-ietf-pppext-ppp-over-aal2-00.txt Pages : Date : 05-Mar-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt 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-pppext-ppp-over-aal2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <20010305132130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ppp-over-aal2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132130.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Mar 8 03:09:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19999 for ; Thu, 8 Mar 2001 03:09:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 96E2B5DDC2; Thu, 8 Mar 2001 03:09:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A19C5DDBF; Thu, 8 Mar 2001 03:09:21 -0500 (EST) Received: from exchange.Ic4ic.com (unknown [194.90.135.194]) by segue.merit.edu (Postfix) with SMTP id 369725DDB9 for ; Thu, 8 Mar 2001 03:09:16 -0500 (EST) content-class: urn:content-classes:message Subject: RTP/UDP/IP Compression over PPP Date: Thu, 8 Mar 2001 10:07:10 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D3687@exchange.Ic4ic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Thread-Topic: RTP/UDP/IP Compression over PPP Thread-Index: AcCnpsZld9VeXjgETZaTxRBzKI/Uhw== X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Daniel Feldman" To: , "rem-conf" Cc: "Eyal Gutman" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA19999 Does anyone know how to set up a PPP connection for RTP/UDP/IP compressed? I know it is possible to it for TCP/IP compressed. Thanks a lot, ~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Engineer, IC4IC ltd. office: +972-4-9594644 ext. 121 mobile: +972-53-980442 fax: +972-4-9594944 ~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ietf-ppp-outgoing@merit.edu Thu Mar 8 07:36:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23803 for ; Thu, 8 Mar 2001 07:36:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53BA75DDA5; Thu, 8 Mar 2001 07:32:54 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 31A625DEAA; Thu, 8 Mar 2001 07:32:54 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9A4825DDA5 for ; Thu, 8 Mar 2001 07:32:52 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15127; Thu, 8 Mar 2001 04:32:45 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01868; Thu, 8 Mar 2001 07:32:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f28CXJG97407; Thu, 8 Mar 2001 07:33:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15015.31759.318909.361837@gargle.gargle.HOWL> Date: Thu, 8 Mar 2001 07:33:19 -0500 (EST) From: James Carlson To: "Daniel Feldman" Cc: , "rem-conf" , "Eyal Gutman" Subject: Re: RTP/UDP/IP Compression over PPP In-Reply-To: Daniel Feldman's message of 8 March 2001 10:07:10 References: <88BC9E379956AE4DB689CC5FF6F5A43D3687@exchange.Ic4ic.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Daniel Feldman writes: > Does anyone know how to set up a PPP connection for RTP/UDP/IP > compressed? I know it is possible to it for TCP/IP compressed. Are you asking a question about the protocol? If so, then see RFC 2509. If you're asking a question about a particular implementation, then this is the wrong place to ask. Try contacting the manufacturer involved, or a related newsgroup, or search the web. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Mar 9 00:34:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24300 for ; Fri, 9 Mar 2001 00:34:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id F38C95DE19; Fri, 9 Mar 2001 00:31:13 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D18065DE26; Fri, 9 Mar 2001 00:31:12 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 9E78A5DE19 for ; Fri, 9 Mar 2001 00:31:10 -0500 (EST) Received: from kkb3 (kkb3-099.kk.etx.ericsson.se [130.100.99.23]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f295V8d10211 for ; Fri, 9 Mar 2001 06:31:09 +0100 (MET) Received: from ericsson.com.au by kkb3 (SMI-8.6/LME-2.2.6) id GAA10602; Fri, 9 Mar 2001 06:31:05 +0100 Message-ID: <3AA86A94.F391D50B@ericsson.com.au> Date: Fri, 09 Mar 2001 16:31:01 +1100 From: Ian Rytina X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt References: <200103061151.GAA07935@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Bruce/Tmima, I am a bit confused about the use of the UUI code-points in Section 6.1.3 of PPP/AAL2. It is proposed to use the values 1, 3 and 5 to indicate "non-final packet" for the three different types of encapsulation. What is the purpose of these values ? Can't you just use UUI=27 for all of these non-final packet scenarios ? Cheers, Ian. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > Title : PPP over AAL2 > Author(s) : B. Thompson, b. Buffam, T. Koren > Filename : draft-ietf-pppext-ppp-over-aal2-00.txt > Pages : > Date : 05-Mar-01 > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > transporting multi-protocol datagrams over point-to-point links. > This document describes the use of ATM Adaptation Layer 2 (AAL2) for > framing PPP encapsulated packets. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt > > 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-pppext-ppp-over-aal2-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ---------------------------------------------------------------------------------------- From owner-ietf-ppp-outgoing@merit.edu Fri Mar 9 11:32:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20864 for ; Fri, 9 Mar 2001 11:32:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id E377A5DDD2; Fri, 9 Mar 2001 11:30:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0EE5C5DEC9; Fri, 9 Mar 2001 11:30:04 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by segue.merit.edu (Postfix) with ESMTP id 7B0085E143 for ; Fri, 9 Mar 2001 11:25:41 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA12443; Fri, 9 Mar 2001 08:25:44 -0800 (PST) Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AIT14546; Fri, 9 Mar 2001 08:25:38 -0800 (PST) Message-Id: <4.3.1.0.20010309081500.0188d490@mira-sjcm-2.cisco.com> X-Sender: brucet@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 09 Mar 2001 08:28:34 -0800 To: Ian Rytina From: Bruce A Thompson Subject: Re: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt Cc: ietf-ppp@merit.edu In-Reply-To: <3AA86A94.F391D50B@ericsson.com.au> References: <200103061151.GAA07935@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 04:31 PM 03/09/2001 +1100, Ian Rytina wrote: >Hi Bruce/Tmima, > >I am a bit confused about the use of the UUI code-points in >Section 6.1.3 of PPP/AAL2. > >It is proposed to use the values 1, 3 and 5 to indicate "non-final >packet" for the three different types of encapsulation. What is >the purpose of these values ? Can't you just use UUI=27 for all of >these non-final packet scenarios ? Are you looking at the draft that was just submitted? Section 6.1.3 in that draft says the following: >This proposal uses three UUI code-points as follows: > > UUI Code-point Packet Content > ++++++++++++++ ++++++++++++++ > > 27 Long CRC encapsulation, non-final packet. > > 26 Long CRC encapsulation, final packet. > > 25 Short CRC encapsulation. Code point 27 is the only code point we are using to indicate "non-final packet". Both code points 26 and 25 indicate final packet. Bruce T >Cheers, > >Ian. > > >Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > > > Title : PPP over AAL2 > > Author(s) : B. Thompson, b. Buffam, T. Koren > > Filename : draft-ietf-pppext-ppp-over-aal2-00.txt > > Pages : > > Date : 05-Mar-01 > > > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > > transporting multi-protocol datagrams over point-to-point links. > > This document describes the use of ATM Adaptation Layer 2 (AAL2) for > > framing PPP encapsulated packets. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt > > > > 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-pppext-ppp-over-aal2-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > ---------------------------------------------------------------------------------------- Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Sun Mar 11 14:53:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13583 for ; Sun, 11 Mar 2001 14:53:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAE585DE34; Sun, 11 Mar 2001 14:50:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D91FA5DE10; Sun, 11 Mar 2001 14:50:00 -0500 (EST) Received: from smtp.netreach.net (fatuka.netreach.net [207.29.195.121]) by segue.merit.edu (Postfix) with SMTP id 1FE505DE2B for ; Sun, 11 Mar 2001 14:49:59 -0500 (EST) Received: (qmail 18655 invoked by uid 102); 11 Mar 2001 19:50:39 -0000 Received: from static-cc.netreach.net (HELO delbert) (207.29.201.235) by smtp.netreach.net with SMTP; 11 Mar 2001 19:50:39 -0000 Message-Id: <4.2.0.58.20010311144757.00a07ec0@mail2.netreach.net> X-Sender: programs@corecom.com@mail2.netreach.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 11 Mar 2001 14:49:04 -0500 To: ietf-ppp@merit.edu From: TISC Programs Subject: The Internet Security Conference 2001 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The Fifth Internet Security Conference will be held June 4-8, 2001 at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars, Century City Los Angeles, CA 90067-4696. TISC is an educational forum for security professionals and practitioners. TISC Workshops on network security principles, Windows 2000 security, firewall practices, incident response, security systems for the Internet, attack trends and countermeasures, VPNs, and hacking are presented by leading experts in the security community. In addition, over 50 security experts will offer technical advice and present invited papers during the TISC Security Symposium. Topics include Anti-Hacking, IDS, VPNs, Authentication and PKI, web security and privacy, network forensics, LINUX security, wireless security, malware, web threats, and more. To view the complete agenda, visit http://www.tisc2001.com/agenda.html We hope to see you in Los Angeles! The TISC 2001 Program Committee www.tisc2001.com From owner-ietf-ppp-outgoing@merit.edu Mon Mar 12 21:23:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27430 for ; Mon, 12 Mar 2001 21:23:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 700EF5DE73; Mon, 12 Mar 2001 21:19:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 530B35DEC0; Mon, 12 Mar 2001 21:19:14 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 218F35DE73 for ; Mon, 12 Mar 2001 21:19:12 -0500 (EST) Received: from kkb3 (kkb3-098.kk.etx.ericsson.se [130.100.98.23]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2D2JAC00761; Tue, 13 Mar 2001 03:19:10 +0100 (MET) Received: from ericsson.com.au by kkb3 (SMI-8.6/LME-2.2.6) id DAA06986; Tue, 13 Mar 2001 03:19:05 +0100 Message-ID: <3AAD8390.96D4D862@ericsson.com.au> Date: Tue, 13 Mar 2001 13:18:56 +1100 From: Ian Rytina X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt References: <200103061151.GAA07935@ietf.org> <4.3.1.0.20010309081500.0188d490@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Bruce, Sorry - I was looking at the one that Tmima had distributed to me a week before submission. It looks like it changed quite considerably between that one and the submitted draft....... I notice that the "minimal" payload encapsulation has disappeared (where the CRC-8 only covers the PPP protocol id field). What was the reason for leaving this out ? /Ian. Bruce A Thompson wrote: > At 04:31 PM 03/09/2001 +1100, Ian Rytina wrote: > > >Hi Bruce/Tmima, > > > >I am a bit confused about the use of the UUI code-points in > >Section 6.1.3 of PPP/AAL2. > > > >It is proposed to use the values 1, 3 and 5 to indicate "non-final > >packet" for the three different types of encapsulation. What is > >the purpose of these values ? Can't you just use UUI=27 for all of > >these non-final packet scenarios ? > > Are you looking at the draft that was just submitted? Section 6.1.3 in that draft says the following: > > >This proposal uses three UUI code-points as follows: > > > > UUI Code-point Packet Content > > ++++++++++++++ ++++++++++++++ > > > > 27 Long CRC encapsulation, non-final packet. > > > > 26 Long CRC encapsulation, final packet. > > > > 25 Short CRC encapsulation. > > Code point 27 is the only code point we are using to indicate "non-final packet". Both code points 26 and 25 indicate final packet. > > Bruce T > > >Cheers, > > > >Ian. > > > > > >Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > > > > > Title : PPP over AAL2 > > > Author(s) : B. Thompson, b. Buffam, T. Koren > > > Filename : draft-ietf-pppext-ppp-over-aal2-00.txt > > > Pages : > > > Date : 05-Mar-01 > > > > > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > > > transporting multi-protocol datagrams over point-to-point links. > > > This document describes the use of ATM Adaptation Layer 2 (AAL2) for > > > framing PPP encapsulated packets. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt > > > > > > 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-pppext-ppp-over-aal2-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > ---------------------------------------------------------------------------------------- > > Bruce Thompson > Cisco Systems > email: brucet@cisco.com > office: (408)527-0446 > home office: (408)868-0112 > San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Mon Mar 12 23:39:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00785 for ; Mon, 12 Mar 2001 23:39:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id E70455DD92; Mon, 12 Mar 2001 23:37:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D51155DECE; Mon, 12 Mar 2001 23:37:29 -0500 (EST) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 7F6865DD92 for ; Mon, 12 Mar 2001 23:37:28 -0500 (EST) Received: from karl-w98l.xc.org (208.46.234.170 [208.46.234.170]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FJJR44X3; Mon, 12 Mar 2001 21:37:27 -0700 Message-Id: <4.3.2.7.2.20010312220121.047cb340@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Mar 2001 23:37:19 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: 50th IETF PPPEXT Working Group Agenda Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu If you want to get on the agenda, you still have a chance. Here's what I have so far. Karl ---------------------------------------------------------------- PPP Extensions (PPPEXT) Working Group 50th IETF, Minneapolis, MN Tuesday, March 20 at 1700-1800 (opposite furi, burp, disman, dnsop, ssm, stime and tsvwg) Agenda EAP SIM Authentication (Version 1) draft-haverinen-pppext-eap-sim-00.txt Henry Haverinen 5 minutes IP Header Compression over PPP draft-koren-avt-crtp-ipcp-00.txt Tmima Koren 5 minutes Class Extensions for PPP over AAL2 draft-brucet-pppext-ppp-over-aal2-class-00.txt PPP over AAL2 draft-ietf-pppext-ppp-over-aal2-00.txt Bruce Thompson 15 minutes A Call for Volunteers--Editors and Implementation Questionnaire Authors Needed Karl Fox 15 minutes Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Tue Mar 13 01:23:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03592 for ; Tue, 13 Mar 2001 01:23:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DA1A5DEB7; Tue, 13 Mar 2001 01:20:02 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3A9895DEB3; Tue, 13 Mar 2001 01:20:02 -0500 (EST) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 26A965DD91 for ; Tue, 13 Mar 2001 01:20:00 -0500 (EST) Received: from unknown (HELO muralidharan) (203.199.38.53) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Mar 2001 06:19:58 -0000 X-Apparently-From: Message-ID: <002901c0ab85$faa6a840$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: , "Karl Fox" Cc: References: <4.3.2.7.2.20010312220121.047cb340@mail.via-net.net> Subject: Re: 50th IETF PPPEXT Working Group Agenda Date: Tue, 13 Mar 2001 11:52:07 +0530 Organization: OSS Systems India/IEEE Bombay Section MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, Would it be possible to know the status of the draft: Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads thanks in advance regards, muralidharan ----- Original Message ----- From: "Karl Fox" To: Cc: Sent: Tuesday, March 13, 2001 10:07 AM Subject: 50th IETF PPPEXT Working Group Agenda > If you want to get on the agenda, you still have a chance. Here's what I > have so far. > > Karl > ---------------------------------------------------------------- > PPP Extensions (PPPEXT) Working Group > 50th IETF, Minneapolis, MN > > Tuesday, March 20 at 1700-1800 > (opposite furi, burp, disman, dnsop, ssm, stime and tsvwg) > > Agenda > > EAP SIM Authentication (Version 1) > draft-haverinen-pppext-eap-sim-00.txt > Henry Haverinen > 5 minutes > > IP Header Compression over PPP > draft-koren-avt-crtp-ipcp-00.txt > Tmima Koren > 5 minutes > > Class Extensions for PPP over AAL2 > draft-brucet-pppext-ppp-over-aal2-class-00.txt > PPP over AAL2 > draft-ietf-pppext-ppp-over-aal2-00.txt > Bruce Thompson > 15 minutes > > A Call for Volunteers--Editors and Implementation > Questionnaire Authors Needed > Karl Fox > 15 minutes > > Karl Fox > Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Tue Mar 13 08:20:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19279 for ; Tue, 13 Mar 2001 08:20:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id C47475DDB2; Tue, 13 Mar 2001 08:15:11 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 43A575DE67; Tue, 13 Mar 2001 08:15:11 -0500 (EST) Received: from woody.aiinet.com (mail1.aiinet.com [38.195.69.30]) by segue.merit.edu (Postfix) with ESMTP id 5E4A65DDB2 for ; Tue, 13 Mar 2001 08:15:06 -0500 (EST) Received: from karl-w98l.xc.org (karl-w98l.aiinet.com [172.16.56.244]) by woody.aiinet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GV8HNPKZ; Tue, 13 Mar 2001 08:15:01 -0500 Message-Id: <4.3.2.7.2.20010313080359.0470f660@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 08:05:24 -0500 To: "R. Muralidharan" , From: Karl Fox Subject: Re: 50th IETF PPPEXT Working Group Agenda In-Reply-To: <002901c0ab85$faa6a840$1000a8c0@muralidharan> References: <4.3.2.7.2.20010312220121.047cb340@mail.via-net.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu It's waiting to go to working group last call. I dropped the ball; I'll announce last call after the Minneapolis meeting. Karl At 01:22 AM 3/13/01, R. Muralidharan wrote: >Hi, > Would it be possible to know the status of the draft: > > Extending PPP over SONET/SDH, > with virtual concatenation, high order and low order payloads > > >thanks in advance >regards, >muralidharan > > >----- Original Message ----- >From: "Karl Fox" >To: >Cc: >Sent: Tuesday, March 13, 2001 10:07 AM >Subject: 50th IETF PPPEXT Working Group Agenda > > >> If you want to get on the agenda, you still have a chance. Here's what I >> have so far. >> >> Karl >> ---------------------------------------------------------------- >> PPP Extensions (PPPEXT) Working Group >> 50th IETF, Minneapolis, MN >> >> Tuesday, March 20 at 1700-1800 >> (opposite furi, burp, disman, dnsop, ssm, stime and tsvwg) >> >> Agenda >> >> EAP SIM Authentication (Version 1) >> draft-haverinen-pppext-eap-sim-00.txt >> Henry Haverinen >> 5 minutes >> >> IP Header Compression over PPP >> draft-koren-avt-crtp-ipcp-00.txt >> Tmima Koren >> 5 minutes >> >> Class Extensions for PPP over AAL2 >> draft-brucet-pppext-ppp-over-aal2-class-00.txt >> PPP over AAL2 >> draft-ietf-pppext-ppp-over-aal2-00.txt >> Bruce Thompson >> 15 minutes >> >> A Call for Volunteers--Editors and Implementation >> Questionnaire Authors Needed >> Karl Fox >> 15 minutes >> >> Karl Fox >> Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 >> > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Tue Mar 13 10:13:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21565 for ; Tue, 13 Mar 2001 10:13:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC1C45E071; Tue, 13 Mar 2001 10:10:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A507B5E077; Tue, 13 Mar 2001 10:10:50 -0500 (EST) Received: from woody.aiinet.com (mail1.aiinet.com [38.195.69.30]) by segue.merit.edu (Postfix) with ESMTP id 2E6DF5E071 for ; Tue, 13 Mar 2001 10:10:49 -0500 (EST) Received: from karl-w98l.xc.org (karl-w98l.aiinet.com [172.16.56.244]) by woody.aiinet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GV8HNQBV; Tue, 13 Mar 2001 10:10:41 -0500 Message-Id: <4.3.2.7.2.20010313101014.00d805a0@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 10:10:36 -0500 To: "Jones, Nevin R (Nevin)" , ietf-ppp@merit.edu, "'R. Muralidharan'" From: Karl Fox Subject: RE: 50th IETF PPPEXT Working Group Agenda Cc: "'chris murton'" In-Reply-To: <2723E6389F55D311BDC200508B12954704B4DC09@pai820exch003u.mi cro.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Nevin, Don't do it today; wait until after the meeting or this one will get dropped, too. Karl At 09:22 AM 3/13/01, Jones, Nevin R (Nevin) wrote: >Karl, > >I believe per the outcome of the Novemeber meeting in San Diego, you were to >issue a last call for this document. > >I had sent you and email regarding the next steps for progressing the >document but it must have slipped through the cracks since I do not believe >I received a response. > >P.S. I wil be uploading an updated version later today. > >Regards, > > >Nevin R. Jones > >Agere Systems >Broadband IC System Architecture >Rm 7E-321 >600 Mountain Avenue >Murray Hill, NJ >07974 >Ph: 908-582-5343 >Fax: 908-582-4185 >nrjones@lucent.com > >> ---------- >> From: R. Muralidharan[SMTP:raghavan_muralidharan@yahoo.com] >> Reply To: R. Muralidharan >> Sent: Tuesday, March 13, 2001 1:22 AM >> To: ietf-ppp@merit.edu; Karl Fox >> Cc: agenda@ietf.org >> Subject: Re: 50th IETF PPPEXT Working Group Agenda >> >> Hi, >> Would it be possible to know the status of the draft: >> >> Extending PPP over SONET/SDH, >> with virtual concatenation, high order and low order payloads >> >> >> thanks in advance >> regards, >> muralidharan >> >> >> ----- Original Message ----- >> From: "Karl Fox" >> To: >> Cc: >> Sent: Tuesday, March 13, 2001 10:07 AM >> Subject: 50th IETF PPPEXT Working Group Agenda >> >> >> > If you want to get on the agenda, you still have a chance. Here's what >> I >> > have so far. >> > >> > Karl >> > ---------------------------------------------------------------- >> > PPP Extensions (PPPEXT) Working Group >> > 50th IETF, Minneapolis, MN >> > >> > Tuesday, March 20 at 1700-1800 >> > (opposite furi, burp, disman, dnsop, ssm, stime and tsvwg) >> > >> > Agenda >> > >> > EAP SIM Authentication (Version 1) >> > draft-haverinen-pppext-eap-sim-00.txt >> > Henry Haverinen >> > 5 minutes >> > >> > IP Header Compression over PPP >> > draft-koren-avt-crtp-ipcp-00.txt >> > Tmima Koren >> > 5 minutes >> > >> > Class Extensions for PPP over AAL2 >> > draft-brucet-pppext-ppp-over-aal2-class-00.txt >> > PPP over AAL2 >> > draft-ietf-pppext-ppp-over-aal2-00.txt >> > Bruce Thompson >> > 15 minutes >> > >> > A Call for Volunteers--Editors and Implementation >> > Questionnaire Authors Needed >> > Karl Fox >> > 15 minutes >> > >> > Karl Fox >> > Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 >> > >> >> >> _________________________________________________________ >> Do You Yahoo!? >> Get your free @yahoo.com address at http://mail.yahoo.com >> >> Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Tue Mar 13 12:52:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24887 for ; Tue, 13 Mar 2001 12:52:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97EF05DE1F; Tue, 13 Mar 2001 12:51:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 854C85DDCF; Tue, 13 Mar 2001 12:51:56 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 606F65DE67 for ; Tue, 13 Mar 2001 12:51:54 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA14667; Tue, 13 Mar 2001 09:50:41 -0800 (PST) Received: from brucet-nt3.cisco.com (dhcp-128-107-142-109.cisco.com [128.107.142.109]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AJE05414; Tue, 13 Mar 2001 09:51:44 -0800 (PST) Message-Id: <4.3.1.0.20010313091801.018918d0@mira-sjcm-2.cisco.com> X-Sender: brucet@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 13 Mar 2001 09:54:42 -0800 To: Ian Rytina From: Bruce A Thompson Subject: Re: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt Cc: ietf-ppp@merit.edu In-Reply-To: <3AAD8390.96D4D862@ericsson.com.au> References: <200103061151.GAA07935@ietf.org> <4.3.1.0.20010309081500.0188d490@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 01:18 PM 03/13/2001 +1100, Ian Rytina wrote: >Hi Bruce, > >Sorry - I was looking at the one that Tmima had distributed to me >a week before submission. It looks like it changed quite considerably >between that one and the submitted draft....... > >I notice that the "minimal" payload encapsulation has disappeared (where >the CRC-8 only covers the PPP protocol id field). What was the reason >for leaving this out ? We wanted to simplify the draft from the version you looked at. The version you looked at had 3 CRC options: 16 bit CRC (covers packets to 1500 bytes), 8 bit CRC (covers packets to 32 bytes), and minimal 8 bit CRC (covers the first 32 bytes of the packet). We had a good deal of discussion about whether minimal 8 bit CRC should do a CRC on just 1 byte or multiple bytes or 32 bytes. We realized the answer was based on the trade off between allowing errors payloads (for codecs such as the AMR codec) and protecting compressed headers (compressed RTP and IP headers should really be covered by a CRC since the IP checksum is not transmitted). Another issue that came up with minimal 8 bit CRC was the potential conflicts it caused with I.366.1. This issue was that we couldn't just use UUI code point 27 to indicate non-final packet with minimal 8 bit CRC. That's because we wanted to allow the receiver to identify the type of CRC a packet had before the last fragment was received. This allows the receiver to run a CRC check while the fragments of the packet are coming in. We didn't know how to solve this problem without conflicting with the current UUI definitions in I.366.1. The final issue with minimal 8 bit CRC was the concern about applications that don't use UDP or TCP checksums and rely on the link layer checksums to discard packets. This is very common in networks today. This means that the only place that minimal 8 bit CRC could be used was a carefully engineered network where it was known that all the sources were generating proper transport and application layer checksums. In addition, we didn't know if there were other PPP payload types besides IP that depend on link layer checksums for error detection. This issues was going to cause us to have to write a large about of text trying to describe the conditions that it would actually be safe to cover less than a full packet with a CRC. In the end, we decided that minimal 8 bit CRC was causing too many complexities in the draft compared to the added bandwidth savings for packets larger than 32 bytes. Our thought was that if bandwidth savings for VoIP was that important, you could run CRTP with a compressed codec (like AMR) and end up with packets less than 32 bytes. Regular 8 bit CRC could be used for these packets. If this is still an issue for you I would be glad to discuss it further. Will you be at the mtg? Bruce T >/Ian. > > >Bruce A Thompson wrote: > > > At 04:31 PM 03/09/2001 +1100, Ian Rytina wrote: > > > > >Hi Bruce/Tmima, > > > > > >I am a bit confused about the use of the UUI code-points in > > >Section 6.1.3 of PPP/AAL2. > > > > > >It is proposed to use the values 1, 3 and 5 to indicate "non-final > > >packet" for the three different types of encapsulation. What is > > >the purpose of these values ? Can't you just use UUI=27 for all of > > >these non-final packet scenarios ? > > > > Are you looking at the draft that was just submitted? Section 6.1.3 in that draft says the following: > > > > >This proposal uses three UUI code-points as follows: > > > > > > UUI Code-point Packet Content > > > ++++++++++++++ ++++++++++++++ > > > > > > 27 Long CRC encapsulation, non-final packet. > > > > > > 26 Long CRC encapsulation, final packet. > > > > > > 25 Short CRC encapsulation. > > > > Code point 27 is the only code point we are using to indicate "non-final packet". Both code points 26 and 25 indicate final packet. > > > > Bruce T > > > > >Cheers, > > > > > >Ian. > > > > > > > > >Internet-Drafts@ietf.org wrote: > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > > > > > > > Title : PPP over AAL2 > > > > Author(s) : B. Thompson, b. Buffam, T. Koren > > > > Filename : draft-ietf-pppext-ppp-over-aal2-00.txt > > > > Pages : > > > > Date : 05-Mar-01 > > > > > > > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > > > > transporting multi-protocol datagrams over point-to-point links. > > > > This document describes the use of ATM Adaptation Layer 2 (AAL2) for > > > > framing PPP encapsulated packets. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt > > > > > > > > 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-pppext-ppp-over-aal2-00.txt". > > > > > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > Send a message to: > > > > mailserv@ietf.org. > > > > In the body type: > > > > "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility. To use this > > > > feature, insert the command "ENCODING mime" before the "FILE" > > > > command. To decode the response(s), you will need "munpack" or > > > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which have been split > > > > up into multiple messages), so check your local documentation on > > > > how to manipulate these messages. > > > > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII version of the > > > > Internet-Draft. > > > > > > > > ---------------------------------------------------------------------------------------- > > > > Bruce Thompson > > Cisco Systems > > email: brucet@cisco.com > > office: (408)527-0446 > > home office: (408)868-0112 > > San Jose, CA Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Thu Mar 15 23:25:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15085 for ; Thu, 15 Mar 2001 23:25:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 566545E050; Thu, 15 Mar 2001 21:51:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E5CEF5E15E; Thu, 15 Mar 2001 20:42:43 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id C308C5E2E9 for ; Thu, 15 Mar 2001 19:59:27 -0500 (EST) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2G0xQC03840; Fri, 16 Mar 2001 01:59:26 +0100 (MET) Received: from ericsson.com.au by kkb3 (SMI-8.6/LME-2.2.6) id BAA04704; Fri, 16 Mar 2001 01:59:21 +0100 Message-ID: <3AB16569.5729CA6B@ericsson.com.au> Date: Fri, 16 Mar 2001 11:59:22 +1100 From: Ian Rytina X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt References: <200103061151.GAA07935@ietf.org> <4.3.1.0.20010309081500.0188d490@mira-sjcm-2.cisco.com> <4.3.1.0.20010313091801.018918d0@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Bruce......comments below.......Ian. Bruce A Thompson wrote: > At 01:18 PM 03/13/2001 +1100, Ian Rytina wrote: > > >Hi Bruce, > > > >Sorry - I was looking at the one that Tmima had distributed to me > >a week before submission. It looks like it changed quite considerably > >between that one and the submitted draft....... > > > >I notice that the "minimal" payload encapsulation has disappeared (where > >the CRC-8 only covers the PPP protocol id field). What was the reason > >for leaving this out ? > > We wanted to simplify the draft from the version you looked at. The version you looked at had 3 CRC options: 16 bit CRC (covers packets to 1500 bytes), 8 bit CRC (covers packets to 32 bytes), and minimal 8 bit CRC (covers the first 32 bytes of the packet). > > We had a good deal of discussion about whether minimal 8 bit CRC should do a CRC on just 1 byte or multiple bytes or 32 bytes. We realized the answer was based on the trade off between allowing errors payloads (for codecs such as the AMR codec) and protecting compressed headers (compressed RTP and IP headers should really be covered by a CRC since the IP checksum is not transmitted). > > > Another issue that came up with minimal 8 bit CRC was the potential conflicts it caused with I.366.1. This issue was that we couldn't just use UUI code point 27 to indicate non-final packet with minimal 8 bit CRC. That's because we wanted to allow the receiver to identify the type of CRC a packet had before the last fragment was received. This allows the receiver to run a CRC check while the fragments of the packet are coming in. We didn't know how to solve this problem without conflicting with the current UUI definitions in I.366.1. I am not sure I follow this entirely (however my CRC knowledge is a bit rusty these days). Don't you need the CRC in the final packet, and the whole packet reassembled before you can use the CRC ? I guess you could do some sort of computation as the packets come in, but ultimately you still have to wait until the final packet and then do your CRC. So practically speaking, what do you gain by knowing the eventual type of the CRC. > > > The final issue with minimal 8 bit CRC was the concern about applications that don't use UDP or TCP checksums and rely on the link layer checksums to discard packets. This is very common in networks today. This means that the only place that minimal 8 bit CRC could be used was a carefully engineered network where it was known that all the sources were generating proper transport and application layer checksums. In addition, we didn't know if there were other PPP payload types besides IP that depend on link layer checksums for error detection. This issues was going to cause us to have to write a large about of text trying to describe the conditions that it would actually be safe to cover less than a full packet with a CRC. I thought the text was ok as it was. The protocol RFC provides support of the function, it is up to the implementors/network operators to decide how and when it is appropriate to use it. > > > In the end, we decided that minimal 8 bit CRC was causing too many complexities in the draft compared to the added bandwidth savings for packets larger than 32 bytes. Our thought was that if bandwidth savings for VoIP was that important, you could run CRTP with a compressed codec (like AMR) and end up with packets less than 32 bytes. Regular 8 bit CRC could be used for these packets. FR, EFR and some modes of AMR (plus header) won't fit into 32 bytes. For AMR, this complicates things somewhat, since the sender would have to be aware of the AMR mode, or continuously checking the length of packets before deciding which CRC option to use. > > > If this is still an issue for you I would be glad to discuss it further. Will you be at the mtg? > I still think this is minimal CRC valid practical option, since the ATM/AAL2 CRCs and the UDP CRC can validly cover the other parts of the packet. I'll be in Minneapolis next week, so we can further develop things there. > > Bruce T > > >/Ian. > > > > > >Bruce A Thompson wrote: > > > > > At 04:31 PM 03/09/2001 +1100, Ian Rytina wrote: > > > > > > >Hi Bruce/Tmima, > > > > > > > >I am a bit confused about the use of the UUI code-points in > > > >Section 6.1.3 of PPP/AAL2. > > > > > > > >It is proposed to use the values 1, 3 and 5 to indicate "non-final > > > >packet" for the three different types of encapsulation. What is > > > >the purpose of these values ? Can't you just use UUI=27 for all of > > > >these non-final packet scenarios ? > > > > > > Are you looking at the draft that was just submitted? Section 6.1.3 in that draft says the following: > > > > > > >This proposal uses three UUI code-points as follows: > > > > > > > > UUI Code-point Packet Content > > > > ++++++++++++++ ++++++++++++++ > > > > > > > > 27 Long CRC encapsulation, non-final packet. > > > > > > > > 26 Long CRC encapsulation, final packet. > > > > > > > > 25 Short CRC encapsulation. > > > > > > Code point 27 is the only code point we are using to indicate "non-final packet". Both code points 26 and 25 indicate final packet. > > > > > > Bruce T > > > > > > >Cheers, > > > > > > > >Ian. > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > > > > > > > > > Title : PPP over AAL2 > > > > > Author(s) : B. Thompson, b. Buffam, T. Koren > > > > > Filename : draft-ietf-pppext-ppp-over-aal2-00.txt > > > > > Pages : > > > > > Date : 05-Mar-01 > > > > > > > > > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > > > > > transporting multi-protocol datagrams over point-to-point links. > > > > > This document describes the use of ATM Adaptation Layer 2 (AAL2) for > > > > > framing PPP encapsulated packets. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt > > > > > > > > > > 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-pppext-ppp-over-aal2-00.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > http://www.ietf.org/shadow.html > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > Send a message to: > > > > > mailserv@ietf.org. > > > > > In the body type: > > > > > "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > MIME-encoded form by using the "mpack" utility. To use this > > > > > feature, insert the command "ENCODING mime" before the "FILE" > > > > > command. To decode the response(s), you will need "munpack" or > > > > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > > > > exhibit different behavior, especially when dealing with > > > > > "multipart" MIME messages (i.e. documents which have been split > > > > > up into multiple messages), so check your local documentation on > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > > implementation to automatically retrieve the ASCII version of the > > > > > Internet-Draft. > > > > > > > > > > ---------------------------------------------------------------------------------------- > > > > > > Bruce Thompson > > > Cisco Systems > > > email: brucet@cisco.com > > > office: (408)527-0446 > > > home office: (408)868-0112 > > > San Jose, CA > > Bruce Thompson > Cisco Systems > email: brucet@cisco.com > office: (408)527-0446 > home office: (408)868-0112 > San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Fri Mar 16 14:43:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09301 for ; Fri, 16 Mar 2001 14:43:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5EBE75DE32; Fri, 16 Mar 2001 14:08:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B6C165DF64; Fri, 16 Mar 2001 14:06:28 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 1BF995E0FA for ; Fri, 16 Mar 2001 14:00:48 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id KAA01665; Fri, 16 Mar 2001 10:59:33 -0800 (PST) Received: from brucet-nt3.cisco.com (dhcp-128-107-142-109.cisco.com [128.107.142.109]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AJZ01795; Fri, 16 Mar 2001 11:00:34 -0800 (PST) Message-Id: <4.3.1.0.20010316102017.0228aa90@mira-sjcm-2.cisco.com> X-Sender: brucet@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 16 Mar 2001 11:03:29 -0800 To: Ian Rytina From: Bruce A Thompson Subject: Re: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-00.txt Cc: ietf-ppp@merit.edu In-Reply-To: <3AB16569.5729CA6B@ericsson.com.au> References: <200103061151.GAA07935@ietf.org> <4.3.1.0.20010309081500.0188d490@mira-sjcm-2.cisco.com> <4.3.1.0.20010313091801.018918d0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 11:59 AM 03/16/2001 +1100, Ian Rytina wrote: > > Another issue that came up with minimal 8 bit CRC was the potential conflicts it caused with I.366.1. This issue was that we couldn't just use UUI code point 27 to indicate non-final packet with minimal 8 bit CRC. That's because we wanted to allow the receiver to identify the type of CRC a packet had before the last fragment was received. This allows the receiver to run a CRC check while the fragments of the packet are coming in. We didn't know how to solve this problem without conflicting with the current UUI definitions in I.366.1. > >I am not sure I follow this entirely (however my CRC knowledge is a bit rusty these >days). Don't you need the CRC in the final packet, and the whole packet reassembled >before you can use the CRC ? I guess you could do some sort of computation as >the packets come in, but ultimately you still have to wait until the final packet and then >do your CRC. So practically speaking, what do you gain by knowing the eventual >type of the CRC. Specifying the CRC type before the last fragment first requested by James Carlson in an earlier thread when he went through the initial version of the draft. I think the issue is that the receiver may build up a running CRC as the fragments of a packet are received. Here is what he said in that thread: >If you're talking about the variable CRC scheme, I think the >consequences of this might be fairly serious, and that's the part of >my comment that I was holding until later to see where the dust >settled. For both software and hardware, the implication is that both >CRC-16 and CRC-32 must be run in parallel on all data received on a >given CID. For hardware implementations, it means that two pipelines >are required. For software implementations (think 860SAR on a T1 >line), it means that the inner loop does twice as work. For both, >this bumps up the intermediate state storage requirement for each of >these streams and the I/O rate to that storage. > >I'm not an AAL2 expert, and I don't know the restrictions on UUI >values (why is 27 'continue' and what are 28-31?), but it certainly >would be nice to alert the receiver about the CRC mode in use before >the first chunk has to be processed rather than as the last one is. According to his comments, if you don't specify the CRC type until the last fragment is received the receiver must do a running CRC calculation for all possible CRC's in parallel. > > > > > > The final issue with minimal 8 bit CRC was the concern about applications that don't use UDP or TCP checksums and rely on the link layer checksums to discard packets. This is very common in networks today. This means that the only place that minimal 8 bit CRC could be used was a carefully engineered network where it was known that all the sources were generating proper transport and application layer checksums. In addition, we didn't know if there were other PPP payload types besides IP that depend on link layer checksums for error detection. This issues was going to cause us to have to write a large about of text trying to describe the conditions that it would actually be safe to cover less than a full packet with a CRC. > >I thought the text was ok as it was. The protocol RFC provides support of the function, >it is up to the implementors/network operators to decide how and when it is appropriate >to use it. I think at least the text for minimal CRC should describe the assumptions made to allow it's use. I.E., that layers above PPP are separately providing protection via CRC/checksum for important parts of the payload since the link layer CRC is not covering the entire payload. I have a question in this regard. Are there any standardized link layers that provide transport for IP and/or PPP that don't include a CRC over the entire payload? If not, it seems like we'll be breaking new ground here for PPP transport by creating a mode that don't cover the entire payload. That's my main concern here. I would like to hear some consensus from the group that it's OK to leave portions of the PPP payload uncovered by the CRC. > > > > > > In the end, we decided that minimal 8 bit CRC was causing too many complexities in the draft compared to the added bandwidth savings for packets larger than 32 bytes. Our thought was that if bandwidth savings for VoIP was that important, you could run CRTP with a compressed codec (like AMR) and end up with packets less than 32 bytes. Regular 8 bit CRC could be used for these packets. > >FR, EFR and some modes of AMR (plus header) won't fit into 32 bytes. For AMR, this >complicates things somewhat, since the sender would have to be aware of the AMR mode, >or continuously checking the length of packets before deciding which CRC option to use. Are you then advocating we run only 1 CRC method per PPP session? If not, the receiver would have to check incoming packets for which CRC to run on them. If we ran 1 CRC method per PPP session, this would simplify things again. We could then go to just 2 possible CRC modes where a single mode is negotiated per PPP session. It could be just CRC-16 as the base mode and minimal CRC-8 as a negotiated mode. Once the CRC was negotiated, it would be the only CRC method used for that PPP session. This would get rid of the issue described above about specifying the CRC type in fragments. The only issue I would have with an option like this is whether it OK to define a PPP transport where portions of the PPP payload are uncovered by the CRC. > > > > > > If this is still an issue for you I would be glad to discuss it further. Will you be at the mtg? > > > >I still think this is minimal CRC valid practical option, since the ATM/AAL2 CRCs and >the UDP CRC can validly cover the other parts of the packet. I'll be in Minneapolis >next week, so we can further develop things there. We should meet before the working group mtg to resolve this. Please send me some contact info so we can get together before the mtg on Tuesday. Bruce T > > > > Bruce T > > > > >/Ian. > > > > > > > > >Bruce A Thompson wrote: > > > > > > > At 04:31 PM 03/09/2001 +1100, Ian Rytina wrote: > > > > > > > > >Hi Bruce/Tmima, > > > > > > > > > >I am a bit confused about the use of the UUI code-points in > > > > >Section 6.1.3 of PPP/AAL2. > > > > > > > > > >It is proposed to use the values 1, 3 and 5 to indicate "non-final > > > > >packet" for the three different types of encapsulation. What is > > > > >the purpose of these values ? Can't you just use UUI=27 for all of > > > > >these non-final packet scenarios ? > > > > > > > > Are you looking at the draft that was just submitted? Section 6.1.3 in that draft says the following: > > > > > > > > >This proposal uses three UUI code-points as follows: > > > > > > > > > > UUI Code-point Packet Content > > > > > ++++++++++++++ ++++++++++++++ > > > > > > > > > > 27 Long CRC encapsulation, non-final packet. > > > > > > > > > > 26 Long CRC encapsulation, final packet. > > > > > > > > > > 25 Short CRC encapsulation. > > > > > > > > Code point 27 is the only code point we are using to indicate "non-final packet". Both code points 26 and 25 indicate final packet. > > > > > > > > Bruce T > > > > > > > > >Cheers, > > > > > > > > > >Ian. > > > > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > > > > > > > > > > > Title : PPP over AAL2 > > > > > > Author(s) : B. Thompson, b. Buffam, T. Koren > > > > > > Filename : draft-ietf-pppext-ppp-over-aal2-00.txt > > > > > > Pages : > > > > > > Date : 05-Mar-01 > > > > > > > > > > > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > > > > > > transporting multi-protocol datagrams over point-to-point links. > > > > > > This document describes the use of ATM Adaptation Layer 2 (AAL2) for > > > > > > framing PPP encapsulated packets. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt > > > > > > > > > > > > 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-pppext-ppp-over-aal2-00.txt". > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > http://www.ietf.org/shadow.html > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > Send a message to: > > > > > > mailserv@ietf.org. > > > > > > In the body type: > > > > > > "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-00.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > > MIME-encoded form by using the "mpack" utility. To use this > > > > > > feature, insert the command "ENCODING mime" before the "FILE" > > > > > > command. To decode the response(s), you will need "munpack" or > > > > > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > > > > > exhibit different behavior, especially when dealing with > > > > > > "multipart" MIME messages (i.e. documents which have been split > > > > > > up into multiple messages), so check your local documentation on > > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > > > implementation to automatically retrieve the ASCII version of the > > > > > > Internet-Draft. > > > > > > > > > > > > ---------------------------------------------------------------------------------------- > > > > > > > > Bruce Thompson > > > > Cisco Systems > > > > email: brucet@cisco.com > > > > office: (408)527-0446 > > > > home office: (408)868-0112 > > > > San Jose, CA > > > > Bruce Thompson > > Cisco Systems > > email: brucet@cisco.com > > office: (408)527-0446 > > home office: (408)868-0112 > > San Jose, CA Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Fri Mar 16 16:51:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13765 for ; Fri, 16 Mar 2001 16:51:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id E96125DE72; Fri, 16 Mar 2001 16:38:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0754C5E222; Fri, 16 Mar 2001 16:17:00 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by segue.merit.edu (Postfix) with ESMTP id 3CE5C5E307 for ; Fri, 16 Mar 2001 15:50:34 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 16 Mar 2001 10:07:10 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7W4TCZR; Fri, 16 Mar 2001 10:07:06 -0500 Received: from americasm01.nt.com (wcars111.ca.nortel.com [47.129.149.161]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M3NDCJG; Fri, 16 Mar 2001 10:07:12 -0500 Message-ID: <3AB22C1D.66E6EB21@americasm01.nt.com> Date: Fri, 16 Mar 2001 10:07:09 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: LQM over SONET Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I was wondering if anyone was using LQM over packet over SONET (POS) interfaces because I cannot see how it can provide accurate performance measurements. Let's assume we are receiving 8000000 packets/sec (OC-192, 10 GBits/s with 1500 byte packets). When I receive an LQR packet, it is excepted up to software. While the LQR packet is being processed by software, the hardware datapath can be simultaneously receiving more data traffic. Therefore, the ifInUinPackets and ifInNUniPackets counters will be increasing. By the time software retrieves the ifIn counters, they have already increased. Hence, when we attempt to perform quality measurements over the incoming link, the delta for SaveInPackets will be inaccurate as it contains packets after the LQR packet was received and before the ifIn counters could be retrieved. If we assume a 10 msec delay to process the LQR packet and retrieve the ifIn counters, we would have received 8000 packets before being able to retrieve the ifIn counters. Secondly, at OC-192 rates, the 32 bit octet counters will wrap every 3 seconds; suggesting that we would have to send LQR packets at least every 3 secs which will add a lot of congestion in your network. Kim From owner-ietf-ppp-outgoing@merit.edu Fri Mar 16 17:37:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14279 for ; Fri, 16 Mar 2001 17:37:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id C8CE95DFF2; Fri, 16 Mar 2001 17:35:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1AA275E068; Fri, 16 Mar 2001 17:23:13 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8C9805E08B for ; Fri, 16 Mar 2001 17:08:31 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09555; Fri, 16 Mar 2001 14:07:42 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04465; Fri, 16 Mar 2001 17:07:41 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2GM8Hh38939; Fri, 16 Mar 2001 17:08:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15026.36560.726783.571021@gargle.gargle.HOWL> Date: Fri, 16 Mar 2001 17:08:16 -0500 (EST) From: James Carlson To: "Kim Edwards" Cc: ietf-ppp@merit.edu Subject: Re: LQM over SONET In-Reply-To: Kim Edwards's message of 16 March 2001 10:07:09 References: <3AB22C1D.66E6EB21@americasm01.nt.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Kim Edwards writes: > Let's assume we are receiving 8000000 packets/sec (OC-192, 10 GBits/s > with 1500 byte packets). Those numbers look strange to me; the packets per second is off by a factor of 10. Subtracting out the SONET overhead, I see 9.58464Gbps on OC-192c. That's 9.58464E9/1500/8 = 798720 packets per second. (Ignoring the RFC 1662 overhead, which is statistical and normally about 1%.) > If we assume a 10 msec delay to process the LQR packet and retrieve the > ifIn counters, we would have received 8000 packets before being able to > retrieve the ifIn counters. True; but you should always be off by about this amount. All that matters here are the approximate packet counts that are seen in a given interval and the number of link errors relative to that. These are very rough numbers, and adding 1% error isn't going to affect them. (I would think that the section and path error monitoring in SONET would be more interesting than LQR ...) > Secondly, at OC-192 rates, the 32 bit octet counters will wrap every 3 > seconds; Right. > suggesting that we would have to send LQR packets at least > every 3 secs which will add a lot of congestion in your network. Really? One extra 48 octet (+8 nominal PPP overhead) packet out of 2.4 million 1500 octet packets causes noticable congestion on that link? How is that possible? I think you should be able to send tens of thousands of LQR packets per second without causing noticable link congestion. (The software might have trouble, but the link should not.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Mar 16 18:23:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14882 for ; Fri, 16 Mar 2001 18:23:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22FAE5DD9B; Fri, 16 Mar 2001 18:19:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6E46D5DEB5; Fri, 16 Mar 2001 18:14:47 -0500 (EST) Received: from fncomr02.fnc.fujitsu.com (fncomr.fnc.fujitsu.com [167.254.105.20]) by segue.merit.edu (Postfix) with ESMTP id 4495C5DFD1 for ; Fri, 16 Mar 2001 18:06:52 -0500 (EST) Received: from timor.tddny.fujitsu.com (timor.tddny.fujitsu.com [167.254.240.106]) by fncomr02.fnc.fujitsu.com (Mirapoint) with ESMTP id ACK48053; Fri, 16 Mar 2001 17:06:37 -0600 (GMT+6) Received: from tddny.fujitsu.com ([167.254.241.51]) by timor.tddny.fujitsu.com (Netscape Messaging Server 3.6) with ESMTP id AAAC53 for ; Fri, 16 Mar 2001 18:05:46 -0500 Message-ID: <3AB29C4A.ED55D1@tddny.fujitsu.com> Date: Fri, 16 Mar 2001 18:05:46 -0500 From: Che min Hsieh Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-ppp@merit.edu" Subject: MPLS tagging over PPP Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I am wondering if there is any RFC that describes the MPLS tagging over PPP. The closest one I can find is in the "MPLS Technology and Applications" book by Bruce Davie and Yakov Rekhter, Section 4.3 "Tag Encapsulation on Non-ATM links", page 113, 2nd paragraph, " On point-to-point subnetworks, packets that carry tags are identified by the PPP protocol field ....". In which RFC is this documented? Or , it is a proprietary extention from Cicso. Is there any PPP extention that allows multiple instances of NCPs over a single LCP? (let's say multiple BCPs over a PPP link) Any information about this matter is appreciated. Thanks. From owner-ietf-ppp-outgoing@merit.edu Sat Mar 17 00:41:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20753 for ; Sat, 17 Mar 2001 00:41:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id E38615DF93; Sat, 17 Mar 2001 00:39:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2702E5DF8E; Sat, 17 Mar 2001 00:39:02 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 9F9C25DE99 for ; Sat, 17 Mar 2001 00:38:58 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id f2H5cup19846; Sat, 17 Mar 2001 00:38:56 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15026.63599.600280.22320@h006008986325.ne.mediaone.net> Date: Sat, 17 Mar 2001 00:38:55 -0500 (EST) To: Che min Hsieh Cc: "ietf-ppp@merit.edu" Subject: Re: MPLS tagging over PPP In-Reply-To: Che min Hsieh's message of 16 March 2001 18:05:46 References: <3AB29C4A.ED55D1@tddny.fujitsu.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Che min Hsieh writes: > I am wondering if there is any RFC that describes the MPLS tagging over > PPP. Try RFC 3032. Section 4 describes MPLSCP and the encoding used for PPP. > Is there any PPP extention that allows multiple instances of NCPs over a > single LCP? (let's say multiple BCPs over a PPP link) You want to run multiple copies of a single NCP over a PPP link? No, that's not possible. Perhaps if you can describe the application, someone here can give a better answer. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Mar 19 02:39:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04543 for ; Mon, 19 Mar 2001 02:39:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id E58585DDC2; Mon, 19 Mar 2001 02:37:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA41E5DE1F; Mon, 19 Mar 2001 02:37:10 -0500 (EST) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 70F555DDC2 for ; Mon, 19 Mar 2001 02:37:09 -0500 (EST) Received: from karl-w98l.xc.org (pcp000572pcs.wireless.meeting.ietf.org [135.222.64.72]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FJJR408B; Mon, 19 Mar 2001 00:37:08 -0700 Message-Id: <4.3.2.7.2.20010319023156.05085b20@mail.via-net.net> X-Sender: kfox@mail.via-net.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Mar 2001 02:36:37 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: Volunteer needed to take minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I need a volunteer to record the minutes of the PPPEXT meeting Tuesday. Please reply directly to me by e-mail (don't annoy the rest of the list with your reply). The salary is low: ten thousand dot-com underwater stock options and the beverage of your choice. Thanks, Karl P.S. To those out there with lawyers and without a sense of humor, please note that no actual stock options are being offered with this offer. Just so we're clear. :-) Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Mon Mar 19 08:54:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10784 for ; Mon, 19 Mar 2001 08:54:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 484C95DE7E; Mon, 19 Mar 2001 08:50:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20FD55DEA0; Mon, 19 Mar 2001 08:50:58 -0500 (EST) Received: from fncomr01.fnc.fujitsu.com (fncomr.fnc.fujitsu.com [167.254.105.21]) by segue.merit.edu (Postfix) with ESMTP id 679BD5DE7E for ; Mon, 19 Mar 2001 08:50:56 -0500 (EST) Received: from timor.tddny.fujitsu.com (timor.tddny.fujitsu.com [167.254.240.106]) by fncomr01.fnc.fujitsu.com (Mirapoint) with ESMTP id ACA48904; Mon, 19 Mar 2001 07:50:37 -0600 (GMT+6) Received: from tddny.fujitsu.com ([167.254.241.51]) by timor.tddny.fujitsu.com (Netscape Messaging Server 3.6) with ESMTP id AAA5C52; Mon, 19 Mar 2001 08:49:45 -0500 Message-ID: <3AB60E79.465B936F@tddny.fujitsu.com> Date: Mon, 19 Mar 2001 08:49:45 -0500 From: Che min Hsieh Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Carlson Cc: "ietf-ppp@merit.edu" Subject: Re: MPLS tagging over PPP References: <3AB29C4A.ED55D1@tddny.fujitsu.com> <15026.63599.600280.22320@h006008986325.ne.mediaone.net> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson wrote: > Che min Hsieh writes: > > I am wondering if there is any RFC that describes the MPLS tagging over > > PPP. > > Try RFC 3032. Section 4 describes MPLSCP and the encoding used for > PPP. > Thanks. > > > Is there any PPP extention that allows multiple instances of NCPs over a > > single LCP? (let's say multiple BCPs over a PPP link) > > You want to run multiple copies of a single NCP over a PPP link? No, > that's not possible. > > Perhaps if you can describe the application, someone here can give a > better answer. > Let's say a service provider is providing Remote MAC bridge service to customers. Customer A has LAN port A1 of 10/100bt , WAN port WA1, remote WAN port WA2, and LAN port A2 of 10/100bt. The WA1, and WA2 are connected by PPP on POS over OC3c Customer B has LAN port B1 of 10/100bt, WAN port WB1, remote WAN port WB2, and LAN port B2 of 10/100bt. The WB1, and WB2 are connected by another PPP on POS over OC3c BCP, LCP, POS will be fine in this case. But if the service provider says, it is a waste of WAN bandwidth. The LAN port bandwith is 100 meg , but the POS is 150 meg. How about let them share the same OC3c path, and have some statistical gain, if possible. There needs to have a multiplexing/demultiplexing scheme to distinguish which flow of traffic it is. MPLS label seems not able to help. It has the addr, control, protocol (=mpls), label, network header ( =IP), ... What we need is after the label, it carries the MAC frame. > > -- > James Carlson > "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Mar 19 10:08:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12221 for ; Mon, 19 Mar 2001 10:08:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A7CE5DEB3; Mon, 19 Mar 2001 10:05:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1343D5DE77; Mon, 19 Mar 2001 10:05:03 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id 3F77E5DE5A for ; Mon, 19 Mar 2001 10:05:01 -0500 (EST) Received: from zcard00n.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 19 Mar 2001 08:19:10 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H1JQMBXM; Mon, 19 Mar 2001 08:19:16 -0500 Received: from americasm01.nt.com (wcars111.ca.nortel.com [47.129.149.161]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M3ND1TH; Mon, 19 Mar 2001 08:19:14 -0500 Message-ID: <3AB6074E.1F0479B3@americasm01.nt.com> Date: Mon, 19 Mar 2001 08:19:10 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Carlson Cc: ietf-ppp@merit.edu Subject: Re: LQM over SONET References: <3AB22C1D.66E6EB21@americasm01.nt.com> <15026.36560.726783.571021@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James, James Carlson wrote: > Kim Edwards writes: > > Let's assume we are receiving 8000000 packets/sec (OC-192, 10 GBits/s > > with 1500 byte packets). > > Those numbers look strange to me; the packets per second is off by a > factor of 10. Subtracting out the SONET overhead, I see 9.58464Gbps > on OC-192c. That's 9.58464E9/1500/8 = 798720 packets per second. > (Ignoring the RFC 1662 overhead, which is statistical and normally > about 1%.) ... thanks for pointing that out, I should have cut and paste the 800k number from my calc (typo) > > If we assume a 10 msec delay to process the LQR packet and retrieve the > > ifIn counters, we would have received 8000 packets before being able to > > retrieve the ifIn counters. > > True; but you should always be off by about this amount. All that > matters here are the approximate packet counts that are seen in a > given interval and the number of link errors relative to that. These > are very rough numbers, and adding 1% error isn't going to affect > them. > ... sure, I'll buy that > > (I would think that the section and path error monitoring in SONET > would be more interesting than LQR ...) > ... my intention was to use the SONET PMs for link quality, but I have also been requested to support LQM. I cannot find anyone POS interfaces in the market that support LQM. Do you know of any POS devices using LQM? > > > Secondly, at OC-192 rates, the 32 bit octet counters will wrap every 3 > > seconds; > > Right. > > > suggesting that we would have to send LQR packets at least > > every 3 secs which will add a lot of congestion in your network. > > Really? One extra 48 octet (+8 nominal PPP overhead) packet out of > 2.4 million 1500 octet packets causes noticable congestion on that > link? How is that possible? > > I think you should be able to send tens of thousands of LQR packets > per second without causing noticable link congestion. (The software > might have trouble, but the link should not.) > ... I am not affraid of congestion on the link; our box has such a rich feature set, that I am affraid software will not be able to keep up with all of the processing (stats collection, SONET APS processing, SONET PMs, MPLS, IP, PPP, LQM, MLT ...) ... your congestion assumption is absolutely correct and I should have worded my statement more accurately Many thanks, Kim From owner-ietf-ppp-outgoing@merit.edu Mon Mar 19 11:29:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14492 for ; Mon, 19 Mar 2001 11:29:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64BCF5DE21; Mon, 19 Mar 2001 11:29:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 51F485DDF8; Mon, 19 Mar 2001 11:29:00 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9F9CD5DDAC for ; Mon, 19 Mar 2001 11:28:58 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23539; Mon, 19 Mar 2001 08:28:57 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12478; Mon, 19 Mar 2001 11:28:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2JGTXM43158; Mon, 19 Mar 2001 11:29:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15030.13293.367043.926606@gargle.gargle.HOWL> Date: Mon, 19 Mar 2001 11:29:33 -0500 (EST) From: James Carlson To: Che min Hsieh Cc: "ietf-ppp@merit.edu" Subject: Re: MPLS tagging over PPP In-Reply-To: Che min Hsieh's message of 19 March 2001 08:49:45 References: <3AB29C4A.ED55D1@tddny.fujitsu.com> <15026.63599.600280.22320@h006008986325.ne.mediaone.net> <3AB60E79.465B936F@tddny.fujitsu.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Che min Hsieh writes: > Let's say a service provider is providing Remote MAC bridge service to > customers. > > Customer A has LAN port A1 of 10/100bt , WAN port WA1, remote WAN port WA2, > and LAN port A2 of 10/100bt. The WA1, and WA2 are connected by PPP on POS > over OC3c > > Customer B has LAN port B1 of 10/100bt, WAN port WB1, remote WAN port WB2, > and LAN port B2 of 10/100bt. The WB1, and WB2 are connected by another PPP > on POS over OC3c OK. > BCP, LCP, POS will be fine in this case. > > But if the service provider says, it is a waste of WAN bandwidth. The LAN > port bandwith is 100 meg , but the POS is 150 meg. How about let them > share the same OC3c path, and have some statistical gain, if possible. I'm not sure I follow you here. How do you get a single STS-3c from the provider to terminate at multiple sites? Aren't STS-3c paths point-to-point? In any event, read the BCP document (RFC 2878). It includes VLAN support, which will do approximately what you're asking. (What you're asking doesn't entirely make sense to me. As a customer, why do I want Ethernet bridging service? IP connectivity would seem to be much better, and avoids issues like this. But, then, they're your customers ...) > There needs to have a multiplexing/demultiplexing scheme to distinguish > which flow of traffic it is. MPLS label seems not able to help. It has > the addr, control, protocol (=mpls), label, network header ( =IP), ... > What we need is after the label, it carries the MAC frame. If you use MPLS, you can stack any number of labels to get the tunnel multiplexing to work the way you want. If you need more information than that, I'd recommend hiring a consultant. Network design is a little hard to do by email, and is certainly not appropriate for an IETF mailing list. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Mar 19 11:37:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14765 for ; Mon, 19 Mar 2001 11:37:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5D345DE96; Mon, 19 Mar 2001 11:36:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A184D5DDAC; Mon, 19 Mar 2001 11:36:48 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8F6875DE86 for ; Mon, 19 Mar 2001 11:36:46 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29854; Mon, 19 Mar 2001 08:36:10 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27496; Mon, 19 Mar 2001 11:36:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2JGak243212; Mon, 19 Mar 2001 11:36:46 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15030.13726.599211.992025@gargle.gargle.HOWL> Date: Mon, 19 Mar 2001 11:36:46 -0500 (EST) From: James Carlson To: "Kim Edwards" Cc: ietf-ppp@merit.edu Subject: Re: LQM over SONET In-Reply-To: Kim Edwards's message of 19 March 2001 08:19:10 References: <3AB22C1D.66E6EB21@americasm01.nt.com> <15026.36560.726783.571021@gargle.gargle.HOWL> <3AB6074E.1F0479B3@americasm01.nt.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Kim Edwards writes: > ... my intention was to use the SONET PMs for link quality, but I have also > been requested to support LQM. I cannot find anyone POS interfaces in the > market that support LQM. > > Do you know of any POS devices using LQM? Don't Cisco GSR-12000 routers do this? I worked on LQM support at Ironbridge, but that product never saw daylight. > ... I am not affraid of congestion on the link; our box has such a rich > feature set, that I am affraid software will not be able to keep up with all > of the processing (stats collection, SONET APS processing, SONET PMs, MPLS, > IP, PPP, LQM, MLT ...) Except for extreme circumstances -- if, for example, nobody could implement the protocol -- the standards process really doesn't address such issues. The standard IETF response is that you need to solve that problem yourself. Buy a faster CPU, distribute the load among multiple processors, design hardware assistance, et cetera. It's a system design issue, not a protocol issue. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Mar 20 18:56:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02419 for ; Tue, 20 Mar 2001 18:56:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F1B75DE6D; Tue, 20 Mar 2001 18:55:22 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6FA445DE70; Tue, 20 Mar 2001 18:55:22 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BC2715DE6D for ; Tue, 20 Mar 2001 18:55:20 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26546 for ; Tue, 20 Mar 2001 15:55:20 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19834 for ; Tue, 20 Mar 2001 18:55:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2KNtua44951; Tue, 20 Mar 2001 18:55:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15031.60939.739862.473634@gargle.gargle.HOWL> Date: Tue, 20 Mar 2001 18:55:55 -0500 (EST) From: James Carlson To: pppext Subject: Secure Remote Password interest X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I asked this at the working group meeting today, and I'd like to put it to the group at large: if there are folks out there looking at the EAP SRP-SHA1 draft (draft-ietf-pppext-eap-srp-01.txt) please let me know; either privately or on the list. I have tested an implementation based on ANU ppp-2.4.0, and I'm planning to release this under a BSD license (pending some document signatures within Sun). This could serve as a reference implementation for testing purposes. I've gotten reports from the open source community that there's user interest, mostly because it fixes the CHAP shared secret problem. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Mar 20 19:36:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04052 for ; Tue, 20 Mar 2001 19:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1040B5DED7; Tue, 20 Mar 2001 19:34:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EDC875DED6; Tue, 20 Mar 2001 19:34:19 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id E04155DED5 for ; Tue, 20 Mar 2001 19:34:17 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2L0YG525294 for ietf-ppp@merit.edu env-from ; Tue, 20 Mar 2001 17:34:16 -0700 (MST) Date: Tue, 20 Mar 2001 17:34:16 -0700 (MST) From: Vernon Schryver Message-Id: <200103210034.f2L0YG525294@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > I asked this at the working group meeting today, and I'd like to put > it to the group at large: if there are folks out there looking at the > EAP SRP-SHA1 draft (draft-ietf-pppext-eap-srp-01.txt) please let me > know; either privately or on the list. > > I have tested an implementation based on ANU ppp-2.4.0, and I'm > planning to release this under a BSD license (pending some document > signatures within Sun). This could serve as a reference > implementation for testing purposes. > > I've gotten reports from the open source community that there's user > interest, mostly because it fixes the CHAP shared secret problem. I'm worried by that last statement and this: Unlike CHAP (and variants MS-CHAPv1 [6] and MS-CHAPv2 [7]), access to the cleartext password is not required for the authenticator. Does that community really understand the issue, or is it only reacting to the extremely energetic salesmanship of advocates of the various mechanisms that improve the security of cleartext password protocols? Is the CHAP shared secret problem worthy of attention, since in some important sense it is neither fixable nor fixed by this protocol? Because people consistently choose bad passphrases and because computers have become so fast, you must treat digests of passwords as if they were cleartext. If the bad guys can get a copy of the authenticator's database of verifiers, why can't they do dictionary attacks to recover the cleartext passwords? In other words, the warning in last paragraph of section 4 is far too weak given what most people will infer from the claim about cleartext passwords in the start of the draft. Please let's not make a new mistake like the incorrect claims about the security of MSCHAP compared to CHAP. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 09:26:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22112 for ; Wed, 21 Mar 2001 09:26:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id D630D5DDA2; Wed, 21 Mar 2001 09:25:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AE0855DDB8; Wed, 21 Mar 2001 09:25:42 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 35E165DDA2 for ; Wed, 21 Mar 2001 09:25:41 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11271; Wed, 21 Mar 2001 06:25:38 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26582; Wed, 21 Mar 2001 09:25:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2LEQEd45348; Wed, 21 Mar 2001 09:26:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15032.47621.640651.125266@gargle.gargle.HOWL> Date: Wed, 21 Mar 2001 09:26:13 -0500 (EST) From: James Carlson To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest In-Reply-To: Vernon Schryver's message of 20 March 2001 17:34:16 References: <200103210034.f2L0YG525294@calcite.rhyolite.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Vernon Schryver writes: > > From: James Carlson > > I've gotten reports from the open source community that there's user > > interest, mostly because it fixes the CHAP shared secret problem. > > I'm worried by that last statement and this: > > Unlike CHAP (and variants MS-CHAPv1 [6] and > MS-CHAPv2 [7]), access to the cleartext password is not required for > the authenticator. Have you read the SRP documentation (RFC 2945)? This is an asymmetric system. The mechanism described has these properties: - Authentication of a peer can be done using a non-invertible hash of the passphrase. - Proof of identity requires access to the original passphrase. - The hash cannot be used as proof of identity. > Does that community really understand the issue, or is it only reacting > to the extremely energetic salesmanship of advocates of the various > mechanisms that improve the security of cleartext password protocols? This is not a cleartext password protocol. > Is the CHAP shared secret problem worthy of attention, since in > some important sense it is neither fixable nor fixed by this protocol? Please explain that statement. The shared secret problem (at least as fixed by this protocol) is that the authenticator must also have access to the passphrase in order to authenticate. This allows the authenticator to masquerade as the authenticatee, and for common deployments invites attack of the database that holds many shared secrets. SRP does not have those problems. > Because people consistently choose bad passphrases and because computers > have become so fast, you must treat digests of passwords as if they > were cleartext. If the bad guys can get a copy of the authenticator's > database of verifiers, why can't they do dictionary attacks to recover > the cleartext passwords? Dictionary attacks are always possible against stolen hashes. However, they can be made quite infeasible. You're right that this protocol doesn't prevent fools from choosing bad passwords. Determined fools are hard to stop. However, with well-chosen passphrases, SRP is a significant set up from CHAP. The "hash" used for SRP passphrases isn't your run-of-the-mill message digest. It's the result of modular exponentiation. I expect that it's attackable using the same methods as are used for RSA. For long keys, that's hard. (On a 366MHz P-II and using a 1500 bit modulus, I was able to try one key every 10 seconds.) > In other words, the warning in last paragraph of section 4 is far too > weak given what most people will infer from the claim about cleartext > passwords in the start of the draft. Please let's not make a new mistake > like the incorrect claims about the security of MSCHAP compared to CHAP. MS-CHAP's error is not comparable here. MS-CHAP merely throws a thin veneer of MD4 on top of a vaguely CHAP-ish protocol. It uses this hash as the shared secret -- neither authenticator nor authenticatee needs access to the "user password." The hash alone is enough to authenticate with MS-CHAP. SRP is different. An authenticatee cannot use the hash alone to authenticate. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 11:25:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28470 for ; Wed, 21 Mar 2001 11:25:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F3C25DD99; Wed, 21 Mar 2001 11:25:04 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1ABA05DDB8; Wed, 21 Mar 2001 11:25:04 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 447205DD99 for ; Wed, 21 Mar 2001 11:25:02 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2LGP1409937 for ietf-ppp@merit.edu env-from ; Wed, 21 Mar 2001 09:25:01 -0700 (MST) Date: Wed, 21 Mar 2001 09:25:01 -0700 (MST) From: Vernon Schryver Message-Id: <200103211625.f2LGP1409937@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > Have you read the SRP documentation (RFC 2945)? This is an asymmetric > system. The mechanism described has these properties: > > - Authentication of a peer can be done using a non-invertible > hash of the passphrase. > > - Proof of identity requires access to the original > passphrase. > > - The hash cannot be used as proof of identity. That also describes the ancient UNIX user authentication scheme. What SRP and other so called zero-knowledge schemes add are ways to not put the cleartext password on the wire and ways to make the old UNIX hash computation perhaps 1000 times slower. > > Does that community really understand the issue, or is it only reacting > > to the extremely energetic salesmanship of advocates of the various > > mechanisms that improve the security of cleartext password protocols? > > This is not a cleartext password protocol. Yes, but there are good (and bad) reasons why the people selling SRP and so called zero-knowledge authentication systems so often contrast their systems with protocols using cleartext and badly chosen passwords. > > Is the CHAP shared secret problem worthy of attention, since in > > some important sense it is neither fixable nor fixed by this protocol? > > Please explain that statement. I think the CHAP shared secret problem is that both authenticator and authenticatee must know something determined by a shared secret. In real life, passwords have only a couple dozen bits of entropy but there are 2**24 milliseconds in a week. At best passwords used by humans are among 3 or 4 word strings from a college dictionary plus all of "Bartlett's Familiar Quotations." That implies that given access to the hash of the secret and time to try 1,000,000's of guesses, access to a hash of the passphrase is equivalent to access to the passphrase. If the shared secret involved 100 bits of entropy, then SRP would be a complete fix. Perhaps at heart the problem is that the difference between 100 and 20 bits of entropy is not a factor of 5 or even 80, but of 1,000,000,000,000,000,000,000,000. > The shared secret problem (at least as fixed by this protocol) is that > the authenticator must also have access to the passphrase in order to > authenticate. This allows the authenticator to masquerade as the > authenticatee, and for common deployments invites attack of the > database that holds many shared secrets. > > SRP does not have those problems. If SRP were used with passwords with hundreds of bits of entropy (e.g. smart cards), that would be accurate, but this is real life. What an Internet Service Provider can ask a customer to type into a Windows dialog box is severely restricted, not by Microsoft but by human nature. Every third time when I type a Microsoft product key with its apparent 128 bits of entropy, get one of the letters or digits wrong or transposed, and fail to see it for several minutes, I'm reminded of this fact. > > Because people consistently choose bad passphrases and because computers > > have become so fast, you must treat digests of passwords as if they > > were cleartext. If the bad guys can get a copy of the authenticator's > > database of verifiers, why can't they do dictionary attacks to recover > > the cleartext passwords? > > Dictionary attacks are always possible against stolen hashes. > However, they can be made quite infeasible. You're right that this > protocol doesn't prevent fools from choosing bad passwords. > Determined fools are hard to stop. However, with well-chosen > passphrases, SRP is a significant set up from CHAP. Yes, but have you tried choosing UNIX passwords that be remembered and typed accurately and that are resistent to the standard dictionary based hash breaking tools? I have and have been extremely discouraged. My point is that the draft ought to say that unless the secrets have 100 bits of entropy, there is little difference between this scheme and CHAP and therefore the file of hashes must be kept as secret as the UNIX /etc/passwd file or CHAP cleartext passwords, and that in real lifew, passwords are exceptional if they have 20 instead of 10 bits of entropy. > The "hash" used for SRP passphrases isn't your run-of-the-mill message > digest. It's the result of modular exponentiation. I expect that > it's attackable using the same methods as are used for RSA. For long > keys, that's hard. (On a 366MHz P-II and using a 1500 bit modulus, I > was able to try one key every 10 seconds.) The Diffie-Hellman code I've used and shipped was all in C, but needed only about a second per exponentiaion on a Dell 200 MHz P-II with Borland's 5.0 C compiler. If you don't care about portability, you can make even that a lot faster. Still, if this SRP-PPP proposal needs even 1 second of computing per PPP authentication, then I doubt PPP hardware vendors or customers will be enthused--to grossly understate that problem. But that's not my point. The lesson to be learned from the history of UNIX passwords is that if the authentication computations are quick enough to be tolerable, then they are too quick to significantly increase security for long. The UNIX authentication scheme used a modified form of DES intended to require a similar amount of computing. The idea was that the so much time was required to compute the UNIX hash that dictionary attacks were infeasable, although the phrase "dictionary attack" was not used. Consider the implications of the growing availability of hardware accelerators for HTTPS on how long modular exponentiations will require in 5 or 10 years. > > In other words, the warning in last paragraph of section 4 is far too > > weak given what most people will infer from the claim about cleartext > > passwords in the start of the draft. Please let's not make a new mistake > > like the incorrect claims about the security of MSCHAP compared to CHAP. > > MS-CHAP's error is not comparable here. MS-CHAP merely throws a thin > veneer of MD4 on top of a vaguely CHAP-ish protocol. It uses this > hash as the shared secret -- neither authenticator nor authenticatee > needs access to the "user password." The hash alone is enough to > authenticate with MS-CHAP. Yes, but that was not the big mistake of MSCHAP. The mistake was not that MSCHAP was a bad idea, since it was a good idea, The problem was that the MSCHAP selling was based on snake-oil. It was sold as being significantly more secure than CHAP, when it fact it was only more secure against the unithinking or unmotivated. That is worthwhile, but nothing to write home about. (Never mind the errors that made MSCHAP significantly less secure in some situations, since they have nothing to do with the good idea in MSCHAP.) This PPP proposal with the passwords that will be used in real life is better than CHAP, but *PLEASE* let's not over-sell it. > SRP is different. An authenticatee cannot use the hash alone to > authenticate. No! If an authenticatee can reduce the set of possible secrets to, for example, the words in a college dictionary, and has merely a typical 2000 vintage PC, then an authenticatee can break the hash within 24 hours. A less inaccurate description of the advantage of SRP is that if the secret is uncharacteristically and implausibly well chosen or if the authenticatee that cannot do more than one D-H exponentiation in a second, then the authenticatee cannot use the hash alone. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 11:50:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29703 for ; Wed, 21 Mar 2001 11:50:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id B47955DEA9; Wed, 21 Mar 2001 11:47:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DA335DEAB; Wed, 21 Mar 2001 11:47:50 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id CFC635DEA9 for ; Wed, 21 Mar 2001 11:47:48 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19391; Wed, 21 Mar 2001 08:47:42 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22226; Wed, 21 Mar 2001 11:47:37 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2LGmE245490; Wed, 21 Mar 2001 11:48:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15032.56141.780709.251843@gargle.gargle.HOWL> Date: Wed, 21 Mar 2001 11:48:13 -0500 (EST) From: James Carlson To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest In-Reply-To: Vernon Schryver's message of 21 March 2001 09:25:01 References: <200103211625.f2LGP1409937@calcite.rhyolite.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Vernon Schryver writes: > I think the CHAP shared secret problem is that both authenticator and > authenticatee must know something determined by a shared secret. Here we disagree. Storing something that's trivially useful on a server is quite a different thing from storing something that's hard to use. We can't set policy here. Perhaps it would be a good thing to have a BCP on choosing passwords, how often to change them, and such. This is not a problem with the protocol, though. What the protocol really does is stop people from asking for stupid changes. A frequently asked question is "how do I encrypt my CHAP passwords?" Another is "how do I make it work with LDAP/NIS/whatever?" The proper answer is "no." Those things are avoided with SRP. As I said before, SRP isn't going to make stupid users smarter. I have no illusions about that and I suspect that it's a fundamentally unsolvable problem. All that can be done is make the smart ones safer. SRP *does* do that. > In > real life, passwords have only a couple dozen bits of entropy but there > are 2**24 milliseconds in a week. At best passwords used by humans are > among 3 or 4 word strings from a college dictionary plus all of "Bartlett's > Familiar Quotations." That implies that given access to the hash of > the secret and time to try 1,000,000's of guesses, access to a hash of > the passphrase is equivalent to access to the passphrase. It depends. Small things, like abbreviations (the common password on many Xylogics systems was once "LicGio"; would you get that out of your dictionary?) make the attack much harder. > If SRP were used with passwords with hundreds of bits of entropy > (e.g. smart cards), that would be accurate, but this is real life. > What an Internet Service Provider can ask a customer to type into a Windows > dialog box is severely restricted, not by Microsoft but by human nature. > Every third time when I type a Microsoft product key with its apparent > 128 bits of entropy, get one of the letters or digits wrong or transposed, > and fail to see it for several minutes, I'm reminded of this fact. I agree that's a problem, but I think it's out of scope. We don't deal with user interfaces here, do we? > Yes, but have you tried choosing UNIX passwords that be remembered > and typed accurately and that are resistent to the standard dictionary > based hash breaking tools? I have and have been extremely discouraged. I agree that there's user interface and deployment issues here. > My point is that the draft ought to say that unless the secrets have 100 > bits of entropy, there is little difference between this scheme and CHAP > and therefore the file of hashes must be kept as secret as the UNIX > /etc/passwd file or CHAP cleartext passwords, and that in real lifew, > passwords are exceptional if they have 20 instead of 10 bits of entropy. OK; I can note that good password choice is hard and that choosing bad passwords makes a dictionary attack much easier. The situation is still far better than CHAP. If you steal the secrets from a CHAP authenticator, then you're in with no work at all. It doesn't matter how good the secrets are. The real issue is that users have to evaluate the threat model and adjust accordingly. For many common configurations, SRP is simply much better than CHAP. It doesn't have the same exposure. In general, I think SRP does enough. Who is going to spend millions to break security on something that's worth only a few dollars, like an ISP account? If what you're protecting is a lot more valuable, then you need to take that into account, but that's out of our scope. > The Diffie-Hellman code I've used and shipped was all in C, but needed > only about a second per exponentiaion on a Dell 200 MHz P-II with Borland's > 5.0 C compiler. The time I quoted was actually for the entire authentication exchange with a 1500 bit modulus. There are several exponentiations and other operations in there. Probably not an issue, though. > Yes, but that was not the big mistake of MSCHAP. The mistake was not > that MSCHAP was a bad idea, since it was a good idea, The problem > was that the MSCHAP selling was based on snake-oil. It was sold as > being significantly more secure than CHAP, when it fact it was only > more secure against the unithinking or unmotivated. That is worthwhile, > but nothing to write home about. (Never mind the errors that made > MSCHAP significantly less secure in some situations, since they have > nothing to do with the good idea in MSCHAP.) No. In fact, the MD4 hash is the shared secret. It is therefore equivalent to CHAP. It's not a good idea. It's not worthwhile. (And yes there are also flaws that make it *less* secure than CHAP.) > This PPP proposal with the passwords that will be used in real life > is better than CHAP, but *PLEASE* let's not over-sell it. OK. Any suggested text? > A less inaccurate description of the advantage of SRP is that if > the secret is uncharacteristically and implausibly well chosen or > if the authenticatee that cannot do more than one D-H exponentiation > in a second, then the authenticatee cannot use the hash alone. I mean text that would be useful in a draft. :-/ -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 13:08:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04014 for ; Wed, 21 Mar 2001 13:08:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEBC35DD9E; Wed, 21 Mar 2001 13:07:04 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A8B885DDC9; Wed, 21 Mar 2001 13:07:04 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id C0A8C5DD9E for ; Wed, 21 Mar 2001 13:07:02 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2LI72e11781 for ietf-ppp@merit.edu env-from ; Wed, 21 Mar 2001 11:07:02 -0700 (MST) Date: Wed, 21 Mar 2001 11:07:02 -0700 (MST) From: Vernon Schryver Message-Id: <200103211807.f2LI72e11781@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > I agree that's a problem, but I think it's out of scope. We don't > deal with user interfaces here, do we? On the contrary, we must deal with how PPP can and will be used in real life. Real life dictates that the entropy of passwords is low. Moreover, the draft already makes statements touching on this issue. > ... > OK; I can note that good password choice is hard and that choosing bad > passwords makes a dictionary attack much easier. I'd feel better with stronger words than those. Part of my problem is that I've argued in public with Thomas Wu and others about so called zero knowledge password systems and feel that they advocate their schemes as ways to make garbage passwords tolerable on Duh Internet. When pressed on that issue, they agree (Thomas Wu more readily than others) that garbage passwords are always Double Plus Not Good(tm). For the sort of thing that has sensitized my hackles, please read http://www-cs-students.stanford.edu/~tjw/srp/analysis.html Is is simply wrong to claim as he does that CHAP amounts to "weak authentication." > The situation is still far better than CHAP. If you steal the secrets > from a CHAP authenticator, then you're in with no work at all. It > doesn't matter how good the secrets are. > > The real issue is that users have to evaluate the threat model and > adjust accordingly. For many common configurations, SRP is simply > much better than CHAP. It doesn't have the same exposure. No, the most important exposure remains unchanged. That is really bad passwords, such as username and password the same. SRP does nothing against really bad passwords, which is ok, since nothing can help there. It's not ok that common sales literature implies that such protocols do help against really bad passwords. The IETF should not endorse or repeat that snake oil. SRP is like using the stength of the passwords themselves to protect the CHAP cleartext database. That's worthwhile, but not what is commonly claimed, that CHAP is "weak authentication" and SRP is strong. Contrary to the claims of SRP and zero-knowledge advocates, because of the random challenge all but the really bad CHAP passwords are proof against on-line attacks (only on the wire, no access to the cleartext database). > > Yes, but that was not the big mistake of MSCHAP. The mistake was not > > that MSCHAP was a bad idea, since it was a good idea, The problem > > was that the MSCHAP selling was based on snake-oil. It was sold as > > being significantly more secure than CHAP, when it fact it was only > > more secure against the unithinking or unmotivated. > ... > No. In fact, the MD4 hash is the shared secret. It is therefore > equivalent to CHAP. It's not a good idea. It's not worthwhile. (And > yes there are also flaws that make it *less* secure than CHAP.) Making the shared, cleartext password secret be something other than what the unthinking user thinks is nothing to write home about and it had no effect on the security of the system against a motivated and thinking attacker. Still, it does significantly protect against casual attackers, and as you say elsewhere, that is important when what you're talking about something such as a PPP connection with so little value. MSCHAP was a major security improvement in protecting the authenticator's database only if you make the obviously false assumption that no one is smart enough to use the MD4 hash of the nominal password. PPP-SRP similarly protects the authenticator's database only if you make the obviously false assumption that real passwords resist not only on-line but also off-line attacks. When talking about a security protocol, you can't close a hole by labeling it mere human nature or a user interface interface issue. Whether you're selling MSCHAP, SRP, or zero-knowledge passwords, you don't get to adjust reality to prove a protocol's security. > ... > I mean text that would be useful in a draft. :-/ The user's choice password SHOULD be restricted to limit the effectiveness of dictionary attacks. However, unless the individaul passwords or secrets are uncharacteristically well chosen, the hash values stored in the authenticator's database MUST be protected against disclosure. In practice, even when the user's choices of passwords is restricted, passwords have only a couple dozen bits of entropy. Off-line dictionary attacks on the database of hashes are feasable unless the each password has 100 or more bits of entropy. Even passphrases are rarely that strong. Thus, the authenticator's database MUST also be kept secret much as the UNIX /etc/passwd or /etc/shadow are today. The password generators and limiters I've seen force users to have better passwords, but they are still far short of resistent to serious dictionary attacks. I personally think that the password generators are a bad idea, since they merely force users to put their passwords on Postit Notes next to their monitors, but that's not entirely relevant to PPP. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 13:26:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05212 for ; Wed, 21 Mar 2001 13:26:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id F04A35DDD0; Wed, 21 Mar 2001 13:26:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D83945DDE7; Wed, 21 Mar 2001 13:26:15 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E668C5DDD0 for ; Wed, 21 Mar 2001 13:26:13 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03007; Wed, 21 Mar 2001 10:26:11 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10270; Wed, 21 Mar 2001 13:26:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2LIQlm45591; Wed, 21 Mar 2001 13:26:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15032.62054.676364.865384@gargle.gargle.HOWL> Date: Wed, 21 Mar 2001 13:26:46 -0500 (EST) From: James Carlson To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest In-Reply-To: Vernon Schryver's message of 21 March 2001 11:07:02 References: <200103211807.f2LI72e11781@calcite.rhyolite.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Vernon Schryver writes: > For the sort of thing that has sensitized my hackles, please read > http://www-cs-students.stanford.edu/~tjw/srp/analysis.html > Is is simply wrong to claim as he does that CHAP amounts to "weak > authentication." I agree with that. The problem with CHAP isn't on the wire. It's in the database. > No, the most important exposure remains unchanged. That is really > bad passwords, such as username and password the same. There's more than one exposure here. CHAP has the same dictionary guessing exposure as SRP. If I trap a CHAP Challenge and Response from the wire, then I can use a dictionary attack to reveal the shared password used to generate that given Response from that given Challenge. for (i in guesses) if MD5(id,i,chal)=response print i; At least theoretically, having multiple different Challenges and Responses should make this attack easier by giving additional key material. The random ID does no good here. SRP essentially moves this same vulnerability out to the database. > SRP does > nothing against really bad passwords, which is ok, since nothing can > help there. It's not ok that common sales literature implies that > such protocols do help against really bad passwords. The IETF should > not endorse or repeat that snake oil. Fine; I can certainly have a "no bad passwords" statement in the draft. I've already agreed that this is a reasonable thing to do. > SRP is like using the stength of the passwords themselves to protect the > CHAP cleartext database. That's worthwhile, but not what is commonly > claimed, that CHAP is "weak authentication" and SRP is strong. Contrary > to the claims of SRP and zero-knowledge advocates, because of the random > challenge all but the really bad CHAP passwords are proof against on-line > attacks (only on the wire, no access to the cleartext database). As described above, that's not true. If you can mount a dictionary attack against the SRP hashes, then you can mount the same attack against the CHAP Response values. It's no different. In fact, it's a little easier to do with CHAP; less computation involved. > Making the shared, cleartext password secret be something other than what > the unthinking user thinks is nothing to write home about and it had no > effect on the security of the system against a motivated and thinking > attacker. Still, it does significantly protect against casual attackers, > and as you say elsewhere, that is important when what you're talking about > something such as a PPP connection with so little value. The problem was that the security of the hash itself was sold as an improvement. This part is a lie. It's not an improvement. In fact, since administrators often think of the hashes as more secure, it's a significant problem. They now have what appear to be nice hashes, but are actually cleartext passwords. > MSCHAP was a major security improvement in protecting the authenticator's > database only if you make the obviously false assumption that no one is > smart enough to use the MD4 hash of the nominal password. PPP-SRP > similarly protects the authenticator's database only if you make the > obviously false assumption that real passwords resist not only on-line > but also off-line attacks. When talking about a security protocol, you > can't close a hole by labeling it mere human nature or a user interface > interface issue. Whether you're selling MSCHAP, SRP, or zero-knowledge > passwords, you don't get to adjust reality to prove a protocol's security. I don't think it's reasonable to say that we're going to somehow upgrade the users themselves through force of IETF documents. I'm not making the assumption that real and bad passwords resist reasonably determined attacks. I am making the assumption that good passwords do resist such attacks, and the current state of the art (prior to SRP) does *NOT* allow the administrator to take advantage of that. I don't think it's possible to fix the stupid user problem by IETF documentation. I'd like to avoid trying to do the impossible and stick to the protocols. Do you disagree that SRP is an improvement over CHAP and PAP? [...] > entropy. Even passphrases are rarely that strong. Thus, the > authenticator's database MUST also be kept secret much as the UNIX > /etc/passwd or /etc/shadow are today. Perfect; that fits the situation exactly. Thanks; I'll add it to the next update. > The password generators and limiters I've seen force users to have better > passwords, but they are still far short of resistent to serious dictionary > attacks. I personally think that the password generators are a bad idea, > since they merely force users to put their passwords on Postit Notes next > to their monitors, but that's not entirely relevant to PPP. True ... -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 13:41:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06021 for ; Wed, 21 Mar 2001 13:41:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF9BB5DDE7; Wed, 21 Mar 2001 13:40:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DE5BA5DDE9; Wed, 21 Mar 2001 13:40:43 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 678F35DDE7 for ; Wed, 21 Mar 2001 13:40:42 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.3/8.11.3) id f2LIegw12402 for ietf-ppp@merit.edu env-from ; Wed, 21 Mar 2001 11:40:42 -0700 (MST) Date: Wed, 21 Mar 2001 11:40:42 -0700 (MST) From: Vernon Schryver Message-Id: <200103211840.f2LIegw12402@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > There's more than one exposure here. CHAP has the same dictionary > guessing exposure as SRP. If I trap a CHAP Challenge and Response > from the wire, then I can use a dictionary attack to reveal the shared > password used to generate that given Response from that given > Challenge. for (i in guesses) if MD5(id,i,chal)=response print i; > > At least theoretically, having multiple different Challenges and > Responses should make this attack easier by giving additional key > material. > > The random ID does no good here. > > SRP essentially moves this same vulnerability out to the database. > ... That's a quite good point in favor of SRP and against CHAP that should be made more clear in the draft. CHAP is vulnerable to dictionary attacks even when the bad guy does not have access to the database. The price of a modular exponentiation in SRP forces dictionary attackers to get the hash database. If I were writing the draft, I'd flog that aspect more than replacing the CHAP cleartext database. With reasonable operating systems, read-only access to the CHAP cleartext database often implies write-access, and write-access ends the game for any authentication scheme including SRP. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 14:56:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10421 for ; Wed, 21 Mar 2001 14:56:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 449205DF29; Wed, 21 Mar 2001 14:53:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 30DCF5DE67; Wed, 21 Mar 2001 14:53:26 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 580BB5DF1C for ; Wed, 21 Mar 2001 14:53:24 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26766; Wed, 21 Mar 2001 11:53:22 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26808; Wed, 21 Mar 2001 14:53:21 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2LJrr745774; Wed, 21 Mar 2001 14:53:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15033.1745.453819.921776@gargle.gargle.HOWL> Date: Wed, 21 Mar 2001 14:53:53 -0500 (EST) From: James Carlson To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Secure Remote Password interest In-Reply-To: Vernon Schryver's message of 21 March 2001 11:40:42 References: <200103211840.f2LIegw12402@calcite.rhyolite.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Vernon Schryver writes: > That's a quite good point in favor of SRP and against CHAP that should be > made more clear in the draft. OK, I will do that. > CHAP is vulnerable to dictionary attacks even when the bad guy does not > have access to the database. The price of a modular exponentiation > in SRP forces dictionary attackers to get the hash database. I'm not sure if that's true. I think the risk of the data on the wire is the same as that for the database for SRP. I'm not an expert though. > If I were writing the draft, I'd flog that aspect more than replacing the > CHAP cleartext database. With reasonable operating systems, read-only > access to the CHAP cleartext database often implies write-access, and > write-access ends the game for any authentication scheme including SRP. True, but I'd say sometimes instead. Think of leaky web servers and the like -- lots of things can grant read-only access. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 14:59:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10598 for ; Wed, 21 Mar 2001 14:59:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DDB05DF83; Wed, 21 Mar 2001 14:56:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 319915DFBF; Wed, 21 Mar 2001 14:56:45 -0500 (EST) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 78FB45DFB1 for ; Wed, 21 Mar 2001 14:56:43 -0500 (EST) Received: from karl-w98l.xc.org (pcp001284pcs.wireless.meeting.ietf.org [135.222.67.16]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FJJRV1T3; Wed, 21 Mar 2001 12:56:41 -0700 Message-Id: <4.3.2.7.2.20010321145234.00d05100@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Mar 2001 14:56:24 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: 50th IETF PPPEXT Meeting Minutes Cc: minutes@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks to Ross Wheeler for taking these minutes. Karl ---------------------------------------------------- EAP SIM Authentication (Version 1) draft-haverinen-pppext-eap-sim-00.txt Henry Haverinen Presentation Comments: Went over presentation... Questions/Comment: Henry: this is a new EAP type - what is the policy here? Karl: Do your best and we'll set it up. Matt: Key management protocol - passing distributed keys was frowned upon. Please contact Bernard Aboba. Mark: send the AAA AD a question regarding. Mark: Experimental - EAP TLS is already... Matt: Do your draft ask the chair to see if there is consensus to being a standard and see what happens after that. Henry: has the IANA number Matt: remove the word RADIUS Jari: UMTS authentication ? Henry: just for GSM ---------------------------------------------------- Class Extensions for PPP over AAL2 draft-brucet-pppext-ppp-over-aal2-class-00.txt PPP over AAL2 draft-ietf-pppext-ppp-over-aal2-00.txt Bruce Thompson Presentation Comments: Went over presentation... Is there a need for CRC8? Karl: Get rid of it. Questions/Comments: Karl: Can you use PPPMUX? Bruce: would not be applicable... Response: PPPMUX introduces delay. So maybe that's why? Karl: Can you use PPPMUX to reduce ? Bruce: Yes. Question: AAL2 Work item question 4 traffic measurement studies. Bruce: Question 15 - people expecting a specific SID scheduling algorithm Bruce: What next? Karl: Last call? Karl: Anybody object to it being a working group item? Karl: Done -------------------------------------------------------------------------- IP Header Compression over PPP draft-koren-avt-crtp-ipcp-00.txt Tmima Koren Presentation Question: Requesting to accept this as a work group item... Questions/Comments: Karl: Any objections to being a work group item? Karl: Accepted! ----------------------------------------------------------------- Call for Volunteers - document editors, implementation questionnaire. Karl Fox Need to demonstrate two independent implementations Come up afterward and discuss with Karl. It will be posted to the list. ----------------------------------------------------------------- Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Wed Mar 21 15:46:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13285 for ; Wed, 21 Mar 2001 15:46:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C2355DF18; Wed, 21 Mar 2001 15:19:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 43FED5DF1B; Wed, 21 Mar 2001 15:19:52 -0500 (EST) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id C62CB5DF18 for ; Wed, 21 Mar 2001 15:19:50 -0500 (EST) Received: from karl-w98l.xc.org (pcp001284pcs.wireless.meeting.ietf.org [135.222.67.16]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FJJRV1VG; Wed, 21 Mar 2001 13:19:49 -0700 Message-Id: <4.3.2.7.2.20010321145727.00d036d0@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Mar 2001 15:19:31 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: Request for Implementation Questionnaire Authors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu RFC 2026 (The Internet Standards Process -- Revision 3) specifies that, for protocol documents to advance from Proposed Standard to Draft Standard, at least two independent and interoperable implementations must exist. This requirement applies not only to the protocol as a whole, but also to all of the options and features of the specification. If one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to Draft Standard only if those options or features are removed. It is my responsibility as Chair to provide documentation supporting the assertion of interoperability when we ask the IESG to advance the document. However, I have not been an implementor for several years, while many of you are or have recently been involved with implementing many of the protocols under consideration. Please help me out. I need volunteers willing to examine each of the below documents and come up with a list of "options or features" that I can use in an implementation questionnaire so that we can move these documents forward. Please do not respond to the list; send e-mail to me privately at karl@xc.org. Please include the RFC (or RFCs) you would like to examine. RFC 1332, IPCP RFC 1962, CCP RFC 1968, ECP RFC 1618, PPP over ISDN RFC 1471, LCP MIB RFC 1472, CHAP MIB RFC 1473, IPCP MIB RFC 2878, BCP (the new one with VLAN support) Thanks, Karl Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Tue Mar 27 08:45:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17986 for ; Tue, 27 Mar 2001 08:45:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9D095DDB3; Tue, 27 Mar 2001 08:44:22 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B01845DE36; Tue, 27 Mar 2001 08:44:22 -0500 (EST) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 874665DDB3 for ; Tue, 27 Mar 2001 08:44:20 -0500 (EST) Received: from karl-w98l.xc.org (ai70-020.aiinet.com [38.195.70.20]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FJJRVMP0; Tue, 27 Mar 2001 06:44:18 -0700 Message-Id: <4.3.2.7.2.20010327084024.053434a0@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Mar 2001 08:44:08 -0500 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: AODI to Informational Standard Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_809447==_" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --=====================_809447==_ Content-Type: text/plain; charset="us-ascii" Thomas and Erik, The PPPEXT Working Group recommends that Always On Dynamic ISDN (AODI), draft-ietf-pppext-aodi-02.txt (attached, as it has expired) be advanced to Informational Standard. --=====================_809447==_ Content-Type: text/plain; charset="us-ascii" PPPEXT Working Group Matt Holdrege Internet Draft Lucent Technologies Category: Standard March 2000 Always On Dynamic ISDN (AODI). Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Introduction: Always On/Dynamic ISDN (AO/DI) is a networking service that provides an always-available connection to TCP/IP-based services through a specific wide area connection. This service provides several advantages over current practices for dial-up access to Internet services. * For the end-user, there is no need to dial-up the service each time access is desired. * For the Internet service provider, it is possible to give the end- user a notification, such as the arrival of new mail. * For the Local Exchange Carrier, the switched circuit trunk utilization is more efficient. It should be understood that TCP/IP is the network protocol of choice for public data networks (Internet), and private data networks (Intranet) typically used for businesses. AO/DI does not Holdrege [Page 1] I-D Always On Dynamic ISDN March 2000 differentiate whether the user is connected to either the Internet or an Intranet, or both simultaneously. Further, the issues involved in either case are very similar as far as client behaviors and impact on the public telephony networks. The potential impact of Internet access is quite large. According to a recent survey, only 24% of US households have a computer with a modem. It's likely that most of these systems are not used on a regular basis for anything, much less Internet access. But this is changing quickly and already the relatively small number of users are having an impact on the network. There are similar predictions for other countries. Description of AO/DI Operation AO/DI is based on using existing infrastructure of modern central office switches and using The Bandwidth Allocation Control Protocol (RFC 2025). * Modern central offices are capable of supplying ISDN, and many of these central office switches are configured with X.25 packet handlers. * BACP is available in many remote access products. The basic idea of AO/DI is that an ISDN D-Channel X.25 connection is made from the subscriber to the Internet service provider. The multilink PPP protocol and TCP/IP protocols are encapsulated within the X.25 logical circuit carried by the D-Channel. The Bearer Channels are invoked as additional bandwidth is needed. The Bearer Channels use the multilink protocol without the Q.922 and X.25 encapsulation used on the D-Channel. I.e., a circuit-switched connection between the ISP and the client is established over the B- Channels over which IP packets are sent through PPP encapsulation. It is possible to offer a full-duplex, always-available services based on the fact that Because the ISDN physical-layer signalling (2B1Q synchronous modulation) and the Q.922 link layer are kept running at all times, even when there are no Q.931 messages being transceived. The physical and link layers allow for packets to be sent across a connection-oriented X.25 virtual circuit to be established between the Internet Service Provider and the subscriber. Further, because the D-Channel X.25 packets are handled at the central office by the X.25 packet handler, it is possible to route these packets without first crossing the time-division circuit- switched fabric of the switch, which reduces the impact to the telephony network. X.25 provides for two call types: a switched virtual circuit (SVC) and a permanent virtual circuit (PVC). Considerations are: * Not all the worlds Packet Handler implementations can be Holdrege [Page 2] I-D Always On Dynamic ISDN March 2000 guaranteed to support PVCs. * Some service providers that own the ISDN infrastructure may not be an ISP in their own right and may be providing ISPs with a standard X.31/X.75 delivery of D-Channel traffic. If this is the case, there is a need to use (and change) X.121 addresses in order for a user (of the CPE) to be able to change ISPs easily. I.e., using an SVC makes is simpler for the users to move to other ISPs, or to establish a connection to a corporate Intranet, as is required for telecommuters. * An SVC can be treated as a "permanent" connection. Once the call is established it does need not to be cleared and can remain in the data state in a similar manner to a PVC. * The success of X.25 networks was due in part to the use of SVCs and the ease of provisioning. Frame Relay, although successful, is extremely complex to provision because of its PVC implementation and the same would apply to a managed service provider solution. Given these considerations, AO/DI uses SVCs. Response to the Loss of an SVC Under certain conditions, the X.25 SVC may be cleared (disconnected). Conditions under the SVC could be cleared include, but are not limited to: * Inability to contact the subscriber. This could be due to the user terminal being turned off, an equipment problem due to hardware or software in the network or the user terminal, etc. * The result of the ISP clearing the call to redistribute the X.25 SVC across other LEC facilities due to traffic congestion. This action might be undertaken by an ISP to help distribute network loads across facilities. * An equipment problem in the network. While X.25 disconnects are considered highly unlikely, it is a matter of further study to control the frequency at which the user terminal attempts to re-establish the SVC. As certain failures (e.g. other than a user terminal problem) have a remote possibility to result in hundreds of endpoints simultaneously attempting to re- establish their connections which could be a substantial burden on the switch. When the X.25 SVC is disconnected, the terminal should attempt to re-establish the SVC at the earliest convenient time. It is suggested that the rate of re-establishments attempts within be limited to avoid excessive setup requests sent to the network. Holdrege [Page 3] I-D Always On Dynamic ISDN March 2000 Network Connection Sequence An example of the calling sequence is shown below: * The subscriber makes an X.25 connection to the Internet Service Provider (or Intranet Service Provider) * When additional bandwidth is needed, the appropriate phone numbers are exchanged between the subscriber's equipment and the Internet service provider's equipment to allow additional Bearer channels to be dialed. The Bearer Channels are routed through the switched fabric directly to the Internet service provider without the use of the packet handlers in the central office. Subsequent to successful connection, the multilink protocols are resolved to aggregate the additional bandwidth into a single transport connection. * The X.25 SVC will stop sending PPP payload when one or more B channels are in use. However, BACP messages may still be sent over the X.25 circuit. The Use of IETF RFC 1598 The IETF provides some guidelines for the use of PPP over X.25 in RFC 1598. Strictly speaking, RFC 1598 does not apply to AO/DI, but it has been used as a source of many useful concepts. The essential difference between AO/DI and RFC 1598 is that AO/DI treats X.25 as another dial-up resource, over which PPP is used to frame the data transmission, whereas RFC 1598 describes a way to replace the default HDLC header with an X.25 expanded HDLC header. Physical Layer Requirements From RFC 1598: PPP treats X.25 framing as a bit synchronous link. The link MUST be full-duplex, but MAY be either dedicated (permanent) or switched. AO/DI uses the X.25 as a synchronous transport; i.e., there are not character-based escape codes. The connection type is Switched Virtual Circuit, as previously discussed. Call User Data (CUD) Field From RFC 1598: When the link is configured as a Switched Virtual Circuit (SVC), the first octet in the Call User Data (CUD) Field (the first data octet in the Call Request packet) is used for protocol de-multiplexing, in accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC TR 9577 [5]. This field contains a one octet Network Layer Protocol Identifier (NLPID), which identifies the encapsulation in use over the X.25 virtual circuit. The CUD field MAY contain more than one octet of information. The PPP encapsulation MUST be indicated by the PPP NLPID value (CF Holdrege [Page 4] I-D Always On Dynamic ISDN March 2000 hex). Any subsequent octet in this CUD is extraneous and MUST be ignored. The call originator MUST set the NLPID of the CUD to 0xCF. The Data Link Layer From RFC 1598: Since both "PPP in HDLC Framing" [3] and X.25 use ISO 3309 as a basis for framing, the X.25 header is easily substituted for the smaller HDLC header. The PPP Protocol field and the following Information and Padding fields are described in RFC 1661. AO/DI recommends against header substitution by the transmitter. AO/DI uses the X.25 as a virtual PPP dial-up connection, so we recommend that the PPP header be part of the X.25 payload. This approach better isolates the protocol layers. It is desirable that X.25 receivers that expect the header substitution, also be able to properly function when the PPP header is included the X.25 payload. The PPP FCS MUST not be used in the X.25 PPP encapsulation on the D channel. Underlying Multilink Protocol Behaviors AO/DI MAY use the BACP multilink protocol to negotiate for bandwidth, manage phone number exchange, and to aggregate the bandwidth of subsequent connections. In today's multilink protocols (RFC's 1990 & 1934), the session originator (the end that placed the first call) is required to add the following call, thus incurring the additional charges, hence they are not symmetric in the sense that the session originator is obliged to add bandwidth. This is an acceptable model to many people, but not universally so. BACP, being a symmetric control protocol, allows either end of the Internet service to place a phone call to the other so that additional bandwidth can be added to the connection. Either side may request the other to originate the call or may refuse the request to originate the call, and may terminate a link in a bundle. In any case, it may be desirable to have a user interface that confirms with the user the request for additional bandwidth, should the users be sensitive to these charges. Strictly speaking, client (CPE) behavior is left to vendor-specific implementation. A vendor may choose to provide differentiation in the features, behaviors, and look-and-feel of the dialer (the software that controls the addition/subtraction of B-Channels) to Holdrege [Page 5] I-D Always On Dynamic ISDN March 2000 meet customer requirements for a specific business environment. For example: * for a voice call, the dialer would need to grant exclusive access of one of the B-Channels. * for requests to add B-Channels, the dialer may query the user to grant permission depending on the requester; a remote corporate access request might be granted automatically, whereas an unknown source would require manual intervention. Invoking Additional Bandwidth Given the relatively low net bandwidth of the Internet service due to the low bandwidth of the D-Channel (16 kbps total with 9600 bps guaranteed X.25 frame throughput) and the protocol encapsulation, TCP/IP over the D-Channel X.25 has limited applications. However, there are significant application domains where the low-bandwidth, always-available are useful such as * basic ASCII email services, * news feeds, and * automated data collection. Using BACP to Increase Bandwidth To increase the overall bandwidth beyond low-bandwidth of the D- Channel X.25 circuit, BACP messages are used to signal when Bearer Channels should be added to the link bundle. The B-Channels are invoked to temporarily boost data throughput, then the B-Channels are disconnected. This mode of operation statistically multiplexes the switch fabric and inter-office trunk lines across more users, thus reducing the traffic impact to the wide area network. Using the B-Channels for bandwidth-on-demand is good for both the Local Exchange Carrier and the Internet service provider as compared to having users "camp on" a Bearer Channel. AO/DI discourages X.25 spoofing (similar to the current method for spoofing ISDN B-Channel and modem dial-up connections) because 1) this is contrary to the design goals for AO/DI to provide constant connectivity without further intervention of the applications or the operating system, 2) X.25 spoofing is likely to create excessive numbers of X.25 setup messages which can degrade the network and increase the costs to the user, and 3) as distributed applications become more common, spoofing will become much less useful as connections will tend to last longer. This recommendation makes it possible for users to operate AO/DI capable protocol stacks even when the user's ISDN network interface card does not support AO/DI, or if the user does not have an AO/DI service due either to lack of facilities at the users ISP and/or at the LEC. Holdrege [Page 6] I-D Always On Dynamic ISDN March 2000 BACP Phone Deltas BACP was designed for use over a network with only a single numbering plan; i.e. multiple analog modem lines or multiple B- Channels. However, X.25 addresses are only E.164 or X.121. Further, special dialing sequences, such as '9' to access an outside line may not be applicable to X.25 calls. Additional numbers are exchanged in BACP using the concept of "deltas" whereby only the shortest string of digits needed to convey the change are sent. Since this is not guaranteed to work due to the differing numbering plans, AO/DI has a set of recommendations: * Separate X.25 Dial-up setup (likely different than E.164) * Don't use X.25 as base for first B-Channel delta; i.e. send first B-Channel in its entirety * Second B-Channel also sent to client in its entirety * Phone #s are national format only (e.g. N.A. 10 digits: area code+prefix+# ) * Local dialing exceptions are configured at the client (e.g. leading 9 to get outside line, or dialing codes for international access) * The technical subcommittee suggests the software provide an ability to have user-entered defaults. D-Channel Idling The following text proposes a method for idling a link of a Multilink PPP (MP-RFC 1990) bundle. Motivation An AO/DI ISDN MP bundle consists of one or two B-channel links, each running at either 56Kbps or 64Kbps, and an X.25 D-channel link running at 9600bps. To improve throughput and reduce connection costs, it is desirable to stop transferring data over the D-channel whenever at least one B-channel is in the bundle. Idling an MP link, however, causes a problem with the algorithm for detecting lost fragments. This algorithm depends on the value M; only fragments with sequence numbers less than M will be detected as lost. Since M is never incremented if a link is idle, the MP receiver could stall indefinitely (or until a timer expires) if a fragment is lost while one of the links is idle. What this all means is that if one side of an MP connection decides to stop transmitting data on one of the links, the receiver must be able to adapt its receiving algorithm accordingly. Idling a member link, therefore, must occur by mutual agreement between the sender Holdrege [Page 7] I-D Always On Dynamic ISDN March 2000 and the receiver. Recommended Behavior For AO/DI-compatible systems, the implicit algorithm for idling the D-channel shall be as follows: * When a link of 56Kbps or faster is added to an MP bundle that contains a link of 9600bps or slower: 1. Both transmitters should immediately cease transmitting all "re- directable" packets on the slow link and instead transmit all such packets over the faster link(s). A packet is deemed re-directable if it is able to be transmitted using the multilink procedure, as described in RFC 1990. The only packets currently NOT able to be redirected are LCP Configure-Request, -Reject, -Ack, -Nak, Terminate-Request, or -Ack packets. Also BAP packets should remain on the X.25 link. 2. Both receivers should exclude the slow link from the calculation of M. For simpler implementations, this exclusion could be immediate, but this increases the chances of losing any fragments currently being sent on the slow link. For more robust implementations, the exclusion could be started after a certain (short) time has elapsed. This would give any fragments currently on the slow link a chance to be received successfully. * A robust receiver should: * Receive and process successfully any fragments received on the slow link, as long as the sequence number is greater than M. * Discard any fragments received on the slow link that have a sequence number less than M. Note that this approach requires that both peers adhere to the rules described above. This should be acceptable since we may specifically NOT want to work with equipment that continues to load the D- channel. For a longer term solution, we may want to consider an extension to MP or BAP that would include "Idle-Link" and "Idle-Link-Ack" primitives. Traffic Estimates Based on these estimates, the following triggers can be used as a stimulus for requesting additional bandwidth. Triggers for Requesting Additional Bandwidth Bearer channels are added if the traffic will take more that 5 seconds to transmit through the D-Channel X.25, or if the pending data is larger than 7500 bytes. Holdrege [Page 8] I-D Always On Dynamic ISDN March 2000 When the amount of data is larger than 7500 bytes, we invoke a B- channel; further, this B-channel establishment, negotiation, and initialization for data takes 3 seconds, meaning the D-Channel X.25 is active for only 3 seconds, or approximately 4500 bytes, before data is no longer sent across it. Thereafter, as long as the B- Channel(s) is active, the X.25 is active-idle; i.e., the connection is maintained, but no data is transceived. Note: AO/DI receivers should be capable of continuing to receive data on the X.25 link as well as B-Channels. This allows simplistic MLPPP-based systems to be used. (Experience has shown that this simplistic approach is actually slower than the recommended D- Channel Idling, and more susceptible to error conditions.) An Example Heuristic for Adding Bearer Channels One method for determining when additional bandwidth needs to be added is described below. * Is the packet service outbound queue getting full? Where full means that at current throughput, will it take longer than 5 seconds to empty? Will it take longer than 10 seconds? * If the time to empty the queue is less than 5 seconds, use D- Channel X.25 without invoking a B-Channel. * If the time to empty the queue is more than 5 second, but less than 10, use the D-Channel X.25 to convey a BAP request for a B- Channel. * If a B-Channel is available, use the multilink protocol to augment the packet service connection. * If a B-Channel is not available, continue to empty the queue and monitor for queue fullness and B-Channel availability. * If the time to empty the queue is more than 10 seconds, request two B-Channels. * If two B-Channels are available, use the multilink protocol to augment the packet service connection. * If only one B-Channel is available, augment the connection with the single B-Channel. Continue to empty the queue and monitor for queue fullness and B-Channel availability. * If a B-Channel is not available, continue to empty the queue and monitor for queue fullness and B-Channel(s) availability. Following this heuristic allows the user the freedom to use the ISDN resources in multiple methods without affecting the ability to augment bandwidth when available. For example, the user may be having an ISDN-voice call simultaneously with the use of the AO/DI. Holdrege [Page 9] I-D Always On Dynamic ISDN March 2000 De-allocating Bandwidth After completing the data transfer that required invocation of the additional B-Channel(s), the B-Channels need to be disconnected so the circuit-switched resources can be returned to the trunk pool. BACP supports such requests. An Example Heuristic for De-allocating Bearer Channels An activity timer is a simple method for deciding when BACP should be used to release the B-Channels. If no activity is seen within 5 seconds of the end of the transfer, the channels should be releases. A more sophisticated method would look at the application that generated the request to guide the use of BACP. For example: * When looking at Web pages, a good activity timer is 5-10 seconds. After suchtime it probably means the users is studying the received materials and will be absorbed for several tens of seconds longer. * For email, once messages have been exchanged between the client and the post office server, release the B-Channels. De-allocating Bearer Channels for Other Applications A reason to de-allocate a B-Channel is to allow the user access to a voice call, either incoming or outgoing. The CPE is notified of an incoming call through the Q.931 messages. In response, the CPE can surrender a B-Channel, if necessary, or optionally forward the call to another number (such as an answering service), or decide to ignore the incoming call. If the CPE is at the S/T interface, it can monitor for other ISDN devices seeking to place outgoing voice calls. When it detects an outbound call, it can surrender a B-Channel to the other device. The exact behavior of the CPE regarding bandwidth deallocation is vendor-dependent. Network Architecture from the Switch to the Internet Service Provider The network architecture is an important consideration to understand the potential impact of services - in fact the reason to use AO/DI is to help alleviate network congestion associated with the trend towards more data networking. X.25 Network Utilization When an X.25 call is made, the packets are assigned to a specific trunk group and are not changed while the X.25 call is active; in other words, the logical X.25 circuit is bound to a physical channel. The binding of a subscriber's X.25 packet traffic to a specific aggregation channel depends on the type of connection made. Holdrege [Page 10] I-D Always On Dynamic ISDN March 2000 For the PVC this binding is permanent, whereas for the SVC the binding lasts as long as the circuit as active. For example, an ISP may subscribe to a X.25 service carried within one of the B-Channels of a PRI. This B-Channel can multiplex up to 64 X.25 circuits (users) simultaneously. Typically, this binding is not problematic. However, because the physical channel is statistically multiplexed over many users, then under certain circumstances it is possible that the users whose X.25 traffic is bound to this B-Channel will not get sufficient throughput. The concern is that a few users could opt to use only D-Channel X.25 for all data exchange in the hope that this could lead to lower bills. The attendant worry these users could consume all the available bandwidth, thus "starving" the other users for bandwidth. This concern is somewhat unrealistic because: First, the concern implies that these users are willing to forebear low throughput. Were they really willing to do so, they would have opted to use a lower-speed analog modem with a flat-rate tariff. We assume that (1) users are attracted to access the Internet through ISDN for its higher throughput, and (2)choose AO/DI because it is a more compelling user model and is more cost effective than a purely switched-circuit access. Second, as multiple logical circuits are crowded into the same physical channel, the throughput of all the users will decrease as the protocol windowing and acknowledgments impose delays. Third, this problem degenerates gracefully under AO/DI. If the D- Channel X.25 throughput to too small, the B-Channel(s) are added. SVC Lifetimes A concern voiced about the duration of an SVC being used for AO/DI. The concerns are based on several factors: * The "binding" issue discussed in the section above. * A desire to be able to rebalance the load should "binding" become a problem. * The number of SVCs that a modern central office can host simultaneously due to memory and processing constraints in the Packet Handlers. To allay these concerns, it has been suggested that AO/DI be recommended with an option to use inactivity timers in conjunction with SVCs. The notion being that when no traffic is detected within some interval, such 5 minutes, that the SVC be disconnected. When the user (or more likely the user application) attempts to query the ISP (such as for email) the SVC would be re-established, typically without the user becoming aware of the dial-up delay. Holdrege [Page 11] I-D Always On Dynamic ISDN March 2000 Short-lived SVCs seem unnecessary for several reasons: * As proposed, AO/DI is symmetric in that both the ISP and the client can be used as servers while retaining the model that the ISP subscriber originates calls to the ISP. Switching to an inactivity timer would cause the ISP to originate the packet SVC to the subscriber. While this model could work, given the current business practices of the ISPs, they will not readily adopt this method. * While, the above point seems negative, it should be contrasted with the current practice of long-duration calls (both analog and ISDN) and the adverse impact of this behavior on the public telephony network. * As LECs become ISPs in their own right, they may wish to retain the current ISP networking practices with respect to call origination. * As applications become more distributed, such as downloaded Java applets, it becomes very likely that the SVC inactivity timer would never be exceeded, hence the SVC would not be disconnected. The ideal way to resolve these issues is through real-world experience through trial deployments. It should be clear that there are complex interactions between user behaviors, network impacts, and tariffs that are difficult to predict - much the same as the Internet phenomena itself. X.25 Parameters * Packet size default = 128 * Window size = 2 (mod 8) * Call type = SVC * (PVCs are not in AO/DI, but may exist at CPE Termination. Assigned PVCs start at LCN 01 and increment) * TEI = 21 * # of logical channels (LCN) = 4 (01,02,03,04 starting with 01) * Throughput class = 9600 bps * X.25 flow control negotiation = enabled * client must be able to negotiate at least to default reverse charging allowed @ client * reverse charging accepted @ router * 1988 blue book X.25 Holdrege [Page 12] I-D Always On Dynamic ISDN March 2000 * no d-bit modification * q-bit should be ignored and the sender should set it to zero * CUD up to 16 octets in length * no fast select * ability for the client to handle separate DN for D X.25 (for local # portability) Use of Call User Data field in X.25 Call Request packet for AO/DI Octet 1: Protocol Identifier for AO/DI to be selected from reserved values in ISO/IEC TR 9577 Octets 2-4: Reserved for future AO/DI use. Optional. If these octets are present, then: * these octets must be filled in all zeros (0). * octet must be present in its entirety The absence of Octet 2 or the presence of all zeros in Octet 2 represents that AO/DI Version 1 is operating. Octets 5 - 16: Optional. Available for supplier- specific/application-specific use. If present, then an integral number of octets must be present. Octet 2 must be present in order for Octets 3 to 16 to be utilized. If AO/DI Version 1 is operating and Octets 3 to 16 are not utilized, then: Octet 2 may or may not be inserted into the Call User Data field. (That is, equipment that originates AO/DI SVCs has the option as to whether it will utilize Octet 2. Equipment that terminates AO/DI SVCs must be capable of accepted CUDs with and without Octet 2.) Connections to the ISP Routing D-Channel X.25 packet calls to the Internet service provider can be done more efficiently without over-loading the switch trunk lines and the switching fabric. For efficiencies, the X.25 can be concentrated into standard WAN connections (e.g., T1 or PRI) between the central office and the Internet service provider; several central office-to-Internet service provider options are available and can be decided on their own merits between the Local Exchange Carrier and the Internet service provider. X.25 Translations The general goals for the translations are that they be 1.) user- friendly, 2.) network-friendly, and 3.) switch-specific. X.25 Translation Caveats: Holdrege [Page 13] I-D Always On Dynamic ISDN March 2000 1. These translations are for the client, not for the router. 2. The reverse charging parameter, which is set to No in the translations, refers to Reverse Charging Acceptance. This parameter does not prohibit Reverse Charging Allowed (Reverse Charging Allowed gives the client the ability to originate calls containing the Reverse Charging facility). 3. The Directory Numbers assigned for D-channel packet are different from the other Directory Numbers assigned to the terminal for voice or circuit-mode data. AO/DI Stability and Robustness It should also be recognized that AO/DI is inherently stable in these regards. This is achieved through the following behaviors: When bandwidth becomes insufficient, AO/DI attempts to augment the bandwidth. Failure to augment bandwidth results in continuing with a slower-than-desired throughput, but no damage. If the D-Channel throughput becomes unacceptable, an attempt to add a B-Channel will be made; this could be the result of delays in packet acknowledgment or even packet rejection at the packet handler. Given the discussions above regarding the use of SVCs and network congestion, it is clear that some behaviors can be incorporated into AO/DI to help overall robustness. One possiblel behavior is to put a "bandwidth limiter" on the D-Channel that slows the transmission of packets through the D-Channel when a threshold is exceeded over some relatively short time interval. Kudos: The authors wish to thank Joe Boucher for his contribution on the D-Channel Idling, Scott Stamp for his contributions on X.25 translations, and Pierre-Luc Provencal for his contribution on the BACP phone deltas and efforts to register an NLPID for X.25 specific to AO/DI. This work came from the Vendors ISDN Association members (especially those on the AO/DI technical subcommittee) and thanks to the National ISDN Council for their enthusiasm and persistence. References K. Sklower, B. Lloyd, G. McGregor, D. Carr, "The PPP Multilink Protocol" RFC 1990 Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661 K. Smith, "Ascend's Multilink Plus (MP+)," RFC 1934 C. Richards, K. Smith, "The PPP Bandwidth Allocation Protocol (BAP), The PPP Bandwidth Allocation Control Protocol (BACP)" RFC 2125 Holdrege [Page 14] I-D Always On Dynamic ISDN March 2000 A. Kuzma, et al, "AO/DI Network Architecture," Revision 2, Vendors ISDN Association white paper, December 1996. Simpson, W., Editor, "PPP in X.25," RFC 1598 ITU-T Q.922 - ISDN Data Link Layer Specification for Frame Mode Bearer Services ITU-T Q.931 - ISDN User-Network Interface Layer 3 Speicifcation for Basic Call Control ITU-T X.25 - Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit Acknowledgements This work is the result of the efforts of Andy Kuzma in the Vendors ISDN Association. The author would like to acknowledge the wise counsel from James Carlson and Jonathan Goodchild. Author's Address Matt Holdrege Lucent Technologies 223 Ximeno Ave. Long Beach, CA 90803 USA holdrege@lucent.com Holdrege [Page 15] --=====================_809447==_ Content-Type: text/plain; charset="us-ascii" Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 --=====================_809447==_-- From owner-ietf-ppp-outgoing@merit.edu Tue Mar 27 15:27:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28600 for ; Tue, 27 Mar 2001 15:27:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6401C5E0BB; Tue, 27 Mar 2001 15:17:07 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4581E5E0BA; Tue, 27 Mar 2001 15:17:07 -0500 (EST) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 301135DF2B for ; Tue, 27 Mar 2001 15:17:02 -0500 (EST) Received: from karl-w98l.xc.org (ai70-020.aiinet.com [38.195.70.20]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FJJRVNQB; Tue, 27 Mar 2001 13:17:01 -0700 Message-Id: <4.3.2.7.2.20010327151505.00df4100@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Mar 2001 15:16:47 -0500 To: James Carlson , Vernon Schryver From: Karl Fox Subject: Re: Secure Remote Password interest Cc: ietf-ppp@merit.edu In-Reply-To: <15033.1745.453819.921776@gargle.gargle.HOWL> References: <200103211840.f2LIegw12402@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Consider also key servers, LDAP servers and other security servers, some of which also store their goodies in clear text. There are ways of increasing server security outside the scope of the protocol itself. Karl At 02:53 PM 3/21/01, James Carlson wrote: >Vernon Schryver writes: >> That's a quite good point in favor of SRP and against CHAP that should be >> made more clear in the draft. > >OK, I will do that. > >> CHAP is vulnerable to dictionary attacks even when the bad guy does not >> have access to the database. The price of a modular exponentiation >> in SRP forces dictionary attackers to get the hash database. > >I'm not sure if that's true. I think the risk of the data on the wire >is the same as that for the database for SRP. I'm not an expert though. > >> If I were writing the draft, I'd flog that aspect more than replacing the >> CHAP cleartext database. With reasonable operating systems, read-only >> access to the CHAP cleartext database often implies write-access, and >> write-access ends the game for any authentication scheme including SRP. > >True, but I'd say sometimes instead. Think of leaky web servers and >the like -- lots of things can grant read-only access. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Tue Mar 27 18:02:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02397 for ; Tue, 27 Mar 2001 18:02:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66FB65DEBC; Tue, 27 Mar 2001 13:55:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7B2C65DED5; Tue, 27 Mar 2001 13:55:41 -0500 (EST) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id E1A8A5DFA2 for ; Tue, 27 Mar 2001 13:53:05 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f2RIrSd03017; Tue, 27 Mar 2001 13:53:28 -0500 Message-Id: <200103271853.f2RIrSd03017@hygro.adsl.duke.edu> To: Karl Fox Cc: Erik Nordmark , ietf-ppp@merit.edu Subject: Re: AODI to Informational Standard In-Reply-To: Message from Karl Fox of "Tue, 27 Mar 2001 08:44:08 EST." <4.3.2.7.2.20010327084024.053434a0@mail.via-net.net> Date: Tue, 27 Mar 2001 13:53:28 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > The PPPEXT Working Group recommends that Always On Dynamic ISDN (AODI), > draft-ietf-pppext-aodi-02.txt (attached, as it has expired) be advanced to > Informational Standard. Is that Informational, or Proposed Standard (there is no Informational Standard). Thomas From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 17:13:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13652 for ; Wed, 28 Mar 2001 17:13:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B5235DFA4; Wed, 28 Mar 2001 17:01:36 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A823F5DFA5; Wed, 28 Mar 2001 17:01:28 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by segue.merit.edu (Postfix) with ESMTP id 64AAA5E0C5 for ; Wed, 28 Mar 2001 17:00:35 -0500 (EST) Received: from packetdesign.com (bubba.packetdesign.com [192.168.0.223]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f2SM0G259651; Wed, 28 Mar 2001 14:00:16 -0800 (PST) (envelope-from archie@packetdesign.com) Message-ID: <3AC25EF0.55E14A5C@packetdesign.com> Date: Wed, 28 Mar 2001 14:00:16 -0800 From: Archie Cobbs Organization: Packet Design X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari Cc: "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu Subject: Re: Cisco HDLC References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B68@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit > I have checked that. It seems that the only difference from the standard HDLC (RFC-1662) is the value encoded in > Address, control field. There's more to it than that.. if you can read FreeBSD kernel source code there is an implementation at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_cisco.c?rev=1.14&content-type=text/x-cvsweb-markup > Is it still using the byte or bit stuffing? Yes, same frame encoding (bit stuffing, flags, CRC's, etc.) -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 17:21:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13835 for ; Wed, 28 Mar 2001 17:21:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81FB55DEFA; Wed, 28 Mar 2001 17:20:13 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E7755DFF3; Wed, 28 Mar 2001 17:20:02 -0500 (EST) Received: from stargate.ttc.com (stargate.ttc.com [157.234.250.2]) by segue.merit.edu (Postfix) with ESMTP id 6466C5E05E for ; Wed, 28 Mar 2001 17:18:24 -0500 (EST) Received: from relay.ttc.com (relay.ttc.com [157.234.7.6]) by stargate.ttc.com with ESMTP id RAA19772; Wed, 28 Mar 2001 17:19:41 -0500 (EST) From: michael.koller@acterna.com Received: from relay.ttc.com by relay.ttc.com with SMTP id RAA14640; Wed, 28 Mar 2001 17:18:16 -0500 (EST) Received: by ttcmta1-7.ttc.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A1D.007A8AC5 ; Wed, 28 Mar 2001 18:18:29 -0400 X-Lotus-FromDomain: GLOBAL To: ietf-ppp@merit.edu Cc: Archie Cobbs Message-ID: <85256A1D.007A898B.00@ttcmta1-7.ttc.com> Date: Wed, 28 Mar 2001 18:18:10 -0400 Subject: Re: Cisco HDLC Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Is there a spec for this somewhere? Or does this still remain a Cisco "secret?" Archie Cobbs on 03/28/2001 05:00:16 PM To: Shahram Davari cc: "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu Subject: Re: Cisco HDLC > I have checked that. It seems that the only difference from the standard HDLC (RFC-1662) is the value encoded in > Address, control field. There's more to it than that.. if you can read FreeBSD kernel source code there is an implementation at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_cisco.c?rev=1.14&content-type=text/x-cvsweb-markup > Is it still using the byte or bit stuffing? Yes, same frame encoding (bit stuffing, flags, CRC's, etc.) -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 17:22:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13892 for ; Wed, 28 Mar 2001 17:22:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A5875DFFA; Wed, 28 Mar 2001 17:21:54 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 882F25DFFB; Wed, 28 Mar 2001 17:21:53 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C25685DF55 for ; Wed, 28 Mar 2001 17:21:50 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24948; Wed, 28 Mar 2001 14:21:44 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00697; Wed, 28 Mar 2001 17:21:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2SMMLO70007; Wed, 28 Mar 2001 17:22:21 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15042.25628.563092.91431@gargle.gargle.HOWL> Date: Wed, 28 Mar 2001 17:22:20 -0500 (EST) From: James Carlson To: Archie Cobbs Cc: Shahram Davari , "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu Subject: Re: Cisco HDLC In-Reply-To: Archie Cobbs's message of 28 March 2001 14:00:16 References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B68@BBY1EXM01> <3AC25EF0.55E14A5C@packetdesign.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Archie Cobbs writes: > There's more to it than that.. if you can read FreeBSD kernel source > code there is an implementation at: I saved the following message from comp.dcom.sys.cisco several years ago. Hope this helps ... -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) Subject: Re: Wanted: IP directly over HDLC Date: 7 Nov 90 07:57:33 GMT We have an opportunity here to productize a capability of doing IP over serial lines. The way I've prototyped this is to encapsulate IP datagrams directly into HDLC framing (ISO 3309), without any of the "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff. Indeed, this is what almost all of the major router vendors do. PPP is also like this except that there is a potential of doing millions of lines of code to support all the random option negotiation. We were wondering if there are any implementations out there that are also able to do this. Both Wellfleet and cisco boxes come to mind, but are there any other implementations that can do this in a non-proprietary manner? As far as I know, wellfleet and cisco "hdlc" encapsulations are only "proprietary" in that no one else does them - they aren't big secrets. (Ill enclose a description of cisco's spec later in this message...) Note: I am aware of PPP and am not interested in implementing it as a solution at this time. Why not? I would think that this would be a good idea, especially if you leave out the negotiation of the millions of options. A "minimal subset" (refuse all options) of PPP is not difficult, and even a format equivilent to PPP with not option negotiation supported at all (eg only the PPP wire format) probably has a better interoperability future than anything else... Bill Westfield cisco Systems. cisco Serial Line Encapsulation ------------------------------- cisco's default encapsulation on synchronous serial lines uses HDLC framing, with packet contents defined as follows: The first ("address") octet is set to 0x0F for unicast packets and 0x8F for broadcast packets. Broadcast just means that the higher-level protocol thought this was a broadcast packet; cisco doesn't support multidrop HDLC at this time. The second ("control") octet is always 0. The next two octets are a 16-bit protocol code, sent most-significant-first. These codes are usually Ethernet type codes. cisco has added some codes to support packet types that don't appear on Ethernets. The current list of codes is as follows: TYPE_PUP 0x0200 PUP TYPE_XNS 0x0600 XNS TYPE_IP10MB 0x0800 IP TYPE_CHAOS 0x0804 Chaos TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot. TYPE_DECNET 0x6003 DECnet phase IV TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet TYPE_APOLLO 0x8019 Apollo domain TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!) TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol TYPE_ETHERTALK 0x809b Apple EtherTalk TYPE_AARP 0x80f3 Appletalk ARP TYPE_NOVELL1 0x8137 Novell IPX TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP This list is shared between serial and Ethernet encapsulations. Not all these codes will necessarily appear on serial lines. This list will probably be extended as cisco adds support for more protocols. Bytes after this are higher-level protocol data. These normally look the same as they'd look on Ethernet. Bridging packets include Ethernet/802.3 MAC headers; no other packets do. Packets with type 8035 (reverse ARP) don't contain reverse ARP data as they would on an Ethernet. Instead, they carry a protocol cisco refers to as SLARP. SLARP has two functions: dynamic IP address determination and serial line keepalive. The serial line model supported by SLARP assumes that each serial line is a separate IP subnet, and that one end of the line is host number 1, while the other end is host number 2. The SLARP address resolution protocol allows system A to request that system B tell system A system B's IP address, along with the IP netmask to be used on the network. It does this by sending a SLARP address resolution request packet, to which system B responds with a SLARP address resolution reply packet. System A then attempts to determine its own IP address based on the address of system B. If the host portion of system B's address is 1, system A will use 2 for the host portion of its own IP address. Conversely, if system B's IP host number is 2, system A will use IP host number 1. If system B replies with any IP host number other than 1 or 2, system A assumes that system B is unable to provide it with an address via SLARP. For the SLARP keepalive protocol, each system sends the other a keepalive packet at a user-configurable interval. The default interval is 10 seconds. Both systems must use the same interval to ensure reliable operation. Each system assigns sequence numbers to the keepalive packets it sends, starting with zero, independent of the other system. These sequence numbers are included in the keepalive packets sent to the other system. Also included in each keepalive packet is the sequence number of the last keepalive packet _received_ from the other system, as assigned by the other system. This number is called the returned sequence number. Each system keeps track of the last returned sequence number it has received. Immediately before sending a keepalive packet, it compares the sequence number of the packet it is about to send with the returned sequence number in the last keepalive packet it has received. If the two differ by 3 or more, it considers the line to have failed, and will route no further higher-level data across it until an acceptable keepalive response is received. There is interaction between the SLARP address resolution protocol and the SLARP keepalive protocol. When one end of a serial line receives a SLARP address resolution request packet, it assumes that the other end has restarted its serial interface and reset its keepalive sequence numbers. In addition to responding to the address resolution request, it will act as if the other end had sent it a keepalive packet with a sequence number of zero, and a returned sequence number the same as the returned sequence number of the last real keepalive packet it received from the other end. The following is a C definition for the SLARP packet. The "long" and "ulong" types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit number, high octet sent first. struct slarp { long code; /* SLARP packet type code */ union sl { /* followed by one of: */ struct { /* Address resolution functions */ ulong address; /* Address of system sending this pkt */ ulong mask; /* IP subnet mask for this line */ ushort unused; /* Unused: contents undefined */ } add; /* -- or -- */ struct { /* Keepalive probing functions */ ulong mysequence; /* Outgoing sequence number */ ulong yoursequence; /* Returned sequence number */ ushort reliability; /* Reserved: set to FFFF */ } chk; } t; }; Note that the data storage for t.add is overlayed on the data storage for t.chk. The whole SLARP packet consists of a 32-bit type code, followed by two 32-bit quantities and one 16-bit quantity. The overall length of the SLARP packet is 14 octets. The "code" field is used to identify the packet's SLARP type. Legal values for the "code" field are as follows: SLARP_REQUEST 0 Address resolution request SLARP_REPLY 1 Address resolution reply SLARP_LINECHECK 2 Line keepalive For address resolution request packets, the "address" and "mask" fields are set to zero, and the contents of the "unused" field field are undefined. For address resolution reply packets, the "address" field contains the IP address of the _replying_ system, and the "mask" field contains the IP subnet mask to be used. The contents of the "unused" field are undefined. For keepalive packets, the "mysequence" field contains the sequence number of the packet and the "yoursequence" field contains the returned sequence number, which is the sequence number of the last keepalive packet the sending system has gotten from the receiving system. The "reliability" field is reserved for future use, and _must_ be set to FFFF hexadecimal. From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 18:31:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14893 for ; Wed, 28 Mar 2001 18:31:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5D5F5DDD8; Wed, 28 Mar 2001 16:35:13 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 877E15DFB0; Wed, 28 Mar 2001 16:35:13 -0500 (EST) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by segue.merit.edu (Postfix) with SMTP id B0E2B5DDD8 for ; Wed, 28 Mar 2001 16:35:04 -0500 (EST) Received: (qmail 29759 invoked by uid 104); 28 Mar 2001 21:35:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.25202 secs); 28/03/2001 13:35:02 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 28 Mar 2001 21:35:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2SLZ1V00164 for ; Wed, 28 Mar 2001 13:35:01 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Mar 2001 13:35:31 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B67@BBY1EXM01> From: Shahram Davari To: ietf-ppp@merit.edu Subject: Cisco HDLC Date: Wed, 28 Mar 2001 13:35:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi All, Does any body know what is the protocol format of the Cisco HDLC? Yours, -Shahram From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 18:34:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14925 for ; Wed, 28 Mar 2001 18:34:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA22C5DF40; Wed, 28 Mar 2001 16:51:05 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C4E475DF3C; Wed, 28 Mar 2001 16:51:05 -0500 (EST) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by segue.merit.edu (Postfix) with SMTP id C2A8B5DF3B for ; Wed, 28 Mar 2001 16:51:03 -0500 (EST) Received: (qmail 11034 invoked by uid 104); 28 Mar 2001 21:51:02 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.654906 secs); 28/03/2001 13:51:02 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 28 Mar 2001 21:51:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2SLp1V03600; Wed, 28 Mar 2001 13:51:01 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Mar 2001 13:51:31 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B68@BBY1EXM01> From: Shahram Davari To: "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu Subject: RE: Cisco HDLC Date: Wed, 28 Mar 2001 13:51:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B7D1.385694A0" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B7D1.385694A0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have checked that. It seems that the only difference from the standard HDLC (RFC-1662) is the value encoded in Address, control field. Is it still using the byte or bit stuffing? What is the advantage of Cisco HDLC? Yours, -Shahram -----Original Message----- From: Sylvanus Jonnalagadda [mailto:Sylvanus@coronanetworks.com] Sent: Wednesday, March 28, 2001 4:56 PM To: Shahram Davari; ietf-ppp@merit.edu Subject: RE: Cisco HDLC Hi Sharam, I think it is explained in section 4.3.1 of RFC 1547. Check it out. -Sylvanus. -----Original Message----- From: Shahram Davari [ mailto:Shahram_Davari@pmc-sierra.com ] Sent: Wednesday, March 28, 2001 1:35 PM To: ietf-ppp@merit.edu Subject: Cisco HDLC Hi All, Does any body know what is the protocol format of the Cisco HDLC? Yours, -Shahram ------_=_NextPart_001_01C0B7D1.385694A0 Content-Type: text/html; charset="iso-8859-1" RE: Cisco HDLC
Hi,
 
I have checked that. It seems that the only difference from the standard HDLC (RFC-1662) is the value encoded in Address, control field. Is it still using the byte or bit stuffing?
 
What is the advantage of Cisco HDLC?
 
Yours,
-Shahram
-----Original Message-----
From: Sylvanus Jonnalagadda [mailto:Sylvanus@coronanetworks.com]
Sent: Wednesday, March 28, 2001 4:56 PM
To: Shahram Davari; ietf-ppp@merit.edu
Subject: RE: Cisco HDLC

Hi Sharam,

I think it is explained in section 4.3.1 of RFC 1547. Check it out.

-Sylvanus.

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, March 28, 2001 1:35 PM
To: ietf-ppp@merit.edu
Subject: Cisco HDLC


Hi All,

Does any body know what is the protocol format of the Cisco HDLC?

Yours,
-Shahram

------_=_NextPart_001_01C0B7D1.385694A0-- From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 20:33:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16560 for ; Wed, 28 Mar 2001 20:33:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46C525DFC8; Wed, 28 Mar 2001 16:45:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2AC705DF65; Wed, 28 Mar 2001 16:45:44 -0500 (EST) Received: from mailsrv.coronanetworks.com (unknown [38.186.47.7]) by segue.merit.edu (Postfix) with ESMTP id BB4EC5DECF for ; Wed, 28 Mar 2001 16:45:40 -0500 (EST) Received: by newmail.coronanetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Mar 2001 13:56:36 -0800 Message-ID: From: Sylvanus Jonnalagadda To: Shahram Davari , ietf-ppp@merit.edu Subject: RE: Cisco HDLC Date: Wed, 28 Mar 2001 13:56:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B7D1.F16E4F00" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B7D1.F16E4F00 Content-Type: text/plain; charset="ISO-8859-1" Hi Sharam, I think it is explained in section 4.3.1 of RFC 1547. Check it out. -Sylvanus. -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, March 28, 2001 1:35 PM To: ietf-ppp@merit.edu Subject: Cisco HDLC Hi All, Does any body know what is the protocol format of the Cisco HDLC? Yours, -Shahram ------_=_NextPart_001_01C0B7D1.F16E4F00 Content-Type: text/html; charset="ISO-8859-1" RE: Cisco HDLC

Hi Sharam,

I think it is explained in section 4.3.1 of RFC 1547. Check it out.

-Sylvanus.

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, March 28, 2001 1:35 PM
To: ietf-ppp@merit.edu
Subject: Cisco HDLC


Hi All,

Does any body know what is the protocol format of the Cisco HDLC?

Yours,
-Shahram

------_=_NextPart_001_01C0B7D1.F16E4F00-- From owner-ietf-ppp-outgoing@merit.edu Wed Mar 28 23:37:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27628 for ; Wed, 28 Mar 2001 23:37:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 893E55DD8F; Wed, 28 Mar 2001 23:34:02 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 69E1A5DDB1; Wed, 28 Mar 2001 23:34:02 -0500 (EST) Received: from localhost.pluris.com (adsl-63-201-33-109.dsl.snfc21.pacbell.net [63.201.33.109]) by segue.merit.edu (Postfix) with ESMTP id 7E1275DD8F for ; Wed, 28 Mar 2001 23:33:58 -0500 (EST) Received: from localhost (localhost.pluris.com [127.0.0.1]) by localhost.pluris.com (8.10.2/8.10.2) with ESMTP id f2T4WZ500371; Wed, 28 Mar 2001 20:32:35 -0800 (PST) Message-Id: <200103290432.f2T4WZ500371@localhost.pluris.com> Date: Wed, 28 Mar 2001 20:32:34 -0800 From: Bora Akyol Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Cisco HDLC Cc: Archie Cobbs , Shahram Davari , "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu To: James Carlson X-Mailer: Apple Mail (2.387) In-Reply-To: <15042.25628.563092.91431@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v387) Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Isn't it amazing that most people outside Cisco that have implemented C-HDLC have implemented it using this newsgroup message from years ago? I would like to confirm that if you follow the message, the resulting implementation works. Bora On Wednesday, March 28, 2001, at 02:22 PM, James Carlson wrote: > Archie Cobbs writes: >> There's more to it than that.. if you can read FreeBSD kernel source >> code there is an implementation at: > > I saved the following message from comp.dcom.sys.cisco several years > ago. Hope this helps ... > > -- > James Carlson, Internet Engineering > SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > Second Edition now available - http://people.ne.mediaone.net/carlson/ppp > > From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) > Subject: Re: Wanted: IP directly over HDLC > Date: 7 Nov 90 07:57:33 GMT > > > We have an opportunity here to productize a capability of doing IP > over serial lines. The way I've prototyped this is to encapsulate > IP > datagrams directly into HDLC framing (ISO 3309), without any of the > "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff. > > Indeed, this is what almost all of the major router vendors do. PPP is > also like this except that there is a potential of doing millions of > lines > of code to support all the random option negotiation. > > > We were wondering if there are any implementations out there that > are > also able to do this. Both Wellfleet and cisco boxes come to mind, > but are there any other implementations that can do this in a > non-proprietary manner? > > As far as I know, wellfleet and cisco "hdlc" encapsulations are only > "proprietary" in that no one else does them - they aren't big secrets. > (Ill enclose a description of cisco's spec later in this message...) > > > Note: I am aware of PPP and am not interested in implementing it > as a > solution at this time. > > Why not? I would think that this would be a good idea, especially if > you leave out the negotiation of the millions of options. A "minimal > subset" (refuse all options) of PPP is not difficult, and even a format > equivilent to PPP with not option negotiation supported at all (eg only > the PPP wire format) probably has a better interoperability future than > anything else... > > Bill Westfield > cisco Systems. > > > cisco Serial Line Encapsulation > ------------------------------- > > cisco's default encapsulation on synchronous serial lines uses HDLC > framing, > with packet contents defined as follows: > > The first ("address") octet is set to 0x0F for unicast packets and 0x8F > for broadcast packets. Broadcast just means that the higher-level > protocol > thought this was a broadcast packet; cisco doesn't support multidrop > HDLC at this time. > > The second ("control") octet is always 0. > > The next two octets are a 16-bit protocol code, sent > most-significant-first. > These codes are usually Ethernet type codes. cisco has added some codes > to > support packet types that don't appear on Ethernets. The current list > of codes > is as follows: > > TYPE_PUP 0x0200 PUP > TYPE_XNS 0x0600 XNS > TYPE_IP10MB 0x0800 IP > TYPE_CHAOS 0x0804 Chaos > TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge > spanning prot. > TYPE_DECNET 0x6003 DECnet phase IV > TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet > TYPE_APOLLO 0x8019 Apollo domain > TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse > ARP!) > TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree > protocol > TYPE_ETHERTALK 0x809b Apple EtherTalk > TYPE_AARP 0x80f3 Appletalk ARP > TYPE_NOVELL1 0x8137 Novell IPX > TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP > > This list is shared between serial and Ethernet encapsulations. Not all > these codes will necessarily appear on serial lines. This list will > probably > be extended as cisco adds support for more protocols. > > Bytes after this are higher-level protocol data. These normally look the > same as they'd look on Ethernet. Bridging packets include Ethernet/802.3 > MAC headers; no other packets do. > > Packets with type 8035 (reverse ARP) don't contain reverse ARP data as > they would on an Ethernet. Instead, they carry a protocol cisco refers > to > as SLARP. SLARP has two functions: dynamic IP address determination and > serial line keepalive. > > The serial line model supported by SLARP assumes that each serial line > is > a separate IP subnet, and that one end of the line is host number 1, > while > the other end is host number 2. The SLARP address resolution protocol > allows > system A to request that system B tell system A system B's IP address, > along with the IP netmask to be used on the network. It does this by > sending > a SLARP address resolution request packet, to which system B responds > with a > SLARP address resolution reply packet. System A then attempts to > determine its > own IP address based on the address of system B. If the host portion of > system > B's address is 1, system A will use 2 for the host portion of its own IP > address. Conversely, if system B's IP host number is 2, system A will > use IP > host number 1. If system B replies with any IP host number other than 1 > or 2, > system A assumes that system B is unable to provide it with an address > via > SLARP. > > For the SLARP keepalive protocol, each system sends the other a > keepalive > packet at a user-configurable interval. The default interval is 10 > seconds. > Both systems must use the same interval to ensure reliable operation. > Each system assigns sequence numbers to the keepalive packets it sends, > starting with zero, independent of the other system. These sequence > numbers > are included in the keepalive packets sent to the other system. Also > included > in each keepalive packet is the sequence number of the last keepalive > packet > _received_ from the other system, as assigned by the other system. This > number > is called the returned sequence number. Each system keeps track of the > last > returned sequence number it has received. Immediately before sending a > keepalive > packet, it compares the sequence number of the packet it is about to > send with > the returned sequence number in the last keepalive packet it has > received. > If the two differ by 3 or more, it considers the line to have failed, > and > will route no further higher-level data across it until an acceptable > keepalive > response is received. > > There is interaction between the SLARP address resolution protocol and > the > SLARP keepalive protocol. When one end of a serial line receives a SLARP > address resolution request packet, it assumes that the other end has > restarted > its serial interface and reset its keepalive sequence numbers. In > addition > to responding to the address resolution request, it will act as if the > other end had sent it a keepalive packet with a sequence number of zero, > and a returned sequence number the same as the returned sequence number > of the last real keepalive packet it received from the other end. > > The following is a C definition for the SLARP packet. The "long" and > "ulong" > types are 32-bit numbers, high octet sent first. The "ushort" type is a > 16-bit > number, high octet sent first. > > struct slarp { > long code; /* SLARP packet type code */ > union sl { /* followed by one of: */ > struct { /* Address resolution > functions */ > ulong address; /* Address of system sending > this pkt */ > ulong mask; /* IP subnet mask for this > line */ > ushort unused; /* Unused: contents undefined */ > } add; /* -- or -- */ > struct { /* Keepalive probing > functions */ > ulong mysequence; /* Outgoing sequence number */ > ulong yoursequence; /* Returned sequence number */ > ushort reliability; /* Reserved: set to FFFF */ > } chk; > } t; > }; > > Note that the data storage for t.add is overlayed on the data storage > for > t.chk. The whole SLARP packet consists of a 32-bit type code, followed > by > two 32-bit quantities and one 16-bit quantity. The overall length of the > SLARP packet is 14 octets. The "code" field is used to identify the > packet's > SLARP type. Legal values for the "code" field are as follows: > > SLARP_REQUEST 0 Address resolution request > SLARP_REPLY 1 Address resolution reply > SLARP_LINECHECK 2 Line keepalive > > For address resolution request packets, the "address" and "mask" fields > are > set to zero, and the contents of the "unused" field field are > undefined. For > address resolution reply packets, the "address" field contains the IP > address > of the _replying_ system, and the "mask" field contains the IP subnet > mask > to be used. The contents of the "unused" field are undefined. > > For keepalive packets, the "mysequence" field contains the sequence > number > of the packet and the "yoursequence" field contains the returned > sequence > number, which is the sequence number of the last keepalive packet the > sending > system has gotten from the receiving system. The "reliability" field is > reserved for future use, and _must_ be set to FFFF hexadecimal. > From owner-ietf-ppp-outgoing@merit.edu Thu Mar 29 05:39:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05030 for ; Thu, 29 Mar 2001 05:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BF0D5DDC0; Thu, 29 Mar 2001 05:39:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E69285DDD7; Thu, 29 Mar 2001 05:39:15 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 4F6215DDC0 for ; Thu, 29 Mar 2001 05:39:14 -0500 (EST) Received: from gwzpc (sjc-vpn-121.cisco.com [10.21.64.121]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA13595 for ; Thu, 29 Mar 2001 02:39:11 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Ietf-Ppp@Merit. Edu" Subject: has anyone implemented RFC 2484? Date: Thu, 29 Mar 2001 02:36:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit From owner-ietf-ppp-outgoing@merit.edu Thu Mar 29 07:23:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11121 for ; Thu, 29 Mar 2001 07:23:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68F5F5DE06; Thu, 29 Mar 2001 07:19:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4B83B5DE03; Thu, 29 Mar 2001 07:19:17 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 96D735DDF8 for ; Thu, 29 Mar 2001 07:19:15 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20194 for ; Thu, 29 Mar 2001 04:19:15 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07028 for ; Thu, 29 Mar 2001 07:19:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2TCJqF70693; Thu, 29 Mar 2001 07:19:52 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15043.10344.251474.236007@gargle.gargle.HOWL> Date: Thu, 29 Mar 2001 07:19:52 -0500 (EST) From: James Carlson To: ietf-ppp@merit.edu Subject: clearing up some confusion (was Re: Cisco HDLC) In-Reply-To: Bora Akyol's message of 28 March 2001 20:32:34 References: <15042.25628.563092.91431@gargle.gargle.HOWL> <200103290432.f2T4WZ500371@localhost.pluris.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit > > From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) [...] > > Indeed, this is what almost all of the major router vendors do. PPP is > > also like this except that there is a potential of doing millions of > > lines > > of code to support all the random option negotiation. Since it apparently wasn't clear to everyone, I'd like to point out explicitly that those are *not* my words nor are they my opinion. They appeared in the original usenet posting. For what it's worth, the new version of Solaris PPP that I'm currently working on is about 59,642 lines of code, including all the user and kernel bits and debug utilities. Even if I did *all* of the options currently defined, I'd have a hard time breaking the one million line mark. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Mar 29 10:56:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20255 for ; Thu, 29 Mar 2001 10:56:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE7C05DED9; Thu, 29 Mar 2001 10:52:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C95F95DED5; Thu, 29 Mar 2001 10:52:17 -0500 (EST) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by segue.merit.edu (Postfix) with SMTP id 768675DEC8 for ; Thu, 29 Mar 2001 10:52:15 -0500 (EST) Received: (qmail 7049 invoked by uid 104); 29 Mar 2001 15:52:14 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.454148 secs); 29/03/2001 07:52:14 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 29 Mar 2001 15:52:13 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2TFq8V01106; Thu, 29 Mar 2001 07:52:12 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Mar 2001 07:52:28 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B6B@BBY1EXM01> From: Shahram Davari To: "'Bora Akyol'" , James Carlson Cc: Archie Cobbs , "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu Subject: RE: Cisco HDLC Date: Thu, 29 Mar 2001 07:52:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Bora, Thanks. But there are still some things that are not clear. For example: 1)is C-HDLC bit-stuffed or byte-stuffed? (somebody said it is bit-stuffed) 2)Does it have padding at the end? 3)Does it have CRC-16 or 32? 4)Does it use the same flag as HDLC? 5)Can C-HDLC be used in packet over sonet application? 6)If yes is it scrambled or not? If so what type of scrambling? Yours, -Shahram > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Wednesday, March 28, 2001 11:33 PM > To: James Carlson > Cc: Archie Cobbs; Shahram Davari; 'Sylvanus Jonnalagadda'; > ietf-ppp@merit.edu > Subject: Re: Cisco HDLC > > > Isn't it amazing that most people outside Cisco that have implemented > C-HDLC have implemented it using this newsgroup message from > years ago? > > I would like to confirm that if you follow the message, the resulting > implementation works. > > Bora > > On Wednesday, March 28, 2001, at 02:22 PM, James Carlson wrote: > > > Archie Cobbs writes: > >> There's more to it than that.. if you can read FreeBSD > kernel source > >> code there is an implementation at: > > > > I saved the following message from comp.dcom.sys.cisco several years > > ago. Hope this helps ... > > > > -- > > James Carlson, Internet Engineering > > > SUN Microsystems / 1 Network Drive 71.234W Vox +1 > 781 442 2084 > > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > 781 442 1677 > > Second Edition now available - > http://people.ne.mediaone.net/carlson/ppp > > > > > From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) > > Subject: Re: Wanted: IP directly over HDLC > > Date: 7 Nov 90 07:57:33 GMT > > > > > > We have an opportunity here to productize a capability > of doing IP > > over serial lines. The way I've prototyped this is to > encapsulate > > IP > > datagrams directly into HDLC framing (ISO 3309), > without any of the > > "upper-layer" (ISO 4335 or LAPB) retransmission or > windowing stuff. > > > > Indeed, this is what almost all of the major router vendors > do. PPP is > > also like this except that there is a potential of doing > millions of > > lines > > of code to support all the random option negotiation. > > > > > > We were wondering if there are any implementations out > there that > > are > > also able to do this. Both Wellfleet and cisco boxes > come to mind, > > but are there any other implementations that can do this in a > > non-proprietary manner? > > > > As far as I know, wellfleet and cisco "hdlc" encapsulations are only > > "proprietary" in that no one else does them - they aren't > big secrets. > > (Ill enclose a description of cisco's spec later in this message...) > > > > > > Note: I am aware of PPP and am not interested in > implementing it > > as a > > solution at this time. > > > > Why not? I would think that this would be a good idea, > especially if > > you leave out the negotiation of the millions of options. > A "minimal > > subset" (refuse all options) of PPP is not difficult, and > even a format > > equivilent to PPP with not option negotiation supported at > all (eg only > > the PPP wire format) probably has a better interoperability > future than > > anything else... > > > > Bill Westfield > > cisco Systems. > > > > > > cisco Serial Line Encapsulation > > ------------------------------- > > > > cisco's default encapsulation on synchronous serial lines uses HDLC > > framing, > > with packet contents defined as follows: > > > > The first ("address") octet is set to 0x0F for unicast > packets and 0x8F > > for broadcast packets. Broadcast just means that the higher-level > > protocol > > thought this was a broadcast packet; cisco doesn't support multidrop > > HDLC at this time. > > > > The second ("control") octet is always 0. > > > > The next two octets are a 16-bit protocol code, sent > > most-significant-first. > > These codes are usually Ethernet type codes. cisco has > added some codes > > to > > support packet types that don't appear on Ethernets. The > current list > > of codes > > is as follows: > > > > TYPE_PUP 0x0200 PUP > > TYPE_XNS 0x0600 XNS > > TYPE_IP10MB 0x0800 IP > > TYPE_CHAOS 0x0804 Chaos > > TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge > > spanning prot. > > TYPE_DECNET 0x6003 DECnet phase IV > > TYPE_BRIDGE 0x6558 Bridged > Ethernet/802.3 packet > > TYPE_APOLLO 0x8019 Apollo domain > > TYPE_REVERSE_ARP 0x8035 cisco SLARP (not > real reverse > > ARP!) > > TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree > > protocol > > TYPE_ETHERTALK 0x809b Apple EtherTalk > > TYPE_AARP 0x80f3 Appletalk ARP > > TYPE_NOVELL1 0x8137 Novell IPX > > TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP > > > > This list is shared between serial and Ethernet > encapsulations. Not all > > these codes will necessarily appear on serial lines. This list will > > probably > > be extended as cisco adds support for more protocols. > > > > Bytes after this are higher-level protocol data. These > normally look the > > same as they'd look on Ethernet. Bridging packets include > Ethernet/802.3 > > MAC headers; no other packets do. > > > > Packets with type 8035 (reverse ARP) don't contain reverse > ARP data as > > they would on an Ethernet. Instead, they carry a protocol > cisco refers > > to > > as SLARP. SLARP has two functions: dynamic IP address > determination and > > serial line keepalive. > > > > The serial line model supported by SLARP assumes that each > serial line > > is > > a separate IP subnet, and that one end of the line is host > number 1, > > while > > the other end is host number 2. The SLARP address > resolution protocol > > allows > > system A to request that system B tell system A system B's > IP address, > > along with the IP netmask to be used on the network. It > does this by > > sending > > a SLARP address resolution request packet, to which system > B responds > > with a > > SLARP address resolution reply packet. System A then attempts to > > determine its > > own IP address based on the address of system B. If the > host portion of > > system > > B's address is 1, system A will use 2 for the host portion > of its own IP > > address. Conversely, if system B's IP host number is 2, > system A will > > use IP > > host number 1. If system B replies with any IP host number > other than 1 > > or 2, > > system A assumes that system B is unable to provide it with > an address > > via > > SLARP. > > > > For the SLARP keepalive protocol, each system sends the other a > > keepalive > > packet at a user-configurable interval. The default interval is 10 > > seconds. > > Both systems must use the same interval to ensure reliable > operation. > > Each system assigns sequence numbers to the keepalive > packets it sends, > > starting with zero, independent of the other system. These sequence > > numbers > > are included in the keepalive packets sent to the other > system. Also > > included > > in each keepalive packet is the sequence number of the last > keepalive > > packet > > _received_ from the other system, as assigned by the other > system. This > > number > > is called the returned sequence number. Each system keeps > track of the > > last > > returned sequence number it has received. Immediately > before sending a > > keepalive > > packet, it compares the sequence number of the packet it is > about to > > send with > > the returned sequence number in the last keepalive packet it has > > received. > > If the two differ by 3 or more, it considers the line to > have failed, > > and > > will route no further higher-level data across it until an > acceptable > > keepalive > > response is received. > > > > There is interaction between the SLARP address resolution > protocol and > > the > > SLARP keepalive protocol. When one end of a serial line > receives a SLARP > > address resolution request packet, it assumes that the > other end has > > restarted > > its serial interface and reset its keepalive sequence numbers. In > > addition > > to responding to the address resolution request, it will > act as if the > > other end had sent it a keepalive packet with a sequence > number of zero, > > and a returned sequence number the same as the returned > sequence number > > of the last real keepalive packet it received from the other end. > > > > The following is a C definition for the SLARP packet. The > "long" and > > "ulong" > > types are 32-bit numbers, high octet sent first. The > "ushort" type is a > > 16-bit > > number, high octet sent first. > > > > struct slarp { > > long code; /* SLARP packet type code */ > > union sl { /* followed by one of: */ > > struct { /* Address resolution > > functions */ > > ulong address; /* Address of > system sending > > this pkt */ > > ulong mask; /* IP subnet mask for this > > line */ > > ushort unused; /* Unused: contents > undefined */ > > } add; /* -- or -- */ > > struct { /* Keepalive probing > > functions */ > > ulong mysequence; /* Outgoing > sequence number */ > > ulong yoursequence; /* Returned > sequence number */ > > ushort reliability; /* Reserved: set to FFFF */ > > } chk; > > } t; > > }; > > > > Note that the data storage for t.add is overlayed on the > data storage > > for > > t.chk. The whole SLARP packet consists of a 32-bit type > code, followed > > by > > two 32-bit quantities and one 16-bit quantity. The overall > length of the > > SLARP packet is 14 octets. The "code" field is used to identify the > > packet's > > SLARP type. Legal values for the "code" field are as follows: > > > > SLARP_REQUEST 0 Address resolution request > > SLARP_REPLY 1 Address resolution reply > > SLARP_LINECHECK 2 Line keepalive > > > > For address resolution request packets, the "address" and > "mask" fields > > are > > set to zero, and the contents of the "unused" field field are > > undefined. For > > address resolution reply packets, the "address" field > contains the IP > > address > > of the _replying_ system, and the "mask" field contains the > IP subnet > > mask > > to be used. The contents of the "unused" field are undefined. > > > > For keepalive packets, the "mysequence" field contains the sequence > > number > > of the packet and the "yoursequence" field contains the returned > > sequence > > number, which is the sequence number of the last keepalive > packet the > > sending > > system has gotten from the receiving system. The > "reliability" field is > > reserved for future use, and _must_ be set to FFFF hexadecimal. > > > From owner-ietf-ppp-outgoing@merit.edu Thu Mar 29 11:08:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20946 for ; Thu, 29 Mar 2001 11:08:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id EADCB5DE53; Thu, 29 Mar 2001 11:05:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CA06F5DE6C; Thu, 29 Mar 2001 11:05:29 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 42DD25DE53 for ; Thu, 29 Mar 2001 11:05:28 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27084; Thu, 29 Mar 2001 08:05:21 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08138; Thu, 29 Mar 2001 11:05:15 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f2TG5rq72304; Thu, 29 Mar 2001 11:05:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15043.23905.542317.309854@gargle.gargle.HOWL> Date: Thu, 29 Mar 2001 11:05:53 -0500 (EST) From: James Carlson To: Shahram Davari Cc: "'Bora Akyol'" , Archie Cobbs , "'Sylvanus Jonnalagadda'" , ietf-ppp@merit.edu Subject: RE: Cisco HDLC In-Reply-To: Shahram Davari's message of 29 March 2001 07:52:27 References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B6B@BBY1EXM01> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Shahram Davari writes: > 1)is C-HDLC bit-stuffed or byte-stuffed? (somebody said it is bit-stuffed) This isn't really a Cisco HDLC question; it's an HDLC question. It would be bit-stuffed on synchronous links, and byte-stuffed on asynchronous links. Of course, I don't think it's ever used on async links, but there's nothing wrong with doing that. > 2)Does it have padding at the end? No. > 3)Does it have CRC-16 or 32? Either. As I recall, the default is CRC-16, but there's no reason you couldn't support both. Don't forget -- you have to configure both ends to use this protocol. It's no big deal to configure optional features as well. Plus, it's up to you to test for interoperability with the devices that you care about. You can't get that from any specification. When implementation and specification differ, most folks defer to implementation, since it doesn't help the customer a bit if you merely say "but we do it right, and that other box is wrong." > 4)Does it use the same flag as HDLC? Sure. It uses HDLC. > 5)Can C-HDLC be used in packet over sonet application? > 6)If yes is it scrambled or not? If so what type of scrambling? These are HDLC and deployment questions, not protocol issues. If it were used in POS-type mode, I'd expect it to follow RFC 2615. I haven't seen that done (all the POS devices I've used are either PPP or Cisco SRP), but it sounds doable. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Mar 30 14:54:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09703 for ; Fri, 30 Mar 2001 14:54:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49D535DE01; Fri, 30 Mar 2001 14:54:11 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2AD795DE08; Fri, 30 Mar 2001 14:54:11 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 86E255DE01 for ; Fri, 30 Mar 2001 14:54:09 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA02555; Fri, 30 Mar 2001 11:54:12 -0800 (PST) Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAZ16411; Fri, 30 Mar 2001 11:54:07 -0800 (PST) Message-Id: <4.3.1.0.20010330115255.01d6de98@mira-sjcm-2.cisco.com> X-Sender: brucet@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 30 Mar 2001 11:57:19 -0800 To: Ali Irfan-FIA225 From: Bruce A Thompson Subject: RE: Comments: ppp-over-aal2 Cc: "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu >At 03:38 PM 03/29/2001 -0600, Ali Irfan-FIA225 wrote: > >Sorry, if this is a duplicate, but I have not seen this appear on the pppext >mailing list. > >Irfan > >-----Original Message----- >From: Ali Irfan-FIA225 >Sent: Wednesday, March 21, 2001 11:47 AM >To: Bruce A Thompson >Cc: ietf-ppp@merit.edu; Pazhyannur Rajesh-QA6283 >Subject: Comments: ppp-over-aal2 > > > >Bruce, > >Some comments on the draft: > >Section 4, para 2: Is the limitation of 1500 bytes MRU for CRC-16 a >hard-limit? Is this necessary? The MRU probably depends on the >error-characteristics of the link. Probably leave it as an exercise to the >configurator to determine the appropriate MRU for a link using CRC-16. The >same comment carries over to the last sentence in Section 8. I think you may be right about the 1500 byte CRC being incorrect. We put the 1500 byte MRU in because I thought that this was the maximum payload size that a CRC-16 could protect. From talking to people more knowledgeable than I about CRC's, I understood that in general a CRC of X bits can protect for errors in a payload of up to 2**X bits. I assume this formula is for single bit errors. Now that I run the numbers though, it looks like 2**16 bits comes to a protected payload size of 8K bytes instead of 1500 bytes. So the 1500 byte MRU is incorrect based on the formula above. I think we should base Max MRU in this draft on the CRC length. Above a certain payload size, CRC become ineffective. I'm not sure though what formula we should be using for CRC length to max payload length. Do you have better info on the relationship between CRC length and payload protection again errors? >Section 5.2, para 2: This is not an attempt to nit-pick. You are right about >the overhead associated with PPPMux/AAL5. However, for overhead comparisons, >it might be better to just state the overheads and let the implementor >figure out which implementation is more efficient for his/her case. > >On a per-packet basis > PPP/AAL2 adds the following overhead: > 3 bytes CPS-PKT-HDR + (1 or 2) bytes PPP-Protocol ID + (1 or >2) bytes CRC. > PPPMux/AAL5 adds the following overhead: > (1 or 2) byte Length field + (0-2) bytes PPP Protocol ID. > >On a per-frame (or per muxed-packet) basis: > PPP/AAL2 adds the following overhead: > Padding only when TIMER_CU expires > PPPMux/AAL5 adds the following overhead: > 8 bytes of AAL5 trailer + Padding on the last ATM cell. > >On a per ATM cell basis PPP/AAL2 adds 1 additional byte overhead of STF when >compared with PPPMux/AAL5. I went through this level of detail in the presentation I made in December. We could make the changes you suggest, or remove section 5 entirely. This section was really meant as justification to get the draft accepted as a work group item. Do you feel we should make changes to the section or remove it? >Section 6.1.4: STF =? Start Field in I.363.2. >Section 6.2.1 : Is the CRC-16 computation a commonly used one or is this >new. It might be helpful to provide a reference to a standard where this is >commonly used. We took this from Q.921. Q.921 does not reference a separate spec for the FCS computation. >Section 6.2.2: Same as above for CRC-8. We got this CRC spec from another ITU spec. I forgot which one at the moment. We decided at the last meeting to remove CRC-8 anyways. >Section 7: The example is a little bit too long and contains many facts >which have little relation to the PPP/AAL2 standard. It may be better to >delete all the discussion above the PPP layer. Whether RFC2508 is used for >compression is not related to PPP/AAL2. I thought this section did add value. It sounds like your concern is that we describe too much about the application instead of just describing from PPP downward. We can make this change. >Section 7: Between the length filter and the SSSAR should be the Service >Specific Transmission Error Detection sublayer (SSTED), where the CRC >computation occurs? SSTED specifies a AAL-5 like structure on top of SSSAR. This draft is specifying the encapsulation for PPP over AAL2 which include CRC generation. So, CRC computation for PPP over AAL2 is part of this spec and not currently specified in any ITU document. >Section 8: Should mention that PPP LCP FCS-alternatives extensions is >described in RFC1570. (Any reason for using option values 32 and 64 and not >8 and 16 for 8-bit CRC and 16-bit CRC? Is there a specific name to the 8 and >16 bit CRCs described in the draft? From the last meeting, we decided to get rid of CRC-8. This will get rid of much of the complexity described in the draft. It also means that there will be no negotiation for CRC via LCP. This section will now just say that CRCs cannot be negotiated via LCP and that only CRC-16 is supported. >Section 8, last sentence: See first comments. Also Is the following >statement from RFC2364 applicable here: > >The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a > larger size than the maximum CPCS-SDU size specified in the > associated direction for the virtual connection's traffic contract. The SSSAR function does not have any maximum payload defined for it. We should define the maximum payload based on CRC length from comments above. >Bigger question on section 6.2: In previous email-trains, there was concern >that allowing multiple options for CRC based on length of payload causes >complexity and should be avoided; however, the current draft still has two >options CRC-8 and CRC-16 based on the length of the payload. The difference >is only one byte. In most cases, the smallest size payload including the >PPP-protocol id will be about 10 bytes. The difference between 8 and 16 bit >CRC is 10% and will be lower for smaller sized payloads. Can we not just >stick with the 16 bit CRC? That's what we decided in the last mtg. Note though the complexity is optional since 8 bit CRC is negotiated. >The only reason for having the 8 bit CRC would be to cover the case when one >wants to protect header and not the payload. If that is the objective, then >the 8 bit CRC option should state this clearly. Also, there should be >negotiation for this, and only one CRC algorithm (8 bit-on-header, or 16 >bit-on-payload) should be running on a PPP connection. My opinions. Not true. We defined the max payload size for CRC-8 to be 32 bytes. That's 2**8 bits. So, CRC-8 was for applications that wanted high bandwidth efficiency with very small payloads (< 32 bytes). We decided at the mtg that the benefits did not warrant the complexity of including CRC-8 in the draft. Bruce T >Regards > >Irfan Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA