From owner-ietf-ppp@merit.edu Tue Dec 1 07:50:49 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id HAA08814; Tue, 1 Dec 1998 07:50:07 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Dec 1998 07:43:44 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id HAA08734 for ietf-ppp-outgoing; Tue, 1 Dec 1998 07:43:43 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id HAA08730 for ; Tue, 1 Dec 1998 07:43:36 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id HAA04243 for ietf-ppp@merit.edu; Tue, 1 Dec 1998 07:43:35 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: I-D ACTION:draft-ietf-pppext-scm-01.txt Date: 01 Dec 1998 07:43:35 -0500 Organization: IronBridge Networks Lines: 213 Message-ID: <86g1b0kp6w.fsf@ironbridgenetworks.com> References: <001a01be1948$94b19bc0$3b4aa083@tos92022.lmf.ericsson.se> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu mikael.latvala@ericsson.com ("Mikael Latvala") writes: > 1. We want to be sure that when the physical link is re-established it is > indeed associated with the right PPP session. CLID does not help us > because > of multiple reasons: not always available, B-channel problem (PPP > session > alternates between 2 or more CLIDs), remote host roams to a new service > area, or more than one remote host uses the same circuit-switched link. > > Currently there is now good way to identify PPP sessions uniquely within > the > access network, e.g. two or more hosts can generate the same magic > number. > To fix this we introduced this PPP Session-Identifier option which the > access server gives to the remote host (through LCP negotiation > process). > Once the remote host has it, it uses the value in the option to generate > a LCP Indetification packet which it sents to the access server before > any other packets. Such a mechanism already exists. Concatenating Endpoint Discriminator with authentication credentials works as an identifier of a single node. Note that if the peer doesn't have E-D, which is already described in a standard RFC, it's fairly unlikely that this peer will implement this new, experimental option. Existing solutions are to be preferred. > 2. End users want to disable/enable the terminating call functionality > (i.e. > the access server can re-establish the physical link in case it receives > a > packet destined to the remote host) at a moment's notice. Some people > prefer > to fetch the email when it suits them, others want to receive it > automatically in "real-time" (lot cheaper than probing the mail server > every > X min). Some people want to do the former thing one day and the later > thing the next day. This argument is also valid for interactive > applications, chat, IRC, VoIP, etc. > > SCM allows customers to convey their terminating call wish to access > servers. Don't know any other to do this. Assuming that there are ISPs that will do this in a reasonable way, this can (and is) already configured in most common access servers. Given that it's already being done, of what use is SCM? I think it suffices to arrive at some convential usage for demand dial in this situation rather than creating yet another protocol. For instance, a reasonable implementation would insist that an activity timeout or physical layer drop implies that the peer is still there and should be called back on reception of data matching some complex filter. On the other hand, explicit LCP Terminate-Request by the peer or RNA (ring-no-answer) on attempted dial-back would imply that the peer is no longer present. At least that's how *I've* seen it done in common implementations. Another possibility would be to establish a convention for the text string in the LCP Terminate-Request message. Call it the Blondie option and put the string "Call me" in there. ;-} (Gee, what happens if a bad user out there on the Internet SYN-bombs one of these poor, unsuspecting demand-dial users? In the US, the flood of calls would be a civil matter. In most European countries, though, I believe this would bring criminal charges.) > 3. The implementation (in remote hosts) is more straight forward when the > remote host knows for sure whether the access server supports SCM or > not. > Without this explicit information the implementation has to probe the > access server to find if it supports SCM (probe = terminate and > re-establish > the physical link and see if the access server accepts network packets > without reconfiguring the pont-to-point link). Excuse me? What do you mean by "reconfiguring" the link? When you restart a PPP session, you always renegotiate all options. Are you implying otherwise? > BUT, why do any probing when we have this beatiful negotiation > mechanism? > After all, isn't this why PPP was invented? By the same logic we could > stop using PFC and ACFC options and probe the peer to find out whether > those > options are supported. If we have such a beautiful negotiation mechanism, it seems somewhat odd to want to intentionally circumvent it. > vjs@calcite.rhyolite.com wrote: > >When you are re-establishing a > >connection, you know everything the peer will say except the authentication > >random strings and ID fields, and so can predict every other bit of the > >Configure- Requests and -Acks. However, those can be securely predicted > >given a slight change. Have both peers compute the ID fields and their > >CHAP challenge strings using MD5 hashes of their shared CHAP secret > >concatenated with the last CHAP response of the previous connection. > >Use the first 3 bytes of the 16-byte hash for the ID fields of the LCP > >CR, CHAP challenge, and IPCP CR. Use the entire 16-bytes for the CHAP > >challenge. Then let the peer re-establishing the link by send the LCP > >CR, CHAP challenge, and IPCP Configure-Requests and predicted > >Configure-Acks in a single burst. > > > Hmmm ... isn't this against what RFC1661 says. Quote: > > "3.4. Link Establishment Phase > > [...] > > Any non-LCP packets received during this phase MUST be silently > discarded." Nope. Doesn't violate that clause at all. What happens is that the peer goes through all the normal state transitions and transmits all the normal replies, but when it goes to read the next message, the message just happens to be already available in the input queue. It is true that there are some remarkably poorly designed implementations of PPP out there that have timing flaws that are exposed by this trick. In particular, if state changing is not synchronous with message reading (if message reading is, say, done within a receive interrupt), then this won't work. But so what? The "early" messages from the peer are then just silently discarded (per RFC 1661), and the poor implementation eventually times out, resends LCP Configure-Request, and starts over. An implementation using the fast-reconnect trick would detect this as a peer restart and would switch back to "normal" multiple-RTT negotiation. > OK, could you tell me which commercial products out there do support this > "demand dialing" functionality? None of the MS products have this (that does > not probably surprise anynone). All of the Unix ones do. As a classic Dilbert cartoon said, "here's a nickle, kid; buy yourself a real computer." The ones I've used are IBM's AIX native bos.net.ppp, SGI's IRIX native ppp, the freely available "dp," Ascend MAX servers, Annex servers, and Bay's Clam and Nautica routers. All of these can dial on demand quite nicely, thank you. I'm sure there are many, many others. Since I use no PCs at all, I'm afraid I can't really give you much help finding a good implementation there. I've heard others say good things about FTP and Funk, for what it's worth. > Well, this is not what we keeping hearing from our customers. They want be > able to disable and enable the terminating call functionality at a moment's > notice. > And this is definately within the scope of PPP, configuring whether the peer > can re-establish a physical link. And why can't that be done by convention as described above? Why must it be a novel negotiation option? And what happens to the folks already doing demand dial without benefit of this option? Must they now upgrade in order to keep their current configuration working? > >You did not mention endpoint identifiers. > >Please say why your algorithm could not be implemented using the > >existing LCP Endpoint-Identifier option instead of a new option. > > > > I am not aware of such a LCP Endpoint-Identifier which is guaranteed to be > unique within the access network. Could you point me to the RFC/draft which > specifies such an option? RFC 1990. > >The proposal apparently involves a new LCP option. LCP options are in > >LCP packets. To use the new LCP option, LCP packets must be exchanged. > > > > Yes, both only once, i.e. in the beginning of each PPP session. So I think > what I wrote is still valid. The access server is not required to > re-authenticate the remote host, e.g. some systems would rely on CLIDs. This isn't much of a benefit. Today's dial-up servers could, if they were ingenuous enough, cache calling party information and use this key to determine whether or not to insist on having the peer identify itself. This can be done right now without adding a new protocol. That nobody ever does this reflects two things. First, authentication is simple and fast enough that there's no particular need to conditionally skip it. Second, any system that skips PPP authentication in favor of external credentials is fatally compromised. What I think is really going on here is that there are a number of really, really bad implementations of PPP out there. Worse, some of the worst implementations are in widespread use. This option is an attempt to short-cut some of the more lame aspects of these implementations and deliver the appearance of a faster connection set-up and cleaner behavior to users. This isn't the right way to design protocols. If the implementations are bad and are taking more than a few milliseconds to negotiate a PPP link up or are unable to determine when or if to dial or do not understand the standard, common semantics of link layer termination, then this problem needs to be fixed *first*, before considering anything else. Building a hyperspace bypass around negotiation is safe only if this is some usage of the word with which I was not previously aware. :-/ -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 1 10:50:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA11703; Tue, 1 Dec 1998 10:40:07 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Dec 1998 10:37:51 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA11617 for ietf-ppp-outgoing; Tue, 1 Dec 1998 10:37:50 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA11612 for ; Tue, 1 Dec 1998 10:37:43 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA22757 for ietf-ppp@merit.edu; Tue, 1 Dec 1998 10:37:42 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by merit.edu (8.9.1a/8.9.1) with ESMTP id HAA08853 for ; Tue, 1 Dec 1998 07:51:36 -0500 (EST) Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id NAA00947 for ; Tue, 1 Dec 1998 13:51:31 +0100 (MET) Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA09646; Tue, 1 Dec 1998 14:51:26 +0200 (EET) Message-ID: <3663E641.61648AF7@ericsson.com> Date: Tue, 01 Dec 1998 14:51:13 +0200 From: Mikael Latvala Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: Demand dialing for mobile hosts References: <199811302136.OAA28211@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu vjs@calcite.rhyolite.com wrote: > > > From: Mikael Latvala > > > ... > > What comes to the arg #2 there are customers (i.e. operators) out there > > which would like to offer such an option for their cutomers. Sorry, I am > > not in a position to reveal any names. > > I'm sorry, but I cannot believe that statement without more concrete > support. In the U.S., it is practically impossible to convince an > Internet Service Provider to call its customers under any circumstances, > with the almost as rare exception of a symmetric 'nailed-up' connection, > which could not use the proposed SCM option. The trouble is not that the > commong hardware and software does not support symmetric (or ISP > originating) demand dialing, but that ISP's are unwilling or unable to > handle the purely-human, administrative effort of configuring their > equipement to call their customers. That fact, that ISP's do not and will > not dial, irritates me for several reasons, but it is a fact. That fact > would not be changed by the proposed SCM option. > We already went through this once. Telcos can place NAS boxes next to their CO switches which means that they can re-establish the physical link and still place the charge on the customer. Your dear local operator(s) want to get into this Internet business very badly. > > And yes, there are other less gentle > > ways to do this, turn off your modem or sell your computer so that you wont > > get e.g. disturbing connection requests but they are some what prehistoric. > > What is wrong with turning off your modem or dropping DTR or using a Hayes > command to not receive phone calls? That not be a trendy technique, but > it always works, and does not require waiting for the deployment of any > new LCP options. > For example if you have a modem answering machine. You are not home, want the modem answering machine to save messages but do not want to pay for for multiple futile short connections when you receive an email, VoIP call request, etc. > > This way the end user who is going to ftp files could for example instruct > > the implementation not to drop the line if the other side does not support > > SCM functionality. In demand dialing the end user has to restart the ftp > > session in case the NAS does not support demand dialing functionality (the > > point-to-point link is reconfigured and is assigned most likely a new IP > > address). > > I do not understand that at all. While using FTP to copy files, you do > not want the link to drop, and so the proposed SCM option is not relevant. > But when using SCM the end user knows *before* he starts a FTP session whether the NAS supports SCM. This allows the end user to either tell the implementation not to drop the line during the PPP session or adjust the Idle Timer value to his liking so that the link is most unlikely dropped during the FTP session. Without SCM the end user can find out that the NAS does not support demand dialing either by learning that his machine has been assigned a new IP-address or by being informed of the lack of demand dialing support by the implementation. Neither of these ways is really good because in the former case the information is never given explicitly to the end user, and in the later case the end user receives information concerning the point-to-point link only after link has been in use for "some" time. > I think that instructions on how to implement demand dialing really should > br written by people who have implmented it, or at least used it > extensively, but maybe I'm too picky. > Well, that's what the chair of this WG said in Memphis 1997. Over year and a half later nothing has happened. I think that we have waited for this miracle to become true long enough, volunteers to co-author this draft are warmly welcomed. /Mikael - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 1 11:44:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA13270; Tue, 1 Dec 1998 11:41:04 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Dec 1998 11:38:44 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA13191 for ietf-ppp-outgoing; Tue, 1 Dec 1998 11:38:44 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA13187 for ; Tue, 1 Dec 1998 11:38:38 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id JAA00913 for ietf-ppp@merit.edu env-from ; Tue, 1 Dec 1998 09:38:36 -0700 (MST) Date: Tue, 1 Dec 1998 09:38:36 -0700 (MST) From: Vernon Schryver Message-Id: <199812011638.JAA00913@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Demand dialing for mobile hosts Sender: owner-ietf-ppp@merit.edu > From: Mikael Latvala > ... > > > What comes to the arg #2 there are customers (i.e. operators) out there > > > which would like to offer such an option for their cutomers. Sorry, I am > > > not in a position to reveal any names. > > > > I'm sorry, but I cannot believe that statement without more concrete > > support. In the U.S., it is practically impossible to convince an > > Internet Service Provider to call its customers under any circumstances, > ... > We already went through this once. Telcos can place NAS boxes next to > their CO switches which means that they can re-establish the physical > link and still place the charge on the customer. Your dear local > operator(s) want to get into this Internet business very badly. Since the last time we went through this a year or so ago, *DSL has become popular in the U.S. The Telcos are putting NAS boxes in their CO's, but the resulting IP link is effectively "nailed-up", and does NOT involve the telco dialing the end-user. Similar considerations apply to the IP-over-cable-TV systems. The problem with Internet Service Providers originating phone calls is not merely a matter of billing. Billing is just as easy for orginated as answered phone calls. The problems with ISP's orginating phone calls are not technical, but human. For an ISP (including a telco) to answer a call, the ISP (including the telco) need only configure 3 things, a "username", a "password", and some kind of account name or number for billing. To originate a phone call, the ISP (including telco) needs those three, plus a second "username", a second "password", and at least a phone number. That's a doubling of the configuration information, and a significant problem. However, I suspect the most significant problem is that the ISP must lead the end-user through configuring the end-user's computer to answer the phone. In real life, where the ISP people are at best marginally competent to configure the ISP's own computers, that last issue of configuring the end-user (i.e. "CPE") computer to answer the phone is enough to make anyone with a clue about real life into extended hysterical laughter. Having the typcical telco "craftsperson" instruct the typical "joe sixpack" in configuring the literally hundreds of different kinds of computer that Joe Sixpack might have is a great joke. That's why *DSL and cable-TV boxes work. The craftsperson merely delivers and wires a self-configuring or pre-configured router or bridge to the phone line or TV cable. Joe Sixpack just connects the RJ-11 or DB-9/25 cable between the computer and the box, and it's all done. No where in that sceneario are the SCM proposal or any kind of "fast reconnect" notion needed or even relevant. > ... > > > ways to do this, turn off your modem or sell your computer so that you wont > > > get e.g. disturbing connection requests but they are some what prehistoric. > > > > What is wrong with turning off your modem or dropping DTR or using a Hayes > > command to not receive phone calls? That not be a trendy technique, but > > it always works, and does not require waiting for the deployment of any > > new LCP options. > > For example if you have a modem answering machine. You are not home, > want the modem answering machine to save messages but do not want to pay > for for multiple futile short connections when you receive an email, > VoIP call request, etc. Sheesh!--I addressed that issue in a draft of my response, but deleted it because I feared offending by stating the obvious...You will not have a modem sharing a phone line with a voice answering machine unless you have distinctive ringing or equivalent. Consider blasting modem answer-tones at all of the callers of your voice answering machine. If you have a system that uses DTMF tones, distinctive ringing, ISDN TEI's or other ways to direct incoming calls to a modem (or modem function in a combined system), why can't you simplyt turn off the modem or modem portion of the system? If you are dealing with voice/IP, then why wouldn't you want your modem to answer the phone, so that it could record the voice? > > > This way the end user who is going to ftp files could for example instruct > > > the implementation not to drop the line if the other side does not support > > > SCM functionality. In demand dialing the end user has to restart the ftp > > > session in case the NAS does not support demand dialing functionality (the > > > point-to-point link is reconfigured and is assigned most likely a new IP > > > address). > > > > I do not understand that at all. While using FTP to copy files, you do > > not want the link to drop, and so the proposed SCM option is not relevant. > > > But when using SCM the end user knows *before* he starts a FTP session > whether the > NAS supports SCM. This allows the end user to either tell the > implementation > not to drop the line during the PPP session or adjust the Idle Timer > value to his liking so that the link is most unlikely dropped during the > FTP session. If you are using FTP, then the line does not go idle, and so the link is not dropped. If the line goes idle during an FTP session, then you want to drop the line, because the TCP connection will have long sinced died. > Without SCM the end user can find out that the NAS does not support > demand dialing either by learning that his machine has been assigned a > new IP-address or by being informed of the lack of demand dialing > support by the implementation. Neither of these ways is really good > because in the former case the information is never given explicitly to > the end user, and in the later case the end user receives information > concerning the point-to-point link only after link has been in use for > "some" time. That is entirely false. With SCM, the end user <> determine whether the NAS supports demand dialing. The absense of SCM does not imply that demand dialing is not supported. > > I think that instructions on how to implement demand dialing really should > > br written by people who have implmented it, or at least used it > > extensively, but maybe I'm too picky. > > Well, that's what the chair of this WG said in Memphis 1997. Over year > and a half later nothing has happened. I think that we have waited for > this miracle to become true long enough, volunteers to co-author this > draft are warmly welcomed. Speaking as someone who has implemented demand dialing, I would not be interested in helping Mr. Latvala write an RFC about demand dialing until Mr. Latvala has some personal experience using FTP, PPP, modems, and even demand dialing. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 1 12:33:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA14515; Tue, 1 Dec 1998 12:31:46 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Dec 1998 12:30:32 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA14484 for ietf-ppp-outgoing; Tue, 1 Dec 1998 12:30:31 -0500 (EST) Received: from altiga.com (altiga.com [207.31.202.130]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA14475 for ; Tue, 1 Dec 1998 12:30:23 -0500 (EST) Received: from perforce.altiga.com ([10.10.0.11]) by fw.altiga.com with ESMTP id <130817>; Tue, 1 Dec 1998 12:26:52 -0500 Received: from mail.altiga.com (mail [10.10.0.10]) by perforce.altiga.com (8.9.1/8.9.1) with ESMTP id MAA01376 for ; Tue, 1 Dec 1998 12:27:21 -0500 (EST) Received: by mail.altiga.com with Internet Mail Service (5.5.2232.9) id ; Tue, 1 Dec 1998 12:26:05 -0500 Message-ID: From: "Rodwin, Andrew" To: ietf-ppp@merit.edu Subject: RE: I-D ACTION:draft-ietf-pppext-pptp-06.txt (fwd) Date: Tue, 1 Dec 1998 12:26:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Sorry if I missed the answer to this question, but has the delta between 05 and 06 been posted? (The changes in the last few drafts seem to be exclusively typo fixes and formatting changes.) Thank you much for any help you can provide! =========================================== Andrew Rodwin Altiga Networks Principal Software Engineer 124 Grove Street, Suite 309 arodwin@altiga.com Franklin, MA 02038-3206 508 541-7300, x132 www.altiga.com 508 541-7030 (fax) -----Original Message----- From: David Haas [mailto:david.haas@tddny.fujitsu.com] Sent: Wednesday, November 25, 1998 1:51 PM To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-pptp-06.txt (fwd) > > > 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 : Point-to-Point Tunneling Protocol--PPTP > > Author(s) : K. Hamzeh, G. Pall, W. Verthein, > > J. Taarud, W. Little, G. Zorn > > Filename : draft-ietf-pppext-pptp-06.txt > > Pages : 54 > > Date : 23-Nov-98 > > Could someone summarize what has changed since draft -05? > > Thanks, > -Archie How about posting a diff of the two versions. Stupidly, I did not keep an electronic copy of -05. Thanks, David. > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- David J. Haas Fujitsu Network Communications, Inc. Voice: 914-731-2221 Two Blue Hill Plaza email: david.haas@tddny.fujitsu.com PO Box 1609 Pearl River, NY 10965 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 02:14:34 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id CAA29085; Wed, 2 Dec 1998 02:13:26 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 02:11:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id CAA29042 for ietf-ppp-outgoing; Wed, 2 Dec 1998 02:11:01 -0500 (EST) Received: from lohi.eng.telia.fi (jh@lohi.eng.telia.fi [195.10.149.18]) by merit.edu (8.9.1a/8.9.1) with ESMTP id CAA29036 for ; Wed, 2 Dec 1998 02:10:53 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.8.8/8.8.8/Debian/GNU) id JAA10436; Wed, 2 Dec 1998 09:10:30 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13924.59366.410645.750367@lohi.eng.telia.fi> Date: Wed, 2 Dec 1998 09:10:30 +0200 (EET) To: Matt Holdrege Cc: ietf-ppp@merit.edu, agenda@ietf.org Subject: PPPEXT agenda for Orlando In-Reply-To: <3.0.5.32.19981129200836.00b61cd0@porky> References: <3.0.5.32.19981129200836.00b61cd0@porky> X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: owner-ietf-ppp@merit.edu i'll withdraw the ppp-subnet presentation, because i have got enough commitment from cpe router vendors to implement the ppp/bootp combination for the same purpose. -- juha - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 10:35:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA05549; Wed, 2 Dec 1998 10:33:55 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 10:25:44 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA05348 for ietf-ppp-outgoing; Wed, 2 Dec 1998 10:25:43 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA05344 for ; Wed, 2 Dec 1998 10:25:39 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA13600 for ietf-ppp@merit.edu; Wed, 2 Dec 1998 10:25:38 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by merit.edu (8.9.1a/8.9.1) with ESMTP id FAA01880 for ; Wed, 2 Dec 1998 05:55:34 -0500 (EST) Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id LAA06188 for ; Wed, 2 Dec 1998 11:55:24 +0100 (MET) Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA23023; Wed, 2 Dec 1998 12:55:20 +0200 (EET) Message-ID: <36651C89.FAE59151@ericsson.com> Date: Wed, 02 Dec 1998 12:55:05 +0200 From: Mikael Latvala Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-scm-01.txt References: <86g1b0kp6w.fsf@ironbridgenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu carlson@ironbridgenetworks.com wrote: > > mikael.latvala@ericsson.com ("Mikael Latvala") writes: > > 2. End users want to disable/enable the terminating call functionality (i.e. > > the access server can re-establish the physical link in case it receives > > a packet destined to the remote host) at a moment's notice. Some people > > prefer to fetch the email when it suits them, others want to receive it > > automatically in "real-time" (lot cheaper than probing the mail server > > every X min). Some people want to do the former thing one day and the later > > thing the next day. This argument is also valid for interactive > > applications, chat, IRC, VoIP, etc. > > > > SCM allows customers to convey their terminating call wish to access > > servers. Don't know any other to do this. > > Assuming that there are ISPs that will do this in a reasonable way, > this can (and is) already configured in most common access servers. > Given that it's already being done, of what use is SCM? > > I think it suffices to arrive at some convential usage for demand dial > in this situation rather than creating yet another protocol. For > instance, a reasonable implementation would insist that an activity > timeout or physical layer drop implies that the peer is still there > and should be called back on reception of data matching some complex > filter. On the other hand, explicit LCP Terminate-Request by the peer > or RNA (ring-no-answer) on attempted dial-back would imply that the > peer is no longer present. > Makes sense. Do you know if anybody has implemented such a filter? If so, how can the end user configure the filter? Some application level proprietary protocol? > > (Gee, what happens if a bad user out there on the Internet SYN-bombs > one of these poor, unsuspecting demand-dial users? In the US, the > flood of calls would be a civil matter. In most European countries, > though, I believe this would bring criminal charges.) > Good point. This is exactly why the end user would like to have a some sort filter. The one specified in SCM is the crudest one. That could be, of course, improved (e.g. allowing the end user to specify port numbers) but I guess the question is on what level this filter configuration should happen. Has there been any talk about specifying a new appication level protocol which can be used to configure the filter? > > OK, could you tell me which commercial products out there do support this > > "demand dialing" functionality? None of the MS products have this (that does > > not probably surprise anynone). > > All of the Unix ones do. As a classic Dilbert cartoon said, "here's a > nickle, kid; buy yourself a real computer." I hope Microsoft folks are following this thread because the company policy does not allow me to have anything else on my laptop. > The ones I've used are IBM's AIX native bos.net.ppp, SGI's IRIX native > ppp, the freely available "dp," Ascend MAX servers, Annex servers, and > Bay's Clam and Nautica routers. All of these can dial on demand quite > nicely, thank you. You're welcome. Just curious, since when have the vendors had demand dialing in their access servers? Last time we talked about this, spring 97, nobody mentioned a word about demand dialing. /Mikael - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 10:53:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA06147; Wed, 2 Dec 1998 10:53:20 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 10:52:06 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA06080 for ietf-ppp-outgoing; Wed, 2 Dec 1998 10:52:05 -0500 (EST) Received: from java.tddny.fujitsu.com ([167.254.240.105]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA06072 for ; Wed, 2 Dec 1998 10:51:45 -0500 (EST) Received: from tddny.fujitsu.com ([167.254.240.99]) by java.tddny.fujitsu.com (Netscape Messaging Server 3.5) with ESMTP id AAA5106; Wed, 2 Dec 1998 10:50:28 -0500 Message-ID: <366561BB.A5093EB4@tddny.fujitsu.com> Date: Wed, 02 Dec 1998 10:50:19 -0500 From: David Haas Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Rodwin, Andrew" CC: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-pptp-06.txt (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I have not heard an answer to this question yet and I would love one also. Thanks, David. Rodwin, Andrew wrote: > > Sorry if I missed the answer to this question, but has the delta between 05 > and 06 been posted? (The changes in the last few drafts seem to be > exclusively typo fixes and formatting changes.) > > Thank you much for any help you can provide! > > =========================================== > Andrew Rodwin Altiga Networks > Principal Software Engineer 124 Grove Street, Suite 309 > arodwin@altiga.com Franklin, MA > 02038-3206 > 508 541-7300, x132 www.altiga.com > > 508 541-7030 (fax) > > -----Original Message----- > From: David Haas [mailto:david.haas@tddny.fujitsu.com] > Sent: Wednesday, November 25, 1998 1:51 PM > To: ietf-ppp@merit.edu > Subject: Re: I-D ACTION:draft-ietf-pppext-pptp-06.txt > (fwd) > > > > > > 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 : Point-to-Point Tunneling > Protocol--PPTP > > > Author(s) : K. Hamzeh, G. Pall, W. Verthein, > > > J. Taarud, W. Little, G. Zorn > > > Filename : draft-ietf-pppext-pptp-06.txt > > > Pages : 54 > > > Date : 23-Nov-98 > > > > Could someone summarize what has changed since draft -05? > > > > Thanks, > > -Archie > > How about posting a diff of the two versions. Stupidly, I > did not keep > an > electronic copy of -05. > > Thanks, > David. > > > > > > ___________________________________________________________________________ > > Archie Cobbs * Whistle Communications, Inc. * > http://www.whistle.com > > -- > David J. Haas > Fujitsu Network Communications, Inc. Voice: > 914-731-2221 > Two Blue Hill Plaza email: > david.haas@tddny.fujitsu.com > PO Box 1609 > Pearl River, NY 10965 -- David J. Haas Fujitsu Network Communications, Inc. Voice: 914-731-2221 Two Blue Hill Plaza email: david.haas@tddny.fujitsu.com PO Box 1609 Pearl River, NY 10965 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 11:05:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA06521; Wed, 2 Dec 1998 11:04:42 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 11:03:06 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA06457 for ietf-ppp-outgoing; Wed, 2 Dec 1998 11:03:06 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA06450 for ; Wed, 2 Dec 1998 11:02:59 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id JAA06702 for ietf-ppp@merit.edu env-from ; Wed, 2 Dec 1998 09:02:57 -0700 (MST) Date: Wed, 2 Dec 1998 09:02:57 -0700 (MST) From: Vernon Schryver Message-Id: <199812021602.JAA06702@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-scm-01.txt Sender: owner-ietf-ppp@merit.edu > From: Mikael Latvala > ... > > The ones I've used are IBM's AIX native bos.net.ppp, SGI's IRIX native > > ppp, the freely available "dp," Ascend MAX servers, Annex servers, and > > Bay's Clam and Nautica routers. All of these can dial on demand quite > > nicely, thank you. > > You're welcome. Just curious, since when have the vendors had demand > dialing > in their access servers? Last time we talked about this, spring 97, > nobody mentioned a word about demand dialing. What is a "vendor" in this context? A telco, an Internet Service Provider, or a maker of hardware or software such as IBM, Silicon Graphics, Ascend, Annex, or Bay? Telco's are only now and still slowly discovering that PPP and the rest of the data world exist. As I've said more often than should be necessary, there are reasons why Internet Service Providers have resisted symmetric demand dialing. One-sided demand-dialing, such as by a "client" is very ancient and merely the obvious automation of connecting one computer to another. My first data-over-phones project involved a computer "on demand" using a solenoid to take a standard, Western Electric phone off the hook, using an accoustic coupler to "dial" with DTMF tones, and then sending 103 FSK data. (Such nonsense was required back then, before DAA's and long before Part 68, if you had reasons to not use Western Eletric modems.) 1997 is quite recent. Some vendors considered demand dialing worth implementing before the formation of either or the two IETF groups that were merge to form the current the IETF PPP working group. Demand dialing was in some SLIP implementations. Obviously, all of the vendors Jim Carlson listed above considered demand dialing important well before 1997, because of the delays between making product decisions and delivering products. What is meant by "last time we talked ... nobody mentioned demand dialing"? I'm fairly certain that I mentioned symmetric demand dialing the previous time Mr. Latvala proposed a fast re-connection mechanism. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 14:59:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id OAA11765; Wed, 2 Dec 1998 14:59:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 14:56:31 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA11686 for ietf-ppp-outgoing; Wed, 2 Dec 1998 14:56:30 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA11682 for ; Wed, 2 Dec 1998 14:56:26 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id OAA05033 for ietf-ppp@merit.edu; Wed, 2 Dec 1998 14:56:26 -0500 (EST) Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [199.92.133.126]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA10634 for ; Wed, 2 Dec 1998 14:14:00 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id OAA26737 for ; Wed, 2 Dec 1998 14:14:41 -0500 (EST) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma026690; Wed, 2 Dec 98 14:14:20 -0500 Received: from dur-mail.ctron.com (dur-mail [134.141.69.20]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id OAA06750 for ; Wed, 2 Dec 1998 14:13:36 -0500 (EST) Received: from jpn-exc1.ctron.com ([134.141.240.57]) by dur-mail.ctron.com (8.8.7/8.8.7) with ESMTP id OAA04785 for ; Wed, 2 Dec 1998 14:13:28 -0500 (EST) Received: by JPN-EXC1 with Internet Mail Service (5.5.2232.9) id ; Wed, 2 Dec 1998 02:45:04 +0900 Message-ID: From: "Nelson, David" To: "'ietf-ppp@merit.edu'" Subject: FW: Demand dialing for mobile hosts Date: Wed, 2 Dec 1998 02:45:11 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu > Vernon Schryver writes... >Since the last time we went through this a year or so ago, *DSL has become >popular in the U.S. The Telcos are putting NAS boxes in their CO's, but >the resulting IP link is effectively "nailed-up", and does NOT involve >the telco dialing the end-user. Similar considerations apply to the >IP-over-cable-TV systems. While I don't endorse the SCM draft, I note that the "nailed-up" links prevalent in the US are predicated on the notion of "free" local phone calls. In many other places in the world all calls are charged by the minute, even local ones. Essentially, telephone tariffs and billing practices, and not technical issues, drive the need for dynamic disconnect and reconnect. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 15:36:49 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA12861; Wed, 2 Dec 1998 15:36:27 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 15:35:03 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA12802 for ietf-ppp-outgoing; Wed, 2 Dec 1998 15:35:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA12797 for ; Wed, 2 Dec 1998 15:34:57 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id NAA07711 for ietf-ppp@merit.edu env-from ; Wed, 2 Dec 1998 13:34:55 -0700 (MST) Date: Wed, 2 Dec 1998 13:34:55 -0700 (MST) From: Vernon Schryver Message-Id: <199812022034.NAA07711@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: FW: Demand dialing for mobile hosts Sender: owner-ietf-ppp@merit.edu > From: "Nelson, David" > >Since the last time we went through this a year or so ago, *DSL has become > >popular in the U.S. The Telcos are putting NAS boxes in their CO's, but > >the resulting IP link is effectively "nailed-up", and does NOT involve > >the telco dialing the end-user. Similar considerations apply to the > >IP-over-cable-TV systems. > > While I don't endorse the SCM draft, I note that the "nailed-up" links > prevalent in > the US are predicated on the notion of "free" local phone calls. In many > other > places in the world all calls are charged by the minute, even local ones. Yes, but I wasn't talking about nailed-up POTS lines. *DSL and cable-TV links are flat-rate, at least as far as the link itself is concerned, if not the "connect-time" while application IP packets are being moved. *DSL and cable-TV links are often "nailed-up" because that's how they are often designed to work. They tend to be just as "nailed-up" as the nearest LAN connector, which is to say that the connection is always there, but you can't get 100% of the bandwidth 100% of the time. Note also that many parts of the U.S. do not have nice flat-rate POTS tariffs. For example, the San Francisco Bay Area has had "LUM" charges for a very long time. In many areas of the U.S., you simply cannot get business POTS with flat-rate charges. > Essentially, > telephone tariffs and billing practices, and not technical issues, drive the > need for > dynamic disconnect and reconnect. While I agree it is important to understand telco tariffs and billing habits, it is a mistake to completely separate them from technical issues. The two motives are fundamentally intertwined. Telco people are not simple idiots intent on gouging stupid ratepayers, no matter how emotionally satisfying that image is to us outsiders. While telephone tariffs and billing have been one of the major motivations for demand dialing, they have not been alone. Demand dialing has been useful and popular in places with flat rate phone service. Demand dialing is simply the natural response when the cost of idle time on the link is non-zero. That cost can include "connect time" at the far end and free modem ports or connect time at the near end. For example, in the ~40x~50 mile Denver-Boulder flat-rate calling area, I use demand dialing on my 2 ISDN B channels because my computers need to connect to more than 2 other computers, and sometimes they want to devote both B channels to a single peer. The reason I don't rent enough BRI's to devote B channels to all of my IP and UUCP links is not only the monthly cost, but difficulites in getting more pairs. It took four (4) years to get the first pair. There are more reasons than only U.S.West incompetence for that decades-old shortage of copper. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 2 17:26:37 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id RAA15520; Wed, 2 Dec 1998 17:25:29 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Dec 1998 17:21:59 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA15376 for ietf-ppp-outgoing; Wed, 2 Dec 1998 17:21:58 -0500 (EST) Received: from elusive.oneworldsystems.com ([198.93.138.250]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA15358 for ; Wed, 2 Dec 1998 17:21:18 -0500 (EST) Received: from IANNT5 ([198.93.136.104]) by elusive.oneworldsystems.com (8.9.0/8.9.0) with SMTP id PAA25747 for ; Wed, 2 Dec 1998 15:30:02 -0800 Message-ID: <037201be1e41$487d20a0$68885dc6@IANNT5> From: "Ian Puleston" To: Subject: Re: FW: Demand dialing for mobile hosts Date: Wed, 2 Dec 1998 14:15:34 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0707.2700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0707.2700 Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Vernon Schryver Date: Wednesday, December 02, 1998 12:51 PM Subject: Re: FW: Demand dialing for mobile hosts >Yes, but I wasn't talking about nailed-up POTS lines. *DSL and cable-TV >links are flat-rate, at least as far as the link itself is concerned, if >not the "connect-time" while application IP packets are being moved. *DSL >and cable-TV links are often "nailed-up" because that's how they are often >designed to work. They tend to be just as "nailed-up" as the nearest LAN >connector, which is to say that the connection is always there, but you >can't get 100% of the bandwidth 100% of the time. True at present, but when I was working on ADSL and involved with the ADSL Forum last year, this was generally seen as an "initial offering" service, with ATM signalling being still in its infancy and pretty complex to implement. The "vision for the future" was that ADSL should eventually become a dial-up medium (e.g. for access to ISP and direct access to work). Whether economic facts will change that at all, I don't know. >The two motives are fundamentally intertwined. Telco people are not simple >idiots True, some are quite complex idiots! Ian. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 08:01:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id IAA27567; Thu, 3 Dec 1998 08:00:51 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 07:53:50 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id HAA27465 for ietf-ppp-outgoing; Thu, 3 Dec 1998 07:53:49 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id HAA27461 for ; Thu, 3 Dec 1998 07:53:42 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id HAA00317 for ietf-ppp@merit.edu; Thu, 3 Dec 1998 07:53:41 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: I-D ACTION:draft-ietf-pppext-scm-01.txt Date: 03 Dec 1998 07:53:40 -0500 Organization: IronBridge Networks Lines: 114 Message-ID: <86soexl73f.fsf@ironbridgenetworks.com> References: <36651C89.FAE59151@ericsson.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu mikael.latvala@ericsson.com (Mikael Latvala) writes: > carlson@ironbridgenetworks.com wrote: > > I think it suffices to arrive at some convential usage for demand dial > > in this situation rather than creating yet another protocol. For > > instance, a reasonable implementation would insist that an activity > > timeout or physical layer drop implies that the peer is still there > > and should be called back on reception of data matching some complex > > filter. On the other hand, explicit LCP Terminate-Request by the peer > > or RNA (ring-no-answer) on attempted dial-back would imply that the > > peer is no longer present. > > Makes sense. Do you know if anybody has implemented such a filter? If > so, > how can the end user configure the filter? Some application level > proprietary protocol? (How did we get onto filters? How did the rules of thumb that completely obviate the need for SCM at all get skipped ... ?) Yes, every vendor (except perhaps MS) that has *any* kind of dial-out implements at least a crude packet filter. The one we implemented on the Annex had a set of rules that were tested sequentially and the action lists of the matching rules were unioned. It then fired the total actions. There were several different actions (such as "drop", "icmp" [to send an administratively prohibited ICMP error], and "syslog"). One action was (ignoring the bizarre negative logic we used -- don't ask) "start" -- matching packets could start a demand dial. Another was "activity" -- matching packets would keep an active link up (they counted as activity) but would not by themselves start a new link. Thus, one could mark web traffic as "start" and email as "activity." Web browsing would start a link going, and email would then be allowed through. But email itself wouldn't bring up the link. The user could not configure the filters; only the system administrator could do that. I don't know why you'd want to permit that since filtering is generally both a security issue and is well beyond the ken of users. > > (Gee, what happens if a bad user out there on the Internet SYN-bombs > > one of these poor, unsuspecting demand-dial users? In the US, the > > flood of calls would be a civil matter. In most European countries, > > though, I believe this would bring criminal charges.) > > > > Good point. This is exactly why the end user would like to have a some > sort > filter. Uh, I think you might have missed the point here. Let's say I'm Joe Sixpack, and I dial in. Since I have a nice, fast dial-up of some sort and my ISP pre-configured it for me, I have SCM enabled. I dial in and start reading some mail downloaded by POP. The link drops. I then get called away and just turn off my computer. Now, what happens? Does the server begin dialing my now-unavailable computer repeatedly? Does it give up at any point? If the answer is yes, then SCM didn't much help, since this is what an ordinary demand- dial system should do. If the answer is no, then SCM just made things worse. In any event, no stateless packet filter that *I* know of would protect the customer against this failure mode. It takes a number of stateful dialing heuristics to do it. > The one specified in SCM is the crudest one. That could be, of > course, improved (e.g. allowing the end user to specify port numbers) > but I guess the > question is on what level this filter configuration should happen. Has > there > been any talk about specifying a new appication level protocol which can > be > used to configure the filter? Beyond the publicly-available bpf? No. > > All of the Unix ones do. As a classic Dilbert cartoon said, "here's a > > nickle, kid; buy yourself a real computer." > > I hope Microsoft folks are following this thread because the company > policy does not allow me to have anything else on my laptop. Heh. Fish and corporate management often do seem to have that common directionality when rotting. In any event, I doubt that pointy-haired diktats are really appropriate for this list. More's the pity and all that. > You're welcome. Just curious, since when have the vendors had demand > dialing > in their access servers? Last time we talked about this, spring 97, > nobody mentioned a word about demand dialing. They've had it for *YEARS*. In general, the marketing navel-gazers forced us all to do it at about the same time we were forced to support other pieces of stupidity like IPX and AppleTalk. (The only one we successfully ducked was CNLP.) ISPs, though, don't give a rats patoot about any dial-out capability (whether demand or not), and, like AppleTalk, leave the feature disabled. As I recall, our first crude versions appeared in about 1992 or 1993. Things were "improved" over the years with scripting, filtering, timers, time-of-day restrictions, and other whatnot, though I'm fairly sure that nobody outside of SQA made much use of it. (Heck, we used our own servers for our own dial-up lines, and *WE* never turned on dial-out!) -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 08:21:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id IAA27970; Thu, 3 Dec 1998 08:20:50 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 08:20:05 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id IAA27911 for ietf-ppp-outgoing; Thu, 3 Dec 1998 08:20:04 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id IAA27904 for ; Thu, 3 Dec 1998 08:19:55 -0500 (EST) Received: (from carlson@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id IAA06406; Thu, 3 Dec 1998 08:19:53 -0500 (EST) Date: Thu, 3 Dec 1998 08:19:53 -0500 (EST) Message-Id: <199812031319.IAA06406@ironbridgenetworks.com> X-Authentication-Warning: helios.helios: carlson set sender to carlson@ironbridgenetworks.com using -f From: James Carlson To: mikael.latvala@ericsson.com CC: ietf-ppp@merit.edu In-reply-to: <36668CD8.9D3D92D7@ericsson.com> (message from Mikael Latvala on Thu, 03 Dec 1998 15:06:33 +0200) Subject: Re: fast reconnect requires careful programming References: <86g1b0kp6w.fsf@ironbridgenetworks.com> <36668CD8.9D3D92D7@ericsson.com> Sender: owner-ietf-ppp@merit.edu > If you follow strictly what RFC1661 says fast reconnect gets your > implementation > in trouble if the implementation cannot for one reason or another accept > the Conf-Req. Reason being that RFC 1661 talks only about the restart > timer for > Conf-Req and Term-Req packets the implementation *sends*. You seemed to imply this before. It's still not true, though. An implementation that attempts to do fast-reconnect simply preloads these messages and blasts them to the peer. It DOES NOT change state. It remains in Establishment Phase with LCP in Req-Sent state. If the peer responds as expected, then there should be a flood of responses to the messages (the peer may also be doing fast-reconnect, or it may be responding normally to the messages as presented). These responses will then trigger it to run LCP to Open state, enter Authentication Phase, run to Open, enter Network-Layer Protocol Phase, and run that to Open as well. If it doesn't respond as expected, then the peer will either accept the LCP Configure-Request and issue only a Configure-Ack and ditch the other messages or will ditch all of the messages. Either way, at least one peer is then stuck with LCP in Req-Sent state, and a TO+ event will then kick it back into gear. It requires a little finesse to do this right, but it's not really *that* big a deal. > Although fast reconnect does not violate RFC1661 it definitely requires > careful programming. What I am trying to say here is that there is > enormous need for a document which describes how fast reconnect/demand > dialing should be implemented, > what options are needed, and where those options can be found, etc.. > Especially when there is going to be more and more mobile devices from > number of different manufactures, most of the devices using PPP to > access the Internet. That does seem like a reasonable idea for an Informational track document. > There has been enough talk about brokem PPP > implementations. I don't think that's true. > I won't let my ego stop people from writing this informational draft. > I'll keep getting paid even if my name does not appear on this doc. All > I ask is that the people who are willing to do this make a public pledge > to this mailing list and commit in finishing the first version of the > draft before the Minneapolis meeting. Hmm. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 10:28:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA00243; Thu, 3 Dec 1998 10:27:09 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 10:25:10 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA00197 for ietf-ppp-outgoing; Thu, 3 Dec 1998 10:25:09 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA00179 for ; Thu, 3 Dec 1998 10:24:58 -0500 (EST) Received: (from carlson@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id KAA09023; Thu, 3 Dec 1998 10:24:56 -0500 (EST) Date: Thu, 3 Dec 1998 10:24:56 -0500 (EST) Message-Id: <199812031524.KAA09023@ironbridgenetworks.com> X-Authentication-Warning: helios.helios: carlson set sender to carlson@ironbridgenetworks.com using -f From: James Carlson To: mikael.latvala@ericsson.com CC: ietf-ppp@merit.edu In-reply-to: <3666A587.16009F4@ericsson.com> (message from Mikael Latvala on Thu, 03 Dec 1998 16:51:51 +0200) Subject: Re: I-D ACTION:draft-ietf-pppext-scm-01.txt References: <86soexl73f.fsf@ironbridgenetworks.com> <3666A587.16009F4@ericsson.com> Sender: owner-ietf-ppp@merit.edu > Did I miss the point? Didn't notice you talking about any such failure > in your original comment, just about bad users sending SYN-bombs. The response to SYN-bombing *is* the failure mode. I think we're violently agreeing here. > At any rate, SYN-bombs, etc. are going to be a problem the informational > draft has to issue. The end user wants to definately be sure that > malicious users cannot > cause the access server to re-establish the link thus placing additional > charges > on the end user's account for each such re-established connection. This > relates > to the filter discussion in the earlier messages. Whether the end user > should > be allowed to configure the filter dynamically is another story. There > are cases which would justify that, not sure though if the number of > such cases is big enough to warrant dynamic configuration. I have to disagree with that. Dealing with SYN-bombs and other attacks is a proper subject for an I-D that deals with the topic of dialing on demand. Fast-reconnect may be useful when doing dial-on-demand, but there's no particular reason why this use must be assumed. If an I-D for fast reconnect is written, then I'd leave out the filtering and such, since it is out-of-scope material. > I'll try this once more. For the sake of argument only the > implementation does fast reconnect, not the peer. I also assume that the > peer accepts all the Conf-Reqs/Acks and the CHAP response. For that > matter, all we need to know about the peer is that it sends LCP and NCP > Conf-Reqs and Conf-Acks, CHAP Challenge and Success, and ends up happily > in the Network-Layer Protocol phase. > > So, the implementation sends LCP Conf-Req, Conf-Ack, CHAP response, NCP > Conf-Req > and NCP Conf-Ack. LCP TRANSITION: Starting --> Req-Sent. > > The implementation receives Conf-Req from the peer, does not like it and > sends LCP Conf-Nak. LCP TRANSITION: Stays in Req-Sent. Bang. You're no longer doing fast-reconnect. You either have a perfect guess of all of the options intended -- which can happen either by preconfiguration or by caching of last-known requests -- or you have nothing. If you have the perfect information, then all you ever get is Configure-Request (RCR+) and Configure-Ack from the peer. You never get anything else. If the peer isn't buying your story for whatever reason (bad LCP option or any other flaw), then you're back at square 1. > The implementation receives Conf-Ack from the peer. > LCP TRANSITION: Req-Sent --> Ack-Rcvd. Exactly. The peer, though, should still be in Req-Sent state because the Configure-Ack it received in the pre-loaded message *must not* have matched the Configure-Request it sent. (Otherwise, we wouldn't be sending Configure-Nak!) RFC 1661 page 29 says: On reception of a Configure-Ack, the Identifier field MUST match that of the last transmitted Configure-Request. Additionally, the Configuration Options in a Configure-Ack MUST exactly match those of the last transmitted Configure-Request. Invalid packets are silently discarded. I'd certainly be willing to believe that there are bogus PPP implementations out there that don't do this check, even though it is required in the RFC. Even if this is true, the local side of this conversation never leaves Ack-Rcvd state, and it's retransmit timer is still running. > CLAIM: the implementation will stay in the Ack-Rcvd state indefinately. Wrong on multiple counts. Local implementation is in Ack-Rcvd state, and peer is still in Req-Sent state. TO+ will occur on BOTH sides, and both may resend LCP Configure-Request. See RFC 1661 page 13. Additionally, the reception of Configure-Nak in the peer (RCN) should cause a properly implemented peer to send a new Configure-Request. (Oddly, the RFC 1661 state machine and the verbiage following conflict with each other on this point, so I wouldn't be surprised to find that common implementations don't actually go back to state 6 as the table says they should.) > Why? > Because TO+ event does not get it out of it and LCP Conf-Nak does not > help because by the time the peer receives it it is already in the > Network-Layer Protocol phase. You keep saying that, but it's still not true. Even if the peer is a bogus implementation that improperly accepted a bad LCP Configure-Ack, and thus ended up going all the way into opening the NCPs, the local implementation is STILL in Ack-Rcvd state. TO+ causes LCP Configure-Request to be sent. The peer responds to the unexpected LCP Configure-Request by removing all of the NCPs and authentication data, and returning either to Req-Sent (on RCR-) or to Ack-Sent (RCR+) state. In any of these cases, negotiation then proceeds in the traditional way. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 11:24:59 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA01640; Thu, 3 Dec 1998 11:24:26 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 11:22:39 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA01585 for ietf-ppp-outgoing; Thu, 3 Dec 1998 11:22:38 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA01579 for ; Thu, 3 Dec 1998 11:22:34 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id LAA27413 for ietf-ppp@merit.edu; Thu, 3 Dec 1998 11:22:33 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by merit.edu (8.9.1a/8.9.1) with ESMTP id IAA27685 for ; Thu, 3 Dec 1998 08:06:54 -0500 (EST) Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id OAA12789; Thu, 3 Dec 1998 14:06:52 +0100 (MET) Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA19211; Thu, 3 Dec 1998 15:06:49 +0200 (EET) Message-ID: <36668CD8.9D3D92D7@ericsson.com> Date: Thu, 03 Dec 1998 15:06:33 +0200 From: Mikael Latvala Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: carlson@ironbridgenetworks.com CC: ietf-ppp@merit.edu Subject: fast reconnect requires careful programming References: <86g1b0kp6w.fsf@ironbridgenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu If you follow strictly what RFC1661 says fast reconnect gets your implementation in trouble if the implementation cannot for one reason or another accept the Conf-Req. Reason being that RFC 1661 talks only about the restart timer for Conf-Req and Term-Req packets the implementation *sends*. For fast reconnect the implementation needs a timer also for Conf-Req packets it *receives*. Why? When the peer finally reads LCP Conf-Nak/Reject it is already in Network-Layer Protocol phase and thus discards Conf-Nak/Reject packet (at least it should do that because only "The receipt of the LCP Configure-Request causes a return to the Link Establishment phase from the Network-Layer Protocol phase or Authentication phase"). The only way to ask the peer to send a new LCP Conf-Req is to go back to the Link Establishment phase. Although fast reconnect does not violate RFC1661 it definitely requires careful programming. What I am trying to say here is that there is enormous need for a document which describes how fast reconnect/demand dialing should be implemented, what options are needed, and where those options can be found, etc.. Especially when there is going to be more and more mobile devices from number of different manufactures, most of the devices using PPP to access the Internet. There has been enough talk about brokem PPP implementations. I won't let my ego stop people from writing this informational draft. I'll keep getting paid even if my name does not appear on this doc. All I ask is that the people who are willing to do this make a public pledge to this mailing list and commit in finishing the first version of the draft before the Minneapolis meeting. It would not hurt if the chair of this WG would also try to solicit this idea. /Mikael carlson@ironbridgenetworks.com wrote: > > mikael.latvala@ericsson.com ("Mikael Latvala") writes: > > > vjs@calcite.rhyolite.com wrote: > > >When you are re-establishing a > > >connection, you know everything the peer will say except the authentication > > >random strings and ID fields, and so can predict every other bit of the > > >Configure- Requests and -Acks. However, those can be securely predicted > > >given a slight change. Have both peers compute the ID fields and their > > >CHAP challenge strings using MD5 hashes of their shared CHAP secret > > >concatenated with the last CHAP response of the previous connection. > > >Use the first 3 bytes of the 16-byte hash for the ID fields of the LCP > > >CR, CHAP challenge, and IPCP CR. Use the entire 16-bytes for the CHAP > > >challenge. Then let the peer re-establishing the link by send the LCP > > >CR, CHAP challenge, and IPCP Configure-Requests and predicted > > >Configure-Acks in a single burst. > > > > > > Hmmm ... isn't this against what RFC1661 says. Quote: > > > > "3.4. Link Establishment Phase > > > > [...] > > > > Any non-LCP packets received during this phase MUST be silently > > discarded." > > Nope. Doesn't violate that clause at all. > > What happens is that the peer goes through all the normal state > transitions and transmits all the normal replies, but when it goes to > read the next message, the message just happens to be already > available in the input queue. > > It is true that there are some remarkably poorly designed > implementations of PPP out there that have timing flaws that are > exposed by this trick. In particular, if state changing is not > synchronous with message reading (if message reading is, say, done > within a receive interrupt), then this won't work. > > But so what? The "early" messages from the peer are then just > silently discarded (per RFC 1661), and the poor implementation > eventually times out, resends LCP Configure-Request, and starts over. > An implementation using the fast-reconnect trick would detect this as > a peer restart and would switch back to "normal" multiple-RTT > negotiation. > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 11:34:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA01934; Thu, 3 Dec 1998 11:33:54 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 11:32:12 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA01859 for ietf-ppp-outgoing; Thu, 3 Dec 1998 11:32:11 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA01855 for ; Thu, 3 Dec 1998 11:32:07 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id LAA27987 for ietf-ppp@merit.edu; Thu, 3 Dec 1998 11:32:06 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA29529 for ; Thu, 3 Dec 1998 09:52:17 -0500 (EST) Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id PAA07058; Thu, 3 Dec 1998 15:52:12 +0100 (MET) Received: from ericsson.com by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA24462; Thu, 3 Dec 1998 16:52:08 +0200 (EET) Message-ID: <3666A587.16009F4@ericsson.com> Date: Thu, 03 Dec 1998 16:51:51 +0200 From: Mikael Latvala Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: carlson@ironbridgenetworks.com CC: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-scm-01.txt References: <86soexl73f.fsf@ironbridgenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu carlson@ironbridgenetworks.com wrote: > > mikael.latvala@ericsson.com (Mikael Latvala) writes: > > carlson@ironbridgenetworks.com wrote: > > > (Gee, what happens if a bad user out there on the Internet SYN-bombs > > > one of these poor, unsuspecting demand-dial users? In the US, the > > > flood of calls would be a civil matter. In most European countries, > > > though, I believe this would bring criminal charges.) > > > > > > > Good point. This is exactly why the end user would like to have a some > > sort > > filter. > > Uh, I think you might have missed the point here. Let's say I'm Joe > Sixpack, and I dial in. Since I have a nice, fast dial-up of some > sort and my ISP pre-configured it for me, I have SCM enabled. I dial > in and start reading some mail downloaded by POP. The link drops. I > then get called away and just turn off my computer. > > Now, what happens? Does the server begin dialing my now-unavailable > computer repeatedly? Does it give up at any point? If the answer is > yes, then SCM didn't much help, since this is what an ordinary demand- > dial system should do. If the answer is no, then SCM just made things > worse. > > In any event, no stateless packet filter that *I* know of would > protect the customer against this failure mode. It takes a number of > stateful dialing heuristics to do it. > Did I miss the point? Didn't notice you talking about any such failure in your original comment, just about bad users sending SYN-bombs. Besides, SCM draft says that the peer (i.e. server) should try to re-establish the link "few times", not indefinately (page 8 and 12). Yes, I agree, it's written too vaguely but who cares, it has been shown to me that SCM is not needed. End of that chapter. Like your president keeps saying, let's move on. At any rate, SYN-bombs, etc. are going to be a problem the informational draft has to issue. The end user wants to definately be sure that malicious users cannot cause the access server to re-establish the link thus placing additional charges on the end user's account for each such re-established connection. This relates to the filter discussion in the earlier messages. Whether the end user should be allowed to configure the filter dynamically is another story. There are cases which would justify that, not sure though if the number of such cases is big enough to warrant dynamic configuration. > > If you follow strictly what RFC1661 says fast reconnect gets your > > implementation > > in trouble if the implementation cannot for one reason or another accept > > the Conf-Req. Reason being that RFC 1661 talks only about the restart > > timer for > > Conf-Req and Term-Req packets the implementation *sends*. > > You seemed to imply this before. It's still not true, though. > I'll try this once more. For the sake of argument only the implementation does fast reconnect, not the peer. I also assume that the peer accepts all the Conf-Reqs/Acks and the CHAP response. For that matter, all we need to know about the peer is that it sends LCP and NCP Conf-Reqs and Conf-Acks, CHAP Challenge and Success, and ends up happily in the Network-Layer Protocol phase. So, the implementation sends LCP Conf-Req, Conf-Ack, CHAP response, NCP Conf-Req and NCP Conf-Ack. LCP TRANSITION: Starting --> Req-Sent. The implementation receives Conf-Req from the peer, does not like it and sends LCP Conf-Nak. LCP TRANSITION: Stays in Req-Sent. The implementation receives Conf-Ack from the peer. LCP TRANSITION: Req-Sent --> Ack-Rcvd. CLAIM: the implementation will stay in the Ack-Rcvd state indefinately. Why? Because TO+ event does not get it out of it and LCP Conf-Nak does not help because by the time the peer receives it it is already in the Network-Layer Protocol phase. TO+ event is for the lack of response to Conf-Req the implementation sent to the peer, NOT for the lack of Conf-Req it expects to receive from the peer. That's why there must be an additional timer which RFC1661 does not talk about. Quote: "Timeout (TO+,TO-) This event indicates the expiration of the Restart timer. The Restart timer is used to time responses to Configure-Request and Terminate-Request packets." /Mikael - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 12:12:56 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA02910; Thu, 3 Dec 1998 12:12:05 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 12:10:32 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA02868 for ietf-ppp-outgoing; Thu, 3 Dec 1998 12:10:31 -0500 (EST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA02863 for ; Thu, 3 Dec 1998 12:10:25 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA31192; Thu, 3 Dec 1998 12:10:16 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA29084; Thu, 3 Dec 1998 12:10:18 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id MAA17844; Thu, 3 Dec 1998 12:10:16 -0500 (EST) Message-Id: <199812031710.MAA17844@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Vernon Schryver cc: ietf-ppp@merit.edu Subject: Re: PPP compression In-reply-to: Your message of "Fri, 20 Nov 1998 11:17:01 MST." <199811201817.LAA13805@calcite.rhyolite.com> Date: Thu, 03 Dec 1998 12:10:15 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu > At least some of the CCP RFC's are de facto products of the PPP > working group, and so ought to be in a different catagory than RFC's > documenting prorprietary and probably even obsolete protocols such > as RFC 1934 (MP+), not to mention such very different documents as > RFC 1935 ("What is the Internet") and RFC 1936 (TCP checksum > hardware). My understanding is that all of the PPP compression RFCs are informational because at the time, the process for dealing with Standards Track documents containing patents made made it impossible to put those document on Standards Track. RFC 2026 changed the way IPR issues are handled. Specifically, One can have patented technology in Standards Track documents. For Proposed Standards, IPR issues don't get in the way (assuming the WG decides it wants to standardize on the patented technology). When going to Draft Standard, however, there have to be multiple implementations, and those implementation need to have exercised the legalities of obtaining necessary licences. The idea is to have "running code" showing what the actual cost of obtaining the licenses is, and that the cost is "reasonable", as defined by consensus. If consensus is that the bar for obtaining proper licences is acceptably low, the document can be advanced. That is, the WG decides whether the terms of any necessary licenses are reasonable by excercising them. Is there any desire to identify the key compression protocols that everyone should be implementing and put them onto standards track? This might help folks identify which ones to implement. Then again, is this an issue worth investing cycles on? Thomas - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 13:06:07 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA04224; Thu, 3 Dec 1998 13:05:14 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 13:02:25 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA04141 for ietf-ppp-outgoing; Thu, 3 Dec 1998 13:02:25 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA04133 for ; Thu, 3 Dec 1998 13:02:18 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id LAA12101 env-from ; Thu, 3 Dec 1998 11:02:11 -0700 (MST) Date: Thu, 3 Dec 1998 11:02:11 -0700 (MST) From: Vernon Schryver Message-Id: <199812031802.LAA12101@calcite.rhyolite.com> To: narten@raleigh.ibm.com Subject: Re: PPP compression Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu > From: Thomas Narten > ... > Is there any desire to identify the key compression protocols that > everyone should be implementing and put them onto standards track? I think the only designation that should count is "de facto standard," and that official IETF blessing of an RFC as "Standards Track" is just as important as what the ITU says about the OSI network standards. > This might help folks identify which ones to implement. That is good thought. However, no one competent needs a standards body to say what the market wants. > Then again, is > this an issue worth investing cycles on? I don't know. What effort would be required of anyone outside the IAB and IESG? The most commonly implemented and used compression scheme is easily STAC, but I'm not sure which of its RFC's carry its torch. BSD Compress (RFC 1977) is a distant second, with Predictor Type 1 (RFC 1978) and FZA (RFC 1993) at either third or fourth depending on how you count Gandalf's lone and fading implementation of FZA. (Gandalf now also supports STAC.) Deflate (RFC 1979) is the only other IETF PPP compression scheme that I've heard of being implemented. All five of those schemes might in some sense have trouble qualifying under the multiple independent implementation rule. Doesn't everyone base their STAC implementation on code from STAC Electronics? BSD Compress and Predictor contain enough code that all of those implementations are likely to be quite similar. FZA is proprietary. I think Deflate is only in Paul Mackerras's `pppd` and is effectively defined by the freely-redistributable Deflate compression source. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 15:25:43 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA07655; Thu, 3 Dec 1998 15:24:59 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 15:22:28 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA07595 for ietf-ppp-outgoing; Thu, 3 Dec 1998 15:22:27 -0500 (EST) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA07591 for ; Thu, 3 Dec 1998 15:22:19 -0500 (EST) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id PAA29375; Thu, 3 Dec 1998 15:22:17 -0500 (EST) Received: by carp.morningstar.com (8.8.8/95031605) id PAA29743; Thu, 3 Dec 1998 15:22:17 -0500 (EST) From: Karl Fox Reply-To: Karl Fox To: Mikael Latvala Cc: ietf-ppp@merit.edu Subject: Re: Demand dialing for mobile hosts References: <199811302136.OAA28211@calcite.rhyolite.com> <3663E641.61648AF7@ericsson.com> Date: 03 Dec 1998 15:22:16 -0500 In-Reply-To: Mikael Latvala's message of Tue, 01 Dec 1998 14:51:13 +0200 Message-ID: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu Mikael Latvala writes: > vjs@calcite.rhyolite.com wrote: > > I think that instructions on how to implement demand dialing > > really should be written by people who have implemented it, or at > > least used it extensively, but maybe I'm too picky. > > Well, that's what the chair of this WG said in Memphis 1997. Over year > and a half later nothing has happened. I think that we have waited for > this miracle to become true long enough, volunteers to co-author this > draft are warmly welcomed. As they have been for the entire year and a half. Perhaps nobody has the time to write the document. Or perhaps the issues are obvious enough that nobody with the requisite experience sees the need. As to whether SCM is needed, I believe all your engineering points have been adequately answered; the existing protocols can be implemented in such a way as to allow very quick reconnect times. The only issue that perhaps ought to be documented is Vernon's idea of predicting the CHAP challenge on reconnect. Anyone who's willing to use PAP could write a client implementation today using Vernon's back-to-back packet trick and eliminate all round trips at reconnect time. And any NAS vendor could cache RADIUS information to speed up reconnect authentication times. Please restrict future messages on SCM to issues that haven't been so thoroughly discussed. Please also be careful to limit your criticisms to valid technical points. Thanks, Karl -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 16:32:07 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA09267; Thu, 3 Dec 1998 16:30:57 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 16:28:29 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA09188 for ietf-ppp-outgoing; Thu, 3 Dec 1998 16:28:28 -0500 (EST) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA09177 for ; Thu, 3 Dec 1998 16:28:15 -0500 (EST) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id QAA00433; Thu, 3 Dec 1998 16:28:13 -0500 (EST) Received: by carp.morningstar.com (8.8.8/95031605) id QAA02938; Thu, 3 Dec 1998 16:28:13 -0500 (EST) From: Karl Fox Reply-To: Karl Fox To: Mikael Latvala Cc: ietf-ppp@merit.edu Subject: Re: Demand dialing for mobile hosts References: <199811302136.OAA28211@calcite.rhyolite.com> <3663E641.61648AF7@ericsson.com> Date: 03 Dec 1998 16:28:13 -0500 In-Reply-To: Karl Fox's message of 03 Dec 1998 15:22:16 -0500 Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu Karl Fox writes: > Please restrict future messages on SCM to issues that haven't been so > thoroughly discussed. Please also be careful to limit your criticisms > to valid technical points. After re-reading my own post, it belatedly occurred to me that it looked like I was accusing Mr. Latvala of improper conduct. That was not my intent; I was trying to encourage the entire group to remain on a polite and even keel. My apologies, Mikael, if you were offended. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 3 22:09:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id WAA15639; Thu, 3 Dec 1998 22:08:14 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Dec 1998 22:05:13 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id WAA15551 for ietf-ppp-outgoing; Thu, 3 Dec 1998 22:05:12 -0500 (EST) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.9.1a/8.9.1) with ESMTP id WAA15541 for ; Thu, 3 Dec 1998 22:04:56 -0500 (EST) Received: from brill.shiva.com (brill.shiva.com [140.248.193.94]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id WAA17132; Thu, 3 Dec 1998 22:00:51 -0500 (EST) Received: by brill.shiva.com (SMI-8.6/SMI-SVR4) id WAA11439; Thu, 3 Dec 1998 22:03:50 -0500 Date: Thu, 3 Dec 1998 22:03:50 -0500 Message-Id: <199812040303.WAA11439@brill.shiva.com> From: John Shriver To: vjs@calcite.rhyolite.com CC: narten@raleigh.ibm.com, ietf-ppp@merit.edu In-reply-to: <199812031802.LAA12101@calcite.rhyolite.com> (message from Vernon Schryver on Thu, 3 Dec 1998 11:02:11 -0700 (MST)) Subject: Re: PPP compression Sender: owner-ietf-ppp@merit.edu Um, the second most commonly implemented compression (in terms of nodes deployed, not necessarily implementations) would be MPPC (Microsoft, marketed through Stac). That's the second one that we added (after Stac). Mostly because Windows NT 4.0 RAS only supports MPPC, not Stac (HiFn) LZS. No idea if Windows NT 5.0 will support LZS. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 4 01:23:37 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id BAA18355; Fri, 4 Dec 1998 01:22:08 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Dec 1998 01:18:30 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA18268 for ietf-ppp-outgoing; Fri, 4 Dec 1998 01:18:29 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA18260 for ; Fri, 4 Dec 1998 01:18:13 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id WAA09769 for ; Thu, 3 Dec 1998 22:17:48 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 4 Dec 1998 06:17:48 UT Received: from ascend.com by ascend.com (SMI-8.6/SMI-SVR4) id WAA27439; Thu, 3 Dec 1998 22:18:28 -0800 Received: from ascend.com by ascend.com Message-Id: <3.0.5.32.19981203221652.00b384b0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 22:16:52 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: L2TP discussion added to Orlando agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu I've been requested to add a 10 minute slot to the beginning of the PPPEXT agenda for Orlando. This is to discuss the IESG response to the latest L2TP base draft All those concerned with this will hopefully attend. For those who can't make it, we'll make an extra effort to get the minutes emailed out ASAP. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 4 05:34:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id FAA20786; Fri, 4 Dec 1998 05:32:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Dec 1998 05:26:04 -0500 Received: by merit.edu (8.9.1a/8.9.1) id FAA20691 for ietf-ppp-outgoing; Fri, 4 Dec 1998 05:26:03 -0500 (EST) Received: from sand.global.net.uk (sand.global.net.uk [194.126.82.9]) by merit.edu (8.9.1a/8.9.1) with ESMTP id FAA20686 for ; Fri, 4 Dec 1998 05:25:56 -0500 (EST) Received: from p41s11a01.client.global.net.uk ([195.147.139.66] helo=hardy.farsite.co.uk) by sand.global.net.uk with esmtp (Exim 2.05 #1) id 0zlsQq-0005WD-00 for ietf-ppp@merit.edu; Fri, 4 Dec 1998 10:25:53 +0000 Received: by HARDY with Internet Mail Service (5.0.1457.3) id ; Fri, 4 Dec 1998 10:26:58 -0000 Message-ID: From: Jonathan Goodchild To: ietf-ppp@merit.edu Subject: Re: PPP compression Date: Fri, 4 Dec 1998 10:26:56 -0000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu > All five of those schemes might in some sense have trouble qualifying > under the multiple independent implementation rule. Doesn't everyone base > their STAC implementation on code from STAC Electronics? Umm... I thought the RFCs just decribed the protocol and encapsulation, not the actual compression/decompression algorithms. Does it matter if everyone uses the same LZS code? They've still got their own implementations of the protocol. Jonathan Goodchild FarSite Communications Ltd. Email: jon.goodchild@farsite.co.uk Web: http://www.farsite.co.uk/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 4 10:09:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA24169; Fri, 4 Dec 1998 10:08:59 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Dec 1998 10:06:59 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA24082 for ietf-ppp-outgoing; Fri, 4 Dec 1998 10:06:58 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA24075 for ; Fri, 4 Dec 1998 10:06:52 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id IAA16108 for ietf-ppp@merit.edu env-from ; Fri, 4 Dec 1998 08:06:50 -0700 (MST) Date: Fri, 4 Dec 1998 08:06:50 -0700 (MST) From: Vernon Schryver Message-Id: <199812041506.IAA16108@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPP compression Sender: owner-ietf-ppp@merit.edu > From: Jonathan Goodchild > > All five of those schemes might in some sense have trouble qualifying > > under the multiple independent implementation rule. Doesn't everyone > base > > their STAC implementation on code from STAC Electronics? > > Umm... I thought the RFCs just decribed the protocol and encapsulation, > not the actual compression/decompression algorithms. Does it matter if > everyone uses the same LZS code? They've still got their own > implementations of the protocol. Of course, I agree with you. However, there were apparently serious complaints or claims in this mailinglist that RFC 1977 could never qualify under the two-implementations rule because of the source because it contains. If RFC 1977 can't meet the rule with source available to everyone who reads the RFC, then how could other compression schemes such as LZS and Deflate qualify when their defining source is elsewhere, and in the case of LZS, not even freely available for inspection? (Yes, STAC can be convinced to give you LZS source for no money, but then you must get your corporate lawyers or managers to sign the STAC license. I spent about 3 years working on that hassle, and completely failing, at my previous employer.) Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 4 10:49:55 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA25178; Fri, 4 Dec 1998 10:48:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Dec 1998 10:46:57 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA25128 for ietf-ppp-outgoing; Fri, 4 Dec 1998 10:46:57 -0500 (EST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA25121 for ; Fri, 4 Dec 1998 10:46:51 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA21382; Fri, 4 Dec 1998 10:46:42 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA31096; Fri, 4 Dec 1998 10:46:47 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA22554; Fri, 4 Dec 1998 10:46:44 -0500 (EST) Message-Id: <199812041546.KAA22554@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Matt Holdrege cc: ietf-ppp@merit.edu Subject: Re: L2TP discussion added to Orlando agenda In-reply-to: Your message of "Thu, 03 Dec 1998 22:16:52 PST." <3.0.5.32.19981203221652.00b384b0@porky> Date: Fri, 04 Dec 1998 10:46:44 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu > I've been requested to add a 10 minute slot to the beginning of the PPPEXT > agenda for Orlando. This is to discuss the IESG response to the latest L2TP > base draft Here's the context: During the last telechat, the IESG did not approve the l2tp document as a PS. The overall concern was that the document was poorly written and that it was difficult to follow. This goes against the IETF's prime directive, which is producing good quality specs. Note that the issue has to do with the clarity of the document itself, not the protocol per se. One of the contributors to the decision was a sense that the authors have not been responsive to specific suggestions from the IESG that would improve the clarity of the document. There is a feeling that the changes that have been made are mostly restricted to those that "had to be done" to clear the IESG, and even then not without some grumbling. Some comments were not incorporated at all. I could also point to specific issues that were discussed during the telechat that pushed folks over the edge (the description of Karn's algorithm is incorrect --- l2tp has modified it, the use of the term "slow start" is incorrect where it is used, etc.), but that misses the meta issue. The same can be said about the security-related comments that were pointed out (it turns out that the "hidden stuff" text has a couple of typos). It might appear that a couple of nits tripped up the document, but a more honest observation is that they were the proverbial "last straw". The real issue is a concern over the clarity of the document and a feeling that the WG is not making a good faith effort to produce a quality spec. Thomas - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 01:02:06 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id BAA23415; Tue, 8 Dec 1998 01:00:54 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 00:53:31 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id AAA23293 for ietf-ppp-outgoing; Tue, 8 Dec 1998 00:53:31 -0500 (EST) Received: from mail.shinsegi.com ([203.226.207.231]) by merit.edu (8.9.1a/8.9.1) with ESMTP id AAA23289 for ; Tue, 8 Dec 1998 00:53:23 -0500 (EST) Received: from mail ([203.226.196.75]) by mail.shinsegi.com (Netscape Messaging Server 3.5) with SMTP id AAA317B for ; Tue, 8 Dec 1998 14:51:37 +0900 Date: Tue, 08 Dec 1998 14:48:34 +0900 From: "ji choel park" Reply-To: parkjc@shinsegi.com Organization: Shinsegi Telecomm, Inc. To: "PPP" Subject: (ppp) PPP link re-establishment MIME-Version: 1.0 X-Mailer: HMail 1.0 Video Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <7718E7651411.AAA317B@mail.shinsegi.com> Sender: owner-ietf-ppp@merit.edu Is there anyone who knows the message flows of PPP when occurring PPP link re-establishment during opened state? Assume that a mobile host has a PPP link established with a FA in Mobile IP network. After handoff, the mobile host should establish a new PPP connection with new FA. My knowlege is that the PPP LCP operation starts by PPP client, i.e. the mobile host. Then, the PPP LCP in mobile host should know the event of the handoff. it can be performed by sending the notification of handoff of from mobile station's physical layer to PPP layer to re-establish PPP connection. But, I'm not sure that these procedures are correct and general. Would anyone help me? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 01:13:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id BAA23645; Tue, 8 Dec 1998 01:13:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 01:09:24 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA23588 for ietf-ppp-outgoing; Tue, 8 Dec 1998 01:09:24 -0500 (EST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA23581 for ; Tue, 8 Dec 1998 01:09:18 -0500 (EST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id WAA05958; Mon, 7 Dec 1998 22:07:56 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma005956; Mon, 7 Dec 98 22:07:38 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id WAA02129; Mon, 7 Dec 1998 22:07:38 -0800 (PST) From: Archie Cobbs Message-Id: <199812080607.WAA02129@bubba.whistle.com> Subject: Re: (ppp) PPP link re-establishment In-Reply-To: <7718E7651411.AAA317B@mail.shinsegi.com> from ji choel park at "Dec 8, 98 02:48:34 pm" To: parkjc@shinsegi.com Date: Mon, 7 Dec 1998 22:07:38 -0800 (PST) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu ji choel park writes: > Assume that a mobile host has a PPP link established with a FA in Mobile IP network. After handoff, the mobile host should establish a new PPP connection with new FA. My knowlege is that the PPP LCP operation starts by PPP client, i.e. the mobile host. Then, the PPP LCP in mobile host should know the event of the handoff. it can be performed by sending the notification of handoff of from mobile station's physical layer to PPP layer to re-establish PPP connection. But, I'm not sure that these procedures are correct and general. If I understand the question correctly, the answer is yes. A PPP client must be prepared to receive an LCP Config-Request at any time and fully renegotiate the link. It should work but some broken implementations have had trouble in the past. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 10:28:34 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA29207; Tue, 8 Dec 1998 10:26:24 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 10:13:13 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA28851 for ietf-ppp-outgoing; Tue, 8 Dec 1998 10:13:12 -0500 (EST) Received: from adtrn-srv1.adtran.com (mailin.adtran.com [206.166.249.110]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA28846 for ; Tue, 8 Dec 1998 10:13:01 -0500 (EST) Received: from shannon.adtran.com (shannon.adtran.com [172.22.16.9]) by adtrn-srv1.adtran.com (8.8.8/8.8.8) with SMTP id JAA28892; Tue, 8 Dec 1998 09:12:13 -0600 (CST) Received: by shannon.adtran.com (SMI-8.6/SMI-SVR4) id JAA02307; Tue, 8 Dec 1998 09:16:13 -0600 From: sventers@adtran.com (Stuart Venters) Message-Id: <199812081516.JAA02307@shannon.adtran.com> Subject: PPP at STS-192c draft To: smerchant@cimaron.com Date: Tue, 8 Dec 1998 09:16:13 -0600 (CST) Cc: ietf-ppp@merit.edu, stuart.venters@adtran.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu shahrukh, i have some thoughts concerning your format for PPP at OC-192 speeds. (in decreasing order of importance) First, it appears that the length of the pad field and hence the length of the packet is not protected by the FCS field. How would a bit error in the lsb's of a FLAG immediately following the FCS field be handled at the receiver? The plan contains three nested scramblers, these are an outer 7bit, a middle 48bit, and an inner 29bit one. (That inner one is neat!) I am curious as to why you feel that the middle scrambler is required. Perhaps eliminating it and making the inner one longer would provide the same protection with less parts? It would seem that at these speeds, simplicity is a good idea. In the explanation for the choice of flag and escape byte values, you state that they are sufficiently random, have no repeated bytes, and have 50% ones density. Given the inner and outer scramblers, why would not any 5 values work equally as well? (For Example 00 00 00 0x?) At OC-192, my calculator says to expect an Esc32 every 370 seconds. Eventually when this is scaled to Esc64, this time would turn out to be so long that it is impossible to test that the escape hardware is working. (It's too bad we can't just count and drop any packets requiring an escape.) cheers, Stuart Venters sventers@adtran.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 11:56:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA01569; Tue, 8 Dec 1998 11:55:44 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 11:52:12 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA01523 for ietf-ppp-outgoing; Tue, 8 Dec 1998 11:52:11 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA01517 for ; Tue, 8 Dec 1998 11:51:59 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA19239 for ; Tue, 8 Dec 1998 10:53:48 -0600 (CST) Comments: ( Received on motgate2.mot.com from client mothost.mot.com, sender ramanna@cig.mot.com ) Received: from po_box.cig.mot.com (po_box.cig.mot.com [136.182.15.5]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with SMTP id KAA23292 for ; Tue, 8 Dec 1998 10:51:50 -0600 (CST) Message-Id: <199812081718.MAA22700@po_box.cig.mot.com> Received: (ramanna@localhost) by allegreto.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) id KAA21582 for ietf-ppp@merit.edu; Tue, 8 Dec 1998 10:50:59 -0600 (CST) Date: Tue, 8 Dec 1998 10:50:59 -0600 (CST) From: Shreesha Ramanna In-Reply-To: Archie Cobbs "Re: (ppp) PPP link re-establishment" (Dec 7, 10:07pm) References: <199812080624.AAA23007@allegreto.cig.mot.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: ietf-ppp@merit.edu Subject: Re: fast reconnect Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu I had few questions related fast reconnect. Would highly appreciate if anyone could can give me a answer (atleast some pointers where to look for!). 1. If a PPP client receives a Terminate Req followed immediately by a Config Req a. Can the PPP client renegotiate. b. Can the LCP parameters be different c. Can the IPCP negotiate different IP addresses d. Can the TCP SYN, SYNACKs restarted after c. Thank you, Shreesha Ramanna. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 13:09:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA02858; Tue, 8 Dec 1998 13:08:21 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 13:05:16 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA02752 for ietf-ppp-outgoing; Tue, 8 Dec 1998 13:05:15 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA02747 for ; Tue, 8 Dec 1998 13:05:09 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id LAA11628 env-from ; Tue, 8 Dec 1998 11:05:07 -0700 (MST) Date: Tue, 8 Dec 1998 11:05:07 -0700 (MST) From: Vernon Schryver Message-Id: <199812081805.LAA11628@calcite.rhyolite.com> To: ietf-ppp@merit.edu, ramanna@cig.mot.com Subject: Re: fast reconnect Sender: owner-ietf-ppp@merit.edu > From: Shreesha Ramanna > I had few questions related fast reconnect. Would highly appreciate > if anyone could can give me a answer (atleast some pointers where to > look for!). > 1. If a PPP client receives a Terminate Req followed immediately > by a Config Req Section 3.7 on page 9 of RFC 1661 says in part: ] LCP is used to close the link through an exchange of Terminate ] packets. When the link is closing, PPP informs the network-layer ] protocols so that they may take appropriate action. ] ] After the exchange of Terminate packets, the implementation SHOULD ] signal the physical-layer to disconnect in order to enforce the ] termination of the link, That is consistent with the common practice that the next, non-trivial event after either peer sends an LCP Terminate-Request is that the phone line is disconnected. At most, a Terminate-Ack will been seen on the wire before the link is disconnected. > a. Can the PPP client renegotiate. > b. Can the LCP parameters be different Configure-Requests for any PPP protocol can be sent at any time, and either peer can ask for different values of any parameters. However, it is prudent to assume that the peer will reject any different values. > c. Can the IPCP negotiate different IP addresses As with any PPP protocol, you can always send a Configure-Request. However, if you think about entire systems a little, you'll see that reasonable PPP implementations are not enthusiastic about changing their IP addresses. > d. Can the TCP SYN, SYNACKs restarted after c. A TCP connection is defined by the 4-tuple of IP addresses and port numbers. If you change IP addresses, you're talking about a different connection. Also, SYN's and SYN-ACK's happen only at the start of TCP connection. I cannot see how the word "restarted" can associated with bites that are exchanged only at the start of connection. I think all of those questions, as stated, are answered in RFC 1661 and RFC 1332. A better reference for those who find the RFC's hard to read is Jim Carlson's book, "PPP Design and Debugging", published by Addison-Wesley, ISBN 0-201-18539-3. I do not understand how any of the questions are related to the Fast Reconnect hack. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 13:23:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA03203; Tue, 8 Dec 1998 13:23:01 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 13:18:32 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA03109 for ietf-ppp-outgoing; Tue, 8 Dec 1998 13:18:31 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA03104 for ; Tue, 8 Dec 1998 13:18:13 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id NAA18790 for ietf-ppp@merit.edu; Tue, 8 Dec 1998 13:18:11 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: fast reconnect Date: 08 Dec 1998 13:18:10 -0500 Organization: IronBridge Networks Lines: 57 Message-ID: <867lw2cxb1.fsf@ironbridgenetworks.com> References: <199812081718.MAA22700@po_box.cig.mot.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu ramanna@cig.mot.com (Shreesha Ramanna) writes: > I had few questions related fast reconnect. Would highly appreciate > if anyone could can give me a answer (atleast some pointers where to > look for!). It doesn't appear that your question has anything to do with "fast reconnect," at least as I understand the term. > 1. If a PPP client receives a Terminate Req followed immediately > by a Config Req I assume you mean LCP Terminate-Request and LCP Configure-Request. Note that all NCPs can do the same thing; they use the same state machine and negotiation messages as LCP. Reception of LCP Terminate-Request causes a transition to Stopping state and the transmission of an LCP Terminate-Request. Reception of LCP Configure-Request in this state is *ignored*. Your example does nothing by itself. > a. Can the PPP client renegotiate. It may, but only if it gets an LCP Terminate-Ack in response to its request or if the lower layer does a Down and then an Up transition. Otherwise, with the messages as given, it will stay in Stopping state. > b. Can the LCP parameters be different Sure; any time you renegotiate LCP the parameters may be different. You don't need or want LCP Terminate-Request to do this. Just sending LCP Configure-Request is sufficient to signal that parameters might be renegotiated (or perhaps sufficinet to signal the peer to crash ;-}). > c. Can the IPCP negotiate different IP addresses Sure. Again, when IPCP Configure-Request is sent, IP addresses are up for grabs. They can be renegotiated if desired. > d. Can the TCP SYN, SYNACKs restarted after c. Huh? TCP neither knows nor cares about the link layer. (If you're talking about the problem of having a socket bound to a local address that is no longer valid when the link comes back [note that it goes invalid only if different addresses are negotiated; not when the PPP link glitches], this is a local issue. It can be solved in any of a number of ways. Most systems will just let such sockets time out on their own, and that's probably also the best solution in the generic case. Other solutions -- including having IPCP tell the kernel or the applications to rip up and retry TCP connections -- are only an implementation issue. They're not part of PPP.) -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 13:37:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA03566; Tue, 8 Dec 1998 13:36:56 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 13:33:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA03443 for ietf-ppp-outgoing; Tue, 8 Dec 1998 13:33:00 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA03436 for ; Tue, 8 Dec 1998 13:32:56 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id NAA05186 for ietf-ppp@merit.edu; Tue, 8 Dec 1998 13:32:55 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA00712 for ; Tue, 8 Dec 1998 11:14:38 -0500 (EST) Received: (fox@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id IAA03362; Tue, 8 Dec 1998 08:14:07 -0800 (PST) From: Craig Fox Message-Id: <199812081614.IAA03362@zipper.cisco.com> Subject: PPP on SONET and FCS negotiations To: ietf-ppp@merit.edu Date: Tue, 8 Dec 1998 08:14:07 -0800 (PST) Cc: smerchant@cimaron.com In-Reply-To: <199812081516.JAA02307@shannon.adtran.com> from "Stuart Venters" at Dec 8, 98 09:16:13 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ietf-ppp@merit.edu In the WG session this morning, there was a presentation on a PPP over SONET draft. The draft seemed to imply negotiation of FCS (FCS 16 vs FCS 32) which is documented in RFC 1570. In Dallas, three years ago, the WG decided to drop the FCS option from the upcoming Draft Standard (which is still in I-D form). That decision, which was announced in the Dallas IETF minutes without any comments on the mailing list, would seem to deprecate the FCS option and suggest that we not plan for its use in upcoming specs. Has there been any discussion about resurrecting the FCS option or is there a feeling that it has not been deprecated? In Dallas, the WG chair asked if anyone had implemented this option. I don't recall anyone responding. Has anyone implemented the option? Craig - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 15:52:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA07370; Tue, 8 Dec 1998 15:52:08 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 15:49:07 -0500 Received: by merit.edu (8.9.1a/8.9.1) id PAA07238 for ietf-ppp-outgoing; Tue, 8 Dec 1998 15:49:06 -0500 (EST) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA07228 for ; Tue, 8 Dec 1998 15:48:47 -0500 (EST) Received: from brill.shiva.com (brill.shiva.com [140.248.193.94]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id PAA07487; Tue, 8 Dec 1998 15:45:14 -0500 (EST) Received: by brill.shiva.com (SMI-8.6/SMI-SVR4) id PAA15633; Tue, 8 Dec 1998 15:48:14 -0500 Date: Tue, 8 Dec 1998 15:48:14 -0500 Message-Id: <199812082048.PAA15633@brill.shiva.com> From: John Shriver To: fox@cisco.com CC: ietf-ppp@merit.edu In-reply-to: <199812081614.IAA03362@zipper.cisco.com> (message from Craig Fox on Tue, 8 Dec 1998 08:14:07 -0800 (PST)) Subject: Re: PPP on SONET and FCS negotiations Sender: owner-ietf-ppp@merit.edu I suspect that only Digital implemented that option. No idea if Cabletron or Compaq now owns that patent. However, Networks and Communications went to Cabletron, so that's more likely who owns it. The current owner might not be quite so ego-centric in their patent licensing pricing and terms. DEC quite sucessfully priced it out of the market, resulting in no license revenue to them, and no standard. (No, it's NOT worth more than software LZS compression!) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 8 18:32:30 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id SAA11773; Tue, 8 Dec 1998 18:29:00 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Dec 1998 18:19:57 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA11382 for ietf-ppp-outgoing; Tue, 8 Dec 1998 18:19:56 -0500 (EST) Received: from server4.mtg.ietf.org (server4.mtg.ietf.org [198.67.176.14]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA11360 for ; Tue, 8 Dec 1998 18:19:33 -0500 (EST) Received: from ietf-178-100 (ietf-178-100.mtg.ietf.org [198.67.178.100]) by server4.mtg.ietf.org (8.9.1/8.9.1) with SMTP id PAA27323; Tue, 8 Dec 1998 15:21:14 -0800 (PST) Message-Id: <4.0.2.19981208172341.0115e320@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 08 Dec 1998 18:09:46 -0500 To: Craig Fox From: "Andrew G. Malis" Subject: Re: PPP on SONET and FCS negotiations Cc: ietf-ppp@merit.edu, smerchant@cimaron.com In-Reply-To: <199812081614.IAA03362@zipper.cisco.com> References: <199812081516.JAA02307@shannon.adtran.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Craig, At the meeting, I repeated the proposal that FCS negotiation not be used, and didn't get any arguments. Cheers, Andy ------- At 08:14 AM 12/8/98 -0800, Craig Fox wrote: >In the WG session this morning, there was a presentation on a PPP over SONET >draft. The draft seemed to imply negotiation of FCS (FCS 16 vs FCS 32) >which is documented in RFC 1570. In Dallas, three years ago, the WG >decided to drop the FCS option from the upcoming Draft Standard (which is >still in I-D form). That decision, which was announced in the Dallas IETF >minutes without any comments on the mailing list, would seem to deprecate >the FCS option and suggest that we not plan for its use in upcoming specs. >Has there been any discussion about resurrecting the FCS option or is >there a feeling that it has not been deprecated? > >In Dallas, the WG chair asked if anyone had implemented this option. I >don't recall anyone responding. Has anyone implemented the option? > >Craig > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 9 01:20:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id BAA19472; Wed, 9 Dec 1998 01:19:28 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Dec 1998 01:16:29 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA19415 for ietf-ppp-outgoing; Wed, 9 Dec 1998 01:16:28 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA19411 for ; Wed, 9 Dec 1998 01:16:23 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id WAA25321; Tue, 8 Dec 1998 22:16:22 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 9 Dec 1998 06:16:22 UT Received: from ascend.com by ascend.com (SMI-8.6/SMI-SVR4) id WAA16506; Tue, 8 Dec 1998 22:17:02 -0800 Received: from ascend.com by ascend.com Message-Id: <3.0.5.32.19981208221608.00bd1280@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Dec 1998 22:16:08 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: PPPEXT draft minutes from Orlando Cc: l2tp@zendo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Here are the draft minutes from the first day of the PPPEXT WG from Orlando. Please let me know of any misconceptions or mistakes ASAP before I publish the official minutes. PPPEXT WG Dec. 7th, 1998 Meeting Chair Matt Holdrege - matt@ascend.com Reported by Don Grosser - grosser@us.ibm.com L2TP draft status - Mark Townsley ================================= -Poll: about 50% of attendees monitor the L2TP mailing list -Poll: most of those who monitor the L2TP mailing list saw the email from the IESG (Thomas Narten) -Mark pointed out that the authors have been working hard to advance L2TP. Mark read the following statement: The Layer 2 Tunneling Protocol, which began 2 years ago as the merging of the L2F and PPTP specifications, is currently in its 12th state of Internet Draft revision. In March of this year, the Working Group requested that the 10th revision of L2TP be promoted to RFC Proposed Standard. To date, the Working Group is aware of over 20 independently developed, interoperable L2TP implementations. In reaction to substantial customer demand, several vendors have announced general availability of L2TP in their products and have begun the initial stages of widespread deployment. One could say with clear conscience that L2TP has been in a “de facto” Proposed Standard phase for many months. The high level of endorsement for L2TP by the industry places additional weight on every decision to alter the specification as well as increased demands for an expeditious advancement through the IETF process. In fact, as time has marched forth, the L2TP specification has become less of a static proposal to base new implementations off of, and more of a report on the details of implementations have already been developed. The Editors consider the L2TP draft as the “source code” for which developers have created many L2TP implementations. As with any product which has been in widespread use in the field, every change made is applied with great scrutiny as each invariably run the risk of causing unintentional side affects. In our case, the side affects are the possible introduction of contradictions or ambiguities that may hinder interoperability of future L2TP implementations using the L2TP specification. This state of affairs has created a setting that to the IESG has seemed rigid and closed minded. In fact, this behavior has been a simple effort to balance protection of both the installed base of implementations and hard-earned consensus that the Working Group had already achieved, together with the necessary changes required in order to move the official status of the document forward in a swift manner. It seems, however, that this hard-lined conservative approach has hindered the IETF process more than it helped. Over the past 9 months, the Area Directors and IESG have made a total of 57 specific suggestions for alteration of the L2TP specification. With so many other items on its plate, the IESG must truly be commended for such a thorough review. These items have ranged from simple typos, to operational changes in protocol itself. 23 of the 57 items presented were incorporated into draft 11 and 12. The rest were resisted by the Editors on grounds that they were general misunderstandings, were not backward compatible with the multitude of existing implementations and did not provide enough benefit to outweigh the costs, or would require additional implementation experience in the field to properly address. The latter is something we argue could be taken care of during the Proposed Standard phase. At the IESG’s request, we recently re-evaluated the suggestions that were originally rejected or missed. Of these, 8 were still considered unnecessary and 8 were accepted with the necessary changes to the text applied. The final 18 items were each affiliated in one way or another with the optional flow control feature of L2TP. The Editors have been unable to reconcile each of these issues in a manner that we believe would not require additional review by the Working Group and another round of consensus attained. Therefore, it is the recommendation of the Editors that the portion of the L2TP specification that handles the optional Flow Control mechanism be isolated and moved to its own Internet Draft, leaving the base specification for approval by the IESG without this hindrance. The purpose of this action is NOT to alter the L2TP protocol itself. The express intent is to enhance the clarity and readability of the L2TP specification, properly address all of the concerns of the IESG, and still allow for a swift promotion of the base specification to Proposed Standard. To this end, no new functionality to the new L2TP specification will be permitted during this phase, beyond any necessary items for the clean separation of the Flow Control capability. Of primary concern is that the new draft be backwards compatible to the previous specification, and thus to the many existing L2TP implementations that have already been deployed. Any proposed changes solely for increased clarity and readability will be graciously accepted and evaluated for inclusion into the new specification. However, please remember that when trying to improve the overall clarity of a document, removing words is often more effective than adding them. This “Less is More” principal will certainly apply here. -It is the recommendation of the authors to remove L2TP flow control from the base specification in order to advance the L2TP draft. They propose a new draft to describe L2TP flow control. -It was noted that the new flow control draft should be backwards compatible with existing implementations. -Focus will be on advancing the L2TP base spec *then* the flow control draft. -Mark is targeting Dec. 17 to present base L2TP to the IESG. -Mark requested a document review group to be held later in the week at the IETF to review the changes. -It was noted that the base L2TP spec should always set the R-bit for the benefit of existing implementations which "stick" after dropping a packet. L2TP Link Extensions (Bill Palter/Mark Townsley) ================================================ -Need a way to communicate negotiated LCP options from LNS to LAC. -Need a way for the LAC to provide the LNS with LCP options suggestions/limitations. -LAC to LNS: -LCP want options AVP (format is similar to existing proxy LCP AVPs). A table is provided in the draft giving LCP option meaning in the context of this new AVP. -LCP allow options AVP (format is similar to existing proxy LCP AVPs). A table is provided in the draft giving per LCP option meaning in the context of this new AVP. -It was noted that some LCP options (like auth. protocol) should not be included in the new AVP because the LAC shouldn't have any input as to which auth. protocol the LNS uses. -LNS to LAC: -Bill described a method to communicate LNS negotiated LCP options to the LAC. -The L2TP SLI message can include the LCP-Conf-Req and last- received-LCP-Config-Req AVPs. L2TP MIB - Evan Caves ===================== -Changes from draft -02: -Sessions are no longer logical sub-interfaces represented in the ifTable. -The session table is indexed by tunnel ifIndex and Local CallID. -Mapping tables have been added by request. -A tunnel shared secret object has been added to the Domain and tunnel config tables. -The address and port change counters have been removed in response to the L2TP draft removing these features. -The addressing change notification has been removed. -It was noted that the L2TP MIB draft may need to be separated into an L2TP base MIB and an L2TP flow control MIB draft in light of the proposed L2TP draft split. Framework for L2TP Message Extensions - Richard Shea ==================================================== -This draft describes a generic approach to signal support for an L2TP protocol extension. For example: -new message types -new AVPs -existing AVPs in new messages -A bitmask would be used to indicate support for various extensions - one bit per extension. -It was noted that there should be a way to "reserve" bits. -This approach also serves to minimize new AVPs which signal support for an L2TP protocol extension. L2TP Dynamic Data Window Adjustment - Richard Shea ================================================== -After session establishment the LNS can modify its receive window based on which network control protocols were negotiated. -The LAC can also change its window after receiving window adjustment from LNS Mobile PPP - Mooi Choo Chuah/Don Grosser ======================================== -Goal is to provide uninterrupted VPN service to vanilla mobile nodes without having to renegotiate the PPP link during handovers. -no client software changes -minimize handover messaging/delay on expensive wireless WAN -Clients can have allocated IP addresses from a pool rather than using fixed IP addresses since IPCP will not be renegotiated. -This draft leverages L2TP. -3 models: -Simple AVP Approach - The new "serving LAC" starts a L2TP call (and possibly a tunnel) to the existing LNS. During call setup a new AVP (User AVP) identifies a PPP session on the LNS which is being replaced. The original LAC-LNS call is subsequently dropped. -Independent Tunnel Approach - The end-to-end PPP session is carried over a 2 separate L2TP tunnels. -Concatenated Tunnel Approach - This method expands the L2TP session into a 2-hop L2TP session with end-to-end flow control. -There were comments and concerns regarding its applicability and relationship to other work. L2TP over ATM - Yves ==================== -Removed from the draft: -"raw" PPP framing over L2TP -MRU indication from LAC to LNS -Modified: -extension for assymmetric bw -indication of bearer capabilities/type -indication of framing capabilities/type -ATM cause code -Rx minimum bps (OCRQ) -Rx Maximum bps (OCRQ) -NSAP based dialed number if b bit -A request will be made to the PPPEXT chair to make this draft part of the PPPEXT. PPTP - Glenn Zorn ================= -Someone asked what the delta was for the latest draft. -Glenn noted that the main differences were: -The security considerations section is much larger. -References to Karn's algorithm were removed. -Various format changes were made. -Appendices were moved to the the draft body. MPPE - Glenn Zorn ================= -It was noted that the naming of the associated "key" documents is confusing. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 10 00:31:38 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id AAA20305; Thu, 10 Dec 1998 00:28:20 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Dec 1998 00:18:56 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id AAA20142 for ietf-ppp-outgoing; Thu, 10 Dec 1998 00:18:55 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id AAA20138 for ; Thu, 10 Dec 1998 00:18:50 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id VAA19727 for ; Wed, 9 Dec 1998 21:18:49 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 10 Dec 1998 05:18:49 UT Received: from ascend.com by ascend.com (SMI-8.6/SMI-SVR4) id VAA14907; Wed, 9 Dec 1998 21:19:29 -0800 Received: from ascend.com by ascend.com Message-Id: <3.0.5.32.19981209173632.00b63420@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Dec 1998 17:36:32 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: PPPEXT draft minutes from day 2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id AAA20139 Sender: owner-ietf-ppp@merit.edu Here are the draft minutes from our second session in Orlando. Please let me know if I got anything wrong... Session chair: Matt Holdrege Reported by: Andy Malis Mark Townsley announced that there is going to be an L2TP editing session immediately following this meeting. Shahrukh Merchant (Cimaron) presented his PPP over SONET from STS-1 to STS-192 draft (draft-merchant-pppext-sonet-sdh-00.txt). Purpose: · Document existing practice on previous technology (STS-3c, STS-12c) · Document what appears to be consensus and/or current practice on current technology (STS-48c) · Proposed extension for future technology (STS-192c and above). For STS1, STS-3c, and STS-12c, use HDLC per RFC 1662 and revised ANSI T1.105.02 or Revised G.707 for SONET mapping: C2 = 0x16, x^43 + 1 payload scrambling, FCS-16 is the default and FCS-32 is optional. For STS-48c, the same as above, except that FCS-32 is the default (FCS-16 is not a defined option). For STS-192C, he proposed moving from a byte-oriented HDLC to HDLC-32, a 32-bit oriented HDLC that uses 32-bit alignment in the SONET payload for easier implementation at 10 Gbps speeds. The HDLC-32 payload scrambling (X^29 + 1) prevents potential malicious bandwidth expansion. It supports FCS-32 only. His motivation for HDLC-32 is that byte-wise HDLC is extremely complex and hard to implement at STS-192c and faster speeds. The flag sequences are: Flag0=E7 81 CA 34 Flag1=E7 81 CA 35 Flag2=E7 81 CA 36 Flag3=E7 81 CA 37 The escape sequence is Esc32=EB 8D C6 38 HDLC-32 uses four-octet flags as frame delimiters and as fill when idle. There are four defined 32-bit flag sequences and one escape sequence. The abort sequence is Esc32 + Flag0. Additions he will made to the next version of the draft: · No FCS is not an option for STS/1/3C/12c · FCS-16 is not an option for STS-48c. · ACCM is not used (although an HDLC decode would always decode it properly anyway). Next steps: · Incorporate comments, discussion, and suggestions · Fill in Appendix A, B, and C (clarifying bit ordering of scrambling and CRC calculations) · Fill in Appendix D (PPP over DS3) and expand to include DS1-DS3 and E1-E3 Chuck Benz from Nexabit suggested an intra-packet idle for under run situations for HDLC-32. Shahrouk does not believe that Cimmaron intends to patent HDLC-32. He will confirm that. Andy Hebb said that it looks like you could send up to an additional 6 bytes of overhead per frame (3 extra bytes of flag and at worst padding to a four-octet boundary). However, the probability of needing escapes in the data goes down exponentially, since it is much harder to match the four-octet escape sequence, and packets are scrambled before HDLC insertion, so scrambling will also prevent malicious expansion. Matt Holdrege wrote a draft on Always On/Dynamic ISDN (draft-ietf-ppext-aodi-00.txt), and he asked for comments for the intent of moving it on the standards track. There are multiple interoperable implementations. Anita Freeman announced two upcoming interoperability workshops on L2TP/IPsec, MS-Chapv2, MPPE and perhaps other protocols. Details will be sent to the pppext and ipsec email lists. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 10 17:49:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id RAA15471; Thu, 10 Dec 1998 17:47:55 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Dec 1998 17:42:12 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA15364 for ietf-ppp-outgoing; Thu, 10 Dec 1998 17:42:12 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA15360 for ; Thu, 10 Dec 1998 17:42:08 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id RAA27563 for ietf-ppp@merit.edu; Thu, 10 Dec 1998 17:42:07 -0500 (EST) Received: from adtrn-srv1.adtran.com (mailin.adtran.com [206.166.249.110]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA15339 for ; Thu, 10 Dec 1998 17:41:20 -0500 (EST) Received: from kfarnsworth (engn-157.adtran.com [198.79.126.157]) by adtrn-srv1.adtran.com (8.8.8/8.8.8) with ESMTP id QAA23216 for ; Thu, 10 Dec 1998 16:40:29 -0600 (CST) Message-ID: <009001be248d$a004a440$9d7e4fc6@kfarnsworth.adtran.com> From: "Kyle Farnsworth" To: Subject: Re: I-D ACTION:draft-ietf-pppext-aodi-00.txt Date: Thu, 10 Dec 1998 16:37:09 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: text/plain; boundary="NextPart"; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Some comments about the aodi-00 draft: Why is this not in the draft format that all internet drafts are? Is this informational? Can there really be a copyright notice? Page 6, Last paragraph of The Data Link Layer: The PPP FCS is not required in the X.25 PPP encapsulation on the D channel. This needs to be expanded upon and should say "The PPP FCS SHOULD NOT be used in the X.25 PPP encapsulation on the D channel". During the last bake-off some vendors were placing the FCS in the payload and some were not. This is problem with products which provide transparency (i.e. TA's). It was agreed on the VIA list that the PPP FCS should not be included in the payload. Page 8, BACP Phone Deltas: 2nd paragraph: Additional numbers are exchanged in BAC using the concept of... Typo: BAP instead of BAC Page 9: Recomended Behavior: paragraph 1, last sentence: Also BACP packets should remain on the X.25 link. First, that should be BAP packets not BACP. Second, I don't see why this is being pointed out. The BAP packets can be sent on any member link in or out of the bundle as it says in RFC2125. Page 10, An Example Heuristic for Adding Bearer Channels, 4th paragraph * 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 BAC request for a B- Channel. Another typo, BAC should say BAP. I've noticed BACP and BAP are used loosely through-out the document. This may be picky but BAP pkts are used to request bandwidth changes. BACP pkts are exchanged only once after authentication on the X.25 link. Page 9, Traffic Estimates: Some of the suggestions in here might be stepping on someones patent. I know first hand of one big company that is claiming the idea of using the data queue size to determine bandwidth requirements. Based on what happened with the PPP CCP RFC could this not be a problem with this document also? Thats all I had. Kyle Farnsworth Adtran Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 14 10:59:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA12363; Mon, 14 Dec 1998 10:57:22 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Dec 1998 10:49:48 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA12120 for ietf-ppp-outgoing; Mon, 14 Dec 1998 10:49:47 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA12116 for ; Mon, 14 Dec 1998 10:49:43 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA18578 for ietf-ppp@merit.edu; Mon, 14 Dec 1998 10:49:41 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA03804 for ; Fri, 11 Dec 1998 16:02:03 -0500 (EST) Received: from cheetah.juniper.net (cheetah.juniper.net [208.197.169.152]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA09387; Fri, 11 Dec 1998 13:01:27 -0800 (PST) Received: from cheetah.juniper.net (localhost [127.0.0.1]) by cheetah.juniper.net (8.8.3/8.8.2) with ESMTP id NAA07402; Fri, 11 Dec 1998 13:01:26 -0800 (PST) Message-Id: <199812112101.NAA07402@cheetah.juniper.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: ietf-ppp@merit.edu, sonet-geeks@juniper.net Subject: POS over STS-192c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Dec 1998 13:01:26 -0800 From: Ravi Cherukuri Sender: owner-ietf-ppp@merit.edu Shahrukh, There seems to be an issue with the bit errors in flags that could be construed as yet another flag, there by having the possibility of packets with wrong lengths to the system. This is a result of the fact that the data and pad bytes are covered by CRC32. If the CRC ic caluculated only on packet data (not necessarily 32 bit aligned) this problem can be overcome. I would recommend leaving the packet + pad bytes exactl as in your proposal and just compute CRC32 on only packet bytes. If a bit error did occur in the flag, taht would force a CRC error to be detected on the packet. On the other hand if the intent was to have the CRC32 logic run only at 32 bit boundary, making the 4 flags be maximal distant from each other will reduce the possibility of bit errors on flags to be undetected and send wrong length packets to the system. eg. a min distance of 16 bits - Flag0 E7 81 CA 34 Flag1 E7 81 35 CB Flag2 18 7E 35 CB Flag3 18 7E CA 34 -Ravi Cherukuri - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 14 12:08:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA14385; Mon, 14 Dec 1998 12:07:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Dec 1998 12:04:37 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA14323 for ietf-ppp-outgoing; Mon, 14 Dec 1998 12:04:36 -0500 (EST) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA14314 for ; Mon, 14 Dec 1998 12:04:26 -0500 (EST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 14 Dec 1998 12:03:50 -0500 Message-ID: <1180113EC576D011AADE0060975B88B33B4AFF@neonet_server1.nexabit.com> From: Chuck Benz To: ietf-ppp@merit.edu Subject: RE: POS over STS-192c Date: Mon, 14 Dec 1998 12:03:48 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ietf-ppp@merit.edu I'm in favor of simplifying the CRC to 32 bit boundaries, so I like changing the 4 flag codes as recommended here. (Looking past OC-192c, CRC calcuation/checking will eventually be as problematic as octet/word/whatever-stuffing; using fewer alignment points will help somewhat). \chuck benz (note: this thread also encompasses Stuart Venters' 8-dec email, which raised the concern about the flag difference being just 1 bit). > -----Original Message----- > From: Ravi Cherukuri [SMTP:ravi@juniper.net] > Sent: Friday, December 11, 1998 4:01 PM > To: ietf-ppp@merit.edu; sonet-geeks@juniper.net > Subject: POS over STS-192c > > > Shahrukh, > > There seems to be an issue with the bit errors in flags > that could be construed as yet another flag, there by > having the possibility of packets with wrong lengths to > the system. This is a result of the fact that the data and > pad bytes are covered by CRC32. > > If the CRC ic caluculated only on packet data (not necessarily > 32 bit aligned) this problem can be overcome. I would recommend > leaving the packet + pad bytes exactl as in your proposal and > just compute CRC32 on only packet bytes. If a bit error did occur > in the flag, taht would force a CRC error to be detected on the > packet. > > On the other hand if the intent was to have the CRC32 logic run > only at 32 bit boundary, making the 4 flags be maximal distant > from each other will reduce the possibility of bit errors on flags > to be undetected and send wrong length packets to the system. > > eg. a min distance of 16 bits - > Flag0 E7 81 CA 34 > Flag1 E7 81 35 CB > Flag2 18 7E 35 CB > Flag3 18 7E CA 34 > > -Ravi Cherukuri > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 14 13:25:51 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA16006; Mon, 14 Dec 1998 13:25:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Dec 1998 13:15:10 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA15747 for ietf-ppp-outgoing; Mon, 14 Dec 1998 13:15:09 -0500 (EST) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA15737 for ; Mon, 14 Dec 1998 13:14:58 -0500 (EST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 14 Dec 1998 13:14:27 -0500 Message-ID: <1180113EC576D011AADE0060975B88B33B4B10@neonet_server1.nexabit.com> From: Chuck Benz To: Chuck Benz , ietf-ppp@merit.edu Subject: RE: POS over STS-192c Date: Mon, 14 Dec 1998 13:14:25 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ietf-ppp@merit.edu Then again, why not just extend the CRC coverage to include the flag ? The CRC value won't be the final data of the packet, so this might complicate the CRC check process somewhat, but perhaps we can work out a straight-forward solution to that wrinkle. \chuck benz > -----Original Message----- > From: Chuck Benz [SMTP:cbenz@nexabit.com] > Sent: Monday, December 14, 1998 12:04 PM > To: ietf-ppp@merit.edu > Subject: RE: POS over STS-192c > > I'm in favor of simplifying the CRC to 32 bit boundaries, > so I like changing the 4 flag codes as recommended here. > (Looking past OC-192c, CRC calcuation/checking will > eventually be as problematic as octet/word/whatever-stuffing; > using fewer alignment points will help somewhat). > > \chuck benz > > (note: this thread also encompasses Stuart Venters' 8-dec email, > which raised the concern about the flag difference being just > 1 bit). > > > > -----Original Message----- > > From: Ravi Cherukuri [SMTP:ravi@juniper.net] > > Sent: Friday, December 11, 1998 4:01 PM > > To: ietf-ppp@merit.edu; sonet-geeks@juniper.net > > Subject: POS over STS-192c > > > > > > Shahrukh, > > > > There seems to be an issue with the bit errors in flags > > that could be construed as yet another flag, there by > > having the possibility of packets with wrong lengths to > > the system. This is a result of the fact that the data and > > pad bytes are covered by CRC32. > > > > If the CRC ic caluculated only on packet data (not necessarily > > 32 bit aligned) this problem can be overcome. I would recommend > > leaving the packet + pad bytes exactl as in your proposal and > > just compute CRC32 on only packet bytes. If a bit error did occur > > in the flag, taht would force a CRC error to be detected on the > > packet. > > > > On the other hand if the intent was to have the CRC32 logic run > > only at 32 bit boundary, making the 4 flags be maximal distant > > from each other will reduce the possibility of bit errors on flags > > to be undetected and send wrong length packets to the system. > > > > eg. a min distance of 16 bits - > > Flag0 E7 81 CA 34 > > Flag1 E7 81 35 CB > > Flag2 18 7E 35 CB > > Flag3 18 7E CA 34 > > > > -Ravi Cherukuri > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 14 17:50:32 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id RAA22304; Mon, 14 Dec 1998 17:50:02 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Dec 1998 17:39:35 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA22142 for ietf-ppp-outgoing; Mon, 14 Dec 1998 17:39:34 -0500 (EST) Received: from smtp-2.mdc.net (smtp-2.mdc.net [209.251.64.26]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA22133 for ; Mon, 14 Dec 1998 17:39:22 -0500 (EST) Received: from cimaron.com (xcom-392.mdc.net [208.196.214.152]) by smtp-2.mdc.net (8.9.1/8.9.1) with SMTP id RAA27915 for ; Mon, 14 Dec 1998 17:35:31 -0500 (EST) (envelope-from smerchant@cimaron.com) Received: from cimaron.com [2.1.1.11] by cimaron.com [2.1.1.7] with SMTP (MDaemon.v2.7.SP1.R) for ; Mon, 14 Dec 98 17:37:54 -0500 Message-ID: <36759302.3B03C7B1@cimaron.com> Date: Mon, 14 Dec 1998 17:36:50 -0500 From: Shahrukh Merchant Organization: Cimaron Communications Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: sventers@adtran.com CC: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft References: <199812081516.JAA02307@shannon.adtran.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ietf-ppp@merit.edu Reply-To: smerchant@cimaron.com Sender: owner-ietf-ppp@merit.edu [I was in the middle of composing this response to Stuart's points when I received Ravi's and Chuck's subsequent e-mails, so I will incorporate responses to all. Am also including some more information proposing a better HDLC-32 payload scrambler than x^29+1.] Contents: -------- 1. Revised Flag (and Esc32) codes 2. New Underflow code 3. Revised HDLC-32 payload scrambler proposed (formerly x^29+1) 4. Responses to other points 1. Revised Flag (and Esc32) codes --------------------------------- sventers@adtran.com (Stuart Venters) wrote: > > shahrukh, > > i have some thoughts concerning your format for PPP at OC-192 speeds. > (in decreasing order of importance) > > First, it appears that the length of the pad field and hence the length > of the packet is not protected by the FCS field. How would a bit error > in the lsb's of a FLAG immediately following the FCS field be > handled at the receiver? You're right--good catch! As the pad is currently described, a final word of Databyte(xx) Padbyte(00) Padbyte(00) Padbyte(00) for example, could be apparently converted by a single bit error that changes the subsequent Flag1 to Flag0 into Databyte(xx) Databyte(00) Databyte(00) Databyte(00) and this error would be undetected by the CRC calculation. There are a couple of different simple fixes possible. One possibility is that whenever a pad is used, the CRC needs to be calculated over different values than is actually used for the pad, so that if there is an error in the pad length indication, the CRC will be incorrect and the packet will be flagged as such. E.g., when the packet length is not a multiple of 4 bytes, the CRC would still be calculated based on filling the remaining 1-3 bytes with all zeros. However, the actual pad inserted would be DIFFERENT from all-zeros, e.g., Pad1 = 0x80 (when 1 pad byte is needed) Pad2 = 0x8000 (when 2 pad bytes are needed) Pad3 = 0x800000 (when 3 pad bytes are needed) (The alternative of calculating the CRC only over the real data bytes also works, of course, but is more complex to implement because of the four different cases that have to be handled in the CRC calculation logic.) However, since using more robust flags (see below) provides very strong error protection, I propose NOT using the variable pads as described above since it would require one additional pipelined stage (while we are figuring out whether we need to overwrite bytes going into the CRC calculator 2 words later...). However, if someone believes that packet data is particularly predisposed to ending with zeros, we could make the pad (both used in the CRC-32 calculation as well as transmitted) be something else, e.g., 0x93[93[93]]. For direct protection of the Flag codes, they could be encoded to have greater Hamming distance between them (which also provides better protection in the case of the pad length being errored to appear shorter than it actually is). (Originally, I was going to propose codes that had a distance of 3-4, using the 5 LSBs, to minimize excessive decoding, but Ravi's suggestion of a larger distance of 16 does preserve decoding ease anyway, owing to retention of common 16-bit code blocks, so I would go along with that approach, but propose the following new values for the specific codepoints): Flag0=AD 49 6B 25 Flag1=AD 49 94 DA Flag2=52 B6 6B 25 Flag3=52 B6 94 DA Reasons for this choice are: (a) Significantly greater 1-0/0-1 transitions than previous values (or variations of previous values), which could increase the potential useability for other media or physical layers (b) 50% 1s density in each code (c) Has conceptual and decoding simplicity that "AD49,6B25=0" and "52B6,94DA=1"). Note that it is specifically stipulated that there be no error CORRECTION on the flags (only detection), as otherwise it would entail escaping all correctable versions of the flags too! In order to keep the simplification that Esc32 = Flag0 XOR 0x0C0C0C0C, we modify that to Esc32 = A1 45 67 29 2. New Underflow Code --------------------- As proposed at the PPPEXT meeting in Orlando, an Underflow code is defined: UF32 = FF 55 00 AA The underflow code may be inserted (in the transmit direction towards the line) after transparency processing (whence any underflow words within the payload MUST be escaped), when the packet buffer is depleted mid-packet, as a mechanism to avoid forcing a packet abort in those circumstances. 3. Revised HDLC-32 Payload scrambler ------------------------------------ As indicated in the presentation, I wanted to look further into the scrambler choice to pick possibly a more robust one. x^29+1 is not a maximal length scrambler (in fact, with an input sequence of all zeros, it has a period of only 29). Instead, I propose the polynomial x^29+x^2+1, which is an irreducible primitive polynomial and hence should result in a maximal length sequence (and with only one more "tap"). [See "Error Correcting Codes," Peterson & Weldon, 2nd edition, Appendix C.] Also, this was not explicitly stated in the -00 draft or the presentation, but the 29-bit scrambler would operate in big-endian order, i.e., the MS bit of each 32-bit word will be fed into the shift register first. 4. Responses to other points ---------------------------- sventers@adtran.com (Stuart Venters) wrote: > The plan contains three nested scramblers, these are an outer 7bit, > a middle 48[sic]bit, and an inner 29bit one. (That inner one is neat!) > I am curious as to why you feel that the middle scrambler is required. > Perhaps eliminating it and making the inner one longer would provide > the same protection with less parts? It would seem that at these speeds, > simplicity is a good idea. A couple of other people asked about this too privately. I believe they should both (29 and 43) stay for transport over SONET, as they serve different purposes. The reason has to do with layering. The concatenated mapping in SONET has been shown to be "deficient" in that it is not truly transparent (as "good" mappings ought to be). Specifically, giving the user access to so much consecutive payload allows him to emulate the SONET "outer" scrambler. So the 43-bit SONET payload scrambling really, to my way of thinking, addresses the transparency issue of *SONET* and, as such, should be payload independent. Now that's not the way it went for ATM into SONET, where only the ATM payload is scrambled. But I think it is a step in the right direction for ANSI and ITU-T to specify scrambling over the entire payload for HDLC. (I wish ANSI had gone a step further and made 43-bit scrambling part of the mapping for concatenated payloads--grandfathering ATM as an exception--so that we move away from having special-case processing for each payload type to address what is really an issue for a lower layer.) Implementation of the 43-bit scrambler is not difficult (although it is admittedly one more thing to do), so I think the benefits of keeping our layers clean (i.e., considering the 43-bit scrambling really part of the *SONET* mapping, while the 29-bit is part of the PPP-to-HDLC32 mapping) make its inclusion a worthwhile tradeoff in my mind. > In the explanation for the choice of flag and escape byte values, you > state that they are sufficiently random, have no repeated bytes, and have 50% > ones density. Given the inner and outer scramblers, why would not any 5 values > work equally as well? (For Example 00 00 00 0x?) Well, yes and no. Conceptually you're right. But, for instance, if one wanted to make HDLC-32 standalone (for other protocols or other physical layers, or for carrying directly over fiber, for instance) then a value with more transitions and non-repeating sub-sequences is highly desirable particularly where you would often have the case of sending back-to-back flags when there is no data to send. Another way of saying it is that since there are so many code points to choose 4 flags from, we might as well pick values that have some other "nice" properties. > At OC-192, my calculator says to expect an Esc32 every 370 seconds. Eventually > when this is scaled to Esc64, this time would turn out to be so long that it is > impossible to test that the escape hardware is working. (It's too bad we can't > just count and drop any packets requiring an escape.) Yes, I would certainly recommend having a mode for test purposes (as opposed to operational use, where we are depracating options) to disable each of these scramblers! Slightly less convenient would be a test feature to set the scrambler to a known state so that you could "reverse engineer" your immediately following data to scramble into anything you wanted. Chuck Benz wrote: > Then again, why not just extend the CRC coverage to > include the flag ? The CRC value won't be the final > data of the packet, so this might complicate the CRC > check process somewhat, but perhaps we can work out > a straight-forward solution to that wrinkle. I think this would complicate things (and I'm not sure it's necessary given the protection in the enhanced Flags). For instance, everything that's protected by the CRC is (currently) scrambled by the 29-bit scrambler (after the CRC is calculated), while the Flag bytes are not so scrambled. So I'm not sure that the "flag" covered by the CRC will be able to serve as a delimiter anymore (it will just serve as a "size of pad" indication) and you'll then require an extra flag between packets, which defeats the compaction allowed by the dual function flag/pad-size mechanism now defined. Shahrukh -- Shahrukh Merchant Director, Systems Engineering and Verification Cimaron Communications Corporation Phone: +1 978 623-0009 Ext 3020 Fax: +1 978 623-0024 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 16 18:37:56 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id SAA06624; Wed, 16 Dec 1998 18:30:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Dec 1998 18:21:49 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA06360 for ietf-ppp-outgoing; Wed, 16 Dec 1998 18:21:48 -0500 (EST) Received: from adtrn-srv1.adtran.com (mailin.adtran.com [206.166.249.110]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA06352 for ; Wed, 16 Dec 1998 18:21:41 -0500 (EST) Received: from shannon.adtran.com (shannon.adtran.com [172.22.16.9]) by adtrn-srv1.adtran.com (8.8.8/8.8.8) with SMTP id PAA28438; Wed, 16 Dec 1998 15:40:15 -0600 (CST) Received: by shannon.adtran.com (SMI-8.6/SMI-SVR4) id PAA13013; Wed, 16 Dec 1998 15:44:16 -0600 From: sventers@adtran.com (Stuart Venters) Message-Id: <199812162144.PAA13013@shannon.adtran.com> Subject: Re: PPP at STS-192c draft To: smerchant@cimaron.com Date: Wed, 16 Dec 1998 15:44:16 -0600 (CST) Cc: ietf-ppp@merit.edu In-Reply-To: <36759302.3B03C7B1@cimaron.com> from "Shahrukh Merchant" at Dec 14, 98 05:36:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Shahrukh, I have thought some more concerning your format and have some changes and simplifications for you to consider. You pointed out that scramblers of the form X^n + 1 are not too good when you changed the SCR-29. Perhaps it would also be a good time to set a precident for the 43 bit scrambler also? I wonder if X^43 + X^2 + 1 is also maximal length? It looks to me like the transmission of the pad length could be simplified without sending more words if you were to move the responsibility of transferring this length from the Flag word to the CRC word. What if you encoded the pad length as follows? if (pad length = 0) then = if (pad length = 1) then = xor 0x11111111 if (pad length = 2) then = xor 0x22222222 if (pad length = 3) then = xor 0x33333333 To receive, just go ahead and clock the CRC word into the CRC checker and match the resulting checksum against four constants. The impact on the protection offered by the crc is minimal in that the strength of the crc is decreased from 32 bits to 30 bits. Given this, the choice of FLAG, ESC, and UF could be made more systematic. One way (using your original values) might be the following scheme: All control words (flags, escapes, etc) are of the form . The initial set of control words might be: Esc32 = E7 81 CA 00 Uf32 = E7 81 CA 01 Flag32 = E7 81 CA 80 (perhaps name this start of PPP frame?) Other control words might be added to the set in the future to support new traffic types and features. The receiver should have predictable responses to unrecognized control words so that future versions of the protocol might interoperate with current implementations. (Old receiver should ignore things coded in new codes?) At worst, this plan results in simpler hardware which never gets extended. At best, this could eventually allow a convergence of communications with the physical link able carry an assortment of traffic types. What do you think? Stuart Venters (256) 963-8719 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 16 21:36:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id VAA08759; Wed, 16 Dec 1998 21:36:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Dec 1998 21:33:30 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA08706 for ietf-ppp-outgoing; Wed, 16 Dec 1998 21:33:29 -0500 (EST) Received: from smtp-2.mdc.net (smtp-2.mdc.net [209.251.64.26]) by merit.edu (8.9.1a/8.9.1) with ESMTP id VAA08701 for ; Wed, 16 Dec 1998 21:33:22 -0500 (EST) Received: from cimaron.com (xcom-392.mdc.net [208.196.214.152]) by smtp-2.mdc.net (8.9.1/8.9.1) with SMTP id VAA73881 for ; Wed, 16 Dec 1998 21:29:11 -0500 (EST) (envelope-from smerchant@cimaron.com) Received: from cimaron.com [2.1.1.11] by cimaron.com [2.1.1.7] with SMTP (MDaemon.v2.7.SP1.R) for ; Wed, 16 Dec 98 21:23:41 -0500 Message-ID: <36786ADE.7E8B0998@cimaron.com> Date: Wed, 16 Dec 1998 21:22:22 -0500 From: Shahrukh Merchant Organization: Cimaron Communications Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: sventers@adtran.com CC: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft References: <199812162144.PAA13013@shannon.adtran.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ietf-ppp@merit.edu Reply-To: smerchant@cimaron.com Sender: owner-ietf-ppp@merit.edu Contents -------- 1. Choice of SONET payload scrambling polynomial 2. Simplified and more flexible encoding of control codes (Flags, Esc, etc.) 1. Choice of SONET payload scrambling polynomial ------------------------------------------------ You're right that x^43+1 is not maximal length (although "maximal length" is harder to define for a self-synchronous scrambler where the next state is not just a function of the current state, but also of the input). My reference does not go up to x^43, but one could no doubt find a maximal length sequence of order 43 (it's probably not X^43+x^2+1 except by coincidence). And intuitively that would seem better (does anyone know what the reasoning was that lead to x^43+1 being selected for ATM?). But we currently have x^43+1 recently established as the scrambler for HDLC mapping in ANSI and ITU-T, and the wording is sufficiently blanket to cover all concatenated rates. Nonetheless, one could make the argument: "OK, so we don't touch STS-48c and below, since people are implementing it and ITU-T and ANSI have standardized on this, but for STS-192c we aren't using pure HDLC anyway, but rather HDLC-32, and no one's implemented HDLC-32 yet, so we might as well do it better." It's a valid argument, but (a) the better protection, ironically, would be provided for the case where it was less needed (owing to the SCR-29 scrambling preceding it) and (b) one wonders if the theoretical advantage really translates to a practical advantage. I shall pass the question on to our resident coding theory expert, but if someone on this list has the resources and background to answer authoritatively on this latter point, it would be useful input. My "gut feel" is that there would need to be a burden of proof on adding a different polynomial for this case (people are used to the old one, they've implemented and tested it, its's confusing to have different scramblers for the same function for different SONET rates, etc., etc.) and the theoretical advantage may not be worth the extra confusion ... Stuart Venters wrote: > > Shahrukh, > > I have thought some more concerning your format and have some > changes and simplifications for you to consider. > > You pointed out that scramblers of the form X^n + 1 are not > too good when you changed the SCR-29. Perhaps it would also > be a good time to set a precident for the 43 bit scrambler > also? I wonder if X^43 + X^2 + 1 is also maximal length? 2. Encoding of control codes (Flags, Esc, etc.) ----------------------------------------------- Many different implications in what you write below--let me try to address them separately. (a) Firstly, independently of anything else, it would definitely be prudent to add some additional special reserved control words that would also be escaped, and it would be nice to be able to decode this additional set with a small decoder. So regardless of anything else, I think we should add some number of such words. I was originally thinking of a "handful" but a larger number such as the 256 you propose (subject to their being easily decoded) wouldn't hurt. 2^-24 is still a really small number so the overhead of escaped sequences would still be negligible. (b) Again, this is something I'd need to defer to our resident coding theory expert on, but I don't believe that the effect of XORing the CRC-32 syndrome with the 4 different values would equate to "reducing the strength of the CRC from 32 to 30 bits." CRC codes typically have properties like: - Detects all single bit errors - Detects all 2-bit errors for packet lengths <= P - Detects all burst errors for burst lengths <= Q - Detects (1-2^-N, N=32 in this case) of all multi-bit errors (Does anyone have a reference for CRC-32 that would give these parameters?) I am not sure that the "detects all single bit errors" property, for one, would still hold if one did what you are suggesting, i.e., it could be a qualitative weakening and not just a quantitative one. (c) Your thought of having less spread-out control codes is appealing in its simplicity and ease of decoding. In most cases, where you only want to DETECT errors, I don't think there is a problem with doing that. The FlagN sequences are a special case because we are trying to add error detection to the Flags themselves. An alternative that would achieve both might just be to go back to the other approach I proposed in my last e-mail: Calculate the CRC-32 on a pad of [00[00[00]]] but use an actual pad of say [11[22[33]]] (or perhaps [01[02[04]]]). Assuming that all burst errors of length <=21 are detected (or all 3-bit errors within a burst length of 15 are detected for the latter example), I believe this will detect all pad-length errors. The main disadvantage that I can see of this approach is that you won't know your pad length till 2 words AFTER you ideally would like to know it (to substitute in all-zeros for the pad into the CRC calculation), which could require 2 additional words of data pipelining. (It still doesn't stop you from assigning Flag codes that are at least a small Hamming distance apart.) So a hybrid proposal could be: - All control words (flags, escapes, etc.) are of the form (as you suggest, but using the value from my last e-mail with greater 0/1 transitions). - xx is encoded as follows (shown in binary below): 000y yyyy: FLAG CODES (WITH EXTRA CODE-POINTS FOR ERROR DETECTION) 1111 0101: ESCAPE 1111 1010: UNDERFLOW All others: Reserved for future standardization yyyyy is encoded as follows: --------------------------- 01100=Flag0 10001=Flag1 11010=Flag2 00111=Flag3 all-other=permanently reserved (unuseable) values These have a 3-4 bit Hamming distance between Flag values, which is perhaps sufficient even if not combined with the pad protection mechanism described above. (It also preserves a 4-bit Hamming distance between all the other currently assigned words too, although this is not as important and of course may not be guaranteed by future assignments.) Further thoughts? Shahrukh -- Shahrukh Merchant Director, Systems Engineering and Verification Cimaron Communications Corporation Phone: +1 978 623-0009 Ext 3020 Fax: +1 978 623-0024 Stuart Venters wrote: > It looks to me like the transmission of the pad length could be > simplified without sending more words if you were to move > the responsibility of transferring this length from the > Flag word to the CRC word. What if you encoded the pad > length as follows? > > if (pad length = 0) then = > if (pad length = 1) then = xor 0x11111111 > if (pad length = 2) then = xor 0x22222222 > if (pad length = 3) then = xor 0x33333333 > > To receive, just go ahead and clock the CRC word into the CRC checker and > match the resulting checksum against four constants. The impact on the > protection offered by the crc is minimal in that the strength of the crc > is decreased from 32 bits to 30 bits. > > Given this, the choice of FLAG, ESC, and UF could be made more systematic. > One way (using your original values) might be the following scheme: > > All control words (flags, escapes, etc) are of the form . > The initial set of control words might be: > > Esc32 = E7 81 CA 00 > Uf32 = E7 81 CA 01 > Flag32 = E7 81 CA 80 (perhaps name this start of PPP frame?) > > Other control words might be added to the set in the future > to support new traffic types and features. > > The receiver should have predictable responses to unrecognized > control words so that future versions of the protocol might > interoperate with current implementations. (Old receiver > should ignore things coded in new codes?) > > At worst, this plan results in simpler hardware which never gets extended. > At best, this could eventually allow a convergence of communications with the > physical link able carry an assortment of traffic types. > > What do you think? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 17 10:50:50 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA16720; Thu, 17 Dec 1998 10:49:02 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Dec 1998 10:38:32 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA16485 for ietf-ppp-outgoing; Thu, 17 Dec 1998 10:38:32 -0500 (EST) Received: from adtrn-srv1.adtran.com (mailin.adtran.com [206.166.249.110]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA16474 for ; Thu, 17 Dec 1998 10:38:25 -0500 (EST) Received: from shannon.adtran.com (shannon.adtran.com [172.22.16.9]) by adtrn-srv1.adtran.com (8.8.8/8.8.8) with SMTP id JAA01465; Thu, 17 Dec 1998 09:37:53 -0600 (CST) Received: by shannon.adtran.com (SMI-8.6/SMI-SVR4) id JAA14108; Thu, 17 Dec 1998 09:41:56 -0600 From: sventers@adtran.com (Stuart Venters) Message-Id: <199812171541.JAA14108@shannon.adtran.com> Subject: Re: PPP at STS-192c draft To: smerchant@cimaron.com Date: Thu, 17 Dec 1998 09:41:56 -0600 (CST) Cc: ietf-ppp@merit.edu In-Reply-To: <36786ADE.7E8B0998@cimaron.com> from "Shahrukh Merchant" at Dec 16, 98 09:22:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Shahrukh, With regard to the difficulties of coding the pad length in the CRC word: If one were to use your scheme, Calculate the CRC-32 on a pad of [00[00[00]]] but use an actual pad of say [11[22[33]]] (or perhaps [01[02[04]]]). What if the receiver calculated the CRC remainder over the whole received message including the CRC word. Would the result (assuming no bit errors) be one of four constants depending on the pad length? Would this fix the pipeline problem of having to know the pad length before calculating the CRC? With regard to reserving some special reserved control word values: How do you feel about there being two kinds? The kind the receiver ignores like Uf32 (future codes might be Xon, Xoff?) The kind the receiver used to delimit other data types Cheers, Stuart Venters - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Dec 20 23:49:03 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id XAA06575; Sun, 20 Dec 1998 23:47:36 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sun, 20 Dec 1998 23:39:35 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id XAA06462 for ietf-ppp-outgoing; Sun, 20 Dec 1998 23:39:34 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id XAA06458 for ; Sun, 20 Dec 1998 23:39:28 -0500 (EST) Received: from wawa.juniper.net (wawa.juniper.net [208.197.169.234]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id UAA22747; Sun, 20 Dec 1998 20:38:53 -0800 (PST) Received: from wawa.juniper.net (localhost.juniper.net [127.0.0.1]) by wawa.juniper.net (8.8.8/8.7.3) with ESMTP id UAA04115; Sun, 20 Dec 1998 20:38:52 -0800 (PST) Message-Id: <199812210438.UAA04115@wawa.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: smerchant@cimaron.com cc: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft In-reply-to: Your message of "17 Dec 1998 02:22:22 GMT." <36786ADE.7E8B0998@cimaron.com> Mime-Version: 1.0 Content-Type: text/plain Date: Sun, 20 Dec 1998 20:38:52 -0800 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Shahrukh, > 1. Choice of SONET payload scrambling polynomial > ------------------------------------------------ > You're right that x^43+1 is not maximal length (although "maximal > length" is harder to define for a self-synchronous scrambler where the > next state is not just a function of the current state, but also of the > input). I think this is the key point. A self-synchronous scrambler is not an LFSR, and doesn't produce a fixed, repeating output, so there is no sequence whose length needs to be maximized. That is, adding the extra term to the x^43+1 (or x^29+1) scrambler does not increase the number of states the scrambler can be in (all 2^43 or 2^29 states are possible in both cases), so adding the extra term doesn't make the precise output of the scrambler any harder to guess. Worse, what I think you're ignoring is the fact that self-synchronous scramblers are error-multiplying and adding more terms just makes a single bit error in the scrambled data turn into more errors after descrambling. That is, a single bit error in the x^43+1 scrambled payload turns into two bits in error after descrambling, one at the location of the bit error and one 43 bits later (i.e. a single bit error is turned into a 43 bit burst). Adding another term to the scrambler increases the number of bits in error after descrambling to 3, which is certainly not an improvement and is intuitively likely to make things worse since error multiplication has implications for error detection. The error multiplication is also the first objection I have to the two nested scramblers you are suggesting. If you run the x^43+1 scrambler over packet payload scrambled by the x^29+1 scrambler, then a single bit transmission error in a packet turns into a 4 bit error after descrambling; one at the location of the bit error, one 29 bits later, one 43 bits later and one 72 bits later. If you add a third term to packet scrambler, you now have a single bit error causing 6 bits to be in error after descrambling. If you also add a third term to the x^43+1 scrambler you end up with a single bit tranmission error turning into 9 errored bits after descrambling. You can't assume that this is without impact on error detection performance of the FCS. As you note later, > the strength of the CRC from 32 to 30 bits." CRC codes typically have > properties like: > > - Detects all single bit errors > - Detects all 2-bit errors for packet lengths <= P > - Detects all burst errors for burst lengths <= Q > - Detects (1-2^-N, N=32 in this case) of all multi-bit errors You are systematically ensuring that all transmission errors, even single bit errors, will have a burst length of at least 72 bits with at least 4 bits in error (6 bits with the extra term added to the x^29... scrambler) by the time your FCS sees them. My more serious objection to the x^29... scrambler applied only to packet data, however, is that for a given bit error rate on the circuit the use of the scrambler seems to me to cause the frame error rate to increase with decreasing frame transmission rates. For normal HDLC, without the use of any self-synchronous scrambler, a frame will be errored if a bit error occurs anywhere in the frame payload or in the immediately preceding or succeeding flags. The use of the x^43+1 scrambler widens this window to 43 bits in front of the preceding flag, but errors in the flags not immediately adjacent to the packet do not cause errors in the packet. With your proposal, however, an error anywhere in the flags between frames appears to cause the next frame to arrive to be dropped. That is, a bit error in the interpacket flags will cause the flags to appear as packet data. The FCS protection will likely cause this erroneous data to be dropped, but in the process of doing so you will change the state of the x^29... scrambler. This means that when you do receive a valid frame you will cause errors in the first 29 bits of the valid frame, causing it to be dropped as well. Since erroneous state in the x^29... scrambler will always persist until you receive (and damage) a valid frame, the probability of dropping a frame will depend not only on the length of the frame but also the number of flags preceding the frame. If you've been receiving idle flags for a long time the probability of damaging the next frame to arrive will approach unity. One could argue that the expected bit error rate for SONET should be low enough that this won't matter, but it strikes me as making the framing unnecessarily fragile (it also seems to me the low error rate argument might not necessarily apply at OC-192c either). So I have some reservations about the robustness of the packet scrambler you suggest. More generally, however, I also think that if we're to invent a new framing protocol for higher speeds, it is worth while to make sure the scheme that is chosen gives us maximal advantage. The one other alternative to this I've seen proposed is SDL, from Lucent, which I also have some reservations about but which strikes me as having distinct advantages over this. In particular: - Similar to octet-synchronous HDLC you depend on the SONET framing to align the framing to 32-bit boundaries. SDL does not necessarily depend on the SONET framing, an SDL framer could be built to deframe a bit stream sent over the raw fiber. - Your basic per-frame overhead, at 8 bytes per frame (4 bytes of flag, 4 bytes of FCS) is the same as SDL, but you additionally pad by 0-3 bytes for alignment and occasionally do transparency stuffing. SDL does no stuffing and doesn't bother to pad the frame. SDL actually could pad the frame, but I'd suggest that the implementation complexity of dealing with an odd number of bytes in a frame is not high; it maybe doubles the (relatively small) amount of logic devoted to the FCS computation. - SDL can also retain the 16-bit FCS, if this is worth anything, and can also run reasonably with no FCS at all, which is not useful for PPP but might be if the framed data includes error correction codes. - I think the real implementation complexity of HDLC at high speeds comes from stuffing for transparency. That is, bit-synchronous HDLC is hard if you can't run your data path a bit at a time, and octet-synchronous HDLC is hard if you can't run your data path a byte at a time. Similarly, HDLC-32 is only easy if you can run your data path 4 bytes wide. At OC-192c this means that HDLC-32 is only really easy at 311 MHz, which is more than a bit challenging with current technology and suggests that there'll be incentive to reinvent the framing protocol again if speeds beyond OC-192c become necessarily in the near term. SDL, on the other hand, eliminates transparency stuffing and associated complexity altogether. This seems to me to be fundamentally more scalable, and also permits one the possibility of doing really hard-core bandwidth scheduling on a circuit, something that is made annoyingly imperfect if your framer sometimes randomly grows packets by stuffing. - SDL makes sense at speeds lower than OC-192c, and potentially can fix the problems transparency stuffing causes there too. HDLC-32 is less attractive at lower speeds, so the stuffing problem remains (and it seems to me that if the packet expansion due to stuffing is a problem worth fixing at OC-192c it is also a problem worth fixing at lower speeds). - SDL doesn't use a self-synchronous scrambler, and hence doesn't cause error multiplication. Even if you wanted to retain the use of a self-synchonous scrambler to avoid SDL's scrambler state exchange, however, you could probably do this better with SDL too since SDL also doesn't send flags between packets; it instead sends packets that you throw away, and these could always be made to carry random data for the purpose of clearing errors out of the scrambler before real packets arrive again. If we're going to respecify the framing protocol I'd rather do this just once. It seems to me that SDL, or something more like SDL, might be more likely achieve this than hacking at HDLC. Do you disagree? Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 06:36:07 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id GAA09492; Mon, 21 Dec 1998 06:34:20 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 06:28:05 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id GAA09438 for ietf-ppp-outgoing; Mon, 21 Dec 1998 06:28:05 -0500 (EST) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.9.1a/8.9.1) with ESMTP id GAA09432 for ; Mon, 21 Dec 1998 06:27:43 -0500 (EST) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Mon, 21 Dec 1998 16:54:37 +0530 Received: from auckland.future.futsoft.com (auckland.future.futsoft.com [10.0.2.33]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA08490; Mon, 21 Dec 1998 16:41:37 +0530 Received: by auckland.future.futsoft.com with Microsoft Mail id <01BE2D01.DEDA0580@auckland.future.futsoft.com>; Mon, 21 Dec 1998 16:49:27 +0530 Message-Id: <01BE2D01.DEDA0580@auckland.future.futsoft.com> From: Harischandra Shenoy R To: "'carrel@RedBack.net'" , "'louie@uu.net'" , "'ross@routerware.com'" Cc: "'ietf-ppp@merit.edu'" Subject: PPPoE clarifications reqd ... Date: Mon, 21 Dec 1998 16:49:24 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id GAA09435 Sender: owner-ietf-ppp@merit.edu Hello, I have a few doubts on the PPPoE draft. (1) What is the exact frame that is transmitted from an AC to an ISP (and vice versa) ? Will it contain a PPPoE header that the ISP has to remove ? If the frame is just an ethernet frame (without PPPoE) and if the source address is used by the ISP to determine the client, even then some minor modification will be required to existing PPP software at ISPs so that they can receive and demux ether frames (I presume that current implementations will demux based on some other LL id like CLID or port number). Is this correct ? (2) The section on "Security Considerations", states : "Many Access Concentrators will not wish to offer information regarding what services they offer to an unauthenticated entity. In that case the Access Concentrator should employ one of two policies. It SHOULD never refuse a request based on the Service-Name TAG, and always return the TAG_VALUE that was sent to it. " It is not clear how this will help. A malicious client who wants to find out the services offered by some particular AC can send several seperate PADIs to learn what all services an AC supports. Also, if an AC doest not support a particular service name then it has to refuse a request for that service. (3) Should the services offered by an AC as well as the service(s) requested by a client be prioritised ? For example, the draft says "When the Access Concentrator receives a PADI that it can serve..." (Page 5, section 5.2) - is this an implementation specific decision or should there exist some standard way of saying that an AC can service a particular client ? Similarly, when a client receives PADO packets from several ACs, all offering similar services, then what is the criteria to select an AC ? (4) There is no description in the draft on how the client should respond when it receives a packet with the AC-System Error tag. Is this an implementation-specific feature ? (5) Does "draft-carrel-info-pppoe-02.txt" (PPPoE) have any relation to "draft-ietf-info-pppext-ether-00.txt" ? In addition to the above, I would like to suggest that the draft is tilted towards a client only implementation of PPPoE. More details of how a PPPoE AC should function and changes to existing PPP implementations at the ISP need to be mentioned in the draft. This will reduce a lot of ambiguity. Thanks in advance, Shenoy H (shenoyh@future.futsoft.com) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 09:31:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA11535; Mon, 21 Dec 1998 09:31:23 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 09:29:47 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA11491 for ietf-ppp-outgoing; Mon, 21 Dec 1998 09:29:47 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA11486 for ; Mon, 21 Dec 1998 09:29:26 -0500 (EST) Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id PAA29384; Mon, 21 Dec 1998 15:29:02 +0100 (MET) Received: from tos92022 by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA21631; Mon, 21 Dec 1998 16:28:58 +0200 (EET) Message-Id: <3.0.5.32.19981221162829.00923e90@openmail.lmf.ericsson.se> X-Sender: mikael latvala@openmail.lmf.ericsson.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 21 Dec 1998 16:28:29 +0200 To: ietf-ppp@merit.edu, carlson@ironbridgenetworks.com From: Mikael Latvala Subject: Fast reconnect and CHAP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Some questions and observations concerning fast reconnect and CHAP. 1. Isn't fast reconnect in conflict with RFC1994? RFC1994 says: "Each challenge value SHOULD also be unpredictable, least an attacker trick a peer into responding to a predicted future challenge, and then use the response to masquerade as that peer to an authenticator." Or is the idea to use fast reconnect only with LCP and NCP? In that case the total RTT delay would be 1,5 (0,5 for LCP Conf-Request and Conf-Ack, 0,5 for CHAP challenge, and 0,5 for CHAP response, NCP Conf-Request and Conf-Ack). 2. Mobility would introduce an extra 1 RTT delay when using fast reconnect. RFC1994 says: "Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness." That means that each time a mobile device moves to a new area served by a differrent access server its CHAP response prediction would fail. 3. I was also wondering how L2TP's LAC handles fast reconnect. Has anybody has used fast reconnect and L2TP together? What I am afraid of is that most of the LACs will trow NCP, possibly also authetication packets away while waiting for ICRP from LNS thus making fast reconnect more or less useless. /Mikael ------------------------------------------------------------------------ | Mikael Latvala | Mikael.Latvala@ericsson.com | | Oy L M Ericsson Ab | http://webse1.lmf.ericsson.se/staff/lmfpml | | 02420 Jorvas, Finland | +358 9 299 2850 (W) +358 40 507 2555 (GSM) | ------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 09:57:22 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA12090; Mon, 21 Dec 1998 09:57:06 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 09:56:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA12044 for ietf-ppp-outgoing; Mon, 21 Dec 1998 09:56:00 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA12039 for ; Mon, 21 Dec 1998 09:55:54 -0500 (EST) Received: (from carlson@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id JAA12433; Mon, 21 Dec 1998 09:55:47 -0500 (EST) Date: Mon, 21 Dec 1998 09:55:47 -0500 (EST) Message-Id: <199812211455.JAA12433@ironbridgenetworks.com> X-Authentication-Warning: helios.helios: carlson set sender to carlson@ironbridgenetworks.com using -f From: James Carlson To: mikael.latvala@ericsson.com CC: ietf-ppp@merit.edu In-reply-to: <3.0.5.32.19981221162829.00923e90@openmail.lmf.ericsson.se> (message from Mikael Latvala on Mon, 21 Dec 1998 16:28:29 +0200) Subject: Re: Fast reconnect and CHAP References: <3.0.5.32.19981221162829.00923e90@openmail.lmf.ericsson.se> Sender: owner-ietf-ppp@merit.edu > Some questions and observations concerning fast reconnect and CHAP. > > 1. Isn't fast reconnect in conflict with RFC1994? RFC1994 says: > > "Each challenge value SHOULD also be unpredictable, least an attacker > trick a peer into responding to a predicted future challenge, and > then use the response to masquerade as that peer to an authenticator." No, it's not in conflict, and no, it doesn't prohibit the use of CHAP. The problem here is in the definition of "unpredictable." For CHAP to be secure, the challenge need only be unpredictable as long as you do not know the secret. If you know the secret, then this doesn't apply. One possible way of doing this would be, as Vernon Schryver has suggested, to compute the challenge as an MD5 hash of the previous challenge number, the secret, and the current time of day rounded to one or ten minute increments. (This is used only once and only if the last sequence was successful. Otherwise, a new random number is chosen.) Thus, a rogue peer cannot guess at a future challenges based on any history of the previous challenges, but the correct peer can. There are undoubtedly other ways to produce a secure hash. > Or is the idea to use fast reconnect only with LCP and NCP? In that case > the total RTT delay would be 1,5 (0,5 for LCP Conf-Request and Conf-Ack, > 0,5 for CHAP challenge, and 0,5 for CHAP response, NCP Conf-Request and > Conf-Ack). The total delay when fast reconnect works is still less than 1 RTT if all of the messages are preloaded by both sides, and is just 1 RTT if only one side is preloading. > 2. Mobility would introduce an extra 1 RTT delay when using fast reconnect. > RFC1994 says: > > "Since it is expected that the same secret MAY be used to authenticate with > servers in disparate geographic regions, the challenge SHOULD exhibit > global and temporal uniqueness." > > That means that each time a mobile device moves to a new area served by a > differrent access server its CHAP response prediction would fail. By including time-of-day in the hash, one easily gets temporal uniqueness. The other suggestion (it's not a requirement) -- global uniqueness -- can be enforced by transactions against a central database (clearing the "last challenge" field before transmitting the next computed challenge to the peer), but that's outside of the scope of any PPP document. You're right that the worst case results in falling back to normal negotiation. > 3. I was also wondering how L2TP's LAC handles fast reconnect. Has anybody > has used fast reconnect and L2TP together? What I am afraid of is that most > of the LACs will trow NCP, possibly also authetication packets away while > waiting for ICRP from LNS thus making fast reconnect more or less useless. That sounds like an implementation issue. If a LAC creates the tunnel only after doing LCP and starting authentication, then it may, at its option, save a queue of messages and pass them through when the tunnel is established. If it's lazy, then it can throw it away, and fast reconnect will fail. A LAC may also establish the tunnel completely before *any* PPP messages arrive, in which case fast reconnect should work. This is analogous to the implementation of ARP on Ethernet. If you have an unresolved ARP entry, then new packets to the same destination should be queued, at least to some limit. Throwing them away is usually bad form. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 10:55:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA13336; Mon, 21 Dec 1998 10:55:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 10:53:43 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA13290 for ietf-ppp-outgoing; Mon, 21 Dec 1998 10:53:43 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA13285 for ; Mon, 21 Dec 1998 10:53:39 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA10632 for ietf-ppp@merit.edu; Mon, 21 Dec 1998 10:53:38 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA14514 for ; Fri, 18 Dec 1998 17:04:49 -0500 (EST) Received: from juniper.net (bjorn.juniper.net [207.79.80.226]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id OAA13890; Fri, 18 Dec 1998 14:03:45 -0800 (PST) Message-ID: <367AD0DC.652D9827@juniper.net> Date: Fri, 18 Dec 1998 14:02:04 -0800 From: Bjorn Liencres X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: smerchant@cimaron.com, ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Shahrukh Merchant wrote: > > Contents: > -------- > 2. New Underflow code While it may appear simple to implement this as a framing feature, it has many system design implications. It means that a system with an OC192c interface has to cover the range of an effective input bandwidth from OC192c down to almost zero. This is very hard to do. I believe that the correct solution is that an implementation that purports to support OC192c must have enough bandwidth to finish a packet once it has started. In the very unlikely case that it cannot, it should abort the packet. > 3. Revised HDLC-32 payload scrambler proposed (formerly x^29+1) Binomials such as x^n+1 have the nice property that data can be recovered by knowing only the last n received bits. This implies that the sequence is not maximal. This is a feature, not a bug. If you make it maximal by choosing a trinomial, now both ends of a link must know the initial conditions, and correctly receive all data bits. This works on a perfect link, but not when errors are present. (There are ways around this, but the cure is worse than the disease.) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 13:38:23 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA16624; Mon, 21 Dec 1998 13:38:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 13:36:33 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA16561 for ietf-ppp-outgoing; Mon, 21 Dec 1998 13:36:33 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA16557 for ; Mon, 21 Dec 1998 13:36:27 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id LAA06293 for ietf-ppp@merit.edu env-from ; Mon, 21 Dec 1998 11:36:22 -0700 (MST) Date: Mon, 21 Dec 1998 11:36:22 -0700 (MST) From: Vernon Schryver Message-Id: <199812211836.LAA06293@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: fast connect Sender: owner-ietf-ppp@merit.edu This morning, Jim Carlson proposed a small modification to the fast-connect hack. That was including a time-stamp in the predicted CCP challenge hash to foil replay attacks. You must defend against replay attacks, but I think a timestamp is not best. Timestamps require clocks. All that is necessary is something to add enough entropy to the predicted challenge to make it impractical to replay or to predict. The main defense against predictability comes from the shared CHAP secret. A replay defense can come from including an incrementing counter in hash the generates the predicted challenge. One obvious choice of counter is the ID field of the previous challenge. For global uniqueness of the challenge to defend against Craig Fox's oracle attack either in the fast-connect hack or in ordinary CHAP, there are many mechanisms. One is a global database. Another that is sometimes practical is Craig's caller/callee indication. Yet another is including something in each challenge that identifies the challenge as originally coming from the the responder. If I were to use the fast-connect hack, I would also use regular CHAP re-challenges, starting very soon after the initial fast-connect burst. If I cared a lot about quick PPP connections, I would not merely use the fast-connect hack. I would also see about moving the Authenticate Phase into the Establish Phase. As we agreed before, it is unfortunate for several reasons that LCP must guess about the identity of the peer when it is negotiating. CHAP should have been some LCP options, although you might want to also retain the CHAP protocol packets for re-challenging later without disrupting NCP's. However, all of this is moot. In real life, PPP connections are either quicker to establish than the phone call or the bottlenecks are not in PPP. There are work-arounds, albeit painful and incomplete, for LCP not knowing either its own or the peer's identity until after it is finished. If PPP were to be started over, things would be different. There are insufficient reasons to start over, or even to suffer the inevitable instabilities and incompatilities of fixing those problems. Nothing is perfect, and PPP is good enough. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 15:10:27 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA18488; Mon, 21 Dec 1998 15:09:47 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 15:07:49 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA18438 for ietf-ppp-outgoing; Mon, 21 Dec 1998 15:07:48 -0500 (EST) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA18432 for ; Mon, 21 Dec 1998 15:07:41 -0500 (EST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 21 Dec 1998 15:07:07 -0500 Message-ID: <1180113EC576D011AADE0060975B88B33CA08B@neonet_server1.nexabit.com> From: Chuck Benz To: ietf-ppp@merit.edu Cc: smerchant@cimaron.com, Bjorn Liencres Subject: RE: PPP at STS-192c draft Date: Mon, 21 Dec 1998 15:07:05 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ietf-ppp@merit.edu Re: underflow code... Bjorn has pointed out that the ability to continuously 'stall'/'underflow' can reduce an interface input bandwidth to near zero, which might be difficult with some system designs. But HDLC already has this problem due to escapes - the bandwidth can already span 50% to 100% of the link bandwidth. Re: trinomial vs. binomial scramblers I don't think that the trinomial polynomial implies that initial state is necessary. Is my understanding of how to implement a multi-term self-synchronous descrambler wrong ? I would have expected that the added terms simply come from the same delay line, and get ex-or'ed with the incoming data. But Dennis's message does reflect a significant drawback of adding terms - error multiplication. This is a major point. (Besides, the binomial implementation is easier, especially when the bus width exceeds the feedback delay... BTW, for multi-term polynomials, higher order terms are easier... the low order terms end up echoing many more times...). \chuck benz > -----Original Message----- > From: Bjorn Liencres [SMTP:bjorn@juniper.net] > Sent: Friday, December 18, 1998 5:02 PM > To: smerchant@cimaron.com; ietf-ppp@merit.edu > Subject: Re: PPP at STS-192c draft > > > Shahrukh Merchant wrote: > > > > Contents: > > -------- > > > 2. New Underflow code > > While it may appear simple to implement this as a framing feature, > it has many system design implications. It means that a system > with an OC192c interface has to cover the range of an effective > input bandwidth from OC192c down to almost zero. This is very hard > to do. > > I believe that the correct solution is that an implementation > that purports to support OC192c must have enough bandwidth to finish > a packet once it has started. In the very unlikely case that it > cannot, > it should abort the packet. > > > 3. Revised HDLC-32 payload scrambler proposed (formerly x^29+1) > > Binomials such as x^n+1 have the nice property that data can > be recovered by knowing only the last n received bits. This > implies that the sequence is not maximal. This is a feature, > not a bug. > > If you make it maximal by choosing a trinomial, now both ends > of a link must know the initial conditions, and correctly receive > all data bits. This works on a perfect link, but not when errors > are present. (There are ways around this, but the cure is worse > than the disease.) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 16:19:22 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA20084; Mon, 21 Dec 1998 16:19:09 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 16:18:04 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA20026 for ietf-ppp-outgoing; Mon, 21 Dec 1998 16:18:04 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA20007 for ; Mon, 21 Dec 1998 16:17:46 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id QAA09406 for ietf-ppp@merit.edu; Mon, 21 Dec 1998 16:17:45 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: fast connect Date: 21 Dec 1998 16:17:45 -0500 Organization: IronBridge Networks Lines: 39 Message-ID: <86vhj5p53a.fsf@ironbridgenetworks.com> References: <199812211836.LAA06293@calcite.rhyolite.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu vjs@calcite.rhyolite.com (Vernon Schryver) writes: > This morning, Jim Carlson proposed a small modification to the fast-connect > hack. That was including a time-stamp in the predicted CCP challenge hash > to foil replay attacks. You must defend against replay attacks, but I > think a timestamp is not best. Timestamps require clocks. All that is As much as I'd like to take credit for the time-stamp hack, this was actually a suggestion of yours: >> Date: Wed, 12 Feb 1997 12:03:03 -0700 (MST) [...] >> A known random CHAP number does not need to be a constant CHAP number. >> If you use a constant, you hurt security because of a play-back attack. >> But you don't have to use a constant. You could use a secure PRNG, >> such as the MD5 hash of the shared secret, the previous randome number, >> and the time of day to within the nearest 10 minute. [...] I agree that it's a little dicey, though. The original question was about temporal uniqueness. Hashing with the time fixes that issue, though I don't think it needed to be fixed in the first place. > However, all of this is moot. In real life, PPP connections are either > quicker to establish than the phone call or the bottlenecks are not in > PPP. There are work-arounds, albeit painful and incomplete, for LCP > not knowing either its own or the peer's identity until after it is > finished. If PPP were to be started over, things would be different. > There are insufficient reasons to start over, or even to suffer the > inevitable instabilities and incompatilities of fixing those problems. > Nothing is perfect, and PPP is good enough. Quite true! Though that doesn't seem to slow down the folks bent on "improving" the connection delay. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 16:19:19 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA20074; Mon, 21 Dec 1998 16:18:45 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 16:15:23 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA19921 for ietf-ppp-outgoing; Mon, 21 Dec 1998 16:15:22 -0500 (EST) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA19917 for ; Mon, 21 Dec 1998 16:15:16 -0500 (EST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 21 Dec 1998 16:14:45 -0500 Message-ID: <1180113EC576D011AADE0060975B88B33CC335@neonet_server1.nexabit.com> From: Chuck Benz To: Dennis Ferguson Cc: ietf-ppp@merit.edu Subject: RE: PPP at STS-192c draft Date: Mon, 21 Dec 1998 16:14:43 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ietf-ppp@merit.edu 1. Amoung your first comments, Dennis, you point out that the dual scramblers multiply errors. This could be avoided by computing the CRC after the first scrambler. But this is also flawed, because bit errors can propagate into the descrambler state, as your next comments point out. 2. Those next comments reveal a near fatal problem with the dual scramblers, with bit errors turning idles into error-packets and propagating into the packet scrambler state. Some ways around it might be - send 'idle data' in between packets that is scrambled with the packet scrambler (x^29 or whatever) with yet another flag value that marks it as invalid data to be ignored, except for the synchronizer state. - send scrambler initial state before each packet. Feel free to denigrate both as hacks. I look forward to seeing other ideas - neither of these are pretty. 3. HDLC is octet aligned, and HDLC32 is also aligned, but I don't think that would preclude either from being used over raw fiber, by relying on an initial framing using flags to find and lock the alignment. 4. HDLC vs. SDL vs. HDLC32... there is a 'devil-we-know' vs. 'devil-we-don't-know' in this question. But your arguments do suggest that HDLC32 has some gotchas. \chuck > -----Original Message----- > From: Dennis Ferguson [SMTP:dennis@juniper.net] > Sent: Sunday, December 20, 1998 11:39 PM > To: smerchant@cimaron.com > Cc: ietf-ppp@merit.edu > Subject: Re: PPP at STS-192c draft > > Shahrukh, > > > 1. Choice of SONET payload scrambling polynomial > > ------------------------------------------------ > > You're right that x^43+1 is not maximal length (although "maximal > > length" is harder to define for a self-synchronous scrambler where > the > > next state is not just a function of the current state, but also of > the > > input). > > I think this is the key point. A self-synchronous scrambler is not an > LFSR, and doesn't produce a fixed, repeating output, so there is no > sequence whose length needs to be maximized. That is, adding the > extra > term to the x^43+1 (or x^29+1) scrambler does not increase the number > of states the scrambler can be in (all 2^43 or 2^29 states are > possible > in both cases), so adding the extra term doesn't make the precise > output > of the scrambler any harder to guess. > > Worse, what I think you're ignoring is the fact that self-synchronous > scramblers are error-multiplying and adding more terms just makes a > single bit error in the scrambled data turn into more errors after > descrambling. That is, a single bit error in the x^43+1 scrambled > payload turns into two bits in error after descrambling, one at the > location of the bit error and one 43 bits later (i.e. a single bit > error is turned into a 43 bit burst). Adding another term to the > scrambler increases the number of bits in error after descrambling to > 3, which is certainly not an improvement and is intuitively likely to > make things worse since error multiplication has implications for > error detection. > > The error multiplication is also the first objection I have to the > two nested scramblers you are suggesting. If you run the x^43+1 > scrambler over packet payload scrambled by the x^29+1 scrambler, then > a single bit transmission error in a packet turns into a 4 bit error > after descrambling; one at the location of the bit error, one 29 > bits later, one 43 bits later and one 72 bits later. If you add > a third term to packet scrambler, you now have a single bit error > causing 6 bits to be in error after descrambling. If you also add > a third term to the x^43+1 scrambler you end up with a single bit > tranmission error turning into 9 errored bits after descrambling. > You can't assume that this is without impact on error detection > performance of the FCS. As you note later, > > > the strength of the CRC from 32 to 30 bits." CRC codes typically > have > > properties like: > > > > - Detects all single bit errors > > - Detects all 2-bit errors for packet lengths <= P > > - Detects all burst errors for burst lengths <= Q > > - Detects (1-2^-N, N=32 in this case) of all multi-bit errors > > You are systematically ensuring that all transmission errors, even > single bit errors, will have a burst length of at least 72 bits with > at least 4 bits in error (6 bits with the extra term added to the > x^29... scrambler) by the time your FCS sees them. > > My more serious objection to the x^29... scrambler applied only to > packet data, however, is that for a given bit error rate on the > circuit > the use of the scrambler seems to me to cause the frame error rate to > increase with decreasing frame transmission rates. For normal HDLC, > without the use of any self-synchronous scrambler, a frame will be > errored > if a bit error occurs anywhere in the frame payload or in the > immediately > preceding or succeeding flags. The use of the x^43+1 scrambler > widens this window to 43 bits in front of the preceding flag, but > errors in the flags not immediately adjacent to the packet do not > cause errors in the packet. With your proposal, however, an error > anywhere in the flags between frames appears to cause the next frame > to > arrive to be dropped. That is, a bit error in the interpacket flags > will cause the flags to appear as packet data. The FCS protection > will likely cause this erroneous data to be dropped, but in the > process of doing so you will change the state of the x^29... > scrambler. > This means that when you do receive a valid frame you will cause > errors in the first 29 bits of the valid frame, causing it to be > dropped as well. Since erroneous state in the x^29... scrambler > will always persist until you receive (and damage) a valid frame, > the probability of dropping a frame will depend not only on the > length of the frame but also the number of flags preceding the frame. > If you've been receiving idle flags for a long time the probability > of damaging the next frame to arrive will approach unity. One could > argue that the expected bit error rate for SONET should be low > enough that this won't matter, but it strikes me as making the > framing unnecessarily fragile (it also seems to me the low error > rate argument might not necessarily apply at OC-192c either). > > So I have some reservations about the robustness of the packet > scrambler you suggest. More generally, however, I also think that > if we're to invent a new framing protocol for higher speeds, it is > worth while to make sure the scheme that is chosen gives us maximal > advantage. The one other alternative to this I've seen proposed is > SDL, from Lucent, which I also have some reservations about but which > strikes me as having distinct advantages over this. In particular: > > - Similar to octet-synchronous HDLC you depend on the SONET framing to > align the framing to 32-bit boundaries. SDL does not necessarily > depend on the SONET framing, an SDL framer could be built to deframe > a bit stream sent over the raw fiber. > > - Your basic per-frame overhead, at 8 bytes per frame (4 bytes of > flag, > 4 bytes of FCS) is the same as SDL, but you additionally pad by 0-3 > bytes for alignment and occasionally do transparency stuffing. SDL > does no stuffing and doesn't bother to pad the frame. SDL actually > could pad the frame, but I'd suggest that the implementation > complexity > of dealing with an odd number of bytes in a frame is not high; it > maybe doubles the (relatively small) amount of logic devoted to the > FCS computation. > > - SDL can also retain the 16-bit FCS, if this is worth anything, and > can also run reasonably with no FCS at all, which is not useful for > PPP but might be if the framed data includes error correction codes. > > - I think the real implementation complexity of HDLC at high speeds > comes > from stuffing for transparency. That is, bit-synchronous HDLC is > hard if you can't run your data path a bit at a time, and > octet-synchronous > HDLC is hard if you can't run your data path a byte at a time. > Similarly, > HDLC-32 is only easy if you can run your data path 4 bytes wide. At > OC-192c this means that HDLC-32 is only really easy at 311 MHz, > which > is more than a bit challenging with current technology and suggests > that > there'll be incentive to reinvent the framing protocol again if > speeds > beyond OC-192c become necessarily in the near term. SDL, on the > other hand, eliminates transparency stuffing and associated > complexity > altogether. This seems to me to be fundamentally more scalable, and > also permits one the possibility of doing really hard-core bandwidth > scheduling on a circuit, something that is made annoyingly imperfect > if your framer sometimes randomly grows packets by stuffing. > > - SDL makes sense at speeds lower than OC-192c, and potentially can > fix > the problems transparency stuffing causes there too. HDLC-32 is > less > attractive at lower speeds, so the stuffing problem remains (and it > seems to me that if the packet expansion due to stuffing is a > problem > worth fixing at OC-192c it is also a problem worth fixing at lower > speeds). > > - SDL doesn't use a self-synchronous scrambler, and hence doesn't > cause error multiplication. Even if you wanted to retain the use > of a self-synchonous scrambler to avoid SDL's scrambler state > exchange, however, you could probably do this better with SDL too > since SDL also doesn't send flags between packets; it instead sends > packets that you throw away, and these could always be made to carry > random data for the purpose of clearing errors out of the scrambler > before real packets arrive again. > > If we're going to respecify the framing protocol I'd rather do this > just once. It seems to me that SDL, or something more like SDL, might > be more likely achieve this than hacking at HDLC. Do you disagree? > > Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 16:19:17 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA20070; Mon, 21 Dec 1998 16:18:44 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 16:16:16 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA19954 for ietf-ppp-outgoing; Mon, 21 Dec 1998 16:16:15 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA19949 for ; Mon, 21 Dec 1998 16:16:11 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id QAA29553 for ietf-ppp@merit.edu; Mon, 21 Dec 1998 16:16:11 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA19580 for ; Mon, 21 Dec 1998 16:01:07 -0500 (EST) Received: from juniper.net (bjorn.juniper.net [207.79.80.226]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA26268; Mon, 21 Dec 1998 13:00:35 -0800 (PST) Message-ID: <367EB6B3.97721F2@juniper.net> Date: Mon, 21 Dec 1998 12:59:31 -0800 From: Bjorn Liencres X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Benz , ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft References: <1180113EC576D011AADE0060975B88B33CA08B@neonet_server1.nexabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Chuck Benz wrote: > > Re: underflow code... > > But HDLC already has this problem due to escapes - > the bandwidth can already span 50% to 100% of the link > bandwidth. True. But an effective bandwidth of greater than 50% (although still undesirable) is easier to deal with than greater than zero. > Re: trinomial vs. binomial scramblers > > I don't think that the trinomial polynomial implies that > initial state is necessary. I got confused here. As Dennis clarified, what is being proposed is a self-synchronous scrambler, not an LFSR. So maximal length does not apply. (It would on an LFSR, where it also matters whether it is a binomial or trinomial.) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 16:21:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA20210; Mon, 21 Dec 1998 16:21:32 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 16:20:41 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA20151 for ietf-ppp-outgoing; Mon, 21 Dec 1998 16:20:40 -0500 (EST) Received: from ns3.redbacknetworks.com (mail3.redbacknetworks.com [155.53.200.100]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA20141 for ; Mon, 21 Dec 1998 16:20:30 -0500 (EST) Received: from chef.redbacknetworks.com (chef.redbacknetworks.com [155.53.190.24]) by ns3.redbacknetworks.com (8.8.8/8.8.8) with ESMTP id NAA15382; Mon, 21 Dec 1998 13:19:58 -0800 (PST) Received: from RedBackNetworks.com (localhost [127.0.0.1]) by chef.redbacknetworks.com (8.8.8/8.6.9) with ESMTP id NAA05885; Mon, 21 Dec 1998 13:19:28 -0800 (PST) Message-Id: <199812212119.NAA05885@chef.redbacknetworks.com> To: Harischandra Shenoy R cc: "'louie@uu.net'" , "'ross@routerware.com'" , "'ietf-ppp@merit.edu'" Subject: Re: PPPoE clarifications reqd ... In-reply-to: Your message of "Mon, 21 Dec 1998 16:49:24 +0530." <01BE2D01.DEDA0580@auckland.future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5882.914275168.1@RedBackNetworks.com> Date: Mon, 21 Dec 1998 13:19:28 -0800 From: David Carrel Sender: owner-ietf-ppp@merit.edu > > (1) What is the exact frame that is transmitted from an AC to an ISP (and vic > e versa) ? Will it contain a PPPoE header that the ISP has to remove ? > If the frame is just an ethernet frame (without PPPoE) and if the source addr > ess is used by the ISP to determine the client, even then some minor mo > dification will be required to existing PPP software at ISPs so that th > ey can receive and demux ether frames (I presume that current implement > ations will demux based on some other LL id like CLID or port number). > Is this correct ? I believe you are thinking about this wrong. At the AC, PPP is either terminated or tunneled. ISP <------some network-----> AC <------PPPoE-------> Host This is no different than a RAS box doing PPP for a modem line. So whether the AC is doing PPPoE or PPP over ATM or PPP over serial to the host, the data passed upstream (ie to an ISP) is no different. ISP <------some network-----> RAS <--PPP over async---> PC > (2) The section on "Security Considerations", states : > > "Many Access Concentrators will not wish to offer information > regarding what services they offer to an unauthenticated entity. In > that case the Access Concentrator should employ one of two policies. > It SHOULD never refuse a request based on the Service-Name TAG, and > always return the TAG_VALUE that was sent to it. " > > It is not clear how this will help. A malicious client who wants to find out > the services offered by some particular AC can send several seperate PA > DIs to learn what all services an AC supports. Also, if an AC doest not > support a particular service name then it has to refuse a request for > that service. This is why the security Considerations section recommends this behavior if you wish to _not_ provide ANY information on services. If you respond back with whatever service you receive, then you leak no information. NONE. That means that you have turned off the service selection features. That is fine. Some environments do not need/want that feature. If you are disabling that feature, then you need not refuse a request based on a service request. To do so would be inconsistent. > (3) Should the services offered by an AC as well as the service(s) requested > by a client be prioritised ? For example, the draft says "When the Acc > ess Concentrator receives a PADI that it can serve..." (Page 5, section > 5.2) - is this an implementation specific decision or should there exi > st some standard way of saying that an AC can service a particular clie > nt ? > Similarly, when a client receives PADO packets from several ACs, all offering > similar services, then what is the criteria to select an AC ? There is certainly room for work in that area. Some means of prioritizing might be nice. I personally am looking for more implementation experience with this before defining further details. > (4) There is no description in the draft on how the client should respond whe > n it receives a packet with the AC-System Error tag. Is this an impleme > ntation-specific feature ? I would say this is implementation specific. > (5) Does "draft-carrel-info-pppoe-02.txt" (PPPoE) have any relation to "draft > -ietf-info-pppext-ether-00.txt" ? No. > In addition to the above, I would like to suggest that the draft is tilted to > wards a client only implementation of PPPoE. More details of how a PPPo > E AC should function and changes to existing PPP implementations at the > ISP need to be mentioned in the draft. This will reduce a lot of ambig > uity. There are no changes needed at an ISP. Can you come up with any specific changes you are looking for. I did an AC implementation based on this spec. I know of two client implementations based on this spec that interoperate. I know of one server implementation underway and another couple of client implementations underway. I think the confusion here is that you misunderstood where PPPoE exists in the topology. Dave ------------------------------------------------------------------ David Carrel carrel@RedBack.net RedBack Networks, Inc. (408) 548-3581 1389 Moffett Park Drive (408) 548-3599 <- FAX Sunnyvale, CA 94089-1134 ------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 18:55:51 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id SAA22611; Mon, 21 Dec 1998 18:55:32 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 18:54:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA22570 for ietf-ppp-outgoing; Mon, 21 Dec 1998 18:54:01 -0500 (EST) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA22566 for ; Mon, 21 Dec 1998 18:53:54 -0500 (EST) Received: from hpato.aus.hp.com (hpato.aus.hp.com [15.19.208.10]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id PAA16256; Mon, 21 Dec 1998 15:53:29 -0800 (PST) Received: from aus.hp.com (hpiw0184.aus.hp.com [15.19.208.166]) by hpato.aus.hp.com with ESMTP (8.7.6/8.7.3 TIS Messaging 5.0) id KAA16807; Tue, 22 Dec 1998 10:53:26 +1100 (EDT) Message-ID: <367EDF77.9DCCBD7B@aus.hp.com> Date: Tue, 22 Dec 1998 10:53:27 +1100 From: Stuart Wilson Organization: Hewlett Packard Australia Ltd (AND) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Benz CC: ietf-ppp@merit.edu, smerchant@cimaron.com, Bjorn Liencres Subject: Re: PPP at STS-192c draft References: <1180113EC576D011AADE0060975B88B33CA08B@neonet_server1.nexabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi all, I have a few generic comments to do with POS implementations. On Scrambling ------------- Stating the obvious, robust (ie: high order), scrambling is required in order to combat malicious damage to the SONET link. Even short runs of all 0's or all 1's bits on the link can degrade the clock recovery margins...if the link is already at maximum reach then corruption can occur. If the SONET reciever looses clock sync then the entire link will be lost for several seconds as SONET, LCP, IPCP & NCP et al. are re-established. In short, robust scrambling of user data is absolutely necessary. The move to align data to long word boundaries instead of octet boundaries is absolutely necessary at higher rates. The ability to use wide datapath implementations without octet stuffing problems significantly reduces implementation effort. In short, long word alignment is necessary at higher bandwidths (ie: OC-192). SONET links typically have very low intrinsic bit error rates. These can be WELL below the E-9 BER level for links with good margin. The effect of bit errors to higher layer protocols on SONET links will be low. Equivalently, multiplying errors by 2 or 3 will have a low impact on higher protocol layers, perticularly given that multiple bit errors will mostly be generated in the same packet. (In some cases an error at the end of one packet will be replicated into the following packet, which gets worse for shorter packets). In short, bit error multiplication is not the ogre it can be painted to be when considering SONET links. When designing scramblers for communications hardware, self synchronous scramblers (SSS) are desirable because they do not require external synchronisation sources. They are inherently simple, and as such are desirable. KISS....so long as the link BER is low and higher layer protocols are robust. In short, SSS keep design complexity down. SSS are not limited to single-tap polynomials (ie: X^43+1), but error multiplication does increase linearly with the number of taps, as mentioned. On Optional link parameters --------------------------- I can see no good reason why different FCS lengths, compression options and the like are required for any POS link. These merely complicate the implementation and offer NO real benefits. I will support any standard which reduces options to 1. Regards Stuart Wilson ------------------------------------------------------- Development Engineer Hewlett-Packard Australia Advanced Networks Division (AND) 347 Burwood Highway, Burwood East, VIC 3151 AUSTRALIA Phone: +61 3 9210 5621 Fax: +61 3 9210 5550, +61 3 9886 4037 Internet: stuart_wilson@aus.hp.com _/\_/\ / HP \ / AND \ \ __ / \/ \_*/ __ \/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 21 22:02:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id WAA24526; Mon, 21 Dec 1998 22:02:40 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Dec 1998 21:59:55 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA24469 for ietf-ppp-outgoing; Mon, 21 Dec 1998 21:59:55 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id VAA24465 for ; Mon, 21 Dec 1998 21:59:49 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id TAA14145 for ietf-ppp@merit.edu env-from ; Mon, 21 Dec 1998 19:59:48 -0700 (MST) Date: Mon, 21 Dec 1998 19:59:48 -0700 (MST) From: Vernon Schryver Message-Id: <199812220259.TAA14145@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft Sender: owner-ietf-ppp@merit.edu > From: Stuart Wilson > CC: ietf-ppp@merit.edu, smerchant@cimaron.com, > Bjorn Liencres > ... > occur. If the SONET reciever looses clock sync then the entire link > will be lost for several seconds as SONET, LCP, IPCP & NCP et al. are > re-established. > ... Let's not phrase things in ways that that might cause people who don't know about PPP to think that "LCP, IPCP, & NCP et al" in reasonable implementations require more than milliseconds to get re-established. As we all know, LCP, authentication, IPCP, and any number of other NCP's need at most a total of three (3) round trip times to be restored--of course, only after the physical link is working again. At the speeds you're talking about, I suspect you're talking about entirely terrestrial links, and so propagation delays for PPP frames of less than 70 milliseconds to get to the opposite side of the earth. Any PPP system that needs more than 3 speed-of-light round-trip delays to get all of PPP reestablished has problems that scramblers, CRCs, polynomials and so forth cannot help. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 22 12:04:17 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA03606; Tue, 22 Dec 1998 12:02:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Dec 1998 11:57:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA03401 for ietf-ppp-outgoing; Tue, 22 Dec 1998 11:57:00 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA03394 for ; Tue, 22 Dec 1998 11:56:54 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id LAA09563 for ietf-ppp@merit.edu; Tue, 22 Dec 1998 11:56:53 -0500 (EST) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA01808 for ; Tue, 22 Dec 1998 10:33:29 -0500 (EST) Received: from localhost by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id KAA20008; Tue, 22 Dec 1998 10:32:54 -0500 (EST) Date: Tue, 22 Dec 1998 10:32:54 -0500 (EST) From: "Andrew G. Malis" To: ietf-ppp@merit.edu cc: smerchant@cimaron.com Subject: Re: PPP at STS-192c draft In-Reply-To: <199812210438.UAA04115@wawa.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu In his note on error multiplication, Dennis brought up SDL for OC-192c. I thought it was somewhat "interesting" that there wasn't anyone from Lucent at the meeting to present it. Dennis noted at one point in his note that he has some reservations about SDL (before he went on to sing its praises :-). I also have some comments about SDL that I haven't seen discussed on the list, so I thought I might mention them briefly, in no particular order: While the basic per-packet overhead is similar between HDLC-32 and SDL, SDL also needs to transfer the scrambler state in a special 12 byte packet every 8 packets, which adds additional overhead (especially given the number of TCP ACK packets out there). SDL's main claim to fame is the fixed overhead, since there aren't escapes. It's always been my opinion that the expansion arguments are very overrated when looking at real-world traffic, especially since there's a large class of IP packets (TCP ACKs, as I mentioned above) that applications cannot maliciously manipulate to try to cause expansion to occur. HDLC-32's use of the inner scrambler obviates that threat as well, as does the increased use of encryption for IP VPNs. Service providers have operational experience with the X^43+1 scrambler, and don't have any issues with it. I also prefer the simplicity of self-synchronous scramblers. I also agree with some of the replies to Dennis' message noting that error multiplication isn't a major worry given SONET error characteristics. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-2074 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 22 16:35:23 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA09137; Tue, 22 Dec 1998 16:34:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Dec 1998 16:32:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA09006 for ietf-ppp-outgoing; Tue, 22 Dec 1998 16:31:59 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA08996 for ; Tue, 22 Dec 1998 16:31:39 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08677; Tue, 22 Dec 1998 16:31:03 -0500 (EST) Message-Id: <199812222131.QAA08677@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-pptp-07.txt Date: Tue, 22 Dec 1998 16:31:02 -0500 Sender: owner-ietf-ppp@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 : Point-to-Point Tunneling Protocol (PPTP) Author(s) : K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn Filename : draft-ietf-pppext-pptp-07.txt Pages : 54 Date : 16-Dec-98 This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-07.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-pptp-07.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-pptp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981222145008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pptp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pptp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222145008.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 22 23:59:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id XAA16524; Tue, 22 Dec 1998 23:59:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Dec 1998 23:56:36 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id XAA16440 for ietf-ppp-outgoing; Tue, 22 Dec 1998 23:56:35 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id XAA16435 for ; Tue, 22 Dec 1998 23:56:28 -0500 (EST) Received: from cheetah.juniper.net (cheetah.juniper.net [208.197.169.152]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id UAA03455; Tue, 22 Dec 1998 20:55:57 -0800 (PST) Received: from cheetah.juniper.net (localhost [127.0.0.1]) by cheetah.juniper.net (8.8.3/8.8.2) with ESMTP id UAA06740; Tue, 22 Dec 1998 20:55:57 -0800 (PST) Message-Id: <199812230455.UAA06740@cheetah.juniper.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: Chuck Benz cc: Dennis Ferguson , ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft In-reply-to: Your message of "Mon, 21 Dec 1998 16:14:43 EST." <1180113EC576D011AADE0060975B88B33CC335@neonet_server1.nexabit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Dec 1998 20:55:57 -0800 From: Ravi Cherukuri Sender: owner-ietf-ppp@merit.edu I was dabbling with this idea and thought I will throw it out there - Dennis' concern that bit errrors in flags would be recognized as packets is very much valid. A single bit error on the line in the location where a flag is being sent would be construed as an 8 byte packet (including CRC-32). This happens because of the error multiplication of the x^47+1 scrambler. I think this is the most unwanted phenomenon in the proposal. I can live with the extra per packet overhead. So, there could be a translation function that we use on the state of the x47+1 scrambler that would originate a 'key' for the x^29+1 scrambler. (I do not have complete knowledge in this subject, but this function is taking the 47 bit state and generating a 29 bit key somehow) At the start of transmission of a packet, take this key and use that to scramble the packet with x29+1 and perform transparency. This adds a bit of complexity in the sense that the packet pipeline and the x^47+1 scrambler state have to be matched. But this is a reasonably simple implementation. In this mechanism, if there were no bit errors within the proximity of start of a packet (atleast within 43 bits), a packet can be recovered without errors. How does it sound?? An additional comment I have is that we should leave the option of pad bytes to the user and not use it in length calculations. I like the original proposal of having 4 esc characters. Ravi Cherukuri - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 23 13:56:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA26403; Wed, 23 Dec 1998 13:52:38 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Dec 1998 13:46:11 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA26261 for ietf-ppp-outgoing; Wed, 23 Dec 1998 13:46:10 -0500 (EST) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA26257 for ; Wed, 23 Dec 1998 13:46:04 -0500 (EST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 23 Dec 1998 13:45:32 -0500 Message-ID: <1180113EC576D011AADE0060975B88B33D169C@neonet_server1.nexabit.com> From: Chuck Benz To: Ravi Cherukuri Cc: Dennis Ferguson , ietf-ppp@merit.edu Subject: RE: PPP at STS-192c draft Date: Wed, 23 Dec 1998 13:45:30 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ietf-ppp@merit.edu Coupling the start-of-packet state of the 2 scramblers does seem to solve Dennis' concern about inter-packet errors changing the packet scrambler state. Clever. A purist might argue that this violates a layered view of the scramblers. On a practical basis, this does require that both scramblers be implemented at the same pipeline stage on the transmitter/encoder, which does make for a fair amount of complexity, especially for wider implementations (i.e. HDLC32 with a 64 or 128 bit bus - the latter case has to worry about 2 packets in a single cycle). The idea is clever, but I'm not sure whether I like it or not. \chuck > -----Original Message----- > From: Ravi Cherukuri [SMTP:ravi@juniper.net] > Sent: Tuesday, December 22, 1998 11:56 PM > To: Chuck Benz > Cc: Dennis Ferguson; ietf-ppp@merit.edu > Subject: Re: PPP at STS-192c draft > > I was dabbling with this idea and thought I will throw it out there - > > Dennis' concern that bit errrors in flags would be recognized as > packets is very much valid. A single bit error on the line in the > location > where a flag is being sent would be construed as an 8 byte packet > (including > CRC-32). This happens because of the error multiplication of the > x^47+1 > scrambler. > > I think this is the most unwanted phenomenon in the proposal. I can > live > with the extra per packet overhead. > > So, there could be a translation function that we use on the state of > the x47+1 scrambler that would originate a 'key' for the x^29+1 > scrambler. > (I do not have complete knowledge in this subject, but this function > is > taking the 47 bit state and generating a 29 bit key somehow) > At the start of transmission of a packet, take this key and use that > to scramble > the packet with x29+1 and perform transparency. > > This adds a bit of complexity in the sense that the packet pipeline > and > the x^47+1 scrambler state have to be matched. But this is a > reasonably > simple implementation. > > In this mechanism, if there were no bit errors within the proximity > of start of a packet (atleast within 43 bits), a packet can be > recovered > without errors. > > How does it sound?? > > An additional comment I have is that we should leave the option of pad > bytes > to the user and not use it in length calculations. I like the original > proposal of having 4 esc characters. > > Ravi Cherukuri > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 23 14:03:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id OAA26617; Wed, 23 Dec 1998 14:01:06 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Dec 1998 14:00:07 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA26563 for ietf-ppp-outgoing; Wed, 23 Dec 1998 14:00:07 -0500 (EST) Received: from adtrn-srv1.adtran.com (mailin.adtran.com [206.166.249.110]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA26551 for ; Wed, 23 Dec 1998 13:59:57 -0500 (EST) Received: from shannon.adtran.com (shannon.adtran.com [172.22.16.9]) by adtrn-srv1.adtran.com (8.8.8/8.8.8) with SMTP id MAA19039 for ; Wed, 23 Dec 1998 12:59:23 -0600 (CST) Received: by shannon.adtran.com (SMI-8.6/SMI-SVR4) id NAA29857; Wed, 23 Dec 1998 13:03:29 -0600 From: sventers@adtran.com (Stuart Venters) Message-Id: <199812231903.NAA29857@shannon.adtran.com> Subject: Re: PPP at STS-192c draft To: ietf-ppp@merit.edu Date: Wed, 23 Dec 1998 13:03:28 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Greetings, This is a BOF call for people interested in designing a new protocol to replace HDLC. It looks like from recent transactions on this reflector that there might be others interested in this. I would propose that perhaps the OC-192 design could evolve into a this? For some time I have thought that the communications world could use a replacement for bit-synchronous HDLC (HDLC-BIT). This protocol has been remarkable in that it has served for many years over multiple orders of magnitude of link bandwidth and error rate. It's primary attributes seem to be: 1) Simplicity 2) Frugality with bits over a wide set of operating conditions. 3) In the public domain 4) It gets used because it is what is being used. I think that the additional features that a replacement needs to add are: 5) Operates in byte and bigger modes for byte oriented links and higher speeds. 6) Supports the ability to insert a small packet in the middle of a big one on slower links. (Think of the shenanigans going on in the voice over frame relay and other similar arenas .) (A first step would be to poll if this is the right feature list.) It looks like the PPP Byte-synchronous HDLC (HDLC-BYTE) is a partial step in this direction but apparently suffers in the area of frugality for certain data patterns. The HDLC-32 proposal is moving in a direction to fix this problem with the addition of the inner scrambler. (Future evolutions might be the definition of how to use some of the extra code points to support packet insertions and perhaps an HDLC-16 variant?) It looks like the current architecture of SDL would not support the packet insertions. As I said before, I am curious to see if there are like minded folks out there. Cheers, Stuart Venters p.s. Perhaps it could be called BUN after HAL. (or not) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 23 16:24:34 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA29110; Wed, 23 Dec 1998 16:24:02 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Dec 1998 16:21:17 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA29039 for ietf-ppp-outgoing; Wed, 23 Dec 1998 16:21:17 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA29034 for ; Wed, 23 Dec 1998 16:21:09 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id QAA27652 for ietf-ppp@merit.edu; Wed, 23 Dec 1998 16:21:07 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: PPP at STS-192c draft Date: 23 Dec 1998 16:21:07 -0500 Organization: IronBridge Networks Lines: 72 Message-ID: <86u2ym5zcs.fsf@ironbridgenetworks.com> References: <199812231903.NAA29857@shannon.adtran.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu sventers@adtran.com (Stuart Venters) writes: > I think that the additional features that a replacement > needs to add are: > 5) Operates in byte and bigger modes for byte > oriented links and higher speeds. > 6) Supports the ability to insert a small packet in > the middle of a big one on slower links. (Think > of the shenanigans going on in the voice over > frame relay and other similar arenas .) Those two requirements would seem to be in opposition. You need a nicely parallelizing protocol in order to run at higher speeds. That argument seems appropriate for SONET/SDH. You may need preemption capability in order to run at lower speeds. That argument seems to hold for modem links. It's hard to think of a situation where the complexity of handling *BOTH* of these requirements at the same time is desirable. (I don't think I'd reject out of hand a solution that happens to do both, but it doesn't seem like a good thing to require both at the git-go.) > It looks like the PPP Byte-synchronous HDLC (HDLC-BYTE) > is a partial step in this direction but apparently > suffers in the area of frugality for certain data patterns. > > The HDLC-32 proposal is moving in a direction to fix this > problem with the addition of the inner scrambler. > (Future evolutions might be the definition of how to > use some of the extra code points to support packet > insertions and perhaps an HDLC-16 variant?) I think that both of these are misguided at best. If RFC 1662 O-S HDLC is hard to do at high speed, then the new HDLC-32 buys you only a factor of four in complexity reduction. That's just one generation of SDH technology, and probably only a couple of months in terms of Internet bandwidth growth. If you have to go wider than 32 bits, then you're back in the same boat, and you're dealing with variable-sized chunks again. Things that expand on output and contract on input are tough to deal with in programmable logic, since they generally require lots of byte-steering logic, intermediate registers, and maskable CRC generation. > It looks like the current architecture of SDL would not support > the packet insertions. Certainly true. I wouldn't argue that SDL is a good idea at low speeds. Like HDLC-32, the intent is to do something that works better at high speeds. Although I wrote the draft for using PPP over SDL, I would say that I agree that it's a little too complicated. The A/B messages look and smell too much like FDL, when I'd rather do my in-band link monitoring with LQM and management with SNMP. Bill Simpson's earlier "Ether-like framing" proposal was similar to SDL, but didn't include the error recovery mechanisms and analysis that SDL does. (I tried to contact Bill about co-authoring this, but he's apparently been off the air for quite a while.) One of its beauties of SDL is that it's highly scalable. All of the algorithms it uses can be parallelized in hardware at any word width you'd like, and do not involve complex variable-length blocks. That's not true of any code-stuffing techniques. > As I said before, I am curious to see if there are like > minded folks out there. Sure; I think we do need to have some discussion about this. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 23 16:34:48 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA29428; Wed, 23 Dec 1998 16:34:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Dec 1998 16:33:53 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA29398 for ietf-ppp-outgoing; Wed, 23 Dec 1998 16:33:52 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA29391 for ; Wed, 23 Dec 1998 16:33:42 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id QAA01559 for ietf-ppp@merit.edu; Wed, 23 Dec 1998 16:33:36 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: PPP at STS-192c draft Date: 23 Dec 1998 16:33:35 -0500 Organization: IronBridge Networks Lines: 62 Message-ID: <86soe65ys0.fsf@ironbridgenetworks.com> References: NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu amalis@casc.com ("Andrew G. Malis") writes: > In his note on error multiplication, Dennis brought up SDL for OC-192c. > I thought it was somewhat "interesting" that there wasn't anyone from > Lucent at the meeting to present it. I would have liked to be there to present it, but the recent birth of my son prevented that. I hope to be there with some Lucent folks for another meeting. > While the basic per-packet overhead is similar between HDLC-32 and SDL, > SDL also needs to transfer the scrambler state in a special 12 byte > packet every 8 packets, which adds additional overhead (especially > given the number of TCP ACK packets out there). Actually, no, it doesn't *need* to send it every 8 packets. That's the default configuration for the current design that they've got in the TDAT device. In fact, this special message could be sent every 100 or 10,000 packets, depending on operational experience. The rest of the protocol is well characterized, but this part is just engineering guess at this time. (My guess is that the right insertion rate for state vectors is measured not in packets, but in seconds. Scrambler desynchronization won't happen any faster or slower if the packets are bigger or smaller. It will occur due to transmission problems, which are failures in time.) > SDL's main claim to fame is the fixed overhead, since there aren't > escapes. It's always been my opinion that the expansion arguments are > very overrated when looking at real-world traffic, especially since > there's a large class of IP packets (TCP ACKs, as I mentioned above) > that applications cannot maliciously manipulate to try to cause > expansion to occur. HDLC-32's use of the inner scrambler obviates that > threat as well, as does the increased use of encryption for IP VPNs. Yes, one of SDL's claims to fame is the fixed-overhead issue. You're quite right that there are other ways to limit expansion to small values. Probably a more important issue is the zero data expansion nature of SDL. The difference between zero and little is not important if you're looking at the effective link bandwidth. But it is very important if you're looking at the hardware necessary to implement it. Since SDL neither expands nor contracts the data, it's very easy to deeply pipeline an SDL implementation and to parallelize it at and bus width desired. This is not true of any code-stuffing technique, including HDLC-32. STS-192c may be simple 311MHz logic for HDLC-32, but it'll be very hard when we have to do STS-768c. > Service providers have operational experience with the X^43+1 > scrambler, and don't have any issues with it. I also prefer the > simplicity of self-synchronous scramblers. I agree with that. I'd prefer a solution using a self-synchronous scrambler, despite the possible error multiplication problem, since the error recovery is so trivial. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 24 12:48:38 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA10897; Thu, 24 Dec 1998 12:47:32 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 24 Dec 1998 12:39:19 -0500 Received: by merit.edu (8.9.1a/8.9.1) id MAA10784 for ietf-ppp-outgoing; Thu, 24 Dec 1998 12:39:18 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA10780 for ; Thu, 24 Dec 1998 12:39:15 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id MAA24439 for ietf-ppp@merit.edu; Thu, 24 Dec 1998 12:39:14 -0500 (EST) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA27704 for ; Wed, 23 Dec 1998 14:59:53 -0500 (EST) Received: from localhost by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id OAA04895; Wed, 23 Dec 1998 14:59:12 -0500 (EST) Date: Wed, 23 Dec 1998 14:59:12 -0500 (EST) From: "Andrew G. Malis" To: Stuart Venters cc: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft In-Reply-To: <199812231903.NAA29857@shannon.adtran.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Stuart, > This is a BOF call for people interested in designing a new > protocol to replace HDLC. I think this is a bit premature. Let's continue to discuss OC192c+ on this list and see how we're doing around mid February. Unless we get a huge number of drafts, we should continue this in the PPPext WG meeting. The posse BOF last year was called just because there was enough to discuss that it overflowed the PPPext agenda. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-2074 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 24 15:08:21 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA12451; Thu, 24 Dec 1998 15:08:08 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 24 Dec 1998 15:06:50 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA12413 for ietf-ppp-outgoing; Thu, 24 Dec 1998 15:06:50 -0500 (EST) Received: from smtp-2.mdc.net (smtp-2.mdc.net [209.251.64.26]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA12409 for ; Thu, 24 Dec 1998 15:06:42 -0500 (EST) Received: from cimaron.com (xcom-78-170.mdc.net [209.251.78.170]) by smtp-2.mdc.net (8.9.1/8.9.1) with SMTP id PAA27580 for ; Thu, 24 Dec 1998 15:02:22 -0500 (EST) (envelope-from smerchant@cimaron.com) Received: from cimaron.com [2.1.1.11] by cimaron.com [2.1.1.7] with SMTP (MDaemon.v2.7.SP1.R) for ; Thu, 24 Dec 98 14:59:20 -0500 Message-ID: <36829CAB.FE48F7FF@cimaron.com> Date: Thu, 24 Dec 1998 14:57:31 -0500 From: Shahrukh Merchant Organization: Cimaron Communications Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft References: <199812081516.JAA02307@shannon.adtran.com> <36759302.3B03C7B1@cimaron.com> <367AD063.22E65B45@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ietf-ppp@merit.edu Reply-To: smerchant@cimaron.com Sender: owner-ietf-ppp@merit.edu Various responses and comments ... 1. Underflow code usage 2. Eliminating the effect of scramblers on CRC weakness caused by error multiplication 3. Eliminating the cumulative effect of sporadic bit errors on flags from zapping the next packet 4. Points about SDL 1. Underflow code usage ----------------------- Bjorn Liencres doesn't want underflow codes since they essentially imply that the time it could take a receiver to complete receiving a packet is unbounded. I can certainly see the potential complexities that it may introduce (beyond the framing where it's not difficult to deal with). Bjorn's comments also imply an opinion (as some others opined in Orlando in "hallway discussions") that a "good switch/router wouldn't need to use underflow codes anyway." I don't think we've heard a definitive rationale for why they should be there (beyond a "just in case"). Chuck, you had proposed additing this feature--can you provide some arguments on the "pro" side of keeping it? In general, are there architectures that people are working on that DO require it, where underflows could occur (and SHOULD occur) too regularly to rely on aborting? 2. Effect of scramblers on error multiplication ----------------------------------------------- Dennis Ferguson points out that the x^29[+x^2]+1 self-synchronous scrambler contributes to error multiplication, particulary when cascaded with the x^43+1 SONET payload scrambler, and hence could weaken the error detection capability of the CRC-32. This is a valid point, but addressable at several levels. Most simply, as Chuck Benz proposes, the CRC should be computed (and checked) on the SCR-29 scrambled data, which does not eliminate the error multiplication (less of a factor at expected SONET BER rates as Stuart Wilson and Andrew G. Malis point out, and it affects adjacent packets in only a small fraction of those cases anyway), but does take care of its potentially adverse effect on the CRC. Now, that leaves the error multiplication caused by the x^43+1 SONET payload scrambler. This really serves a different purpose which I mentally associate more with the SONET layer. Firstly, one should determine what fraction of 2-bit errors spaced 43 bits apart CRC-32 will detect (I will repeat my appeal to those who have knowledge of references to a characterization of this specific polynomial to share that with the list and save us work in recharacterizing it!)--if this is 100% then I think it's a non-issue. If it's not 100% then perhaps we should re-evaluate using the x^43+1 scrambler (as some did earlier when they wondered if it was redundant). Despite my advocating treating the two scramblers separately and keeping both in an earlier e-mail, HDLC-32, especially with the more robust SRC-29, doesn't really need it for transparency security reasons. So the issue of using the x^43+1 or not is really orthogonal to the core HDLC-32 proposal (unless it is shown that the SCR-29 is insufficient). 3. Eliminating the cumulative effect of sporadic bit errors on flags -------------------------------------------------------------------- Dennis Ferguson also identifies an interesting phenomenon which is particularly undesirable at low packet rates, whereby even rare bit errors in flags make them look like short packets. Even though those short packets will be almost certainly discarded owing to bad CRC, they will have corrupted the SCR-29 state, and this will kill the next packet too. In cases of very low packet rate, the packet loss rate could be much higher than the BER. Although some might argue that even this phenomenon is minimal owing to low BER, I agree with Dennis and others (Chuck Benz , Ravi Cherukuri ) that this is Not A Good Thing owing to its cumulative nature (and since it is not hard to cure, one should cure it!). Chuck Benz's idea of using idle packets works quite well I think (even though he modestly--and unnecessarily--self-denigrates it as "not pretty" :-). To fill in a little detail, we could have a 2-word idle packet (4 words total including flags) comprising: Flag-I DummyData CRC-32 Flag0 where the now 5 possible flag values distinguished by the 6 LSBs (in order to keep a 3-4 Hamming distance between them): 001100=Flag0, 010001=Flag1, 011010=Flag2, 000111=Flag3, 101011=Flag-I DummyData could be, for instance, a 32-bit packet counter (mod 2^32) or some other 32-bit dummy value. There are no loss-of-bandwidth implications since this is only sent, by definition, when there is no "real" data to be sent anyway. [Ravi has a clever alternative suggestion of deriving a deterministic 29-bit "key" from a fixed position relative to the start of the packet, and using it to initialize the SCR-29 scrambler state. While it is an interesting suggestion, there are 2 difficulties I see with it: (1) It results in excessive dependency on a lower layer to make the higher layer functional. HDLC-32 can otherwise stand alone and be transported over other physical layers than SONET, and this creates too tight a dependency between the two layers to the point that they would almost need to be treated as one--not desirable, I feel. (2) Although the implementation is conceptually simple, I think there would be difficulties in an actual implementation owing to the processing that happens between the two scramblers and the fact that some of that processing is not known until after you decode the data. For instance, in the Rx direction you could feed forward the SCR-43 descrambler state so that it was always available whenever the packet started, so serve as a seed for the SCR-29 descrambler. However, in the Tx direction, that would mean needing to precompute what the SCR-43 scrambler state *would be* some words hence in order to perform the SCR-29 ... but you don't know until after SCR-29 whether you would need to do stuffing for instance. (And even without the stuffing there would be sufficient pipeline stages to make it somewhat messy, I suspect, esp. since 43-bit and 29-bit states don't line up very well either to each other or to 32-bit words.)] 4. Points about SDL ------------------- SDL introduces some good ideas, certainly. One of the primary issues in my mind with its suitability as an HDLC replacement, however, is its fundamental reliance on a packet length field (which is furthermore hard-coded to 16 bits max). This means that you have to know the packet length a priori--this perhaps *is* known for some combinations of system architectures, functional partitioning and protocol support, but certainly would appear to make it less general purpose and architecture-specific (or more architecture-limiting, depending on how you look at it). The alternative is that you would have to buffer a whole packet's worth of data to determine the packet length in the PHY device, before you could transmit it, which is even less desirable. As far as implementation, my initial reaction to SDL was that it appeared considerably more complex to implement--I'm not convinced on arguments that the stuffing in HDLC-like implementations are fundamentally so much more difficult than anything else that they would outweigh all the other complexities of SDL (assuming one isn't trying to fit one approach into an architecture that's been optimized for another). I don't intend to make this an "SDL vs. HDLC-32" thing (HDLC-32 was proposed independently of SDL, rather than as a response to it), but I should clarify some points to avoid any misconceptions of HDLC-32: Dennis Ferguson says: > - Similar to octet-synchronous HDLC you depend on the SONET framing to > align the framing to 32-bit boundaries. SDL does not necessarily > depend on the SONET framing, an SDL framer could be built to deframe > a bit stream sent over the raw fiber. There actually isn't a dependency on SONET. *Given* transport over SONET (which is what the proposal was addressing), I pointed out that you get 32-bit alignment for free, without needing to do word alignment for HDLC-32. HDLC-32, as others have pointed out, can be framed on even if it is carried directly over fibre or over bit-serial protocols, by using the common 26-bit portion of the Flag words (more if you're willing to decode a few extra bits)--this is actually simpler and more robust than an ATM-like check on a 16-bit HEC. (The rest of the data are scrambled or otherwise randomized so they wouldn't emulate these Flags with any significant probability.) > SDL does no stuffing and doesn't bother to pad the frame.... > SDL can also retain the 16-bit FCS, if this is worth anything, and > can also run reasonably with no FCS at all... Of course, HDLC-32 or any other protocol could have all those options as well (and too many, unfortunately, do ...). In HDLC-32, these have been *deliberately* eschewed to remove low-payback features for simplicity of implementation (keeping things on 32-bit boundaries and eliminating different modes and combinations of modes). > SDL, on the > other hand, eliminates transparency stuffing and associated complexity > altogether. This seems to me to be fundamentally more scalable, and > also permits one the possibility of doing really hard-core bandwidth > scheduling on a circuit, something that is made annoyingly imperfect > if your framer sometimes randomly grows packets by stuffing. Owing to the payload scrambling in HDLC-32, the stuffing will be in the noise (2^-24) and should not affect bandwidth scheduling in any material way. Perhaps I'm missing something, but I don't see the scalability arguments applying more to transparency stuffing than to everything else that makes this a non-trivial exercise by whatever means (the best we can do is to reduce the complexity, not eliminate it). > - SDL makes sense at speeds lower than OC-192c, and potentially can fix > the problems transparency stuffing causes there too. HDLC-32 is less > attractive at lower speeds, so the stuffing problem remains (and it > seems to me that if the packet expansion due to stuffing is a problem > worth fixing at OC-192c it is also a problem worth fixing at lower > speeds). Again, I don't see why HDLC-32 might seem less attractive than SDL (or to itself) at lower speeds (than STS-192c); however, my main issue is that I really believe than only plain-old HDLC (RFC 1662) makes sense at lower rates, because it is already established! Anything that wanted to replace the existing infrastructure (or even existing momentum) with a new protocol would need to have a pretty high burden of proof that the cost of doing so was justified (or even that the pain of having to support 2 protocols at the same rate for the same thing was justified). The sense of the community is to eliminate options (e.g., CRC-16 vs. CRC-32, compression/no compression) where possible, otherwise you always end up needing to support every possible combination. That is why HDLC-32 has been positioned for STS-192c--it works very nicely for STS-48c too (and STS-12c as well, for that matter) but there are already too many RFC1662 implementations out there at those rates. (Though HDLC-32 would certainly be applicable for packet-over-fiber at these lower rates too, if and when that becomes deployed, since there isn't an existing infrastructure there.) Shahrukh -- Shahrukh Merchant Director, Systems Engineering and Verification Cimaron Communications Corporation Phone: +1 978 623-0009 Ext 3020 Fax: +1 978 623-0024 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Dec 26 10:53:21 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id KAA26048; Sat, 26 Dec 1998 10:49:42 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sat, 26 Dec 1998 10:44:32 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA26001 for ietf-ppp-outgoing; Sat, 26 Dec 1998 10:44:32 -0500 (EST) Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.200.16]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA25997 for ; Sat, 26 Dec 1998 10:44:22 -0500 (EST) Received: from cabo-1 (dienstmann.informatik.uni-bremen.de [134.102.218.46]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id QAA16798; Sat, 26 Dec 1998 16:43:06 +0100 (MET) From: " Dr. Carsten Bormann" To: "Stuart Venters" , Cc: Subject: RE: PPP at STS-192c draft Date: Sat, 26 Dec 1998 16:44:27 +0100 Message-ID: <002601be30e6$9f057960$72d96686@cabo-1.tzi.org> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal In-reply-to: <199812231903.NAA29857@shannon.adtran.com> Sender: owner-ietf-ppp@merit.edu > For some time I have thought that the communications world > could use a replacement for bit-synchronous HDLC (HDLC-BIT). [...] > 5) Operates in byte and bigger modes for byte > oriented links and higher speeds. > 6) Supports the ability to insert a small packet in > the middle of a big one on slower links. (Think > of the shenanigans going on in the voice over > frame relay and other similar arenas .) I believe there is no need for a protocol that solves both problems at the same time. As others have pointed out, suspend/resume capability is counterproductive on the upward scalability side (and totally useless on a link where an MTU-size packet goes through in a microsecond or so). I also would like to point out that suspend/resume is a solved problem for traditional PPP framing: draft-ietf-issll-isslow-04.txt draft-ietf-issll-isslow-mcml-04.txt draft-ietf-issll-isslow-rtf-03.txt These drafts already have finished working group last call. > It looks like the PPP Byte-synchronous HDLC (HDLC-BYTE) > is a partial step in this direction but apparently > suffers in the area of frugality for certain data patterns. If you want to renovate the PPP byte-sync format for predictable performance but retain most of its efficiency, please also look at draft-ietf-pppext-cobs-00.txt Stuart Cheshire and I have designed a way to include RTF style suspend/resume functionality in COBS; this could be in the next version of the draft. Gruesse, Carsten - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 28 09:10:43 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA13906; Mon, 28 Dec 1998 09:09:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Dec 1998 08:59:33 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id IAA13763 for ietf-ppp-outgoing; Mon, 28 Dec 1998 08:59:33 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id IAA13759 for ; Mon, 28 Dec 1998 08:59:26 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id IAA25083 for ietf-ppp@merit.edu; Mon, 28 Dec 1998 08:59:25 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: PPP at STS-192c draft Date: 28 Dec 1998 08:59:25 -0500 Organization: IronBridge Networks Lines: 121 Message-ID: <86btkonz9e.fsf@ironbridgenetworks.com> References: <36829CAB.FE48F7FF@cimaron.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu smerchant@cimaron.com (Shahrukh Merchant) writes: > 1. Underflow code usage > ----------------------- [...] > In general, are there architectures that people are working on that DO > require it, where underflows could occur (and SHOULD occur) too > regularly to rely on aborting? It depends on the distribution of sojourn times in the system. If the distribution has a heavy tail -- and it's easy to imagine a system where it does -- then no reasonable amount of buffering can accomodate the variance of latency. In this case, you have to choose either to discard the packet (7D 7E in old O-S HDLC), or attempt to fill time (7D 7D or 7D 20 on some controllers). I'll admit that I'm not at all sure whether termination or filling is the right answer (or even that there is a right general answer). It's certainly nice to have the option, though, since it's likely to be useful in *some* systems. I would assume that since everyone working on these high-speed systems is doing extensive event simulation and mathematical modeling, that results on these things do exist, but I doubt that anyone is going to talk about such things publicly. (At least for a while. ;-}) > 4. Points about SDL > ------------------- > SDL introduces some good ideas, certainly. One of the primary issues in > my mind with its suitability as an HDLC replacement, however, is its > fundamental reliance on a packet length field (which is furthermore > hard-coded to 16 bits max). This means that you have to know the packet > length a priori--this perhaps *is* known for some combinations of system > architectures, functional partitioning and protocol support, but > certainly would appear to make it less general purpose and > architecture-specific (or more architecture-limiting, depending on how > you look at it). The alternative is that you would have to buffer a > whole packet's worth of data to determine the packet length in the PHY > device, before you could transmit it, which is even less desirable. Unless you know the packet length well before transmission is attempted, you're in a world of trouble in attempting to implement either RED or WFQ. I would assume that any system working at these speeds already has this data available, and I'd be very surprised to find otherwise. I agree that the packet's length of buffering would be suboptimal, and that the SDL 16 bit length field is annoying. Fortunately, IPv4 also has a 16 bit maximum, and Ethernet has an MTU of 1500, and both of those look like they will be with us for a very long time and will be limiting factors. > As far as implementation, my initial reaction to SDL was that it > appeared considerably more complex to implement--I'm not convinced on > arguments that the stuffing in HDLC-like implementations are > fundamentally so much more difficult than anything else that they would > outweigh all the other complexities of SDL (assuming one isn't trying to > fit one approach into an architecture that's been optimized for > another). Well, if that were true, then doing regular octet-synchronous (O-S) HDLC -- byte stuffing -- wouldn't be a problem and HDLC-32 wouldn't be needed at all. However, byte-stuffing *is* a problem at high speed due to both the expansion on transmission and the compression on reception. When designing a hardware pipeline, doesn't matter how often or how much the data expands or contracts. All that matters is that it *does*; that alone is sufficient to create the complexity seen in O-S implementations. As I said before, HDLC-32 just gives you an extra factor of four in complexity reduction. If that's enough of a reduction that we don't need to revisit this topic again in the next year in order to do HDLC-128, then I guess I like the idea because of its simplicity. But I'm not so sure that we won't be doing this all over again while the innumerate majority celebrate the end of their millennium. (:-<) I don't like the complexity of SDL, but I do like the scalability. > I don't intend to make this an "SDL vs. HDLC-32" thing (HDLC-32 was > proposed independently of SDL, rather than as a response to it), but I > should clarify some points to avoid any misconceptions of HDLC-32: We are, I think, trying to scale the link-layer to grow with higher speeds. Whether it's intentional or not, both SDL and HDLC-32 (along with Bill Simpson's "Ether-like framing") attempt to address this, and I think comparisons are fair. > > SDL, on the > > other hand, eliminates transparency stuffing and associated complexity > > altogether. This seems to me to be fundamentally more scalable, and > > also permits one the possibility of doing really hard-core bandwidth > > scheduling on a circuit, something that is made annoyingly imperfect > > if your framer sometimes randomly grows packets by stuffing. > > Owing to the payload scrambling in HDLC-32, the stuffing will be in the > noise (2^-24) and should not affect bandwidth scheduling in any material > way. Perhaps I'm missing something, but I don't see the scalability > arguments applying more to transparency stuffing than to everything else > that makes this a non-trivial exercise by whatever means (the best we > can do is to reduce the complexity, not eliminate it). The point here is the difference between not stuffing at all and having any stuffing, no matter how improbable. Any system that requires code stuffing necessarily has a fundamental scaling problem. This is easy to see in O-S HDLC; as you go wider than a byte, you need a complex system of multiplexors and registers to paste the data back together. The same will happen with HDLC-32 if the data path widens beyond 32 bits. The same is not true of SDL. > Again, I don't see why HDLC-32 might seem less attractive than SDL (or > to itself) at lower speeds (than STS-192c); however, my main issue is > that I really believe than only plain-old HDLC (RFC 1662) makes sense at > lower rates, because it is already established! Anything that wanted to I agree. We should keep the existing protocols where we can for compatibilities' sake, at least for purposes of discussion. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 28 11:26:07 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA15539; Mon, 28 Dec 1998 11:25:24 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Dec 1998 11:23:48 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA15511 for ietf-ppp-outgoing; Mon, 28 Dec 1998 11:23:47 -0500 (EST) Received: from mlsrv1.avici.com ([208.153.76.9]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA15507 for ; Mon, 28 Dec 1998 11:23:40 -0500 (EST) Received: from gwaters-pc (gwaters-pc.avici.com [10.1.1.169]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id LAA06553 for ; Mon, 28 Dec 1998 11:22:25 -0500 (EST) Message-Id: <3.0.3.32.19981228112145.00942a20@mailhost.avici.com> X-Sender: gwaters@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 28 Dec 1998 11:21:45 -0500 To: ietf-ppp@merit.edu From: Greg Waters Subject: Re: PPP at STS-192c draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Two points... I'll echo this from James Carlson: >Unless you know the packet length well before transmission is >attempted, you're in a world of trouble in attempting to implement >either RED or WFQ. Cut-through packet switching was valuable for 10-Mbit/s Ethernet, and for computer-cluster interconnections at 100 Mbit/s. Cut-through switching is irrelevant for high-speed WANs. RED, WFQ and transparent PPP framing are more valuable than deferring packet length determination. (Both IPv4/6 and the IEEE 802.3 format of Ethernet has the packet's length in front, so the hardware implications are familiar to most.) Secondly, about 16-bit length in SDL: Recall that SDL defines CRC-32, for which packets over some 11 kBytes have significantly weaker error detection. That's good reason for default MTUs to remain in the Ethernet (1500) and SMDS/IP-over-ATM (9200) range. If there's a requirement to enlarge packets beyond 65 kBytes, please enlarge the CRC as well. I'm surprised that some respondents disregard error multiplication from scrambling. We should not degrade the weakest detection patterns for CRC-32, e.g., "detects all 4-bit errors in packets up to 11 kBytes" (I can't locate the practical properties of CRC-32 right now). --gw - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 28 15:20:56 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA18445; Mon, 28 Dec 1998 15:20:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Dec 1998 15:18:31 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA18397 for ietf-ppp-outgoing; Mon, 28 Dec 1998 15:18:30 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA18393 for ; Mon, 28 Dec 1998 15:18:24 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id PAA00185 for ietf-ppp@merit.edu; Mon, 28 Dec 1998 15:18:23 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Patents on SDL Date: 28 Dec 1998 15:18:23 -0500 Organization: IronBridge Networks Lines: 20 Message-ID: <8667awnhps.fsf@ironbridgenetworks.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu I've heard from wg members about concerns over possible patent claims by Lucent over SDL. I've just gotten word from Lucent that while they may patent their particular implementation, they do not intend to patent the protocol itself. Here's the mail I got from Paul Langner, an architect of the TDAT device: We have no patents or plans to patent any of the pieces relating to SDL. The only thing we may patent is how we specifically built our implementation of it, but that is still unclear. The intent is that we do nothing that will impede the acceptance of SDL - so this will be considered in any patents we file. Future drafts will note this. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 30 02:12:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id CAA11327; Wed, 30 Dec 1998 02:11:38 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 30 Dec 1998 02:06:03 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id CAA11261 for ietf-ppp-outgoing; Wed, 30 Dec 1998 02:06:03 -0500 (EST) Received: from main.via-net.net (main.via-net.net [209.116.97.64]) by merit.edu (8.9.1a/8.9.1) with ESMTP id CAA11257 for ; Wed, 30 Dec 1998 02:05:55 -0500 (EST) Received: from bluegill (ppp022.via-net.net [209.116.97.149]) by main.via-net.net (Post.Office MTA v3.5 release 214 ID# 0-52517U2500L250S0V35) with SMTP id net for ; Wed, 30 Dec 1998 02:04:49 -0500 Message-Id: <4.1.19981230020333.00b923e0@via-net.net> X-Sender: KFox@via-net.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 30 Dec 1998 02:05:50 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: New e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Hi! I have left Ascend, so please send all future correspondence for me to karl@xc.org Thanks. Karl Fox PPPEXT Working Group Chair - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 31 13:02:59 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA29782; Thu, 31 Dec 1998 13:00:27 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 31 Dec 1998 12:55:09 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA29703 for ietf-ppp-outgoing; Thu, 31 Dec 1998 12:55:08 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA29699 for ; Thu, 31 Dec 1998 12:55:05 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id MAA12324 for ietf-ppp@merit.edu; Thu, 31 Dec 1998 12:55:04 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.9.1a/8.9.1) with ESMTP id IAA13970 for ; Wed, 30 Dec 1998 08:07:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA01223; Wed, 30 Dec 1998 08:06:23 -0500 (EST) Message-Id: <199812301306.IAA01223@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: IP Header Compression over PPP to Proposed Standard Date: Wed, 30 Dec 1998 08:06:23 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft 'IP Header Compression over PPP' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten Technical Summary This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. Working Group Summary There was Working Group consensus for this document. Protocol Quality This spec has been reviewed for the IESG by Jeffrey Burgan and Thomas Narten. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 31 19:32:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id TAA03233; Thu, 31 Dec 1998 19:31:09 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 31 Dec 1998 19:29:59 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id TAA03185 for ietf-ppp-outgoing; Thu, 31 Dec 1998 19:29:58 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id TAA03181 for ; Thu, 31 Dec 1998 19:29:51 -0500 (EST) Received: from wawa.juniper.net (wawa.juniper.net [208.197.169.234]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id QAA05984; Thu, 31 Dec 1998 16:29:21 -0800 (PST) Received: from wawa.juniper.net (localhost.juniper.net [127.0.0.1]) by wawa.juniper.net (8.8.8/8.7.3) with ESMTP id QAA04004; Thu, 31 Dec 1998 16:29:21 -0800 (PST) Message-Id: <199901010029.QAA04004@wawa.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: smerchant@cimaron.com cc: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft In-reply-to: Your message of "24 Dec 1998 19:57:31 GMT." <36829CAB.FE48F7FF@cimaron.com> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 31 Dec 1998 16:29:21 -0800 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Shahrukh, > 2. Effect of scramblers on error multiplication > ----------------------------------------------- > Dennis Ferguson points out that the x^29[+x^2]+1 > self-synchronous scrambler contributes to error multiplication, > particulary when cascaded with the x^43+1 SONET payload scrambler, and > hence could weaken the error detection capability of the CRC-32. This is > a valid point, but addressable at several levels. Most simply, as Chuck > Benz proposes, the CRC should be computed (and > checked) on the SCR-29 scrambled data, which does not eliminate the Note that this also has a bug. A packet will only be descrambled correctly if both the scrambled packet data and the scrambler state is correct. If you only run the CRC over the scrambled data you will fail to detect errors in the packet caused by faulty scrambler state. You can fix this by including the initial scrambler state in the CRC for the packet. This does add significant complexity to the FCS computation when one packet ends and another starts, however. I'd also point out again that adding the third term to the self-sychronous scrambler does nothing to improve its operation. It just increases the error multiplication. Even if increased error multiplication is only a small negative, there is no apparent offsetting positive that would make adding the additional term to the scrambler desireable. > error multiplication (less of a factor at expected SONET BER rates as > Stuart Wilson and Andrew G. Malis > point out, and it affects adjacent packets in only a > small fraction of those cases anyway), but does take care of its > potentially adverse effect on the CRC. I'm pretty sure I'd be uncomfortable leaving fragility in the framing based on expected SONET BER rates. When the circuit is running degraded I'd much rather be able to deal with it by scheduling maintenance for the middle of the night rather than having to immediately take an OC-192c out of service in the peak part of the day. The more robust the packet framing, the more likely you can do the former rather than the latter. > Now, that leaves the error multiplication caused by the x^43+1 SONET > payload scrambler. This really serves a different purpose which I > mentally associate more with the SONET layer. Firstly, one should Whether associated with the SONET layer or not, the fact is that the only function of the x^43+1 scrambler is to protect against users sending data which synchronizes with the SONET frame scrambler. If you do the packet data scrambling, however, users are effectively prevented from sending data which will synchronize with the SONET frame scrambler in any case. This means that the x^43+1 payload scrambler is not helping anything, but is again causing error multiplication, i.e. a negative (for some arguable value of negative) with no positive. I think you'd be better off just picking one scrambler or the other, rather than both. > 3. Eliminating the cumulative effect of sporadic bit errors on flags > -------------------------------------------------------------------- [...] > Chuck Benz's idea of using idle packets works quite well I think (even > though he modestly--and unnecessarily--self-denigrates it as "not > pretty" :-). To fill in a little detail, we could have a 2-word idle > packet (4 words total including flags) comprising: > > Flag-I DummyData CRC-32 Flag0 > > where the now 5 possible flag values distinguished by the 6 LSBs (in > order to keep a 3-4 Hamming distance between them): > > 001100=Flag0, 010001=Flag1, 011010=Flag2, 000111=Flag3, 101011=Flag-I > > DummyData could be, for instance, a 32-bit packet counter (mod 2^32) or > some other 32-bit dummy value. To tell the truth I really dislike the magic flags stuff as well. Hamming distance or not, it almost certainly increases the chance of failing to detect a damaged packet well above the 2**-32 that the CRC-32 would have you believe. I would have preferred to make the padding self-describing. That is, always pad with fixed values, e.g. # Pad Bytes Pad 1 7d 2 6e 5a 3 9b 4f 8d 4 e2 3c e1 7f where packets without these patterns on the end are unpadded. This adds only small additional overhead (about 0.5% of packets whose length is an even multiple of 4 will have an extra 4 bytes of pad) and keeps everything that is used to determine the length of the packet covered by the CRC. Sending dummy packets will indeed fix the scrambler error accumulation problem, but only at the (smaller) cost of again relying on un-error-checked flag values. An error in a packet's preceeding flag that changed it from a flag-N to a flag-I, would cause the packet to be silently dropped. I guess this latter could be mitigated by redefining the CRC-32 computed on dummy packets (say, by changing the initial value of the CRC register or something), so that the CRC would catch packets with the wrong kind of flag in front. > 4. Points about SDL > ------------------- [...] > As far as implementation, my initial reaction to SDL was that it > appeared considerably more complex to implement--I'm not convinced on > arguments that the stuffing in HDLC-like implementations are > fundamentally so much more difficult than anything else that they would > outweigh all the other complexities of SDL (assuming one isn't trying to > fit one approach into an architecture that's been optimized for > another). You make an unsupported assertion about SDL being `considerably more complex'. If you're talking about the A/B message cruft, the packet offset thing and the scrambler state exchange I think I'd agree, but this is mostly stuff that could be discarded anyway. If you are talking about the basic framing mechanism, however, I strongly disagree. > I don't intend to make this an "SDL vs. HDLC-32" thing (HDLC-32 was > proposed independently of SDL, rather than as a response to it), but I > should clarify some points to avoid any misconceptions of HDLC-32: I don't know why this wouldn't be an SDL vs. HDLC-32 vs. anything else anyone can think of thing. It doesn't seem advantageous to have more than one way to frame packets over OC-192c, and choosing one as *the* way certainly seems to preclude others. > Dennis Ferguson says: > > - Similar to octet-synchronous HDLC you depend on the SONET framing to > > align the framing to 32-bit boundaries. SDL does not necessarily > > depend on the SONET framing, an SDL framer could be built to deframe > > a bit stream sent over the raw fiber. > > There actually isn't a dependency on SONET. *Given* transport over SONET > (which is what the proposal was addressing), I pointed out that you get > 32-bit alignment for free, without needing to do word alignment for > HDLC-32. Does the argument in the last sentence imply that you think it would be okay to have two types of framing formats, one for use when SONET is present and one without SONET? I think it would be more effective to settle on one framing format that worked in both situations. In fact, both bit-synchronous HDLC and ATM framing do work in both situations, the fact that octet-synchronous HDLC does not is a (unique) wart that I think warrants repair. > HDLC-32, as others have pointed out, can be framed on even if > it is carried directly over fibre or over bit-serial protocols, by using > the common 26-bit portion of the Flag words (more if you're willing to > decode a few extra bits)--this is actually simpler and more robust than > an ATM-like check on a 16-bit HEC. (The rest of the data are scrambled > or otherwise randomized so they wouldn't emulate these Flags with any > significant probability.) I don't think the above is true, or at least complete. To frame over a bit stream you need two things, (1) a way to find alignment, and (2) a way to determine when you're not aligned, so you know when to re-search for alignment You describe (1), but don't give a hint as to (2). I also don't buy the robustness thing either. It is true that the probability of finding four bytes with the correct HEC is 2^16, versus 2^26 for your flags. However, just waiting to see if you find a second, correct HEC at the right spot (which you would need to do anyway to initialize a self-synchronous scrambler) reduces the chance of being fooled to 1 in 2^32 while, if your HDLC framer is willing to accept packets that are very long, it may take you a long, long time to figure out you made an alignment mistake. > > SDL, on the > > other hand, eliminates transparency stuffing and associated complexity > > altogether. This seems to me to be fundamentally more scalable, and > > also permits one the possibility of doing really hard-core bandwidth > > scheduling on a circuit, something that is made annoyingly imperfect > > if your framer sometimes randomly grows packets by stuffing. > > Owing to the payload scrambling in HDLC-32, the stuffing will be in the > noise (2^-24) and should not affect bandwidth scheduling in any material > way. Perhaps I'm missing something, but I don't see the scalability > arguments applying more to transparency stuffing than to everything else > that makes this a non-trivial exercise by whatever means (the best we > can do is to reduce the complexity, not eliminate it). As was pointed out to you, if stuffing were not a speed-scalability issue then there would be no need at all for HDLC-32, and the fact that you can expect to rarely stuff doesn't change the logic one bit since rarely is not never. You've even suggested yourself that HDLC-32 may not scale up in speed, and that ever-wider stuff increments may be necessary to keep scaling speeds up. I think the reasoning that makes HDLC-32 desireable makes eliminating stuffing altogether even more desireable. > > - SDL makes sense at speeds lower than OC-192c, and potentially can fix > > the problems transparency stuffing causes there too. HDLC-32 is less > > attractive at lower speeds, so the stuffing problem remains (and it > > seems to me that if the packet expansion due to stuffing is a problem > > worth fixing at OC-192c it is also a problem worth fixing at lower > > speeds). > > Again, I don't see why HDLC-32 might seem less attractive than SDL (or > to itself) at lower speeds (than STS-192c); however, my main issue is > that I really believe than only plain-old HDLC (RFC 1662) makes sense at > lower rates, because it is already established! Anything that wanted to > replace the existing infrastructure (or even existing momentum) with a > new protocol would need to have a pretty high burden of proof that the > cost of doing so was justified (or even that the pain of having to Note that you've gone to the not-insignificant additional complexity of packet data scrambling to prevent users from sending packets which double in size on the wire when framed for OC-192c, yet the exact same degree of packet expansion occurs at lower speeds with octet-synchronous HDLC. It seems to me that preventing packet expansion is no more or less worth-while at OC-192c then it is at any other speed. That is, if the packet expansion really doesn't matter then HDLC-32 could be made significantly simpler by ignoring the issue, but if the packet expansion really does matter and we're inventing something new that fixes it I don't see any point in not attempting to support the option of eventually fixing it at all speeds. I think it is the case that preventing (carefully constructed) packets from doubling in size actually matters a lot if you are attempting to build a system that tightly schedules the bandwidth on circuits. Doing this is now becoming much more interesting that it used to be (particularly on the lowest speed circuits, that you aren't addressing) so I think not taking the opportunity to look at framing that would solve the problem at a wide range of speeds would be a mistake. You've pointed out some things about SDL you don't like, many of which I agree with. Let me suggest an alternative that hasn't had much thought, but which attempts to address some of the issues with it. In particular, - do away with A/B messages and the packet offset configuration thing. The payload of a frame is filled from the start with packet data. - replace the SDL polynomial payload scrambler with the x^43+1 self-synchronous scrambler. The latter is simpler, is familiar, and doesn't do much of anything bad if you stick with the FCS-32. - carry the FCS inside the scrambled payload, and include it in the frame length, rather than having to depend on configuration to correctly frame. - allow segmentation of packets into multiple frames. This does several things. It relieves the 64k packet size limit, it permits a device which can't rely on receiving the full length of the packet up front to run with a limited buffer, it optionally allows long packets to be interrupted by higher-priority packets at low speeds, and it even accomodates systems that can't really send at the full line rate. The SDL header might then be torqued into something like: 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ftype| Frame Length | CRC-16 HEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where CRC-16 HEC is as defined in the SDL document Frame Length is the number of bytes of data carried in the frame, exclusive of the header itself but including the packet payload and FCS. Ftype has the following values 3'b000 - idle frame. Any frame data is copied into the x^43+1 scrambler, but is otherwise discarded 3'b001 - packet A not-last-segment. The frame contains data from packet A, but more segments remain to be received 3'b010 - packet A last-segment. This is the last segment of packet A. The last bytes in the frame will be the packet FCS. 3'b011 - packet A abort. Any previous packet A data is discarded. 3'b100 - reserved. Count error, but otherwise treat as idle frame. 3'b101 - packet B not-last-segment. For low speed implementations this might carry a high-priority packet which is sent between segments of a long, lower priority packet. Non-supporting implementations might count this as an error and otherwise treat it as an idle frame. 3'b110 - packet B last-segment. As above. 3'b111 - packet B abort. As above. Frame synchronization works mostly like SDL, only without the extra complexity of the scrambler. Start delivering data if you find two consecutive error-free headers, resync if a subsequent header fails error correction. High speed implementations could limit themselves to CRC-32, and perhaps could pad out frames using a self-describing pad scheme if the latter helped anything (I'm not sure that it does). The scheme runs with slightly less bandwidth overhead than either HDLC-32 or octet-synchronous HDLC, eliminates stuffing altogether, and is only a bit more complex when run without SONET framing. It also runs with only about 0.5% more bandwidth overhead on average compared to bit-synchronous HDLC, eliminates stuffing there too, supports long packet interruption, and standardizes the scrambling (for HDLC on T3 circuits there are at least 3 scrambling options that need to be implemented since scrambling is optional and DSU vendor specific). Or something like that. The real point is that we've managed to get by with only two basic framing formats for telco circuits so far (three if you count ATM, I guess), both simple and well specified, and both running across a wide range of circuit bandwidths. If we're going to go to the trouble of specifying another format I'd rather have one that is more likely to work scalably and advantageously across a similarly broad range of circuit bandwidths, should that prove desireable, rather than doing one-off hacks to deal with implementation issues at particular speeds. My sense is that something like SDL, or maybe something like SDL-lite(r) above, offers a few advantages over HDLC-anything, is not more complex, and is more likely to scale upwards in speed without constant tweaking. Dennis Ferguson - - - - - - - - - - - - - - - - -