From ietf-ppp-request@MERIT.EDU Mon Oct 2 20:42:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA26743; Mon, 2 Oct 1995 20:42:20 -0400 Resent-Date: Mon, 2 Oct 1995 20:42:20 -0400 Date: Mon, 2 Oct 1995 18:31:15 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510030031.SAA01543@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: BSD Compress draft Resent-Message-ID: <"57MZb2.0.RX6.DR8Sm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/727 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've submitted a new version of the CCP BSD Compress draft. The two main changes are the following note: + Note that the peer receiving compressed data must use the same + code size as the peer sending data. It is not practical for the + receiver to use a larger dictionary or code size, because both + dictionaries must be cleared at the same time, even when the data + is not compressible, so that uncompressed packets are being sent, + and so the receiver cannot receive LZW "CLEAR" codes. As you might guess, in my CCP code, I was too smart by half and didn't actually adjust the dictionary size when the peer wanted something small. A more substantial change so to change the account of bytes compressed from: - db->bytes_out += (wptr-(cp_buf+3) /* count complete bytes */ - + (32-bitno+7)/8); to: + db->bytes_out += (wptr-&cp_buf[2] /* count complete bytes */ + + (32-bitno+7)/8); in the function pf_bsd_comp(). The result of this bug was to cause the receiver and transmitter to not agree when the dictionary is cleared while sending incompressible data, when LZW "CLEAR" codes must be inferred by the receiver. That caused spurious CCP Reset-Requests, about one every MByte in the case that came to my attention. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 07:10:52 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id HAA06627; Wed, 4 Oct 1995 07:10:52 -0400 Resent-Date: Wed, 4 Oct 1995 07:10:52 -0400 From: johnm@VNET.IBM.COM Message-Id: <199510041110.HAA06600@merit.edu> Date: Wed, 4 Oct 95 06:10:11 CDT To: ietf-ppp@MERIT.EDU Subject: How to read PPP RFC's? Resent-Message-ID: <"ojJwT.0.Fd1.WkcSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/728 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, I'm very new to the RFC's and the Internet standards procedures. If my questions below don't make sense or are being asked in the wrong place, I'd appreciate being pointed towards the right way to go with this. I'm trying to digest the PPP RFC's with an eye towards eventually implementing PPP on the IBM AS/400. I'm having trouble following the trail though. I initially assumed that if one RFC, say 1661, obsolete's another, in this case 1548, that everything I would need to know from 1548 would be included in 1661. I'm not so sure that is the case though. For example ... 1) The first paragraph of section 2 in RFC 1548 and 1661, "PPP Encapsulation" states, This encapsulation requires framing to indicate the beginning and end of the encapsulation. Methods of providing framing are specified in companion documents. Isn't this a bit vague for a "standard"? What companion documents? Is this a reference to the appendix in RFC1331? I would assume that the framing R. Stevens describes in his "TCP/IP Illustrated Vol 1" is what's referred to here. But I'm surprised it's not more explicitly described. Is this ambiguity intentional? If so, why? 2) RFC 1548 lists 8 values for the LCP Option Type. Most of the same values are listed in RFC1661, except for 2=Async-Control- Character-Map? So ... what happened to it? Is it now deprecated? The latest Assigned Numbers RFC, RFC1700, lists 21 values for Option Type, including option 2, but NOT including "0 RESERVED" which IS in RFC1661. I don't mean to just nit-pick to no end. I would like to better understand how to read the "standards" so I don't make incorrect assumptions I'll later regret. So ... to put it naively, what does it "mean" to claim your implementation of TCP/IP supports PPP? -john martz, AS/400 TCP/IP configuration (and stuff) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 09:05:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA10017; Wed, 4 Oct 1995 09:05:50 -0400 Resent-Date: Wed, 4 Oct 1995 09:05:50 -0400 X-Sender: kirtleypop@fcr.fcr.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Oct 1995 09:05:51 -0400 To: johnm@VNET.IBM.COM From: kirtley@fcr.com (Bill Kirtley) Subject: Re: How to read PPP RFC's? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"AleAb3.0.FS2.fQeSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/729 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Hi, > >I'm very new to the RFC's and the Internet standards procedures. >If my questions below don't make sense or are being asked in the >wrong place, I'd appreciate being pointed towards the right way >to go with this. > >I'm trying to digest the PPP RFC's with an eye towards eventually >implementing PPP on the IBM AS/400. I'm having trouble following >the trail though. I initially assumed that if one RFC, say 1661, >obsolete's another, in this case 1548, that everything I would >need to know from 1548 would be included in 1661. I'm not so >sure that is the case though. I think RFC1662 will answer your questions. It deals specifically with the framing methods of the physical layer. It also explains the LCP ACCM option. Perhaps 1661 should reference 1662 as an explanation of its physical layer? Regards -Bill ...................................................................... Bill Kirtley : FCR Software, Inc. 24 Upton Street #1 : 222 Third Street, Suite 3130 Boston, MA 02118 : Cambridge, MA 02142 kirtley@fcr.com : Tel. (617) 494-1300 Fax. (617)494-9592 Tel. (617) 424-6269 : WWW Page: http://www.fcr.com/homepage.html - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 09:38:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA11440; Wed, 4 Oct 1995 09:38:38 -0400 Resent-Date: Wed, 4 Oct 1995 09:38:38 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-bsd-compress-05.txt Date: Wed, 04 Oct 95 09:20:15 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9510040920.aa09736@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"0UrEi1.0.To2.QveSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/730 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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. Note: This revision reflects comments received during the last call period. Title : PPP BSD Compression Protocol Author(s) : V. Schryver Filename : draft-ietf-pppext-bsd-compress-05.txt Pages : 27 Date : 10/03/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. Internet-Drafts are 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-bsd-compress-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bsd-compress-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bsd-compress-05.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19951003133352.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bsd-compress-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bsd-compress-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951003133352.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 10:05:52 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA12546; Wed, 4 Oct 1995 10:05:52 -0400 Resent-Date: Wed, 4 Oct 1995 10:05:52 -0400 From: johnm@VNET.IBM.COM Message-Id: <199510041405.KAA12524@merit.edu> Date: Wed, 4 Oct 95 09:05:40 CDT To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"bbTHx3.0.p33.yIfSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/731 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Perhaps 1661 should reference 1662 as an explanation of its physical > layer? Sure sounds like a good idea to me! And also 1663 from what I gather from another note I got. Extracting details that are discussed in another place doesn't bother me. But I couldn't (easily) see the trail of breadcrumbs I was supposed to follow to that other place. Seems as though around the time that RFC1661 was written some things were just plain "obvious" to everyone involved. Probably because at that time everyone WAS involved. But if you're starting more or less from zip as I am, it would help to have a little more direction. For the moment, I guess I'll just ask questions here if/when they occur to me. If I'm bothering the folks on this mailing list, you'll let me know, right? I don't mean to be a nuisance. However, I think I have a natural aptitude for it ... ;-) -john martz, AS/400 TCP/IP configuration (and stuff) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 13:17:36 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA19558; Wed, 4 Oct 1995 13:17:36 -0400 Resent-Date: Wed, 4 Oct 1995 13:17:36 -0400 Date: Wed, 4 Oct 95 16:26:09 GMT From: "William Allen Simpson" Message-ID: <1672.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"o-ONe3.0.En4.f6iSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/732 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: johnm@VNET.IBM.COM > I'm trying to digest the PPP RFC's with an eye towards eventually > implementing PPP on the IBM AS/400. I'm having trouble following > the trail though. I initially assumed that if one RFC, say 1661, > obsolete's another, in this case 1548, that everything I would > need to know from 1548 would be included in 1661. I'm not so > sure that is the case though. > In order to read RFCs, you start with the rfc-index.txt. Using your editor or convenient more or list command, search for the string "PPP". Note that it is in reverse chronological order. So, you shouldn't even have peeked at RFC-1548, since RFC-1661, 1662, and 1663 all come before it! And there is a clear "obsoletes" notice! > 1) The first paragraph of section 2 in RFC 1548 and 1661, > "PPP Encapsulation" states, > This encapsulation requires framing to indicate the beginning > and end of the encapsulation. Methods of providing framing are > specified in companion documents. > > Isn't this a bit vague for a "standard"? What companion documents? > Is this a reference to the appendix in RFC1331? > Why are you looking at RFC-1331? Actually, there are about 6 companion documents. PPP in HDLC-framing, X.25, ISDN, SONET, etc. How would you prefer to have the cross reference? It is already in Internet Standards (most recently RFC-1800). But not all PPP framing techniques are specified in the RFC series. For example, digital cellular telephone use of PPP was recently (last year) specified in EIA/TIA IS-99. Finally, every PPP document specifies this mailing list to contact for asking questions from other implementors. (and here you are!) > I would assume that the framing R. Stevens describes in his > "TCP/IP Illustrated Vol 1" is what's referred to here. But I'm > surprised it's not more explicitly described. Is this ambiguity > intentional? If so, why? > Haven't bothered to get Vol 1, but it might be good for a beginner. Anyway, there are certain terms one would expect an implementor to know, such as "framing", "packet", "datagram", etc. These were taught when I went to school, but I have no idea what they teach nowadays. Just went to a 20-year class reunion on Sat, and am feeling old.... > 2) RFC 1548 lists 8 values for the LCP Option Type. Most of the > same values are listed in RFC1661, except for 2=Async-Control- > Character-Map? So ... what happened to it? Is it now deprecated? > > The latest Assigned Numbers RFC, RFC1700, lists 21 values for > Option Type, including option 2, but NOT including "0 RESERVED" > which IS in RFC1661. > Why are you reading RFC-1548? Folks (on this list) asked for #2 to be moved together with all of the other async details. Made sense to me, and hopefully easier reading for newcomers. But you have to read the _current_ set, not one labeled "obsolete". And yes, IANA is somewhat out of sync on various PPP numbers -- I tell them about it regularly. > I don't mean to just nit-pick to no end. I would like to better > understand how to read the "standards" so I don't make incorrect > assumptions I'll later regret. So ... to put it naively, what does > it "mean" to claim your implementation of TCP/IP supports PPP? > As it clearly says: 1) encapsulation, 2) LCP, 3) family of NCPs. You need to support the PPP Protocol encapsulation, and the LCP packet exchange FSA. No getting around that! As an NCP, presumably you would support IPCP, since you specified IP (above). But there are plenty of others.... Note, you probably want to run it over a link of some kind. So, (as it states) you need some "companion document". RFC-1662 is a good start, assuming that you are using the most common serial links (async, bit-sync, octet-sync). Is that enough to get you started? Shouldn't take longer than 4 months for you to finish and test your implementation. I recommend testing against Morningstar, since they have a rather good implementation. Contact Karl@MorningStar.Com. (no, I don't work there, I have never worked there, and I've never seen their code. they just have one of the first implementations, and have been very supportive of the PPP community. and they let me collect email there. very helpful folks!) Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 14:37:01 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA22387; Wed, 4 Oct 1995 14:37:01 -0400 Resent-Date: Wed, 4 Oct 1995 14:37:01 -0400 Message-Id: Date: Wed, 4 Oct 95 14:42 EDT From: klos@klos.com (Patrick Klos) To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"Qos1g2.0.WT5.6HjSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/734 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Geez! Talk about a guy with an ATTITUDE! Do you really think all your sarcasm and snide remarks are appropriate (or necessary)?? I don't! Patrick >From: "William Allen Simpson" >To: ietf-ppp@MERIT.EDU >Subject: Re: How to read PPP RFC's? >Resent-From: ietf-ppp@MERIT.EDU >X-Mailing-List: archive/latest/732 >X-Loop: ietf-ppp@MERIT.EDU >Precedence: list >Resent-Sender: ietf-ppp-request@MERIT.EDU > >> From: johnm@VNET.IBM.COM >> I'm trying to digest the PPP RFC's with an eye towards eventually >> implementing PPP on the IBM AS/400. I'm having trouble following >> the trail though. I initially assumed that if one RFC, say 1661, >> obsolete's another, in this case 1548, that everything I would >> need to know from 1548 would be included in 1661. I'm not so >> sure that is the case though. >> >In order to read RFCs, you start with the rfc-index.txt. Using your >editor or convenient more or list command, search for the string "PPP". > >Note that it is in reverse chronological order. So, you shouldn't even >have peeked at RFC-1548, since RFC-1661, 1662, and 1663 all come before >it! And there is a clear "obsoletes" notice! > > >> 1) The first paragraph of section 2 in RFC 1548 and 1661, >> "PPP Encapsulation" states, >> This encapsulation requires framing to indicate the beginning >> and end of the encapsulation. Methods of providing framing are >> specified in companion documents. >> >> Isn't this a bit vague for a "standard"? What companion documents? >> Is this a reference to the appendix in RFC1331? >> >Why are you looking at RFC-1331? > >Actually, there are about 6 companion documents. PPP in HDLC-framing, >X.25, ISDN, SONET, etc. > >How would you prefer to have the cross reference? It is already in >Internet Standards (most recently RFC-1800). > >But not all PPP framing techniques are specified in the RFC series. For >example, digital cellular telephone use of PPP was recently (last year) >specified in EIA/TIA IS-99. > >Finally, every PPP document specifies this mailing list to contact for >asking questions from other implementors. (and here you are!) > > >> I would assume that the framing R. Stevens describes in his >> "TCP/IP Illustrated Vol 1" is what's referred to here. But I'm >> surprised it's not more explicitly described. Is this ambiguity >> intentional? If so, why? >> >Haven't bothered to get Vol 1, but it might be good for a beginner. >Anyway, there are certain terms one would expect an implementor to >know, such as "framing", "packet", "datagram", etc. These were taught >when I went to school, but I have no idea what they teach nowadays. >Just went to a 20-year class reunion on Sat, and am feeling old.... > > >> 2) RFC 1548 lists 8 values for the LCP Option Type. Most of the >> same values are listed in RFC1661, except for 2=Async-Control- >> Character-Map? So ... what happened to it? Is it now deprecated? >> >> The latest Assigned Numbers RFC, RFC1700, lists 21 values for >> Option Type, including option 2, but NOT including "0 RESERVED" >> which IS in RFC1661. >> >Why are you reading RFC-1548? > >Folks (on this list) asked for #2 to be moved together with all of the >other async details. Made sense to me, and hopefully easier reading for >newcomers. But you have to read the _current_ set, not one labeled >"obsolete". > >And yes, IANA is somewhat out of sync on various PPP numbers -- I tell >them about it regularly. > > >> I don't mean to just nit-pick to no end. I would like to better >> understand how to read the "standards" so I don't make incorrect >> assumptions I'll later regret. So ... to put it naively, what does >> it "mean" to claim your implementation of TCP/IP supports PPP? >> >As it clearly says: 1) encapsulation, 2) LCP, 3) family of NCPs. > >You need to support the PPP Protocol encapsulation, and the LCP packet >exchange FSA. No getting around that! > >As an NCP, presumably you would support IPCP, since you specified IP >(above). But there are plenty of others.... > >Note, you probably want to run it over a link of some kind. So, (as it >states) you need some "companion document". RFC-1662 is a good start, >assuming that you are using the most common serial links (async, >bit-sync, octet-sync). > >Is that enough to get you started? > >Shouldn't take longer than 4 months for you to finish and test your >implementation. I recommend testing against Morningstar, since they >have a rather good implementation. Contact Karl@MorningStar.Com. > >(no, I don't work there, I have never worked there, and I've never seen >their code. they just have one of the first implementations, and have >been very supportive of the PPP community. and they let me collect >email there. very helpful folks!) > >Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 14:35:40 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA22325; Wed, 4 Oct 1995 14:35:40 -0400 Resent-Date: Wed, 4 Oct 1995 14:35:40 -0400 From: johnm@VNET.IBM.COM Message-Id: <199510041835.OAA22301@merit.edu> Date: Wed, 4 Oct 95 13:21:50 CDT To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"BH0Ao1.0.bS5.sFjSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/733 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Actually, there are about 6 companion documents. PPP in HDLC-framing, >> X.25, ISDN, SONET, etc. This was apparently obvious to everyone else who read RFC1661. It was NOT obvious to me. I wasn't sure from the text in RFC1661 which other documents were the "companion documents". I ended up looking back at the obsoleted RFC's because I thought maybe that's what was meant by "companion documents". Didn't seem likely, but the obsoleted RFC and Assigned Numbers RFC were the only things listed as References. So I thought, "Maybe that's where I'm supposed to be looking ..." Of course the organization all makes sense to me now that it has been explained. It did not make any sense this AM. So I asked about it. -john martz, AS/400 TCP/IP configuration (and stuff) P.S. Are you familiar with "Chad Mulligan's favorite story"? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 14:51:06 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA22974; Wed, 4 Oct 1995 14:51:06 -0400 Resent-Date: Wed, 4 Oct 1995 14:51:06 -0400 Date: Wed, 4 Oct 1995 14:50:15 -0400 From: Moji Kashef Message-Id: <199510041850.OAA00741@olympus.ctron.com> To: ietf-ppp@MERIT.EDU Subject: Calgary Corpus Resent-Message-ID: <"VqVZH2.0.dc5.GUjSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/736 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi: I am trying to locate IETF Standard Calgary Corpus Test Suites. Any Info would be greatly appreciated. Thanks Moji Kashef - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 14:49:00 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA22727; Wed, 4 Oct 1995 14:49:00 -0400 Resent-Date: Wed, 4 Oct 1995 14:49:00 -0400 Date: Wed, 4 Oct 1995 14:48:15 -0400 From: Moji Kashef Message-Id: <199510041848.OAA00711@olympus.ctron.com> To: ietf-ppp@MERIT.EDU Subject: Calgary Corpus Resent-Message-ID: <"7sPYo3.0.oY5.LSjSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/735 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi: I am looking for IETF Standard Calgary Corpus test Suite. Any info is greatly appreciated. Thanks Moji Kashef - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 16:57:16 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA27156; Wed, 4 Oct 1995 16:57:16 -0400 Resent-Date: Wed, 4 Oct 1995 16:57:16 -0400 Date: Wed, 4 Oct 95 20:48:01 GMT From: "William Allen Simpson" Message-ID: <1682.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"7wvyJ1.0.nd6.9KlSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/737 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: klos@klos.com (Patrick Klos) > Geez! Talk about a guy with an ATTITUDE! Do you really think all your > sarcasm and snide remarks are appropriate (or necessary)?? I don't! > Perhaps you might quote or otherwise elucidate the particular sentence which offended you ... RATHER THAN QUOTING THE ENTIRE MESSAGE! Didn't anyone ever teach you netiquette? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 18:18:43 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA29731; Wed, 4 Oct 1995 18:18:43 -0400 Resent-Date: Wed, 4 Oct 1995 18:18:43 -0400 Message-Id: <199510042220.AA29478@himagiri.NSD.3Com.COM> To: ietf-ppp@MERIT.EDU Subject: MLP & Protocol Field Compression Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) Date: Wed, 04 Oct 1995 15:20:40 -0700 From: Venkat Prasad Resent-Message-ID: <"pI4pB.0.GG7.xWmSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/738 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all, This issue was discussed a while ago and I am not sure how it was resolved. Sorry to reopen the issue. RFC 1717 says.. > The packets to be transmitted using the multilink procedure are > encapsulated according to the rules for PPP where the following > options would have been manually configured: > > o No Magic Number > o No Link Quality Monitoring > o Address and Control Field Compression > o Protocol Field Compression > o No Compound Frames > o No Self-Describing-Padding Forcing the Protocol Field Compression in the embedded protocol packet as mandated by RFC 1717 above causes protocol headers to be aligned on odd byte address. This causes performance degradation on the receive side as additional processing is required to copy the packet or split them into multiple buffers etc (especially with higher speed links ) Certain implementations do not support the LCP Protocol Field Compression option with the explicit purpose of avoiding this problem at a minimal cost of an extra byte on the link. Unfortunately when these implementations are upgraded to support MLP(RFC1717) the alignment problem comes back through the back door. I propose that at the time of the next revision of the RFC the text be changed as below " The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP where the following options would have been manually configured: o No Magic Number o No Link Quality Monitoring o Address and Control Field Compression o No Compound Frames o No Self-Describing-Padding If during LCP negotiation the Protocol Field Compression option was successfully negotiated, the packets to be transmitted using the multilink procedure may also compress the Protocol field in the embedded protocol packet. If Protocol Field Compression was not successfully negotiated during the LCP negotiation then the Protocol field in the embedded packet must be sent uncompressed. However, a receiver receiving MLP packets should be capable of processing MLP packets with or without Protocol Field compressed. " With this change performance can be preserved between two consenting peers and at the same time backwards compatibility is maintained with exisiting RFC 1717 implementations. I would like to hear your comments Venkat Prasad 3Com Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 18:44:12 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA00778; Wed, 4 Oct 1995 18:44:12 -0400 Resent-Date: Wed, 4 Oct 1995 18:44:12 -0400 Date: Wed, 4 Oct 1995 15:42:16 -0700 (PDT) From: Keith Sklower Message-Id: <199510042242.PAA02770@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Cc: vsp@NSD.3Com.COM Resent-Message-ID: <"rlQw83.0.xB.vumSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/739 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Venkat - My understanding of the PPP options is that the change you propose is in fact *Not* backwards compatible. If you negotiate protocol field compression, then you are saying "I, as receiver, am willing to get packets which do not contain leading 0's". It does not say that the sender is *required* to omit the leading zeros. It does require you to accept packets with and without the leading zeros. On the other hand, if we were to remove the implicit negotiation of protocol field compression over the bundle, receiver would be *required to toss* packets with the leading zeroes omited, which older implementations of RFC1717 are free to send. THe issue that had been discussed before was not PFC, but Address and Control Field Compression. I had had the mistaken impression that ACFC required you to remove the leading FF03 when I originally wrote the draft, and thought that the option was different from PFC in this respect, but I was wrong. So the issue that was discussed was whether to discourage people from sending an FF03 after the multilink header (even though the strictest reading of the PPP standards say that it is legal to send them). If you really want to forbid the sender from ommitting leading zeroes in PFC, and you want to stay backwards compatible, then I could suggest two possibilities, both of which are guaranteed to launch a firestorm. First (small change) - an LCP option specifically to that end, or second (Huge change) - allow LCP on the bundle as a separate link-level entity from the the constituent member links - and you indicate this by sending LCP packets encoded inside multilink headers. (I've suggested this before and the *overwhelming* consensus at the time was not to do this). In the interest of promoting commerce I strongly recommend we leave the language as it is in the current draft (the proposed revision to RFC1717). Keith Sklower UC Berkeley. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 20:00:55 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA03601; Wed, 4 Oct 1995 20:00:55 -0400 Resent-Date: Wed, 4 Oct 1995 20:00:55 -0400 From: marty@shiva.com Date: Wed, 4 Oct 95 19:58:57 PDT Subject: Re: How to read PPP RFC's? To: ietf-ppp@MERIT.EDU X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1cWln.0.2u.q0oSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/740 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 4 Oct 95 20:48:01 GMT William Allen Simpson wrote: >> From: klos@klos.com (Patrick Klos) >> Geez! Talk about a guy with an ATTITUDE! Do you really think all your >> sarcasm and snide remarks are appropriate (or necessary)?? I don't! >> >Perhaps you might quote or otherwise elucidate the particular sentence >which offended you > > ... RATHER THAN QUOTING THE ENTIRE MESSAGE! > >Didn't anyone ever teach you netiquette? > >Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > Bill, is that the same netiquette that preaches against using all caps? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 21:10:18 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA06013; Wed, 4 Oct 1995 21:10:18 -0400 Resent-Date: Wed, 4 Oct 1995 21:10:18 -0400 Date: Thu, 5 Oct 1995 11:09:10 +1000 From: Paul Mackerras Message-Id: <199510050109.LAA05809@sirius.anu.edu.au> To: ietf-ppp@MERIT.EDU Subject: CCP negotiation Resent-Message-ID: <"jYuMU1.0.bS1.k1pSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/741 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU My implementation of CCP will happily send and accept empty CCP configure-requests. It will send empty CCP conf-reqs if either (a) the peer rejects its request (at present, only for BSD-Compress), or (b) it doesn't want any compression but the peer sends a CCP configure-request. It will always configure-ack an empty configure-request from the peer. I have encountered some other CCP implementations which will configure-reject an empty configure-request. This seems wrong to me - do others agree? The result is that my implementation keeps sending configure-requests until it times out. There are also other implementations which, once they've sent and received an empty configure-request, close CCP and therefore just send terminate-acks in response to configure-requests. This seems to me to be legal but less than ideal because it doesn't terminate the dialog: the peer closing its CCP doesn't mean I close mine, so I keep sending configure-requests until I time out. (I did put in a kludge to close CCP if we receive a CCP terminate-request and we aren't asking for any compression.) Also: there was some discussion a while ago about how CCP should operate when there are multiple compression schemes which are acceptable to both peers. My understanding is that, in response to a CCP configure-request containing multiple options, the peer can: 1. Reply with a configure-ack listing exactly the same options, meaning "ok, I'll send packets compressed using the scheme specified by the first option listed". 2. Reply with a configure-nak suggesting different parameter values for one or more of the options listed in the configure-request, meaning "I can do those schemes, but not with the parameters you originally requested". 3. Reply with a configure-reject listing any options which specify compression schemes which the peer can't or doesn't want to do at all. A side effect of using the LCP FSA is that if the peer sends me a configure-request specifying two schemes, both of which I can do, but I would rather do the second than the first, my options are fairly limited: I can either artificially configure-nak the first with parameter values which (I hope) will make it less attractive to the peer than the second, or else configure-reject the first even though I am in fact able and willing (if reluctantly) to do it. (IMHO, the LCP FSA isn't particularly well suited to the task of deciding which of several alternative compression schemes to use. LCP options are very largely independent, whereas CCP options are alternatives.) Paul Mackerras Dept. of Computer Science Australian National University. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 21:47:43 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA07087; Wed, 4 Oct 1995 21:47:43 -0400 Resent-Date: Wed, 4 Oct 1995 21:47:43 -0400 Message-Id: <199510050149.AA00177@himagiri.NSD.3Com.COM> To: Keith Sklower Cc: ietf-ppp@MERIT.EDU, vsp@NSD.3Com.COM Subject: Re: MLP & Protocol Field Compression Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from Keith Sklower dated Wed, 04 Oct 1995 15:42:16 PDT <199510042242.PAA02770@vangogh.CS.Berkeley.EDU> Date: Wed, 04 Oct 1995 18:49:51 -0700 From: Venkat Prasad Resent-Message-ID: <"5tW9P1.0.Sk1.yapSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/742 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith, >> Venkat - >> My understanding of the PPP options is that the change you propose is >> in fact *Not* backwards compatible. I am not convinced. >> If you negotiate protocol field compression, then you are >> saying "I, as receiver, am willing to get packets which do not contain >> leading 0's". I agree >> It does not say that the sender is *required* to omit the leading zeros. I agree. In addition to that my proposal says that the sender should *not* omit the leading zero if the receiver never indicated a desire to deal with it. ( did not negotiate PFC ) >> It does require you to accept packets with and without the leading zeros. I agree. This is where it becomes backwards compatible. Since the sender in an older RFC1717 implementation would omit the leading zero the receiver in this proposal will still receive it albeit with lower performance. And, of course, if a the sender in this proposal does not omit the leading zero the receiver in this proposal will receive and also delivers better performance. No packets are ever tossed. >> On the other hand, if we were to remove the implicit negotiation >> of protocol field compression over the bundle, receiver would be >> *required to toss* packets with the leading zeroes omited, which >> older implementations of RFC1717 are free to send. That is true. But I heard that at the recent MLP bakeoff there was some consensus that a receiver should be more forgiving and accept with or without leading zeros. >> THe issue that had been discussed before was not PFC, but I probably used the word discussed loosely. I know that this issue was brought up but my email archives do not reflect any conclusion. >> If you really want to forbid the sender from ommitting leading >> zeroes in PFC, and you want to stay backwards compatible, then >> I could suggest two possibilities, both of which are guaranteed >> to launch a firestorm. First (small change) - an LCP option >> specifically to that end, or second (Huge change) - allow LCP >> on the bundle as a separate link-level entity from the the constituent >> member links - and you indicate this by sending LCP packets >> encoded inside multilink headers. (I've suggested this before >> and the *overwhelming* consensus at the time was not to do this). I am not for either of the above. I would like the alternative I proposed if there are no holes in it. >> Keith Sklower >> UC Berkeley. Venkat Prasad 3Com Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 22:25:02 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id WAA08256; Wed, 4 Oct 1995 22:25:02 -0400 Resent-Date: Wed, 4 Oct 1995 22:25:02 -0400 Date: Wed, 4 Oct 1995 19:22:57 -0700 (PDT) From: Keith Sklower Message-Id: <199510050222.TAA03233@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Resent-Message-ID: <"hqmBK.0.l02.l7qSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/743 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Venkat, I indeed did not fully understand your proposal. In your proposal you indicated that the bulleted item "Protocol Field Compression" be removed from the list of state implictly negotiated from the bundle. If you wish to describe the PPP state of an entity that has an equivalent functionality to a PPP link, you must describe the state of every option, and if you remove that bulleted item, then Protocol Field Compression is not in effect, and packets without leading zeroes must be tossed. You agree that the receiver is required to accept packets with or without leading zeroes, and that *IS* the definition of PFC having been configured. Thus the question of whether or not the bulleted item should remain is editorial, and I submit to you that removing it is misleading. (Certainly, I was misled by it). I agree that recommendations or requirements for a sender to always provide leading zeroes when PFC has not been negotiated on every or any member link is a backwards-compatible extension, and seems acceptible (although - sour grapes warning - the ability to conduct LCP negotions on the bundle itself would make this unambigous ;-). What it really means is that the sender has a different notion of the state of the bundle than the receiver, but the mismatch is compatible, and PPP purists may find this regrettable. What is your preference about the case where PFC has been configured on only one member link in a 2-link bundle? Should the sender assume it's OK to omit leading zeroes on the bundle or not? (i.e. in the paragraph above this one, do you prefer "any" or "every"?). Keith Sklower UC Berkeley - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 4 22:31:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id WAA08551; Wed, 4 Oct 1995 22:31:50 -0400 Resent-Date: Wed, 4 Oct 1995 22:31:50 -0400 Date: Wed, 4 Oct 1995 20:30:56 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510050230.UAA00363@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: CCP negotiation Cc: Paul Mackerras Resent-Message-ID: <"K31WB1.0.N52.KEqSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/744 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Paul Mackerras > ... > I have encountered some other CCP implementations which will > configure-reject an empty configure-request. This seems wrong to me - > do others agree? The result is that my implementation keeps sending > configure-requests until it times out. Maybe they are trying to say that CCP has been turned off on their end in both directions. I think in that case it's better to Protocol- Reject CCP, but I've met people who argue otherwise. > ... > Also: there was some discussion a while ago about how CCP should > operate when there are multiple compression schemes which are > acceptable to both peers. My understanding is that, in response to a > CCP configure-request containing multiple options, the peer can: > > 1. Reply with a configure-ack listing exactly the same options, > meaning "ok, I'll send packets compressed using the scheme specified > by the first option listed". > > 2. Reply with a configure-nak suggesting different parameter values > ... Was #1 agreed to? (I'm not objecting, since I think it would save a round of reject-request-ack in many cases. I'm just asking.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 00:48:51 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id AAA12299; Thu, 5 Oct 1995 00:48:51 -0400 Resent-Date: Thu, 5 Oct 1995 00:48:51 -0400 Date: Thu, 5 Oct 95 04:29:44 GMT From: "William Allen Simpson" Message-ID: <1687.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"uto5o3.0.n_2.cEsSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/746 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: marty@shiva.com > Bill, is that the same netiquette that preaches against > using all caps? > Hey, Marty, I expect that it is. Haven't seen a message with all caps on this list in ages. Capitals should only be used for EMPHASIS! There is (or should be soon) a RFC on netiquette coming from User Area. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 00:48:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id AAA12294; Thu, 5 Oct 1995 00:48:50 -0400 Resent-Date: Thu, 5 Oct 1995 00:48:50 -0400 Date: Thu, 5 Oct 95 03:56:42 GMT From: "William Allen Simpson" Message-ID: <1686.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP negotiation Resent-Message-ID: <"kTkRo.0.e_2.bEsSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/745 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Paul Mackerras > My implementation of CCP will happily send and accept empty CCP > configure-requests. It will send empty CCP conf-reqs if either > (a) the peer rejects its request (at present, only for BSD-Compress), > or (b) it doesn't want any compression but the peer sends a CCP > configure-request. It will always configure-ack an empty > configure-request from the peer. > That seems correct. > I have encountered some other CCP implementations which will > configure-reject an empty configure-request. This seems wrong to me - > do others agree? The result is that my implementation keeps sending > configure-requests until it times out. > Depends on whether they are sending their _own_ CCP C-Req. If they C-Rej something that they also send, then they aren't working. And when you report these errors, could you please tell us which vendor, so that we can verify for ourselves? OTOH, when _YOU_ receive a C-Rej, you MUST cease sending C-Req. Until, of course, you receive a C-Req from the peer, which indicates a new attempt. Follow the FSA. > There are also other implementations which, once they've sent and > received an empty configure-request, close CCP and therefore just send > terminate-acks in response to configure-requests. This seems to me to > be legal but less than ideal because it doesn't terminate the dialog: > the peer closing its CCP doesn't mean I close mine, so I keep sending > configure-requests until I time out. (I did put in a kludge to close > CCP if we receive a CCP terminate-request and we aren't asking for any > compression.) > Now, if they are sending T-Acks _before_ exchanging C-Acks, which you imply, they are wrong. Look at the FSA. After Opening, an exchange of T-Req & -Ack closes _both_ sides. Look at the FSA. Stop sending those C-Reqs. > A side effect of using the LCP FSA is that if the peer sends me a > configure-request specifying two schemes, both of which I can do, but > I would rather do the second than the first, my options are fairly > limited: I can either artificially configure-nak the first with > parameter values which (I hope) will make it less attractive to the > peer than the second, or else configure-reject the first even though I > am in fact able and willing (if reluctantly) to do it. > All policy is in the _receiver_ direction. If you can in fact do a scheme, you must Ack the scheme. If you _cannot_ do it with the parameters listed, you should C-Nak with parameters you _can_ use. Still anthropomorphizing "negotiation"? This isn't a two-way market exchange with a common denominator which you reach by agreement. What method of artificial intelligence are you using to measure "reluctance", and how are you per site configuring this omniscient facility? No, it is very simple: the receiver tells you what it wants, and you agree (or not) to do that. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 02:25:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id CAA14937; Thu, 5 Oct 1995 02:25:32 -0400 Resent-Date: Thu, 5 Oct 1995 02:25:32 -0400 Date: Thu, 5 Oct 1995 16:24:39 +1000 From: Paul Mackerras Message-Id: <199510050624.QAA05896@sirius.anu.edu.au> To: ietf-ppp@MERIT.EDU In-reply-to: <1686.bsimpson@morningstar.com> Subject: Re: CCP negotiation Resent-Message-ID: <"QUKdA3.0.Af3.MftSm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/747 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "William Allen Simpson" > > I have encountered some other CCP implementations which will > > configure-reject an empty configure-request. This seems wrong to me - > > do others agree? The result is that my implementation keeps sending > > configure-requests until it times out. > > > Depends on whether they are sending their _own_ CCP C-Req. If they > C-Rej something that they also send, then they aren't working. And when > you report these errors, could you please tell us which vendor, so that > we can verify for ourselves? Sorry, I don't follow. Are you saying that if they conf-reject a compression scheme that they have requested, they aren't working? I thought the two directions were independent. Anyway, that's not the problem. The problem is when they respond to a CCP conf-request containing no options with a CCP conf-reject containing no options. > OTOH, when _YOU_ receive a C-Rej, you MUST cease sending C-Req. Until, > of course, you receive a C-Req from the peer, which indicates a new > attempt. Follow the FSA. Huh? As I read RFC1661, when I get a valid conf-reject (the RCN event) in states Req-Sent, Ack-Rcvd or Ack-Sent, I send another conf-request (the scr action). And on page 32, I'm told that when I get a conf-reject, the next conf-request must not contain any of the options listed in the conf-reject. So it seems to me that a conf-reject containing no options is meaningless. (BTW, RFC1661 says on pages 31 & 32 that "Additionally, the Configuration Options in a Configure-Reject MUST be a proper subset of those in the last transmitted Configure-Request". Isn't a *proper* subset one which is not equal to the original set? So does this mean it isn't valid to configure-reject all of the options in a configure-request? Or should it perhaps say "a non-empty subset"?) > Now, if they are sending T-Acks _before_ exchanging C-Acks, which you > imply, they are wrong. Look at the FSA. Looking back at my email from the user who encountered this, I see that what I wrote was an over-simplification. The peer's behaviour was what you would expect according to the FSA if a Close event had occurred after it had sent and received one conf-reject. > After Opening, an exchange of T-Req & -Ack closes _both_ sides. Look at > the FSA. Stop sending those C-Reqs. The action for RTR in state Req-Sent is sta/6, that is, send a term-ack and stay in the Req-Sent state. What happens next is another timeout (TO+) event and I send another conf-req. The action for RTA is 6, that is, do nothing but stay in state Req-Sent. What is the sequence of actions and states by which a term-req sent by the peer should close my side? > > A side effect of using the LCP FSA is that if the peer sends me a > > configure-request specifying two schemes, both of which I can do, but > > I would rather do the second than the first, my options are fairly > > limited: I can either artificially configure-nak the first with > > parameter values which (I hope) will make it less attractive to the > > peer than the second, or else configure-reject the first even though I > > am in fact able and willing (if reluctantly) to do it. > > > All policy is in the _receiver_ direction. If you can in fact do a > scheme, you must Ack the scheme. If you _cannot_ do it with the > parameters listed, you should C-Nak with parameters you _can_ use. So the receiver gets to make the policy decisions. That's OK; it's simple and it saves having to try to quantify the degree to which each side prefers one scheme over another. But I can see now that users will want switches which they can use to disable certain schemes when talking to certain peers. For example, say some other site is configured to list Predictor-1 first and Deflate second, because it's configured for high-speed lines and CPU usage is an important factor. Then I dial in over a 2400-baud modem. I'll want a switch to turn Predictor-1 off. Paul Mackerras Dept. of Computer Science Australian National University. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 08:15:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id IAA22832; Thu, 5 Oct 1995 08:15:20 -0400 Resent-Date: Thu, 5 Oct 1995 08:15:20 -0400 Date: Thu, 5 Oct 95 08:12:39 EDT Message-Id: <9510051212.AA01039@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: Children! From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Oct 5 08:12:28 1995] Originating-Client: d-cell.ftp.com Content-Length: 773 Resent-Message-ID: <"pNGqS3.0.Qa5.5nySm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/748 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The PPP mailing list is for the discussion of PPP, so why don't you children take this someplace else? > > From: marty@shiva.com > > Bill, is that the same netiquette that preaches against > > using all caps? > > > Hey, Marty, I expect that it is. Haven't seen a message with all caps > on this list in ages. Capitals should only be used for EMPHASIS! > > There is (or should be soon) a RFC on netiquette coming from User Area. > > Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 09:39:21 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA25904; Thu, 5 Oct 1995 09:39:21 -0400 Resent-Date: Thu, 5 Oct 1995 09:39:21 -0400 Message-Id: Date: Thu, 5 Oct 95 09:45 EDT From: klos@klos.com (Patrick Klos) To: ietf-ppp@MERIT.EDU Subject: Re: How to read PPP RFC's? Resent-Message-ID: <"alf5G1.0.XK6.50-Sm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/749 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> From: klos@klos.com (Patrick Klos) >> Geez! Talk about a guy with an ATTITUDE! Do you really think all your >> sarcasm and snide remarks are appropriate (or necessary)?? I don't! >> >Perhaps you might quote or otherwise elucidate the particular sentence >which offended you > > ... RATHER THAN QUOTING THE ENTIRE MESSAGE! Your whole response was offensive, since it was obviously only written to afford you the opportunity to make this person feel unwelcome and uncomfortable asking questions to the list!! If I remember correctly, several responses to his questions were already posted, so he already had any of the information he needed. >Didn't anyone ever teach you netiquette? Certainly not the same person that taught you!! >Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Patrick ============================================================================ Patrick Klos Internet: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 BBS: (603) 429-0032 ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 11:09:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA29419; Thu, 5 Oct 1995 11:09:46 -0400 Resent-Date: Thu, 5 Oct 1995 11:09:46 -0400 From: John.Woods@proteon.com (John Woods) Message-Id: <9510051509.AA00953@kerplop.proteon.com> Subject: Re: CCP negotiation To: bsimpson@morningstar.com (William Allen Simpson) Date: Thu, 5 Oct 1995 11:09:06 -0400 (EDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <1686.bsimpson@morningstar.com> from "William Allen Simpson" at Oct 5, 95 03:56:42 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4449 Resent-Message-ID: <"XZFi33.0.SB7.sK_Sm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/750 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Bill Simpson > > From: Paul Mackerras > > I have encountered some other CCP implementations which will > > configure-reject an empty configure-request. This seems wrong to me - > > do others agree? The result is that my implementation keeps sending > > configure-requests until it times out. > OTOH, when _YOU_ receive a C-Rej, you MUST cease sending C-Req. Until, > of course, you receive a C-Req from the peer, which indicates a new > attempt. Follow the FSA. I'm trying to, perhaps I'm lost. Event RCN (Receive Configure-Nak/Reject) in state Req-Sent is supposed to result in actions irc (initialize restart count) and scr (Send Configure Request), with transition to state 6 (Req-Sent)! Any future Configure-Requests are obligated not to include any of the Configuration Options listed in the Configure-Reject, but if there aren't any options listed? Fine, the next Configure-Request is a *different* null set :-). The text of RFC-1661 certainly doesn't tell me what the meaning of an empty Configure-Reject is. I would suggest that it's meaningless, then. For example, if LCP sent an empty Configure-Request, and received a corresponding empty Configure-Reject, just what is the correct response? (I suppose you might argue that it means the other side doesn't like one of the defaults but is unwilling to explain which, and that you should just hang up the phone in response; myself, I'd argue that it means the other side is just busted and you should hang up the phone in response. Same result, different reason. :-) I think the conceptual problem here is that the "default" state for CCP (no compression) is one which someone might prefer to refuse ("doggone it, I ain't payin' to transfer this 10 megabytes of text in the clear!"). The problem is that Configure-Rejecting an empty CCP Configure-Request isn't the right way to express that, especially since it just plain won't work: sullenly not agreeing to no compression is likely to have exactly the same result as sending Protocol-Reject, the link stays up and no compression happens. (What do they expect, the box on the other side will suddenly acquire code to implement a compression scheme? Couldn't they at least have used Configure-Nak to suggest which compression scheme the other side should magically acquire? ;-) > Now, if they are sending T-Acks _before_ exchanging C-Acks, which you > imply, they are wrong. Look at the FSA. > After Opening, an exchange of T-Req & -Ack closes _both_ sides. Look at > the FSA. Stop sending those C-Reqs. I think (I hope) the implication is that when the close CCP right after negotiating no compression, they send the obligatory T-Req: > > (I did put in a kludge to close CCP if we receive a CCP terminate-request > > and we aren't asking for any compression.) If they do that, they're golden. (In fact, if that's correct, closing CCP after a CCP Terminate-Request isn't a kludge, it's required.) The only question then becomes whether the C-Reqs in the future are legal: the Open event happens whenever an implementation decides that it happens, so if the programmatic network administrator believes that seeing the close event without the link actually going down means that it's OK to open it again, the new C-Reqs should be legal, and get answered by T-Acks until the other side chooses to Open *its* side of the link. > > A side effect of using the LCP FSA is that if the peer sends me a > > configure-request specifying two schemes, both of which I can do, but > > I would rather do the second than the first, my options are fairly > > limited: I can either artificially configure-nak the first with > > parameter values which (I hope) will make it less attractive to the > > peer than the second, or else configure-reject the first even though I > > am in fact able and willing (if reluctantly) to do it. > All policy is in the _receiver_ direction. If you can in fact do a > scheme, you must Ack the scheme. If you _cannot_ do it with the > parameters listed, you should C-Nak with parameters you _can_ use. Right. I think it comes down to a desire to enforce compression here, and while that's an acceptable goal, the empty Configure-Reject is not a correct mechanism; I think a correct mechanism for this would be to have LCP force the link down in the same way that ECP specifies, not to Configure-Reject the lack of compression in hopes the remote will relent. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 11:15:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA29816; Thu, 5 Oct 1995 11:15:19 -0400 Resent-Date: Thu, 5 Oct 1995 11:15:19 -0400 Message-Id: Date: Thu, 5 Oct 95 11:14 EDT From: shilling@symplex.com (Jim Shillington) To: ietf-ppp@MERIT.EDU Subject: IPCP Question Resent-Message-ID: <"CdyLj3.0.aH7.4Q_Sm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/751 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does the IPCP working draft (draft-ietf-pppext-ipcp-00.txt) officially obsolete RFC 1332 or not? If so, why is it still a draft and not a new RFC? I am beginning our implementation of IPCP and need to know which document to follow. Should I follow the draft but allow for a peer that follows the RFC? I am hoping that someone who has already been through this can steer me in the right direction. Thanks, JimS =========================================================================== James E. Shillington Internet: shilling@symplex.com Symplex Communications Corporation Voice: (313) 995-1555 5 Research Drive FAX: (313) 995-3350 Ann Arbor, MI 48103 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 11:30:17 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA00735; Thu, 5 Oct 1995 11:30:17 -0400 Resent-Date: Thu, 5 Oct 1995 11:30:17 -0400 From: John.Woods@proteon.com (John Woods) Message-Id: <9510051529.AA00993@kerplop.proteon.com> Subject: Re: CCP negotiation To: John.Woods@proteon.com (John Woods) Date: Thu, 5 Oct 1995 11:29:28 -0400 (EDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9510051509.AA00953@kerplop.proteon.com> from "John Woods" at Oct 5, 95 11:09:06 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 675 Resent-Message-ID: <"TyRhF3.0.M9.zd_Sm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/752 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > (I did put in a kludge to close CCP if we receive a CCP terminate-request > > > and we aren't asking for any compression.) > If they do that, they're golden. (In fact, if that's correct, closing CCP > after a CCP Terminate-Request isn't a kludge, it's required.) I should have *kept* staring at the FSA table. Receiving TR in Req-Sent leaves you in Req-Sent. (I guess the implication is that the other side's journey through the This-Layer-Finished is probably going to result in the lowest layer physically taking down the link; otherwise, what's the point of saying "Sure, I know you want to terminate the link; now, when are you going to finish setting it up?") - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 12:06:10 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA02354; Thu, 5 Oct 1995 12:06:10 -0400 Resent-Date: Thu, 5 Oct 1995 12:06:10 -0400 Date: Thu, 5 Oct 1995 10:05:26 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510051605.KAA01443@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: empty configure rejects Resent-Message-ID: <"5wuLe1.0.Za.l90Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/753 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU After some private exchanges, I've realized I've also seen bogus, empty Configure-Rejects from one vendor. I didn't realize what Paul Mackerras was talking about. I don't think the crazy (in my opinion) Terminate-Ack responses to Configure-Requests specified in the state machine in RFC 1661 in Closed state are at issue. (I think they're crazy, because as Paul Mackerras wrote, RFC 1661 requires your system to continue sending Configure-Requests and getting Terminate-Acks until your system times-out. From talking to people at Ascend, they evidently go to Closed when CCP is administratively turned off or perhaps if the necessary option is not installed in their box. As they say, RFC 1661 allows this, although it bugs me.) I think Paul Mackerras means something else entirely: good system bad system Conf-Req X & Y ----> <---- completely empty Configure-Reject An empty Configure-Reject is meaningless, especially in response to a non-empty Configure-Rquest. The good system must stop asking for everything in the list of options in the Configure-Reject. So the good system must stop asking the bad system for nothing. Fooey. When my code receives such bogosity, it shuts down the CCP state machine with prejudice and responds to all future CCP packets with Protocol-Rejects. Besides empty Configure-Rejects, there are other things, like bad option lengths and unsolicited Naks for which my code employes the same tactic. A peer that cannot get the obvious stuff right is too likely to get more subtle things wrong. It's better to get the link up without CCP than risk not being able to pass data packets at all. No, I will not say which vendor's system emits the bogusly empty Configure-Rejects. I do not need anyone to "verify" what I've seen. Their problem is among them, their customers, prospective sutomers, and perhaps other vendors that encounter them. If they fix their problem before you see it, then there is no reason to say who they are. If they don't, then you have received fair warning. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 12:20:55 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA02972; Thu, 5 Oct 1995 12:20:55 -0400 Resent-Date: Thu, 5 Oct 1995 12:20:55 -0400 Date: Thu, 5 Oct 1995 10:20:07 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510051620.KAA01549@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Resent-Message-ID: <"0KMVW2.0.Bk.ZN0Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/754 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ] From: Venkat Prasad ] ... ] That is true. But I heard that at the recent MLP bakeoff there ] was some consensus that a receiver should be more forgiving ] and accept with or without leading zeros. ("MLP"? Please, not yet another name besides "MLPPP", "MPPP", "MPP", "BONDING", "ML/PPP", "PPP/ML" for what RFC 1717 labels "MP". I've seen all of those applied to RFC 1717. Yes, I know that BONDING and MPPP have other meanings.) At the April (March?) multilink PPP ISDN tests at PacBell's San Ramon facility I suggested that it is wise to accept compressed protocol fields even when they are not negotigated. This seems to me an application of the "be liberal in what you accept but conservative in what you send" rule. If you toss packets without leading zeros when Protocol Field Compression is off, then the link probably will not work at all, and you won't be able to reach the remote system to reset, reboot, or reconfigure it. > From: Keith Sklower > ... > What is your preference about the case where PFC has been configured > on only one member link in a 2-link bundle? Should the sender > assume it's OK to omit leading zeroes on the bundle or not? > (i.e. in the paragraph above this one, do you prefer "any" or "every"?). Let's leave things as they are, with Protocol Field Compression implicitly turned on for the multilink bundle. Systems that want to send leading zeros are free to do so. Systems that want to always receive leading zeros (eg. to avoid alignment hassels), to require all peers to always send leading zeros, are out of luck Note that my code runs on "RISC" systems with alignment restrictions. I see no significant utility in having the zeros. The MP header and the headers before it mess alignment up enough to make worrying about the alignment of MP fragments uninteresting to me. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 12:48:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA03975; Thu, 5 Oct 1995 12:48:19 -0400 Resent-Date: Thu, 5 Oct 1995 12:48:19 -0400 Message-Id: <199510051648.MAA03953@merit.edu> Date: Thu, 5 Oct 95 12:47:56 EDT From: "Andrew M. Fuqua ((919) 254-9810)" To: ietf-ppp@MERIT.EDU Subject: are there problems with this mailing list ? Resent-Message-ID: <"YrGu8.0.uz.Gn0Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/755 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I haven't received anything from this list in several weeks but one of my co-workers has. Is something wrong? I am sure I haven't unsubscribed. Who do I contact for help? THANKS, andrew - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 12:56:22 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA04358; Thu, 5 Oct 1995 12:56:22 -0400 Resent-Date: Thu, 5 Oct 1995 12:56:22 -0400 Date: Thu, 5 Oct 1995 10:55:46 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510051655.KAA01696@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP negotiation Resent-Message-ID: <"7QBV73.0.t31.ou0Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/756 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: John.Woods@proteon.com (John Woods) > ... > Right. I think it comes down to a desire to enforce compression here, > and while that's an acceptable goal, the empty Configure-Reject is not > a correct mechanism; I think a correct mechanism for this would be to > have LCP force the link down in the same way that ECP specifies, not to > Configure-Reject the lack of compression in hopes the remote will relent. I do not think that is right. In the cases where I have seen empty Configure-Rejects, I think the peer not want to do any CCP. I think they were using Configure-Rejects instead of Protocol-Rejects, Terminate-Requests, or something else that means "go away and don't bother me at all ever again with that stuff." Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 13:40:48 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA05848; Thu, 5 Oct 1995 13:40:48 -0400 Resent-Date: Thu, 5 Oct 1995 13:40:48 -0400 Message-Id: <199510051742.AA01845@himagiri.NSD.3Com.COM> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from vjs@mica.denver.sgi.com (Vernon Schryver) dated Thu, 05 Oct 1995 10:20:07 MDT <199510051620.KAA01549@mica.denver.sgi.com> Date: Thu, 05 Oct 1995 10:42:55 -0700 From: Venkat Prasad Resent-Message-ID: <"RFRv63.0.5R1.SY1Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/758 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> At the April (March?) multilink PPP ISDN tests at PacBell's San Ramon There was another one september 95 at the same location >> facility I suggested that it is wise to accept compressed protocol >> fields even when they are not negotigated. This seems to me an >> application of the "be liberal in what you accept but conservative in >> what you send" rule. If you toss packets without leading zeros when >> Protocol Field Compression is off, then the link probably will not work >> at all, and you won't be able to reach the remote system to reset, >> reboot, or reconfigure it. That is right. > From: Keith Sklower > ... > What is your preference about the case where PFC has been configured > on only one member link in a 2-link bundle? Should the sender > assume it's OK to omit leading zeroes on the bundle or not? > (i.e. in the paragraph above this one, do you prefer "any" or "every"?). >> Let's leave things as they are, with Protocol Field Compression >> implicitly turned on for the multilink bundle. >> Systems that want to send leading zeros are free to do so. Please point me to section in the RFC where this is specified. From the feedback I got from the September multilink PPP ISDN tests at Pacbell most people think that they must omit leading zero to be RFC 1717 compliant. I think there should be some text in the RFC to say it is OK not to omit the leading zero. >> Systems that want to always >> receive leading zeros (eg. to avoid alignment hassels), to require all >> peers to always send leading zeros, are out of luck Right. I am not asking for that. Again, I am asking for a provision in the RFC that a sender is *not* required to omit leading zeros >> Note that my code runs on "RISC" systems with alignment restrictions. >> I see no significant utility in having the zeros. The MP header and Performance at higher speeds (T1 and above) and in WAN concentrators where there a large number of bundles. >> Vernon Schryver, vjs@sgi.com Venkat Prasad 3Com Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 13:35:45 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA05597; Thu, 5 Oct 1995 13:35:45 -0400 Resent-Date: Thu, 5 Oct 1995 13:35:45 -0400 Date: Thu, 5 Oct 1995 13:35:00 -0400 From: John Gregg Message-Id: <199510051735.NAA15489@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU, vsp@NSD.3Com.COM Subject: Re: MLP & Protocol Field Compression Resent-Message-ID: <"2HFqC3.0.BN1.iT1Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/757 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At the recent MP bakeoff what some of my colleagues were seeing is this: some vendors (for whatever reason) have *never* implemented PFC. When they implemented MP, they used the same parsing code they always did and did not add code to do PFC just for MP. When we send MP packets with the leading 0s omitted from the encapsulated protocol ID, they choke. Our solution (a hack, yes) was to compress out the leading 00 of an MP-encapsulated packet's protocol ID only if the other side had in fact negotiated PFC on the link in the bundle that is the next link to be used (essentially sampling a random link in the bundle and using its negotiated parameter). This does not deal with the case in which someone negotiates PFC on one link in a bundle but not on another link in the same bundle, but the only consequence of guessing wrong about a peer's ability to handle PFC on a bundle is that you might not compress when you could have (you waste a byte). Most people negotiate PFC on all links all the time. Further, it is unlikely that a peer would negotiate PFC on one link and not another, then be unable to handle PFC on the bundle. At any rate, since technically we are allowed to compress or not as we see fit, not compressing when we think it *might* make the other side happier (rather than unconditionally compressing) doesn't seem like the worst idea in the world. I'm not saying that this is the right thing to do, just what we did to interoperate with slightly out-of-spec implementations. It seems to work. -John Gregg Shiva Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 14:16:13 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA07047; Thu, 5 Oct 1995 14:16:13 -0400 Resent-Date: Thu, 5 Oct 1995 14:16:13 -0400 Date: Thu, 5 Oct 95 17:20:58 GMT From: "William Allen Simpson" Message-ID: <1697.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP negotiation Resent-Message-ID: <"CcdZ31.0.2j1.932Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/759 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Paul Mackerras > Sorry, I don't follow. Are you saying that if they conf-reject a > compression scheme that they have requested, they aren't working? > I thought the two directions were independent. > Sorry, I was too terse. No, I meant if they C-Rej an _option_ that they are _capable_ of sending, they aren't working. C-Rej _means_ you don't support the option (or at least not with the parameters offered after several C-Naks). > Anyway, that's not the problem. The problem is when they respond to a > CCP conf-request containing no options with a CCP conf-reject > containing no options. > Now I understand! Well, that is perfectly legal. It clearly says [p 32]: "zero or more Configuration Options that the sender is rejecting." Rather silly, and you should just ignore the empty C-Rej. Since CCP doesn't interfere with sending data packets, such as IPCP and IP, it will eventually time out and stop bothering you, or continue for a long time and very slightly reduce throughput. > Huh? As I read RFC1661, when I get a valid conf-reject (the RCN > event) in states Req-Sent, Ack-Rcvd or Ack-Sent, I send another > conf-request (the scr action). And on page 32, I'm told that when I > get a conf-reject, the next conf-request must not contain any of the > options listed in the conf-reject. So it seems to me that a > conf-reject containing no options is meaningless. > Oh, I'll agree it is meaningless, but you still need to accomodate such silliness, as there have been (historically) implementations that send empty C-Rej. As you have experienced. Other approaches are just as silly, such as Protocol-Rejecting because you don't like the empty set. > (BTW, RFC1661 says on pages 31 & 32 that "Additionally, the > Configuration Options in a Configure-Reject MUST be a proper subset of > those in the last transmitted Configure-Request". Isn't a *proper* > subset one which is not equal to the original set? So does this mean > it isn't valid to configure-reject all of the options in a > configure-request? > We argued about this meaning, not that long ago. I assume that this was the agreed upon language. Anyway, _my_ implementations will C-Rej all the offered options. If "proper subset" is the wrong mathematical wording, then I'll take responsibility for the error, although the wording goes back to before my time. > Or should it perhaps say "a non-empty subset"?) Nope, empty is legal. > Looking back at my email from the user who encountered this, I see > that what I wrote was an over-simplification. The peer's behaviour > was what you would expect according to the FSA if a Close event had > occurred after it had sent and received one conf-reject. > Still don't understand this. > > After Opening, an exchange of T-Req & -Ack closes _both_ sides. Look at > > the FSA. Stop sending those C-Reqs. > > The action for RTR in state Req-Sent is sta/6, that is, send a > term-ack and stay in the Req-Sent state. What happens next is another > timeout (TO+) event and I send another conf-req. The action for RTA > is 6, that is, do nothing but stay in state Req-Sent. This was a "feature" we had to add because of Cisco, which would queue large numbers of T-Reqs, even though the line had already gone down. When it came up again, they would show up in response to your C-Req. Eventually, you get past the T-Req stream, and get the C-Req that you expected. > What is the > sequence of actions and states by which a term-req sent by the peer > should close my side? > After Opening, that is, you exchange C-Ack, achieve state 9, and then get a T-Req. > > All policy is in the _receiver_ direction. If you can in fact do a > > scheme, you must Ack the scheme. If you _cannot_ do it with the > > parameters listed, you should C-Nak with parameters you _can_ use. > > So the receiver gets to make the policy decisions. That's OK; it's > simple and it saves having to try to quantify the degree to which each > side prefers one scheme over another. That's the idea. > But I can see now that users > will want switches which they can use to disable certain schemes when > talking to certain peers. For example, say some other site is > configured to list Predictor-1 first and Deflate second, because it's > configured for high-speed lines and CPU usage is an important factor. > Then I dial in over a 2400-baud modem. I'll want a switch to turn > Predictor-1 off. > Sure, and easy to do! The same script that invokes your modem dialing should configure your PPP. That's what most scripts I've seen do.... My code has a separate set of PPP configurations for every interface. I don't see how PPP would work well if that weren't true (although it _will_ work, just more slowly). That high speed link is probably sync, and the modem is probably async. Lots of different parameters. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 14:16:12 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA07041; Thu, 5 Oct 1995 14:16:12 -0400 Resent-Date: Thu, 5 Oct 1995 14:16:12 -0400 Date: Thu, 5 Oct 95 17:51:12 GMT From: "William Allen Simpson" Message-ID: <1698.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP negotiation Resent-Message-ID: <"HriZF.0.Gj1.E32Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/760 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: John.Woods@proteon.com (John Woods) > I'm trying to, perhaps I'm lost. Event RCN (Receive Configure-Nak/Reject) > in state Req-Sent is supposed to result in actions irc (initialize restart > count) and scr (Send Configure Request), with transition to state 6 (Req-Sent)! > Any future Configure-Requests are obligated not to include any of the > Configuration Options listed in the Configure-Reject, but if there aren't > any options listed? Fine, the next Configure-Request is a *different* > null set :-). > > The text of RFC-1661 certainly doesn't tell me what the meaning of an empty > Configure-Reject is. I would suggest that it's meaningless, then. > Why are people trying to add so much semantic meaning to this stuff? Just follow the FSA, and do what it tells you. > For example, if LCP sent an empty Configure-Request, and received a > corresponding empty Configure-Reject, just what is the correct response? It says, send a new C-Req without the C-Rej options. There aren't any, so send the same C-Req. You'll get the same C-Rej. So what? Eventually, you'll time out and not send the CCP C-Req, which said "no compression". Data will be sent with no compression. The desired result. > (I suppose you might argue that it means the other side doesn't like > one of the defaults but is unwilling to explain which, and that you should > just hang up the phone in response; myself, I'd argue that it means the > other side is just busted and you should hang up the phone in response. > Same result, different reason. :-) > Goodness gracious! No! PPP negotiation has useful defaults, and negotiation about improvements. No matter what happens in the negotiation, it all is defined so that eventually bits cross the wire. They may not cross optimally, but they will cross! > I think the conceptual problem here is that the "default" state for CCP > (no compression) is one which someone might prefer to refuse ("doggone it, > I ain't payin' to transfer this 10 megabytes of text in the clear!"). The > problem is that Configure-Rejecting an empty CCP Configure-Request isn't > the right way to express that, especially since it just plain won't work: > sullenly not agreeing to no compression is likely to have exactly the same > result as sending Protocol-Reject, the link stays up and no compression > happens. (What do they expect, the box on the other side will suddenly > acquire code to implement a compression scheme? Couldn't they at least > have used Configure-Nak to suggest which compression scheme the other side > should magically acquire? ;-) > I agree with you here.... ;-) > > > (I did put in a kludge to close CCP if we receive a CCP terminate-request > > > and we aren't asking for any compression.) > > If they do that, they're golden. (In fact, if that's correct, closing CCP > after a CCP Terminate-Request isn't a kludge, it's required.) Absolutely not! A CCP T-Req when you are not Opened is essentially ignored. Follow the FSA. > > All policy is in the _receiver_ direction. If you can in fact do a > > scheme, you must Ack the scheme. If you _cannot_ do it with the > > parameters listed, you should C-Nak with parameters you _can_ use. > > Right. I think it comes down to a desire to enforce compression here, > and while that's an acceptable goal, the empty Configure-Reject is not > a correct mechanism; I think a correct mechanism for this would be to > have LCP force the link down in the same way that ECP specifies, not to > Configure-Reject the lack of compression in hopes the remote will relent. > Could be that you've guessed the implementor's intent. Won't know until they speak up here and are identified. But it certainly won't work, if the peer follows the FSA. Seems to me that there is a pretty fundamental difference between a security policy (ECP) and merely an efficiency policy (CCP). Like shutting down the link when your peer refuses to do VJ compression? Or have a MTU greater than 1500? That is _NOT_ the PPP way! Move those bits! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 14:20:49 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA07338; Thu, 5 Oct 1995 14:20:49 -0400 Resent-Date: Thu, 5 Oct 1995 14:20:49 -0400 From: Karl Fox Date: Thu, 5 Oct 95 14:19:44 -0400 Message-Id: <9510051819.AA06475@gefilte.MorningStar.Com> To: Keith Sklower Cc: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression In-Reply-To: <199510050222.TAA03233@vangogh.CS.Berkeley.EDU> References: <199510050222.TAA03233@vangogh.CS.Berkeley.EDU> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"WYdRZ1.0.Ro1.-72Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/761 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith Sklower writes: > What is your preference about the case where PFC has been configured > on only one member link in a 2-link bundle? Should the sender > assume it's OK to omit leading zeroes on the bundle or not? Assume you have MP over a single link, with PFC not configured. Presumably, you then send MP frames with leading zeros in the protocol field. A second link is then attached to the bundle, but this one *does* have PFC enabled. Now what? Next, assume the first link of the bundle goes down, leaving only the second link. What to do? Whatever we choose, I would strongly recommend that, once the bundle is created, that the protocol field encapsulation remain constant for the life of the bundle. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 14:34:22 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA07772; Thu, 5 Oct 1995 14:34:22 -0400 Resent-Date: Thu, 5 Oct 1995 14:34:22 -0400 Message-Id: <9510051937.AA04875@netmail2.microsoft.com> X-Msmail-Message-Id: 68043486 X-Msmail-Conversation-Id: 68043486 From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Thu, 5 Oct 95 11:04:31 TZ Subject: RE: IPCP Question X-Msxmtid: red-28-msg951005180401MTP[01.51.01]0000012e-27727 Resent-Message-ID: <"UTo0p2.0.Av1.hK2Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/762 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU An update to this draft will be posted next week. Since the new draft merely adds more language to 1332, rather than adding new options I suggest you use 1332 until then. gurdeep ---------- | From: Jim Shillington | To: | Subject: IPCP Question | Date: Thursday, October 05, 1995 11:14AM | | | Does the IPCP working draft (draft-ietf-pppext-ipcp-00.txt) officially | obsolete RFC 1332 or not? If so, why is it still a draft and not a new | RFC? I am beginning our implementation of IPCP and need to know which | document to follow. Should I follow the draft but allow for a peer that | follows the RFC? I am hoping that someone who has already been through | this can steer me in the right direction. | | Thanks, JimS | =========================================================================== | James E. Shillington Internet: shilling@symplex.com | Symplex Communications Corporation Voice: (313) 995-1555 | 5 Research Drive FAX: (313) 995-3350 | Ann Arbor, MI 48103 | - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 14:38:21 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA07871; Thu, 5 Oct 1995 14:38:21 -0400 Resent-Date: Thu, 5 Oct 1995 14:38:21 -0400 Date: Thu, 5 Oct 1995 12:06:01 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510051806.MAA01901@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Resent-Message-ID: <"oQRAB1.0.mw1.QO2Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/763 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Venkat Prasad > ... > Please point me to section in the RFC where this is specified. From > the feedback I got from the September multilink PPP ISDN tests at Pacbell > most people think that they must omit leading zero to be RFC 1717 compliant. > I think there should be some text in the RFC to say it is OK not to > omit the leading zero. Section 6.5 of RFC 1661 seems clear to me. It says the option indicates the ability of the receiver to receive compressed protocol fields. It says nothing about requiring the sender to send them compressed. What's more, it says twice that under some circumstances the sender must transmitt the extra zero. Since this keeps coming up, I agree it would be good to add words to the 5th paragraph like "even when Compressed Protocol fields have been negoiated, the peer is not required to compress protocol fields." Given the fact that the receiver must always be prepared to recieve uncompressed protocol fields, such words are obviously redundant. Still, for questions that keep coming up, the only approriate response is to improve the words in the standard. I wonder if there is a broken implementation out there that refuses to receive uncompressed protocol fields. Why else does this keep coming up? > ... > >> Note that my code runs on "RISC" systems with alignment restrictions. > >> I see no significant utility in having the zeros. The MP header and > > Performance at higher speeds (T1 and above) and in WAN concentrators > where there a large number of bundles. My code is run on 3 or 4 flavors T1 hardware. I'm a lot less worried about the protocol field than about compression at T1 speeds. I hadn't until now heard of anyone bundling T3 links. Does 3Com support that? As far as I can see, compressed protocol fields neither help nor hurt speed in systems with alignment restrictions. You simply optimize for the cases that matter to you and let the others go. This is an old problem. Consider the problems the 14-byte Ethernet header causes for "RISC" systems that want to treat fields in the IP header (e.g. the destination address) as 32-bit or larger "words." Consider the hassles the 13-byte FDDI header cause. Nice header lengths are nice, but they are not a big deal. (As we all no doubt know, the oddities of the FDDI and Ethernet headers are dealt with by padding added in the receiving or transmitting station, padding that never appears on the wire.) Yes, some hardware designers lack such clues, such as the geniuses in charge of National's new "SONIC" Ethernet MAC that can transmit with any alignment insists on receiving to 0(mod 4) instead of 2(mod 4) or 2(mod 8). There are EISA 100MHz Ethernet cards with worse stupidies on output. You deal with such problems however you must. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 15:43:08 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA10464; Thu, 5 Oct 1995 15:43:08 -0400 Resent-Date: Thu, 5 Oct 1995 15:43:08 -0400 Message-Id: <199510051944.AA02270@himagiri.NSD.3Com.COM> To: Keith Sklower Cc: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from Keith Sklower dated Wed, 04 Oct 1995 19:22:57 PDT <199510050222.TAA03233@vangogh.CS.Berkeley.EDU> Date: Thu, 05 Oct 1995 12:43:59 -0700 From: Venkat Prasad Resent-Message-ID: <"SztUz2.0.0Z2.JK3Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/764 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith, >> You agree that the receiver is required to accept packets >> with or without leading zeroes, and that *IS* the definition >> of PFC having been configured. Thus the question of whether >> or not the bulleted item should remain is editorial, and I submit >> to you that removing it is misleading. (Certainly, I was misled >> by it). You can keep the bullet. But add words to the effect that the sender is not obliged to omit the leading zero even though PFC is assumed to be manually configured and may use the the state of the PFC option on the member links to determine to omit the leading zero. >> What is your preference about the case where PFC has been configured >> on only one member link in a 2-link bundle? Should the sender >> assume it's OK to omit leading zeroes on the bundle or not? >> (i.e. in the paragraph above this one, do you prefer "any" or "every"?). I had not given this enough thought since most likely all links in a bundle will have the same set of options. But then they could be different. I suggest that it be based on the first link in the bundle and once determined remains in effect for the life of the bundle. >> Keith Sklower >> UC Berkeley Venkat Prasad 3Com Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 16:02:07 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA11108; Thu, 5 Oct 1995 16:02:07 -0400 Resent-Date: Thu, 5 Oct 1995 16:02:07 -0400 Message-Id: <199510052004.AA02337@himagiri.NSD.3Com.COM> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from vjs@mica.denver.sgi.com (Vernon Schryver) dated Thu, 05 Oct 1995 12:06:01 MDT <199510051806.MAA01901@mica.denver.sgi.com> Date: Thu, 05 Oct 1995 13:04:12 -0700 From: Venkat Prasad Resent-Message-ID: <"MfMgZ1.0.Lj2.yc3Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/765 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU from vjs@mica.denver.sgi.com (Vernon Schryver) >> Section 6.5 of RFC 1661 seems clear to me. It says the option >> indicates the ability of the receiver to receive compressed protocol >> fields. It says nothing about requiring the sender to send them >> compressed. What's more, it says twice that under some circumstances >> the sender must transmitt the extra zero. Thanks. I was looking for words in RFC 1717 >> Since this keeps coming up, I agree it would be good to add words >> to the 5th paragraph like "even when Compressed Protocol fields have been >> negoiated, the peer is not required to compress protocol fields." >> Given the fact that the receiver must always be prepared to recieve >> uncompressed protocol fields, such words are obviously redundant. >> Still, for questions that keep coming up, the only approriate response >> is to improve the words in the standard. Yes. >> I wonder if there is a broken implementation out there that refuses >> to receive uncompressed protocol fields. Why else does this keep >> coming up? It keeps coming up because people keep participating in bakeoffs and there are different participants each time. It will keep coming up if words are not added to the RFC 1717 to clarify this issue. > Performance at higher speeds (T1 and above) and in WAN concentrators > where there a large number of bundles. >> I hadn't until now heard of anyone bundling T3 links. Does 3Com >> support that? Between T1 & T3 there is E1 and also some customers of ours clock our system at > T1 speeds. If some one desires bundling T3 our implementation is capable of supporting it. Again it is not just the speed it is also the number of bundles in the system. >> Vernon Schryver, vjs@sgi.com Venkat Prasad 3Com Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 16:12:03 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA11442; Thu, 5 Oct 1995 16:12:03 -0400 Resent-Date: Thu, 5 Oct 1995 16:12:03 -0400 Message-Id: <199510052014.AA02387@himagiri.NSD.3Com.COM> To: Karl Fox Cc: Keith Sklower , ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from Karl Fox dated Thu, 05 Oct 1995 14:19:44 EDT <9510051819.AA06475@gefilte.MorningStar.Com> Date: Thu, 05 Oct 1995 13:14:11 -0700 From: Venkat Prasad Resent-Message-ID: <"IuCPw3.0.Zo2.Gm3Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/766 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Assume you have MP over a single link, with PFC not configured. >> Presumably, you then send MP frames with leading zeros in the protocol >> field. A second link is then attached to the bundle, but this one >> *does* have PFC enabled. Now what? Next, assume the first link of >> the bundle goes down, leaving only the second link. What to do? >> Whatever we choose, I would strongly recommend that, once the bundle >> is created, that the protocol field encapsulation remain constant for >> the life of the bundle. >> -- I agree. >> Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 >> 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 Venkat Prasad 3Com Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 16:53:33 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA12750; Thu, 5 Oct 1995 16:53:33 -0400 Resent-Date: Thu, 5 Oct 1995 16:53:33 -0400 Date: Thu, 5 Oct 95 16:53:26 EDT From: eallen@BayNetworks.com (Ed Allen) Message-Id: <9510052053.AA27965@BayNetworks.com> To: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Resent-Message-ID: <"T7Nxe2.0._63.AN4Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/767 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The examples given in this thread (and the subject line) have always used protocol field compression (PFC) but Address-and-Control field compression (ACFC) hasn't been mentioned, so I just want to check an assumption. Does everything that has been said about PFC being optionally included by the sender (once PFC has been successfully negotiated) also apply to ACFC? I assume that the following MP packet is "legal", (albeit not necessarily optimal, WRT line utilization) in that the FF 03 preceding the 00 21 may be included, even if the peers negotiated ACFC and PFC. FF 03 00 3d C0 00 00 00 FF 03 00 21 45 [rest of IP packet] ^ | This is what we've been discussing Is this assumption right? Thanks in advance.. Ed Allen Bay Networks - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 16:54:33 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA12793; Thu, 5 Oct 1995 16:54:33 -0400 Resent-Date: Thu, 5 Oct 1995 16:54:33 -0400 Date: Thu, 5 Oct 1995 16:53:43 -0400 From: Moji Kashef Message-Id: <199510052053.QAA24427@olympus.ctron.com> To: ietf-ppp@MERIT.EDU Subject: Motorolla & CCP Resent-Message-ID: <"Z0fxX1.0.f73.6O4Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/768 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Anyone knows what is going on with this licencing issue. Is ccp going to be considered for an advancemnet and eventually an RFC? Is ccp going to be revised? As most of you might know, Frame relay is adopting a similar Compression Control Protocol like CCP, which faces the same issues for licencing. Does this mean that it is accepted, and licencing should be persued. Maybe we all should choose packet mode, which requires no resetting. How about the second patent that they have for multiple dictionaries??? Any Ideas? Moji Kashef - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 17:18:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA13647; Thu, 5 Oct 1995 17:18:58 -0400 Resent-Date: Thu, 5 Oct 1995 17:18:58 -0400 Date: Thu, 5 Oct 1995 15:18:16 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510052118.PAA03892@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: MLP & Protocol Field Compression Resent-Message-ID: <"O4ENS3.0.0L3.0l4Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/769 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Venkat Prasad > ... >> I wonder if there is a broken implementation out there that refuses >> to receive uncompressed protocol fields. Why else does this keep >> coming up? > It keeps coming up because people keep participating in bakeoffs > and there are different participants each time. It will keep coming up if > words are not added to the RFC 1717 to clarify this issue. Actually, it seems John Gregg just now said why it keeps coming up: ] From: John Gregg ] At the recent MP bakeoff what some of my colleagues were ] seeing is this: some vendors (for whatever reason) have *never* ] implemented PFC. When they implemented MP, they used the same parsing ] code they always did and did not add code to do PFC just for MP. When ] we send MP packets with the leading 0s omitted from the encapsulated ] protocol ID, they choke. ... In other words, the problem is that some people failed to read RFC 1717 and understand that all systems implementing RFC 1717 are required to handle compressed protocol fields. There is not much that can be done to deal with such errors. Since this problem has been around for at least 6 months at vendor bake-offs with presumably latest-and-greatest code, it seems the culprits are refusing to fix their error. Because of that, I don't feel like implementing John Gregg's nice kludge to deal with them. People who don't fix such obvious things are likely to fail to handle more subtle things, such as the gyrations necessary to avoid stalling the MP link with inconvenient fragment losses. Besides, I've no desire to slow down my assembly of MP headers. (Output code can assume fixed offsets for parts of the header, and so go faster.) Yes, maybe their code goes faster on packets with uncompressed MP protocol fields, but so what? We all understand that the fast path for input packets is not always the only path. That one alternative is easier does not mean that you can avoid dealing with the nasty cases. All of this suggests that the words in the RFC 1717 that require compressed encapsulated protocol fields need to be made more emphatic, and that more words about whether sending the 0 is optional are beside the point. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 17:32:48 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA14168; Thu, 5 Oct 1995 17:32:48 -0400 Resent-Date: Thu, 5 Oct 1995 17:32:48 -0400 Date: Thu, 5 Oct 95 17:30:13 EDT Message-Id: <9510052130.AA09826@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: Motorolla & CCP From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Oct 5 17:30:03 1995] Originating-Client: europa Content-Length: 1811 Resent-Message-ID: <"HQNZW1.0._S3.xx4Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/770 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Anyone knows what is going on with this licencing issue. Is ccp going to be considered for an advancemnet and eventually an RFC? Is ccp going to be revised? As most of you might know, Frame relay is adopting a similar Compression Control Protocol like CCP, which faces the same issues for licencing. Does this mean that it is accepted, and licencing should be persued. Maybe we all should choose packet mode, which requires no resetting. Speaking as the IESG Area Director stuck with this problem... Please periodically hit the return or enter key on your keyboard. The CCP draft is being held in an indefinite pending state until one of four things happens: 1) The PPP working group withdraws it, presumably to submit something else for CCP that won't be encumbered. This has been attempted and there was enough dissent among the members of the working group that it currently is not a viable option. 2) Motorola agrees to the terms which we must have per RFC1602. We've asked Motorola. They don't want to do what 1602 requires us to do. We all agree that 1602 is broken, but the IAB finding at Danvers requires us to follow it, even when we know it will not work. 3) The 'variance procedure' gets completed and adopted. This is sitting someplace waiting for someone to do some editing. In theory it's real soon now -- but it has been that way for a long time. I periodically try to beat up on the people stuck with this task but... 4) We revise RFC1602 to allow us to accept what Motorola have offered. This is also in the works. When it will happen is unknown. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 18:31:47 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA16567; Thu, 5 Oct 1995 18:31:47 -0400 Resent-Date: Thu, 5 Oct 1995 18:31:47 -0400 Message-Id: <199510052231.QAA08212@zaphod.develcon.com> X-Sender: homer@zaphod.develcon.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Oct 1995 16:33:22 -0500 To: kasten@ftp.com, ietf-ppp@MERIT.EDU From: Homer_Robson@Develcon.com (Homer Robson) Subject: Re: Motorolla & CCP Resent-Message-ID: <"8Znjg3.0.e24.Dp5Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/771 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Anyone knows what is going on with this licencing issue. I was at the NIUF in Long Branch NJ last week. There was a report presented to the ENDIF group that lead me to beleive that Motorola has presented their "fair and reasonable" licensing terms. Are the terms for licensing the Motorola patent known? Where can I get hold of a copy of the terms? I'd like to know, just in case CPP becomes a standard. -- Homer_Robson@Develcon.com Compuserve 74051,32 Develcon, 856 51st Street East, Saskatoon, SK,CAN, S7K 5C7 (306)933-3300 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 19:24:06 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA18233; Thu, 5 Oct 1995 19:24:06 -0400 Resent-Date: Thu, 5 Oct 1995 19:24:06 -0400 Date: Thu, 5 Oct 95 19:21:39 EDT Message-Id: <9510052321.AA10820@mailserv-D.ftp.com> To: Homer_Robson@Develcon.com Subject: Re: Motorolla & CCP From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: kasten@ftp.com, ietf-ppp@MERIT.EDU Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Oct 5 19:21:29 1995] Originating-Client: d-cell.ftp.com Content-Length: 1508 Resent-Message-ID: <"qZwFM.0.cS4.Ja6Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/772 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I was at the NIUF in Long Branch NJ last week. > There was a report presented to the ENDIF group that lead me to beleive that > Motorola has presented their "fair and reasonable" licensing terms. Folks, let me say right up front that the issue with regard to Motorola and the CCP (and the ECP, by the way) is NOT that Motorola have done nothing. Motorola have made what would generally be considered a reasonable offer in this area. It is an offer that is what is generally made to standards bodies and that standards bodies usually accept. The problem is that the IESG and IETF are severely constrained in what we can accept by the rules of RFC1602. These rules require mandate that we MUST have certain terms and conditions which generally are not provided in these cases. The fault is not with Motorola as much as it is with the extremity of our rules. > Are the terms for licensing the Motorola patent known? > Where can I get hold of a copy of the terms? The offer from Motorola is, briefly, that they would make a license available on a fair, reasonable, and nondiscriminatory basis to whoever asks. Basically, if you want to implement CCP and not run afoul of the various patent issues, you call up Motorola and ask them... Unfortunately I do not have the contact information. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 20:18:15 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA19849; Thu, 5 Oct 1995 20:18:15 -0400 Resent-Date: Thu, 5 Oct 1995 20:18:15 -0400 Date: Fri, 6 Oct 1995 10:17:23 +1000 From: Paul Mackerras Message-Id: <199510060017.KAA06074@sirius.anu.edu.au> To: ietf-ppp@MERIT.EDU In-reply-to: <1697.bsimpson@morningstar.com> Subject: Re: CCP negotiation Resent-Message-ID: <"_Woy52.0.wr4.3N7Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/773 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "William Allen Simpson" > > Looking back at my email from the user who encountered this, I see > > that what I wrote was an over-simplification. The peer's behaviour > > was what you would expect according to the FSA if a Close event had > > occurred after it had sent and received one conf-reject. > > > Still don't understand this. OK, just to clarify, this is the sequence of CCP packets exchanged. My side sent: The peer sent: ConfReq id=0x1 ConfReq id=0x2 < 12 06 00 00 00 01> ConfRej id=0x2 < 12 06 00 00 00 01> ConfRej id=0x1 ConfReq id=0x2 TermReq id=0x5 TermAck id=0x5 {3 second pause} ConfReq id=0x2 TermAck id=0x2 {3 second pause} ConfReq id=0x2 TermAck id=0x2 {after my side sends 7 more ConfReqs:} TermReq id=0x3 TermAck id=0x3 (This was my ppp-2.2 package talking to Microsoft PPC.) I don't think there's really a problem, it just means I get email saying "what's going wrong here?" :-). Basically, I guess I'm just asking is there anything wrong with empty CCP conf-reqs and conf-acks (the answer seems to be no), and if not, why do other implementations have such an aversion to them? > > What is the > > sequence of actions and states by which a term-req sent by the peer > > should close my side? > > > After Opening, that is, you exchange C-Ack, achieve state 9, and then > get a T-Req. I see, by "after Opening" you mean after the FSA reaches the Opened state. I thought you meant after it had had an Open event. In the situation I was talking about, the FSA has had the Open event but not reached the Opened state. Paul Mackerras Dept. of Computer Science Australian National University. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 5 21:06:27 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA21330; Thu, 5 Oct 1995 21:06:27 -0400 Resent-Date: Thu, 5 Oct 1995 21:06:27 -0400 From: PAUL CORNING To: "'IETF-ppp@merit.edu'" Subject: paulc@diamondmm.com Date: Wed, 04 Oct 95 19:00:00 PDT Message-ID: <30747FFE@mailgate.diamondmm.com> Encoding: 2 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"JP29f2.0._C5.F48Tm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/774 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU subscribe - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Oct 6 12:37:54 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA16727; Fri, 6 Oct 1995 12:37:54 -0400 Resent-Date: Fri, 6 Oct 1995 12:37:54 -0400 Date: Fri, 6 Oct 95 15:38:22 GMT From: "William Allen Simpson" Message-ID: <1705.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP negotiation Resent-Message-ID: <"bI5p-.0.q44.ziLTm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/775 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Thanks! Most helpful! > From: Paul Mackerras > OK, just to clarify, this is the sequence of CCP packets exchanged. > > My side sent: The peer sent: > > ConfReq id=0x1 > ConfReq id=0x2 < 12 06 00 00 00 01> !!! unregistered, undocumented, supposed to use OUI!!! > ConfRej id=0x2 < 12 06 00 00 00 01> Correct response. > ConfRej id=0x1 > ConfReq id=0x2 This is technically correct. However, with a tiny amount of code, you could just give up. You don't want to compress, so why ask for it unless your peer attempts compression? Remember, not negotiating leaves things at default: no compression. > TermReq id=0x5 !!! attempting to terminate an FSA which has not reached the Opened state. This does _not_ properly implement the FSA. > TermAck id=0x5 Correct response. > {3 second pause} > ConfReq id=0x2 > TermAck id=0x2 > {3 second pause} > ConfReq id=0x2 > TermAck id=0x2 > {after my side sends 7 more ConfReqs:} > TermReq id=0x3 Again, attempting to terminate an FSA which has not reached the Opened state. Just stop sending ConfReq. See the TO- event in state 6 (Req-Sent). Note that a proper response to TO- is _not_ an "administrative close", which it appears that you are doing. > TermAck id=0x3 > > (This was my ppp-2.2 package talking to Microsoft PPC.) > > I don't think there's really a problem, it just means I get email > saying "what's going wrong here?" :-). Basically, I guess I'm just > asking is there anything wrong with empty CCP conf-reqs and conf-acks > (the answer seems to be no), and if not, why do other implementations > have such an aversion to them? > To answer your first question, there is _nothing_ wrong with an empty C-Req/Ack. It would be _required_ in the case where you won't receive but will send a particular compression. But in your example, it would make more sense to not send the empty C-Req, except as a _response_ to a C-Req from the peer. That's what should happen in this case! Instead, the MS PPC improperly sends T-Req. I cannot find anywhere that this response is allowed in the FSA (which I designed). If there is an obscure path exception, please point it out? Which probably answers your second question. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Oct 8 19:57:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA07257; Sun, 8 Oct 1995 19:57:28 -0400 Resent-Date: Sun, 8 Oct 1995 19:57:28 -0400 Date: Mon, 9 Oct 1995 09:56:37 +1000 From: Paul Mackerras Message-Id: <199510082356.JAA06892@sirius.anu.edu.au> To: ietf-ppp@MERIT.EDU In-reply-to: <1705.bsimpson@morningstar.com> Subject: Re: CCP negotiation Resent-Message-ID: <"1VZGf.0.3n1.3L6Um"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/776 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > ConfReq id=0x2 > > This is technically correct. > > However, with a tiny amount of code, > you could just give up. Would it be OK to do this by going to Stopped state from Req-Sent on receiving a Conf-Rej rejecting all our options (assuming we've rejected all the peer's options)? > > {after my side sends 7 more ConfReqs:} > > TermReq id=0x3 > > Again, attempting to terminate an FSA > which has not reached the Opened state. > Just stop sending ConfReq. Whoops, I must have misread the FSA table. Thanks. > Instead, the MS PPC improperly > sends T-Req. I cannot find anywhere that this response is allowed in > the FSA (which I designed). If there is an obscure path exception, > please point it out? I assumed that the peer must have had an administrative Close event while in the Req-Sent state, which does generate the `str' event. Presumably the peer has a policy of closing CCP if no compression is possible. Paul Mackerras Dept. of Computer Science Australian National University. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 9 01:00:45 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id BAA15876; Mon, 9 Oct 1995 01:00:45 -0400 Resent-Date: Mon, 9 Oct 1995 01:00:45 -0400 Date: Mon, 9 Oct 95 04:40:57 GMT From: "William Allen Simpson" Message-ID: <1741.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP negotiation Resent-Message-ID: <"x3elA3.0.jt3.vnAUm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/777 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Paul Mackerras > Would it be OK to do this by going to Stopped state from Req-Sent on > receiving a Conf-Rej rejecting all our options (assuming we've > rejected all the peer's options)? > Sounds OK to me.... Kinda like the Passive option. > I assumed that the peer must have had an administrative Close event > while in the Req-Sent state, which does generate the `str' event. > Presumably the peer has a policy of closing CCP if no compression is > possible. > Yeah, but that's really odd. Why close it when it isn't open? Oh, well, looks like you know how to stop, so that the problem won't happen anymore. Thanks for bringing it to the list, in case someone else was experiencing something similar. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 9 15:13:08 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA08529; Mon, 9 Oct 1995 15:13:08 -0400 Resent-Date: Mon, 9 Oct 1995 15:13:08 -0400 Date: Mon, 9 Oct 1995 15:11:27 -0400 From: Aydin Edguer Message-Id: <199510091911.PAA29406@trigger.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: CCP Negotiations Resent-Message-ID: <"MlAw-2.0.v42.HGNUm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/778 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Morning Star Technologies will C-Ack the empty CCP C-Req. This prevents the string of empty C-Req/C-Rej packets. Microsoft Windows 95 will not do the right thing in this case - it still tries to send a CCP compressed packet even though no CCP options were agreed upon (forcing CCP to use the default of "no compression"). The following is an edited copy of the PPP negotiation showing this behavior. > 9/23-18:05:56-28650 Allocating a 2124-byte buffer > 9/23-18:05:56-28650 Morning Star Technologies PPP > 9/23-18:05:56-28650 Version 1.4.1.6 [5-Mar-1995 20:49:56 sparc] > 9/23-18:05:56-28650 new_state '[off]' > 9/23-18:05:56-28650 new_state '[off, ttym01]' > 9/23-18:05:56-28650 Lock file /usr/spool/locks/LCK..ttym01 created > 9/23-18:05:56-28650 Opened /dev/ttym01 on tty_fd=7 > 9/23-18:05:56-28650 Popped 'ttcompat' STREAMS module > 9/23-18:05:56-28650 Popped 'ldterm' STREAMS module > 9/23-18:05:56-28650 STREAMS module 'pppframe' pushed > 9/23-18:05:56-28650 /usr/etc/pppd shade:ppp-latham log /tmp/dwl.ppplog debug 11 rtscts idle 600 acct /var/adm/pppd.log filter /etc/ppp/Filter ... > 9/23-18:06:03-28650 19-byte PPP frame received: > 9/23-18:06:03-28650 FF0380FD 0101000F 12060000 00011105 "...}............" > 9/23-18:06:03-28650 000104 "..." > 9/23-18:06:03-28650 Received CCP Configure-Request, ID 1, state Stopped (3) > 9/23-18:06:03-28650 CCP: Received unknown option 18 (Rej) > 9/23-18:06:03-28650 CCP: Received option Stac (Rej) > 9/23-18:06:03-28650 CCP: Replying with Configure-Reject > 9/23-18:06:03-28650 CCP event RCR-, state Stopped (3) > 9/23-18:06:03-28650 CCP: Sending option Predictor-1 > 9/23-18:06:03-28650 Sending CCP Configure-Request, ID 1, state Stopped (3) > 9/23-18:06:03-28650 Sending 10-byte PPP frame: > 9/23-18:06:03-28650 FF0380FD 01010006 0102 "...}......" > 9/23-18:06:03-28650 Wrote 11 bytes to tty_fd: > 9/23-18:06:03-28650 80FD0101 00060102 F3127E ".}......s.~" > 9/23-18:06:03-28650 Sending CCP Configure-Reject, ID 1, state Stopped (3) > 9/23-18:06:03-28650 Sending 19-byte PPP frame: > 9/23-18:06:03-28650 FF0380FD 0401000F 12060000 00011105 "...}............" > 9/23-18:06:03-28650 000104 "..." > 9/23-18:06:03-28650 Wrote 21 bytes to tty_fd: > 9/23-18:06:03-28650 80FD0401 000F1206 00000001 7D310500 ".}..........}1.." > 9/23-18:06:03-28650 01042A47 7E "..*G~" ... > 9/23-18:06:03-28650 10-byte PPP frame received: > 9/23-18:06:03-28650 FF0380FD 04010006 0102 "...}......" > 9/23-18:06:03-28650 Received CCP Configure-Reject, ID 1, state Req-Sent (6) > 9/23-18:06:03-28650 CCP: Peer rejected Predictor-1 > 9/23-18:06:03-28650 CCP event RCN, state Req-Sent (6) > 9/23-18:06:03-28650 Sending CCP Configure-Request, ID 2, state Req-Sent (6) > 9/23-18:06:03-28650 Sending 8-byte PPP frame: > 9/23-18:06:03-28650 FF0380FD 01020004 "...}...." > 9/23-18:06:03-28650 Wrote 9 bytes to tty_fd: > 9/23-18:06:03-28650 80FD0102 0004D8FE 7E ".}....X~~" ... > 9/23-18:06:18-28650 CCP event TO+, state Req-Sent (6) > 9/23-18:06:18-28650 Sending CCP Configure-Request, ID 3, state Req-Sent (6) > 9/23-18:06:18-28650 Sending 8-byte PPP frame: > 9/23-18:06:18-28650 FF0380FD 01030004 "...}...." > 9/23-18:06:18-28650 Wrote 10 bytes to tty_fd: > 9/23-18:06:18-28650 7E80FD01 03000404 A47E "~.}.....$~" ... > 9/23-18:06:18-28650 60 bytes read from tty: > 9/23-18:06:18-28650 7E80FD02 02000415 DB7E7E80 FD010200 "~.}.....[~~.}..." > 9/23-18:06:18-28650 04D8FE7E 7E80FD01 03000404 A47E7E80 ".X~~~.}.....$~~." > 9/23-18:06:18-28650 FD010400 0401287E 7E80FD01 050004DD "}.....(~~.}....]" > 9/23-18:06:18-28650 727E7E80 FD010600 04B99D7E "r~~.}....9.~" > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 02020004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Ack, ID 2, state Req-Sent (6) > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 01020004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Request, ID 2, state Req-Sent (6) > 9/23-18:06:18-28650 CCP: Replying with Configure-Ack > 9/23-18:06:18-28650 CCP event RCR+, state Req-Sent (6) > 9/23-18:06:18-28650 Sending CCP Configure-Ack, ID 2, state Req-Sent (6) > 9/23-18:06:18-28650 Sending 8-byte PPP frame: > 9/23-18:06:18-28650 FF0380FD 02020004 "...}...." > 9/23-18:06:18-28650 Wrote 9 bytes to tty_fd: > 9/23-18:06:18-28650 80FD0202 000415DB 7E ".}.....[~" > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 01030004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Request, ID 3, state Ack-Sent (8) > 9/23-18:06:18-28650 CCP: Replying with Configure-Ack > 9/23-18:06:18-28650 CCP event RCR+, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending CCP Configure-Ack, ID 3, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending 8-byte PPP frame: > 9/23-18:06:18-28650 FF0380FD 02030004 "...}...." > 9/23-18:06:18-28650 Wrote 9 bytes to tty_fd: > 9/23-18:06:18-28650 80FD0203 0004C981 7E ".}....I.~" > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 01040004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Request, ID 4, state Ack-Sent (8) > 9/23-18:06:18-28650 CCP: Replying with Configure-Ack > 9/23-18:06:18-28650 CCP event RCR+, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending CCP Configure-Ack, ID 4, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending 8-byte PPP frame: > 9/23-18:06:18-28650 FF0380FD 02040004 "...}...." > 9/23-18:06:18-28650 Wrote 9 bytes to tty_fd: > 9/23-18:06:18-28650 80FD0204 0004CC0D 7E ".}....L.~" > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 01050004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Request, ID 5, state Ack-Sent (8) > 9/23-18:06:18-28650 CCP: Replying with Configure-Ack > 9/23-18:06:18-28650 CCP event RCR+, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending CCP Configure-Ack, ID 5, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending 8-byte PPP frame: > 9/23-18:06:18-28650 FF0380FD 02050004 "...}...." > 9/23-18:06:18-28650 Wrote 9 bytes to tty_fd: > 9/23-18:06:18-28650 80FD0205 00041057 7E ".}.....W~" > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 01060004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Request, ID 6, state Ack-Sent (8) > 9/23-18:06:18-28650 CCP: Replying with Configure-Ack > 9/23-18:06:18-28650 CCP event RCR+, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending CCP Configure-Ack, ID 6, state Ack-Sent (8) > 9/23-18:06:18-28650 Sending 8-byte PPP frame: > 9/23-18:06:18-28650 FF0380FD 02060004 "...}...." > 9/23-18:06:18-28650 Wrote 9 bytes to tty_fd: > 9/23-18:06:18-28650 80FD0206 000474B8 7E ".}....t8~" ... > 9/23-18:06:18-28650 26 bytes read from tty: > 9/23-18:06:18-28650 7E80FD02 030004C9 817E7EFF 03C0210A "~.}....I.~~..@!." > 9/23-18:06:18-28650 06000800 02A3694E 727E ".....#iNr~" > 9/23-18:06:18-28650 8-byte PPP frame received: > 9/23-18:06:18-28650 FF0380FD 02030004 "...}...." > 9/23-18:06:18-28650 Received CCP Configure-Ack, ID 3, state Ack-Sent (8) > 9/23-18:06:18-28650 CCP event RCA, state Ack-Sent (8) ... > 9/23-18:06:18-28650 59 bytes read from tty: > 9/23-18:06:18-28650 7EFD6000 00214500 00380C00 00002001 "~}`..!E..8.... ." > 9/23-18:06:18-28650 98B14B04 68A1F2C1 1A018018 1DE271E9 ".1K.h!rA.....bqi" > 9/23-18:06:18-28650 803DC244 CDE80000 F046DB47 F623E080 ".=BDMh..pF[Gv#`." > 9/23-18:06:18-28650 20802080 03400000 33FF7E " . ..@..3.~" > 9/23-18:06:18-28650 58-byte PPP frame received: > 9/23-18:06:18-28650 FF0300FD 60000021 45000038 0C000000 "...}`..!E..8...." > 9/23-18:06:18-28650 200198B1 4B0468A1 F2C11A01 80181DE2 " ..1K.h!rA.....b" > 9/23-18:06:18-28650 71E9803D C244CDE8 0000F046 DB47F623 "qi.=BDMh..pF[Gv#" > 9/23-18:06:18-28650 E0802080 20800340 0000 "`. . ..@.." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 10 09:12:18 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA06024; Tue, 10 Oct 1995 09:12:18 -0400 Resent-Date: Tue, 10 Oct 1995 09:12:18 -0400 From: "Laughman, Mike" To: IETF Subject: PPP over ATM AAL5 Date: Tue, 10 Oct 95 09:09:00 EDT Message-Id: <307A7378@cronus.aiinet.com> Encoding: 14 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"rxS242.0.vT1.f4dUm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/779 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Gentlemen, I have read several RFCs concerning PPP over various types of circuits (such as Sonet, ISDN, etc) but have not found anything written about running PPP over ATM AAL5. Do you have any documents concerning the subject ??? Have I missed them or why hasn't it been covered for point-to-point ATM links ?? thanks for your quick response, Michael Laughman Applied Innovation mikel@aiinet.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 10 10:38:26 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA09773; Tue, 10 Oct 1995 10:38:26 -0400 Resent-Date: Tue, 10 Oct 1995 10:38:26 -0400 Date: Tue, 10 Oct 1995 10:37:46 -0400 From: John Shriver Message-Id: <199510101437.KAA22200@shiva-dev.shiva.com> To: MIKEL@cronus.aiinet.com CC: ietf-ppp@MERIT.EDU In-reply-to: <307A7378@cronus.aiinet.com> (MIKEL@cronus.aiinet.com) Subject: Re: PPP over ATM AAL5 Resent-Message-ID: <"rXyTN3.0.UO2.VLeUm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/780 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Resent-Date: Tue, 10 Oct 1995 09:12:10 -0400 From: "Laughman, Mike" To: IETF Subject: PPP over ATM AAL5 Date: Tue, 10 Oct 95 09:09:00 EDT Resent-From: ietf-ppp@MERIT.EDU Resent-Sender: ietf-ppp-request@MERIT.EDU Gentlemen, I have read several RFCs concerning PPP over various types of circuits (such as Sonet, ISDN, etc) but have not found anything written about running PPP over ATM AAL5. Do you have any documents concerning the subject ??? Have I missed them or why hasn't it been covered for point-to-point ATM links ?? thanks for your quick response, Michael Laughman Applied Innovation mikel@aiinet.com I would suspect about the same time that a standard is developed for PPP over Ethernet. Remember PPP ::= Point-to-Point Protocol. It can only negotiate between one set of peers. The whole point of ATM is that it is not a point-to-point medium. It is a many-to-many medium. (ATM may not quite be an LAN yet -- the ATM Forum took a great while designing a workable multicast/broadcast protocol.) I think the ATM Forum would be rather disinterested in seeing PPP run over their ATM. They want to be the universal MAC, Data-Link, and Network layer for the Universe -- PPP is not part of that program. You might try searching for ATM in rfc-index.txt, and see that there is plenty of information on IP (and other protocols as well) over ATM. These protocols all scale down just fine to a network of two nodes. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 10 11:54:30 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA15000; Tue, 10 Oct 1995 11:54:30 -0400 Resent-Date: Tue, 10 Oct 1995 11:54:30 -0400 Date: Tue, 10 Oct 95 14:47:47 GMT From: "William Allen Simpson" Message-ID: <1757.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: PPP over ATM AAL5 Resent-Message-ID: <"Xjcg01.0.0g3.nSfUm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/781 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Laughman, Mike" > I have read several RFCs concerning PPP over various types of circuits > (such as Sonet, ISDN, etc) but have not found anything written about > running PPP over ATM AAL5. Do you have any documents concerning > the subject ??? Have I missed them or why hasn't it been covered for > point-to-point ATM links ?? > This issue raises its head from time to time. You are about the 9th vendor who has asked for it in 3 years. But, in the past, none of them seem to actually implement. The ATM crowd has a tendency to write standards first, and then implement later only when there is "momentum". And so, nothing has been written, since the IETF doesn't work that way. However, now a company _is_ implementing, and I am assisting them in putting together a draft. Should be out for discussion at Dallas. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 11 09:44:26 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA28975; Wed, 11 Oct 1995 09:44:26 -0400 Resent-Date: Wed, 11 Oct 1995 09:44:26 -0400 Date: Wed, 11 Oct 1995 09:43:50 -0400 From: Steven West Yates Message-Id: <199510111343.JAA114213@fulton.seas.Virginia.EDU> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ietf-ppp@MERIT.EDU Subject: Multilink PPP CPU & Memory Requirements Resent-Message-ID: <"IeML_.0.O47.TeyUm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/782 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >From swy8p Tue Oct 10 10:58:39 1995 Received: from virginia.edu (uvaarpa.Virginia.EDU [128.143.2.7]) by fulton.seas.Virginia.EDU (8.6.10/8.6.6) with SMTP id KAA120490 for ; Tue, 10 Oct 1995 10:58:38 -0400 Received: from fulton.seas.virginia.edu by uvaarpa.virginia.edu id ab26272; 10 Oct 95 10:58 EDT Received: (from swy8p@localhost) by fulton.seas.Virginia.EDU (8.6.10/8.6.6) id KAA73624; Tue, 10 Oct 1995 10:58:31 -0400 Date: Tue, 10 Oct 1995 10:58:31 -0400 From: Steven West Yates Message-Id: <199510101458.KAA73624@fulton.seas.Virginia.EDU> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sklower@cs.berkeley.edu, brian@lloyd.com, swy8p@virginia.edu Subject: Multilink PPP CPU/Memory Requirements Status: OR * Note the following was previously sent to the authors of RFC 1717, which * describes the multilink PPP protocol. However, I am still in need of * additional information, and I would greatly appreciate any assistance * you may be able to offer. * --Steve Yates Gentlemen, I am currently developing a protocol processing engine that must implement multilink PPP over a novel RF cable modem system that will provide ISDN-like data services. It is required that multilink support 128 kbps over 2 64 kbps links and it is desired that it support 384 kbps over 6 64 kbps links. >From reading RFC 1717, it appears that multilink has significant requirements for both CPU cycles and buffer memory. I have several related questions, and I would greatly appreciate it if you could help in answering them. First, the issue of CPU choice must be resolved. My current preference is for the Motorola 68302, because of its high speed serial interface and communications coprocessor. However, it is unclear whether the 16 or 20 MHz 68000 core will support multilink with 2 or 6 links at these data rates. Can you offer any advice on this choice? What CPUs have previous multilink implementations been ported to? Second, I would appreciate some help clarifing buffer memory requirements. The RFC clearly specifies a formula by which buffer requirements may be calculated. However, the worst-case relative delay between links is difficult to quantify. In my application, the relative inter-link delay is determined by the following components: (1) delay skews in the RF plant, (2) delay skews in the RF server, (3) delay skews in a 10-base-T point-to- point network, and (4) delay skews between B channels in an ISDN primary rate interface. Of these delay skews, (1) and (2) are internal to our system and are well controlled. However, (3) is non-deterministic and difficult to bound and (4) is also difficult to estimate. Can you offer any advice on buffer space requirements for environments with non-deterministic inter-link delays (as encountered in the 10-base-T network) or with delays encountered in the Public Switched Telephone Network? If you do not know of any numerical answers to this question, could you suggest some good references that may assist me in resolving this? Thank you in advance for your help. Steven W. Yates, P.E. President, ADI Engineering (804) 978-2888 Internet: swy8p@virginia.edu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 16 11:45:30 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA13287; Mon, 16 Oct 1995 11:45:30 -0400 Resent-Date: Mon, 16 Oct 1995 11:45:30 -0400 From: orozco@klatue Message-Id: <9510161543.AA03455@klatue.ctron> To: ietf-ppp@MERIT.EDU Cc: flaherty@klatue, mathie@klatue, steffen@klatue, orozco@klatue Subject: MP issues/question. Date: Mon, 16 Oct 95 11:43:38 -0400 Resent-Message-ID: <"Y1WTB2.0.OF3.0udWm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/783 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Salutations all, The following are a set of questions that I have regarding PPP MP support. I would greatly appreciate any comments/suggestions/solutions that any one may have concerning how should an implementation deal with the following cases. Q1 - Can an LCP link opened for more BW allow to negotiate other support or different parameter values than that that was negotiated for the Bundle's first MP link opened? Q2 - Does closing a bundle's 1st member link result/translate to closing the entire bundle regardless if other member links exist? Q3 - If a fragment is repeated (re-sent) without the receiver knowing why: o should the receiver discard the 1st copy of the fragment and replace it with the most recent duplicate fragment received? Note: Duplicate as far as the fragment's sequence number is concerned. - OR - o should the receiver discard any fragment for which a previous fragment with the same sequence number has already been received? - OR - o should the receiver not only discard that duplicate fragment but also all previously received fragments for that yet incomplete packet? Q4 - Does the MP MRRU have precedence over the LCP MRU or must they both be the same? In essence, what must there relationship be for MP to be negotiated and operate successfully? Q5 - Can an LCP link opened for more BW allow to re-negotiate the exact same support as the Bundle's initial member link? Note: The heart of the question here is does the standard permit this, so that an implementation MUST allow for it - notwithstanding the undersireableness of it given the associated unncessary overhead plus perhaps even the consequence of an implemenation seizing all traffic on all other of its member links for that bundle until the re-negotiation is completed. Best Regards Adrian Orozco (603-329-6723, email:orozco@ctron.com) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 16 12:06:41 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA14340; Mon, 16 Oct 1995 12:06:41 -0400 Resent-Date: Mon, 16 Oct 1995 12:06:41 -0400 From: bade@austin.ibm.com Message-Id: <9510161606.AA17394@r1100rs.austin.ibm.com> Subject: Re: MP issues/question. To: orozco@klatue.austin.ibm.com Date: Mon, 16 Oct 95 11:03:22 CDT In-Reply-To: <9510161543.AA03455@klatue.ctron>; from "orozco@klatue" at Oct 16, 95 11:43 am X-Mailer: ELM [version 2.2 PL16] Resent-Message-ID: <"mtUM_.0.lV3.7CeWm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/784 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I'll take a stab at these, although I'm by no means an expert.. #Q1 - Can an LCP link opened for more BW allow to negotiate other support # or different parameter values than that that was negotiated for # the Bundle's first MP link opened? Yes, the each Link's parameters are independent of the bundle. #Q2 - Does closing a bundle's 1st member link result/translate to closing the # entire bundle regardless if other member links exist? Not by my interpretation of the RFC, as long as an active link exists the bundle should remain intact. #Q3 - If a fragment is repeated (re-sent) without the receiver knowing why: # # o should the receiver discard the 1st copy of the fragment and replace it # with the most recent duplicate fragment received? # Note: Duplicate as far as the fragment's sequence number is concerned. # - OR - # o should the receiver discard any fragment for which a previous # fragment with the same sequence number has already been received? # - OR - # o should the receiver not only discard that duplicate fragment but # also all previously received fragments for that yet incomplete packet? I'd assume that the repeated fragment should be discarded, particularly since the RFC does not specify a retranmsit capability... #Q4 - Does the MP MRRU have precedence over the LCP MRU or must they both be # the same? In essence, what must there relationship be for MP to be # negotiated and operate successfully? The MRRU defines the largest frame that can be created from all the data sent on the bundle (ie the largest frame that can be passed up to the network layer)... The MRU defines the maximum size of a frame that a specific link can handle.. In other words, if you have a bundle with 2 links each with a MRU of 1000, and your MRRU is 1500 then a frame that is the full MRRU in size will be broken into 2 fragments. #Q5 - Can an LCP link opened for more BW allow to re-negotiate the exact same # support as the Bundle's initial member link? I guess I'm not clear on this, there is no requirement that each link in a bundle have the same characteristics (I could have an Async link and an ISDN link with different MRU's). The only thing that I think should be fixed is that the MRRU not change after the first link is allocated to the bundle... Which theoritically should not happen, since the two systems communicating over a bundle are the same (Hopefully, otherwise things are going to be really messed up). -- Regards, Steve ***************************************************************** * RISC SYSTEM/6000 Division --- Team AIX --- * WAN Communications Software Engineer * bade@austin.ibm.com ** I don't speak for IBM ** * (512)838-8207 (T/L 678) * Fax (512)838-3509 ***************************************************************** - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 16 18:34:03 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA28057; Mon, 16 Oct 1995 18:34:03 -0400 Resent-Date: Mon, 16 Oct 1995 18:34:03 -0400 Message-Id: Date: Mon, 16 Oct 95 16:32 MDT From: drew@zippy.compatible.com (Drew Thomas) To: ietf-ppp@MERIT.EDU Subject: Status of CCP Predictor Reply-to: drew@Compatible.COM Resent-Message-ID: <"M5Jvu1.0.2s6.gsjWm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/785 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Could anyone provide me with an update as to the status of the CCP Predictor draft? Specifically, it was suggested earlier in the summer that sequence numbers could be used to detect an error prior to decoding a compressed packet, which appears to solve the problems raised by Motorola's patent. It appears that people implementing other algorithms (such as Stac) are using this approach. Was this taken any farther with Predictor? Were there other problems with this idea? Thanks in advance for any info. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 18 15:23:57 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA12928; Wed, 18 Oct 1995 15:23:57 -0400 Resent-Date: Wed, 18 Oct 1995 15:23:57 -0400 Message-Id: <199510181922.NAA26977@zaphod.develcon.com> X-Sender: homer@zaphod.develcon.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 1995 13:25:52 -0500 To: ietf-ppp@MERIT.EDU From: Homer_Robson@Develcon.com (Homer Robson) Subject: Motorolla Licensing Terms (Where to call) Resent-Message-ID: <"dIZdf.0.b93.dGLXm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/786 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Are the terms for licensing the Motorola patent known? >Where can I get hold of a copy of the terms? I got through Motorola's voice mail maze, and found where to get information on the Motorola patents affecting CPP, & the licensing thereof. The contact is: J. Ray Wood, Patent Law Dept, Motorola. (708)576-5569. Mr. Wood would not discuss the terms over the phone, but has a package discussing the patents, and the licensing terms which he will courier to those who need it. -- Homer_Robson@Develcon.com Compuserve 74051,32 Develcon, 856 51st Street East, Saskatoon, SK,CAN, S7K 5C7 (306)933-3300 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Oct 20 16:43:37 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA22248; Fri, 20 Oct 1995 16:43:37 -0400 Resent-Date: Fri, 20 Oct 1995 16:43:37 -0400 Date: Fri, 20 Oct 1995 13:42:16 -0700 From: fcliu@ttl.pactel.com (Frank C. Liu) Message-Id: <9510202042.AA01965@earth.ttl.pactel.com> To: ietf-ppp@MERIT.EDU Subject: PPP MP over wireless channels X-Sun-Charset: US-ASCII content-length: 439 Resent-Message-ID: <"g5mr_1.0.FP5.Ed0Ym"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/787 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I try to apply PPP MP (RFC1717) over wireless data communications for chanel aggregation. Anybody doing: 1. PPP MP over serial links besides ISDN? Data is taken out from the mobile switching center and connected to a modem or terminal server. 2. Adding/subtracting channels over a bundle? During hand-off, the same number of channels may not be available from the new cell. 3. If not, any needs to have a PPP MP extention? Frank - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 23 02:29:16 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id CAA25668; Mon, 23 Oct 1995 02:29:16 -0400 Resent-Date: Mon, 23 Oct 1995 02:29:16 -0400 Date: Fri, 20 Oct 1995 16:45:01 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510202245.QAA27531@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: PPP MP over wireless channels Cc: fcliu@ttl.pactel.com Resent-Message-ID: <"vQxko2.0.pG6.fOpYm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/788 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: fcliu@ttl.pactel.com (Frank C. Liu) > > I try to apply PPP MP (RFC1717) over wireless data communications for > chanel aggregation. Anybody doing: > > 1. PPP MP over serial links besides ISDN? Data is taken out from the > mobile switching center and connected to a modem or terminal server. > 2. Adding/subtracting channels over a bundle? During hand-off, the same > number of channels may not be available from the new cell. > 3. If not, any needs to have a PPP MP extention? 1. the currently shipping PPP implementation from Silicon Graphics supports RFC 1717 over async modems, various sync serial devices, and certain other media, as well as ISDN B channels. PPP MP is good that way. If you can get a serial link up, you can put PPP over it, and bundle it with other links using MP. 2. the SGI system, like many others, also supports "dynamic bandwidth," or adding and removing links as suggested by load, or just the termination (graceful or not) of a link in the bundle by the peer. 3. what do you have in mind? Ascend has a proprietary extension (ab)using LCP option that involves communicating telephone numbers and so forth in support of dynamic bandwidth. I think a minimal protocol along those lines would be a good idea, but I'm pessimistic that the IETF can reach concensus on anything useful and implementable in less than 2 or 3 years. I have not looked at Ascend's protocol; it might be just the ticket. I understand that Ascend is now offering to license their protocol for free. If I were in charge of Ascend, I would have submitted an Informational Internet Draft and offered to modify the protocol through the PPP working group instead of making press releases offering free licenses, but then I also would not have glommed onto LCP option #0 without talking to the IANA. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 24 12:12:52 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA13841; Tue, 24 Oct 1995 12:12:52 -0400 Resent-Date: Tue, 24 Oct 1995 12:12:52 -0400 Date: Tue, 24 Oct 1995 09:12:00 -0700 From: fcliu@ttl.pactel.com (Frank C. Liu) Message-Id: <9510241612.AA02217@earth.ttl.pactel.com> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: re: PPP MP over wireless channels X-Sun-Charset: US-ASCII content-length: 702 Resent-Message-ID: <"lMqXH.0.2O3.i1HZm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/789 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> 3. If not, any needs to have a PPP MP extention? > what do you have in mind? > Vernon Schryver, vjs@sgi.com It seems that there is a need for a PPP MP extention on wireless data communications: - Access speed enhancement on wireless communications could very well be the 2nd major application for PPP MP, besides ISDN. The digital cellular or PCS uses multiple radio channels (or time slots) in which some of the channels can be aggregated to increase access speed. - Mobility or hand-off between cells is a unique problem of wireless communications. If there are fewer channels available on the new cells, how should PPP MP work? Should PPP MP make-before-break? etc.. Frank - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 24 12:41:25 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA14730; Tue, 24 Oct 1995 12:41:25 -0400 Resent-Date: Tue, 24 Oct 1995 12:41:25 -0400 Date: Tue, 24 Oct 1995 10:39:00 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199510241639.KAA02457@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU, fcliu@ttl.pactel.com (Frank C. Liu) Subject: re: PPP MP over wireless channels Resent-Message-ID: <"GFlCL2.0.qb3.MSHZm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/790 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: fcliu@ttl.pactel.com (Frank C. Liu) > To: ietf-ppp@merit.edu, vjs > >> 3. If not, any needs to have a PPP MP extention? > > what do you have in mind? > It seems that there is a need for a PPP MP extention on wireless data > communications: > > - Access speed enhancement on wireless communications could very well > be the 2nd major application for PPP MP, besides ISDN. The digital > cellular or PCS uses multiple radio channels (or time slots) in which > some of the channels can be aggregated to increase access speed. > - Mobility or hand-off between cells is a unique problem of wireless > communications. If there are fewer channels available on the new cells, > how should PPP MP work? Should PPP MP make-before-break? etc.. All of those sound like things that should be considered above PPP (e.g. Mobile IP) or below PPP (e.g. IEEE 802.something--is it 802.10?). I do not see how it would be practical for a PPP sub-protocol such as MP to help in any of those areas. Specifically: - whether something is a "killer application" is unrelated to technical considerations of which glob of hardware or software should implement which part of the application. - I think there are currently vastly more PPP links over modems than ISDN circuits. ISDN is finally becoming noticable, but it is still very puny compared to modems. - the bandwidth allocate to a given subscriber is likely to vary too quickly for PPP or MP to be relevant. The machinery used to notify the mobile telephone of the change is likely to have nothing to do with PPP. - if handing off among cells is visible to PPP, then IP addresses are probably changing, and that would be a Very Bad Thing(tm) for existing and likely applications. - PPP currently copes just fine with channels whose bandwidth varies dramatically. Those zillions of v.34, v.32bis, v.32, and Telebit PEP modems implement links whose bandwidth can vary by a factor of 10. I understand that at least some people looking at cellular data are thinking about doing their own fragmentation, reassembly, and even forward error correction or retransmissions below the subscriber's notice. Given the very high error rates plausible with cellular telephones, such things make sense. Between which two end points is PPP being considered? Between the mobile computer of the subscriber and the subscriber's "server"? So that the subscriber would have a PPP link over a composite telephone circuit involving a copper local loop, various central offices and digital stuff, and the last, cellular hop? If so, then PPP MP is irrelevant. In that topology, any multilinking must be end-to-end, over the entire path between the subscriber's computers. You wouldn't want to add and remove telephone circuits between the cell system and the non-mobile server just because things are changing on the other part of the circuit. Only if the cellular transmitter itself has an IP address and the PPP connection is only between the mobile device and an IP router in the cellular system would PPP MP be relevant to to cellular data. (Yes, PPP can do other things besides IP, but this consideration applies to all other NCP's.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 24 13:12:47 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA15549; Tue, 24 Oct 1995 13:12:47 -0400 Resent-Date: Tue, 24 Oct 1995 13:12:47 -0400 Date: Tue, 24 Oct 1995 10:11:53 -0700 From: fcliu@ttl.pactel.com (Frank C. Liu) Message-Id: <9510241711.AA02224@earth.ttl.pactel.com> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: re: PPP MP over wireless channels X-Sun-Charset: US-ASCII content-length: 570 Resent-Message-ID: <"Lsqcf.0.ko3.CwHZm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/791 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: vjs@mica.denver.sgi.com (Vernon Schryver) > All of those sound like things that should be considered above PPP > (e.g. Mobile IP) or below PPP (e.g. IEEE 802.something--is it 802.10?). > I do not see how it would be practical for a PPP sub-protocol such as MP > to help in any of those areas. Good points. The PPP MP and mobility issue may need to first be dicussed at the PCS/wireless forums or standards. Just a point of clarification, my proposal is to implement PPP MP between handset and the IWF in the mobile switching center, not end-to-end. Frank - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 24 20:27:11 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA28798; Tue, 24 Oct 1995 20:27:11 -0400 Resent-Date: Tue, 24 Oct 1995 20:27:11 -0400 Date: Tue, 24 Oct 95 23:49:21 GMT From: "William Allen Simpson" Message-ID: <1911.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: PPP MP over wireless channels Resent-Message-ID: <"n7Uy5.0.c17.OHOZm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/792 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: fcliu@ttl.pactel.com (Frank C. Liu) > Good points. The PPP MP and mobility issue may need to first be dicussed > at the PCS/wireless forums or standards. Just a point of clarification, > my proposal is to implement PPP MP between handset and the IWF in > the mobile switching center, not end-to-end. > This is already defined, albeit the committee contracted featuritis from the original Karn and Simpson design. See EIA/TIA IS-99. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 25 16:15:24 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA26999; Wed, 25 Oct 1995 16:15:24 -0400 Resent-Date: Wed, 25 Oct 1995 16:15:24 -0400 Date: Wed, 25 Oct 1995 13:14:45 -0700 X-Sender: timon@foxtrot.rahul.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU From: timon@timonware.com (Timon Sloane) Subject: public domain ppp implementations Resent-Message-ID: <"pG57i1.0.Gb6.2hfZm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/793 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What public domain ppp implementations are available? thanks, timon - - - - - - - - - - - - - - - - -