From ietf-ppp-request@MERIT.EDU Mon Apr 1 12:17:00 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA21745; Mon, 1 Apr 1996 12:17:00 -0500 (EST) Resent-Date: Mon, 1 Apr 1996 12:17:00 -0500 (EST) Date: Mon, 1 Apr 1996 10:15:25 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604011715.KAA12588@mica.denver.sgi.com> To: ppp Subject: RE:BA(C)P without MP Resent-Message-ID: <"ki1JT1.0.8J5.0z0On"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1471 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Ron Cohen > > What good is sending the Link-Drop-Query-Request before actually hanging? > >Why not just send a Terminate-Request? > >I've been running a symmetric demand-dialed PPP link for years, and > >have never needed more than Terminate-Requests. > > We have a customer which uses Video monitoring. Most of the traffic runs > uni-directional from the remote site (the camera) to the center. When the > camera detects an event that needs to be informed to the center it triggers > the line by sending frames to the center. But it may happen that the manager > from the center wishes to see what is going on in the branch, and triggers > the line from the center to the branch. After the line is triggered, once > more the traffic runs mostly from the branch to the center (no Acks). > Our algorithm to decide when to disconnect the line is by examining the > traffic sent on the line, not the traffic received. Therefore, when the line > is triggered from the center, we may decide to terminate the connection > while traffic is still being sent from the branch. In this case, a > Link-Drip-Query-Request would help. On the contrary., in that case a Link-Drip-Query-Request can convey absolutely no more information either or both: 1. fixing your line-activity detecting code. 2. terminate request. > In any case, suppose I want to use MP + BA(C)P but I begin with one link, > and may want to use a second link on demand. Should I negotiate MP on this > single line before using BA(C)P or only after the second line is up? BA(C)P has absolutely nothign to do with that question. It is best to in that case to always send the MP LCP CR options even when you are using only 1 line, and to omit the MP header when only one link is in the bundle, but you could always send a new LC CR on a non-MP link and hope the peer is willing to turn on MP. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 1 12:57:37 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA23329; Mon, 1 Apr 1996 12:57:37 -0500 (EST) Resent-Date: Mon, 1 Apr 1996 12:57:37 -0500 (EST) From: Dana Blair Message-Id: <199604011756.JAA16855@stilton.cisco.com> Subject: Re: BA(C)P without MP To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Mon, 1 Apr 1996 09:56:20 -0800 (PST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199604011715.KAA12588@mica.denver.sgi.com> from "Vernon Schryver" at Apr 1, 96 10:15:25 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KNmwH2.0.Ei5.Da1On"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1472 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > From: Ron Cohen > > > > What good is sending the Link-Drop-Query-Request before actually hanging? > > >Why not just send a Terminate-Request? > > >I've been running a symmetric demand-dialed PPP link for years, and > > >have never needed more than Terminate-Requests. > > > > We have a customer which uses Video monitoring. Most of the traffic runs > > uni-directional from the remote site (the camera) to the center. When the > > camera detects an event that needs to be informed to the center it triggers > > the line by sending frames to the center. But it may happen that the manager > > from the center wishes to see what is going on in the branch, and triggers > > the line from the center to the branch. After the line is triggered, once > > more the traffic runs mostly from the branch to the center (no Acks). > > Our algorithm to decide when to disconnect the line is by examining the > > traffic sent on the line, not the traffic received. Therefore, when the line > > is triggered from the center, we may decide to terminate the connection > > while traffic is still being sent from the branch. In this case, a > > Link-Drip-Query-Request would help. > > On the contrary., in that case a Link-Drip-Query-Request can convey > absolutely no more information either or both: > > 1. fixing your line-activity detecting code. > 2. terminate request. > Actually, this is an excellent example of the need for the Link-DrOp-Query- Request. The Link-Drop-Query-Request will prevent the link from being disconnected and reconnected immediately because one end needs the bandwidth and will NAK/REJ the request. Terminate request will bring the link down. See discussion on state transition associated with the terminate request. So that does not prevent the disconnect/reconnect sequence. Fixing the line-activity code is not a complete solution either. You would also have to require compatible configurations on the either end. The configuration compatibility becomes a nightmare when you have a multivendor meshed network with several possible peer combinations. Add application dependent requirements like realtime video and the complexity goes up even more. Now the BoD algorithm needs to know what application is running. Dana Blair > > In any case, suppose I want to use MP + BA(C)P but I begin with one link, > > and may want to use a second link on demand. Should I negotiate MP on this > > single line before using BA(C)P or only after the second line is up? > > BA(C)P has absolutely nothign to do with that question. It is best to > in that case to always send the MP LCP CR options even when you are > using only 1 line, and to omit the MP header when only one link > is in the bundle, but you could always send a new LC CR on a non-MP > link and hope the peer is willing to turn on MP. > > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 1 16:05:11 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA29319; Mon, 1 Apr 1996 16:05:11 -0500 (EST) Resent-Date: Mon, 1 Apr 1996 16:05:11 -0500 (EST) Date: Mon, 1 Apr 1996 14:04:30 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604012104.OAA12900@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: BA(C)P without MP Resent-Message-ID: <"uvZGb2.0.g97.jJ4On"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1473 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Dana Blair > The Link-Drop-Query-Request will prevent the link from being disconnected > and reconnected immediately because one end needs the bandwidth and will > NAK/REJ the request. > > Terminate request will bring the link down. See discussion on state > transition associated with the terminate request. So that does not > prevent the disconnect/reconnect sequence. Yes, please do see all of that discusssion. All current vendors of MP code agreed in that previous of TR's that one TR does not take down the whole bundle. > Fixing the line-activity code is not a complete solution either. You > would also have to require compatible configurations on the either end. > The configuration compatibility becomes a nightmare when you have > a multivendor meshed network with several possible peer combinations. > > Add application dependent requirements like realtime video and the > complexity goes up even more. Now the BoD algorithm needs to know > what application is running. That is false both in theory and in real life. Silicon Graphics provides realtime video applications that run over PPP. My PPP code does not know which applications are running. Still, demand-bandwidth works just fine. It turns out that for video conferencing, it's handy to use an MTU of ~300 bytes at 64-128 kbit/sec, but that's a different discussion. Most of us agree that it is necessary that the 1st caller must originate all calls, even with BA(C)P. That means that the 1st caller ought to monitor load in both directions, and bring up and take down links. With ISDN, monitoring load in both directions is easy. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 3 15:10:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA05956; Wed, 3 Apr 1996 15:10:02 -0500 (EST) Resent-Date: Wed, 3 Apr 1996 15:10:02 -0500 (EST) From: Dana Blair Message-Id: <199604032008.MAA06199@stilton.cisco.com> Subject: Re: BA(C)P without MP To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 3 Apr 1996 12:08:18 -0800 (PST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199604012104.OAA12900@mica.denver.sgi.com> from "Vernon Schryver" at Apr 1, 96 02:04:30 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ForEn1.0.TS1.MhjOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1474 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > From: Dana Blair > > > > The Link-Drop-Query-Request will prevent the link from being disconnected > > and reconnected immediately because one end needs the bandwidth and will > > NAK/REJ the request. > > > > Terminate request will bring the link down. See discussion on state > > transition associated with the terminate request. So that does not > > prevent the disconnect/reconnect sequence. > > Yes, please do see all of that discusssion. All current vendors of MP > code agreed in that previous of TR's that one TR does not take > down the whole bundle. > I did not say bring down the whole bundle. The purpose of the Link-Drop- Query-Request is to prevent the link from being disconnected and immediately reconnected because one peer thinks it needs the bandwidth and the other does not. The goal here is to prevent an unnecessary disconnect then reconnect sequence. > > > Fixing the line-activity code is not a complete solution either. You > > would also have to require compatible configurations on the either end. > > The configuration compatibility becomes a nightmare when you have > > a multivendor meshed network with several possible peer combinations. > > > > Add application dependent requirements like realtime video and the > > complexity goes up even more. Now the BoD algorithm needs to know > > what application is running. > > That is false both in theory and in real life. Silicon Graphics > provides realtime video applications that run over PPP. My PPP code > does not know which applications are running. Still, demand-bandwidth > works just fine. It turns out that for video conferencing, it's > handy to use an MTU of ~300 bytes at 64-128 kbit/sec, but that's > a different discussion. > > Most of us agree that it is necessary that the 1st caller must > originate all calls, even with BA(C)P. That means that the 1st caller > ought to monitor load in both directions, and bring up and take down > links. With ISDN, monitoring load in both directions is easy. > > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 3 15:21:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA06621; Wed, 3 Apr 1996 15:21:45 -0500 (EST) Resent-Date: Wed, 3 Apr 1996 15:21:45 -0500 (EST) From: Dana Blair Message-Id: <199604032020.MAA06661@stilton.cisco.com> Subject: Re: BA(C)P without MP To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 3 Apr 1996 12:20:21 -0800 (PST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199604012104.OAA12900@mica.denver.sgi.com> from "Vernon Schryver" at Apr 1, 96 02:04:30 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0dqq63.0.Cd1.JtjOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1475 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am resending this with my complete response. > > > From: Dana Blair > > > > The Link-Drop-Query-Request will prevent the link from being disconnected > > and reconnected immediately because one end needs the bandwidth and will > > NAK/REJ the request. > > > > Terminate request will bring the link down. See discussion on state > > transition associated with the terminate request. So that does not > > prevent the disconnect/reconnect sequence. > > Yes, please do see all of that discusssion. All current vendors of MP > code agreed in that previous of TR's that one TR does not take > down the whole bundle. > I did not say bring down the whole bundle. The purpose of the Link-Drop- Query-Request is to prevent the link from being disconnected and immediately reconnected because one peer thinks it needs the bandwidth and the other does not. The goal here is to prevent an unnecessary disconnect then reconnect sequence. > > > Fixing the line-activity code is not a complete solution either. You > > would also have to require compatible configurations on the either end. > > The configuration compatibility becomes a nightmare when you have > > a multivendor meshed network with several possible peer combinations. > > > > Add application dependent requirements like realtime video and the > > complexity goes up even more. Now the BoD algorithm needs to know > > what application is running. > > That is false both in theory and in real life. Silicon Graphics > provides realtime video applications that run over PPP. My PPP code > does not know which applications are running. Still, demand-bandwidth > works just fine. It turns out that for video conferencing, it's > handy to use an MTU of ~300 bytes at 64-128 kbit/sec, but that's > a different discussion. > I agree that many applications do not fiddle with bandwidth requirements over PPP links at this point in time. The requirement to use existing applications as is ( no modifications ) forces the person configuring the multilink interface or whatever to put in the right parameters to bring up the required amount of bandwidth and keep it from disconnecting at the wrong time. Thus my point above: > > The configuration compatibility becomes a nightmare when you have > > a multivendor meshed network with several possible peer combinations. > Most of us agree that it is necessary that the 1st caller must > originate all calls, even with BA(C)P. That means that the 1st caller > ought to monitor load in both directions, and bring up and take down > links. With ISDN, monitoring load in both directions is easy. > Are you claiming consensus on the this point ? With BACP , clients don't even need to implement BoD algorithms or configure demand-dial parameters. As long as they can make the first phone call, the server or service provider manages the rest using the Callback request or Call request. So I believe there are many instances where the first caller does not need to monitor the load and may or may not make the second call. Dana Blair > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 3 21:13:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA16457; Wed, 3 Apr 1996 21:13:13 -0500 (EST) Resent-Date: Wed, 3 Apr 1996 21:13:13 -0500 (EST) Content-Type: text/plain Message-ID: X-Mailer: Novell GroupWise 4.1 Date: Wed, 03 Apr 1996 21:10:32 -0500 From: RSALES@novell.com (Randy Sales) To: ietf-ppp@MERIT.EDU Subject: PSCP Interoperability testing - interest level Resent-Message-ID: <"6k08l1.0.m04.Q_oOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1476 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all, Is anyone interested in doing (informal) interoperability testing of PSCP at the ISDN PPP Interoperability Workshop (May 20 - 24). This is by no means a solicitation for a committment. Regards, Randy Sales, Novell, Inc. 408.577.8912 rsales@novell.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 3 22:12:26 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA18180; Wed, 3 Apr 1996 22:12:26 -0500 (EST) Resent-Date: Wed, 3 Apr 1996 22:12:26 -0500 (EST) Date: Wed, 3 Apr 1996 20:12:07 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604040312.UAA15428@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: BA(C)P without MP Resent-Message-ID: <"teZ7C2.0.oR4.MupOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1477 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Dana Blair > I did not say bring down the whole bundle. The purpose of the Link-Drop- > Query-Request is to prevent the link from being disconnected and immediately > reconnected because one peer thinks it needs the bandwidth and the > other does not. > > The goal here is to prevent an unnecessary disconnect then reconnect > sequence. Oh, I didn't understand. Nevertheless, the Link-Drop-Query-Request is useless in real life for such a purpose. The Link-Drop-Query-Request cannot and will not prevent unnecessary disconnect then reconnect sequences. If your implementation follows the universal rule that the system that made the first call makes and terminates all other calls, then there can be no disagreement that might liead to disconnect then reconnect sequences. The called system is not involved except possibly to ask the calling system to <> another system, and then only if BACP is involved. On an ISDN or other sync link (i.e. neither modem nor v.120+v.42bis) there is no reason for both PPP systems to monitor load and to possibly have disagreements, whether by dialing and hanging up on each other or by sending and rejecting BACP Link-Add requests. Both systems have all necessary information. They can differ only in their policies. The piper calls the tune, which is to say that the caller is the system that decides whether to add or delete the first, second, and all other links. There is no plausible situation involving sync. links where the callee cares, with the possible exception of dial-back for second links. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 3 22:52:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA19339; Wed, 3 Apr 1996 22:52:15 -0500 (EST) Resent-Date: Wed, 3 Apr 1996 22:52:15 -0500 (EST) Date: Wed, 3 Apr 1996 20:51:29 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604040351.UAA15669@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: BA(C)P without MP Resent-Message-ID: <"QbCfS2.0.yj4.gTqOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1478 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Dana Blair > I am resending this with my complete response. Ooops. I'm sorry I didn't read all of my mail first, and so I will also speak twice. > I did not say bring down the whole bundle. The purpose of the Link-Drop- > Query-Request is to prevent the link from being disconnected and immediately > reconnected because one peer thinks it needs the bandwidth and the > other does not. > > The goal here is to prevent an unnecessary disconnect then reconnect > sequence. Oh, I didn't understand. Nevertheless, the Link-Drop-Query-Request is useless in real life for such a purpose. The Link-Drop-Query-Request cannot and will not prevent unnecessary disconnect then reconnect sequences. If your implementation follows the universal rule that the system that made the first call makes and terminates all other calls, then there can be no disagreement that might liead to disconnect then reconnect sequences. The called system is not involved except possibly to ask the calling system to <> another system, and then only if BACP is involved. On an ISDN or other sync link (i.e. neither modem nor v.120+v.42bis) there is no reason for both PPP systems to monitor load and to possibly have disagreements, whether by dialing and hanging up on each other or by sending and rejecting BACP Link-Add requests. Both systems have all necessary information, and so either, and particularly the first caller can know what to do. They can differ only in their policies. The piper calls the tune, which is to say that the caller is the system that should decide whether to add or delete the first, second, and all other links. I cannot think of a plausible situation involving sync links where the callee even cares, with the possible exception of dial-back for second links. > ... > > works just fine. It turns out that for video conferencing, it's > > handy to use an MTU of ~300 bytes at 64-128 kbit/sec, but that's > > a different discussion. > > I agree that many applications do not fiddle with bandwidth requirements > over PPP links at this point in time. I don't think I meant to say that. My code dynamically adds and removes links and has in commercial installations for a year or two. (Before RFC 1717, (and still) it supported "BF&I", a.k.a. "load balancing" or "round robin".) > The requirement to use existing applications as is ( no modifications ) > forces the person configuring the multilink interface or whatever to > put in the right parameters to bring up the required amount of bandwidth > and keep it from disconnecting at the wrong time. That is false, at least in my implementation. In my code, the user need only specify the maximum number of phone calls that the system is allowed to make. The user can optionally fiddle with other parameters. However, with the weak exception of the timeouts for the entire bundle, in my experience based on a bunch of real life, operational installations, all such fiddling is wrong. Some people insist on twisting all of the knobs, but they only make things worse. > Thus my point above: > > > The configuration compatibility becomes a nightmare when you have > > > a multivendor meshed network with several possible peer combinations. > > > Most of us agree that it is necessary that the 1st caller must > > originate all calls, even with BA(C)P. That means that the 1st caller > > ought to monitor load in both directions, and bring up and take down > > links. With ISDN, monitoring load in both directions is easy. > > Are you claiming consensus on the this point ? Consensus on points of verifiable fact is irrelvant. Consensus is a relevant notion for how to deal with facts. There may be a concensus on whether BACP is good and useful (with me disagreeing). However, it is a technical fact for which concensus is irrelevant that both peers easily know the state of sync links. Both peers can easily monitor bit rates and so know whether the link is saturated or not. Yes, the receiver cannot precisely know the depth of the sender's queue, but the receiver can know whether the link is saturated. If a link is running at close to 100%, then simple queuing theory tells you that the sender at least some of the time has more than 100% load to offer. > With BACP , clients don't even need to implement > BoD algorithms or configure demand-dial parameters. Not so. BoD algorithms are dirt simple, amounting to few lines of code. Doesn't everyone's code count bytes, if only for LQM or SNMP monitoring? Given those counts and the clock needed for LCP, IPCP, or BACP, you have all that is needed for a BoD algorithm. BoD is not rocket science. Furthermore, without a BoD algorithm, how do you dynamically start the first link? You cannot use BACP at all unless your BoD algorithm is smart enough to start the first link. In all cases, the caller must have some configured demand-dial parameters, since otherwise the first link in the bundle cannot be brought up. In my experience, parameters for adding additional links are best fixed and not changed by users. There are a bunch of installations of my code. Many people fiddle with the initial link and overall bundle parameters (generally foolishly), but none that I've heard of fiddle with the additional link parameters, except the parameters that specify the total and minimum numbers of links. I have heard absolutely no requests for more knobs to fiddle the BoD parameters. > As long as they can make the first phone call, the server or service provider > manages the rest using the Callback request or Call request. > > So I believe there are many instances where the first caller does not > need to monitor the load and may or may not make the second call. Previous (released, in commercial, real-life use) versions of my code let either the callee or first caller add additional on-demand links to the bundle. I found having the callee make the second call is a bad idea for a lot of reasons, including billing, predictability, and understandability. Having the caller do all load monitoring and make all calls made a lot of people happy. BACP would not have helped. i have never heard of "thrashing" except by rumor from other vendors. I have never heard nor thought of a thrashing scenario that did not involve very serious misconfiguration. Cisco has repeated mentioned thrashing, but not responded to my requests for a concrete scenario. Perhaps you see thrashing because of features or parameters or other characteristics in your code but absent from mine. Please describe a non-error scenario in which thrashing occurs. Or please describe those parameters that users must configure correctly to prevent thrashing and/or that require the Link-Drop-Query-Request. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 4 02:30:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id CAA24497; Thu, 4 Apr 1996 02:30:06 -0500 (EST) Resent-Date: Thu, 4 Apr 1996 02:30:06 -0500 (EST) Sender: okorf@netcs.com Message-Id: <31637AD9.19F6@netcs.com> Date: Thu, 04 Apr 1996 09:31:37 +0200 From: Oliver Korfmacher Organization: NetCS Informationstechnik GmbH X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: Vernon Schryver Cc: ietf-ppp@MERIT.EDU Subject: Re: BA(C)P without MP References: <199604040351.UAA15669@mica.denver.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cO7891.0.9z5.KftOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1479 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver wrote: > .. > > .. > > With BACP , clients don't even need to implement > > BoD algorithms or configure demand-dial parameters. > > Not so. > BoD algorithms are dirt simple, amounting to few lines of code. > Doesn't everyone's code count bytes, if only for LQM or SNMP > monitoring? Given those counts and the clock needed for LCP, IPCP, or > BACP, you have all that is needed for a BoD algorithm. BoD is not > rocket science. Furthermore, without a BoD algorithm, how do you > dynamically start the first link? You cannot use BACP at all unless > your BoD algorithm is smart enough to start the first link. Not so. BoD algorithms are not required to be simple. One may relate the decision to add (!) a link to length of the queue of packets to be send, or even a average of this queue length. I am absolutely not sure (yet) if this approach (which we use) is better than the one you mentioned, but at least it is working quite well (for add, for remove we use a idle thing as you do). This, obviously, shows that both sides must be able to establish a connection, (or use BACP to request addition of a channel to the bundle) since the queue length is only locally known. As you (Vern) stated earlier, support for applications with asymmetrical traffic is needed. > > So I believe there are many instances where the first caller does not > > need to monitor the load and may or may not make the second call. > > Previous (released, in commercial, real-life use) versions of my code > let either the callee or first caller add additional on-demand links to > the bundle. I found having the callee make the second call is a bad > idea for a lot of reasons, including billing, predictability, and > understandability. > All true, but these reasons should influence the configuration but not the whole bundling thing? If, for reasons we do not see now, it is needed that the callee makes a call, we should have the standards allowing that. Oliver - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 4 08:33:05 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA06592; Thu, 4 Apr 1996 08:33:05 -0500 (EST) Resent-Date: Thu, 4 Apr 1996 08:33:05 -0500 (EST) From: Karl Fox Date: Thu, 4 Apr 96 08:31:46 -0500 Message-Id: <9604041331.AA02712@gefilte.MorningStar.Com> To: Oliver Korfmacher Cc: ietf-ppp@MERIT.EDU Subject: Re: BA(C)P without MP In-Reply-To: <31637AD9.19F6@netcs.com> References: <199604040351.UAA15669@mica.denver.sgi.com> <31637AD9.19F6@netcs.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"F_ynQ1.0.cc1.szyOn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1480 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Oliver Korfmacher writes: > If, for reasons we do not see now, it is needed that the callee > makes a call, we should have the standards allowing that. Sorry, no. Our task is to create and document currently needed and working protocols. If a feature will be needed in the future, we can add it then. -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 4 09:43:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA08781; Thu, 4 Apr 1996 09:43:59 -0500 (EST) Resent-Date: Thu, 4 Apr 1996 09:43:59 -0500 (EST) Date: Thu, 4 Apr 1996 07:43:17 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604041443.HAA16391@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: BA(C)P without MP Resent-Message-ID: <"i1H2K2.0.-82.d0-On"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1481 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Oliver Korfmacher > > BoD algorithms are dirt simple, amounting to few lines of code. > > ... > Not so. > BoD algorithms are not required to be simple. One may relate the decision > to add (!) a link to length of the queue of packets to be send, or even > a average of this queue length. I am absolutely not sure (yet) if this > approach (which we use) is better than the one you mentioned, but at least > it is working quite well (for add, for remove we use a idle thing as you do). Watching the queue length counts as simple in my book, but maybe the point is that inferring the queue length of the transmitter from the receiving PPP system is not simple. If so, I do not agree. > This, obviously, shows that both sides must be able to establish a connection, > (or use BACP to request addition of a channel to the bundle) since the queue length > is only locally known. As you (Vern) stated earlier, support for applications > with asymmetrical traffic is needed. No, I've claimed that the queue length of the transmitter can be easily inferred by the receiver based on link load. If the link is persistently significantly less than 100% loaded, the receiver knows the transmitter queue is trivial, and more, the receiver knows how many links should be removed from the bundle. If the link is persistently 100% full, then the receiver knows the transmitter's queue is long enough to justify at least one additional link in the bundle. > > > So I believe there are many instances where the first caller does not > > > need to monitor the load and may or may not make the second call. > > > > Previous (released, in commercial, real-life use) versions of my code > > let either the callee or first caller add additional on-demand links to > > the bundle. I found having the callee make the second call is a bad > > idea for a lot of reasons, including billing, predictability, and > > understandability. > > > All true, but these reasons should influence the configuration but not the > whole bundling thing? I do not understand that sentence. I think the "configuration" consists of phone numbers and criteria for adding and removing links. If you have the first caller make and break all calls, then I do not see why you need a delete-link request. Given dirt-simple received bit-rate monitoring, the first caller can also know when to add more links reqardless of the direction of the traffic. I see no need for either BACP delete-link nor add-link requests. > If, for reasons we do not see now, it is needed that > the callee makes a call, we should have the standards allowing that. I am of the school that does not admit admiration for unneeded features, that applies Occam's Razor to designs. I think that unless a clear, compelling need is demonstrated, one that cannot be adaquetly satisfied in any other way a feature, protocol, or whatever should be at least postponed. PPP is already grossly bloated by galloping featurism, by things that no one will ever implement. I don't think that is a good thing nor something that should be made worse. Given BACP add- and delete-link requests, you could use them, but they are not strictly necessary. The first caller can correctly add and delete all links when using sync PPP links. Furthermore, since BACP will not be present in many BoD MP peers at least at first, you must for competative reasons implement BoD without BACP. Since you are forced to support BoD without BACP, why ever support BoD with BACP? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 4 12:37:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA14507; Thu, 4 Apr 1996 12:37:19 -0500 (EST) Resent-Date: Thu, 4 Apr 1996 12:37:19 -0500 (EST) Message-Id: <199604041735.JAA18650@vandys-lap.cisco.com> X-Authentication-Warning: vandys-lap.cisco.com: Host localhost.cisco.com [127.0.0.1] didn't use HELO protocol To: ietf-ppp@MERIT.EDU Subject: L2F, updated draft Date: Thu, 04 Apr 1996 09:35:20 -0800 From: Andy Valencia Resent-Message-ID: <"YR54e3.0.9Y3.3Y0Pn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1482 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have submitted an updated draft for the L2F protocol, to appear shortly. Its filename will likely be draft-ietf-pppext-l2f-02.txt. The following changes have been made based on comments received: 1. "Layer", not "Level", as in "Layer 2 Forwarding" 2. Document status is "Internet Draft", not "Experimental" 3. Clarification of requirements, do not require telco-level support 4. HDLC CRC is *not* present in forwarded packet, in either direction. L2F CRC is present as previously specified, based on C bit. 5. P (priority) bit added 6. Some tidying and centralization of illegal packet handling 7. must->MUST, as appropriate to draw out required actions of the protocol 8. Note about use of "offset"/F usage 9. A great deal of clarification of authentication handling, both between tunnel endpoints and WRT clients 10. L2F_CONF_TYPE is actually L2F_OPEN_TYPE; there is only one kind of authentication between tunnel endpoints, and many types on behalf of clients 11. Multilink PPP across multiple Home Gateways; an error code has been added to "guide" the NAS to try a different Home Gateway 12. Optional protection against out-of-sequence packets 13. Snapshot of initial client CONFREQ to aid Home Gateway in detecting latent capabilities of the client. 14. Heavily reworked state tables 15. Editorial cleanup, citations 16. Added previously implicit details of UDP implementation 17. Optional handling of out-of-sequence packets, new Sequence bit Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 5 18:21:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA08113; Fri, 5 Apr 1996 18:21:15 -0500 (EST) Resent-Date: Fri, 5 Apr 1996 18:21:15 -0500 (EST) 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-l2f-02.txt Date: Fri, 05 Apr 96 17:26:09 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9604051726.aa20600@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"WEj2Q1.0.T-1.ngQPn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1483 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. Title : Layer Two Forwarding (Protocol) "L2F" Author(s) : A. Valencia, M. Littlewood, T. Kolar Filename : draft-ietf-pppext-l2f-02.txt Pages : 27 Date : 04/04/1996 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. 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-l2f-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2f-02.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 (193.205.245.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-l2f-02.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: <19960404141731.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2f-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2f-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960404141731.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 8 12:26:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA14201; Mon, 8 Apr 1996 12:26:58 -0400 (EDT) Resent-Date: Mon, 8 Apr 1996 12:26:58 -0400 (EDT) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: IESG Secretary Subject: Protocol Action: PPP in Frame Relay to Proposed Standard Date: Mon, 08 Apr 96 12:19:38 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9604081219.aa13355@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"_QPeo2.0._S3.6uJQn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1484 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has approved the Internet-Draft "PPP in Frame Relay" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeff Burgan. Technical Summary The "PPP In Frame Relay" protocol describes the use of Frame Relay for carrying PPP-encapsulated packets. This is of particular importance to those who wish to use PPP-specific facilities, such as LCP, NCP, authentication, and compression. This is only applicable to nodes which use Frame Relay in a point-to-point manner. Mesh, or multi-access, networking is not supported. Working Group Summary This protocol is the result of a prolonged effort in the PPP Working group. There was considerable discussion on the relative merits of this protocol and other proposals which were put forth. The working group agreed that this protocol addressed some different issues than the other proposals and agreed to put forward this proposal. Protocol Quality This protocol has been reviewed by Frank Kastenholz, Co-Internet Area Director. There are two known implementations of this protocol. There may be others. Notes to RFC Editor: The following references need to get updated... [1] Should now refer to the updated RFC 1661, July 1994. [3] Should now refer to the published RFC 1662, July 1994 [4] Should now refer to the updated RFC 1490, July 1993. Also, the new chair's name and address should be include in the RFC. This will replace Fred Baker's name. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 8 12:33:44 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA14597; Mon, 8 Apr 1996 12:33:44 -0400 (EDT) Resent-Date: Mon, 8 Apr 1996 12:33:44 -0400 (EDT) To: IETF-Announce:; Cc: Jon Postel -- RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU Cc: The Internet Engineering Steering Group From: The IESG Subject: Protocol Action: The PPP Compression Control Protocol (CCP) to Proposed Standard Date: Mon, 08 Apr 96 12:32:47 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9604081232.aa13700@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"-youP3.0.sZ3.a_JQn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1485 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has approved the Internet-Draft "The PPP Compression Control Protocol (CCP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeff Burgan. The IESG also approved the publication of the following ten Internet-Drafts as Informational RFCs: 1. PPP Stac LZS Compression Protocol 2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol 3. PPP Gandalf FZA Compression Protocol 4. PPP Predictor Compression Protocol' 5. PPP BSD Compression Protocol 7. PPP LZS-DCP Compression Protocol (LZS-DCP) 8. PPP Magnalink Variable Resource Compression 9. PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) 10. PPP Serial Data Transport Protocol (SDTP) Technical Summary The "PPP Compression Control Protocol provides a standard method for negotiating compression techniques to use over a point-to-point connection. This is of particular to those who use low speed serial connections and wish to obtain high throughput. The Compression Control Protocol does NOT define any of the compression algorithms which may be used. These algorithms will be defined in a separate set of Informational RFCs. Many of these algorithms are proprietary. It was felt by the working group, and the area directors have concurred, that it would not be proper to define any one algorithm to be the standard compression algorithm. Working Group Summary This protocol is the result of an effort in the PPP Working group. The protocol is subject to certain patent claims from the Motorola Corporation. The working group discussed alternate techniques that did not use encumbered technology but could not come to consensus on such a technique. Furthermore, Motorola was unwilling to provide the licensing agreements required by RFC 1602. A Variance to the requirements of RFC 1602, allowing the adoption of the CCP was requested by the working group and was received from the IETF, see RFC 1915. Protocol Quality This protocol has been reviewed by Frank Kastenholz and Susan Thomson (RET.), Co-Internet Area Directors. There are at least 5 known implementations of this protocol, which have demonstrated varying levels of interoperability. There may be others. Special Note: On 5 June, 1995, the IESG received the following communication from Motorola Inc. Motorola, Inc. has advised the IETF that it holds two patents that it believes to be essential to the CCP and ECP standards, U.S. 5,245,614 and U.S. 5,130,993, and has declared its willingness to make licenses to these patents available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination. Parties interested in obtaining such a license may contact: Mr. John A. Fisher Vice President and Intellectual Property Licensing Counsel Motorola, Inc. 1303 E. Algonquin Road Schaumburg, Ill. 60196 The IESG and IETF make no statement on the validity of this claim. See also RFC 1915. Note to RFC Editor: The following references need to get updated... [1] Should now refer to the updated RFC 1661, July 1994. [2] Should now refer to RFC 1700, October 1994. [3] Should now refer to the published RFC 1663, July 1994. Also, the new chair's name and address should be include in the RFC. This will replace Fred Baker's name. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 8 12:42:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA15369; Mon, 8 Apr 1996 12:42:59 -0400 (EDT) Resent-Date: Mon, 8 Apr 1996 12:42:59 -0400 (EDT) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Protocol Action: The PPP Encryption Control Protocol (ECP) to Proposed Standard Date: Mon, 08 Apr 96 12:37:16 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9604081237.aa13866@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"dC5Au.0.ol3.D8KQn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1486 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has approved the Internet-Draft "The PPP Encryption Control Protocol (ECP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeff Burgan. The IESG also approved the publication of PPP DES Encryption Protocol (DESE) as an Informational RFC. Technical Summary The "PPP Encryption Control Protocol provides a standard method for negotiating encryption techniques to use over a point-to- point connection. The Encryption Control Protocol does NOT define any of the encryption algorithms which may be used. These algorithms will be defined in a separate set of Informational RFCs. Due to possible licensing, export, and other legal issues, it was felt by the working group, and the area directors have concurred, that it would not be proper to define any one algorithm to be a standard encryption algorithm. Working Group Summary This protocol is the result of an effort in the PPP Working group. The protocol is subject to certain patent claims from the Motorola Corporation. The working group discussed alternate techniques that did not use encumbered technology but could not come to consensus on such a technique. Furthermore, Motorola was unwilling to provide the licensing agreements required by RFC 1602. A Variance to the requirements of RFC 1602, allowing the adoption of the ECP was requested by the working group and was received from the IETF, see RFC 1915. Protocol Quality This protocol has been reviewed by Frank Kastenholz and Susan Thomson (RET.), Co-Internet Area Directors. There is 1 known implementation of this protocol. There may be others. Special Note: On 5 June, 1995, the IESG received the following communication from Motorola Inc. Motorola, Inc. has advised the IETF that it holds two patents that it believes to be essential to the CCP and ECP standards, U.S. 5,245,614 and U.S. 5,130,993, and has declared its willingness to make licenses to these patents available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination. Parties interested in obtaining such a license may contact: Mr. John A. Fisher Vice President and Intellectual Property Licensing Counsel Motorola, Inc. 1303 E. Algonquin Road Schaumburg, Ill. 60196 The IESG and IETF make no statement on the validity of this claim. See also RFC 1915. Note to RFC Editor: The following references need to get updated... [1] Should now refer to the updated RFC 1661, July 1994. Also, the new chair's name and address should be include in the RFC. This will replace Fred Baker's name. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 8 14:03:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA18340; Mon, 8 Apr 1996 14:03:12 -0400 (EDT) Resent-Date: Mon, 8 Apr 1996 14:03:12 -0400 (EDT) To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , ietf-ppp@MERIT.EDU From: The IESG Subject: Protocol Action: The PPP Compression Control Protocol (CCP) to Proposed Standard Date: Mon, 08 Apr 96 13:24:06 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9604081324.aa15700@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"5LvkC2.0.JU4.TJLQn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1488 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Note: This announcement supercedes the previous CCP Announcement. Sorry for the mailbox clutter. The IESG has approved the Internet-Draft "The PPP Compression Control Protocol (CCP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeff Burgan. The IESG also approved the publication of the following ten Internet-Drafts as Informational RFCs: 1. PPP Stac LZS Compression Protocol 2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol 3. PPP Gandalf FZA Compression Protocol 4. PPP Predictor Compression Protocol' 5. PPP BSD Compression Protocol 7. PPP LZS-DCP Compression Protocol (LZS-DCP) 8. PPP Magnalink Variable Resource Compression 9. PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) 10. PPP Serial Data Transport Protocol (SDTP) Technical Summary The "PPP Compression Control Protocol provides a standard method for negotiating compression techniques to use over a point-to-point connection. This is of particular to those who use low speed serial connections and wish to obtain high throughput. The Compression Control Protocol does NOT define any of the compression algorithms which may be used. These algorithms will be defined in a separate set of Informational RFCs. Many of these algorithms are proprietary. It was felt by the working group, and the area directors have concurred, that it would not be proper to define any one algorithm to be the standard compression algorithm. Working Group Summary During the development of this protocol, the Motorola Corporation advised the IETF that it owns patents which Motorola claims cover some of the techniques used by the protocol. The working group discussed alternate techniques that did not use encumbered technology but could not come to consensus on such a technique. Furthermore, Motorola was unwilling to provide the licensing agreements required by RFC 1602. A Variance to the requirements of RFC 1602, allowing the adoption of the CCP was requested by the working group and was received from the IETF, see RFC 1915. Protocol Quality This protocol has been reviewed by Frank Kastenholz and Susan Thomson (RET.), Co-Internet Area Directors. There are at least 5 known implementations of this protocol, which have demonstrated varying levels of interoperability. There may be others. Special Note: On 5 June, 1995, the IESG received the following communication from Motorola Inc. Motorola, Inc. has advised the IETF that it holds two patents that it believes to be essential to the CCP and ECP standards, U.S. 5,245,614 and U.S. 5,130,993, and has declared its willingness to make licenses to these patents available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination. Parties interested in obtaining such a license may contact: Mr. John A. Fisher Vice President and Intellectual Property Licensing Counsel Motorola, Inc. 1303 E. Algonquin Road Schaumburg, Ill. 60196 The IESG and IETF make no statement on the validity of this claim. See also RFC 1915. Note to RFC Editor: The following references need to get updated... [1] Should now refer to the updated RFC 1661, July 1994. [2] Should now refer to RFC 1700, October 1994. [3] Should now refer to the published RFC 1663, July 1994. Also, the new chair's name and address should be include in the RFC. This will replace Fred Baker's name. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 8 13:52:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA17829; Mon, 8 Apr 1996 13:52:45 -0400 (EDT) Resent-Date: Mon, 8 Apr 1996 13:52:45 -0400 (EDT) Date: Mon, 8 Apr 96 13:43:39 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: ietf-ppp@MERIT.EDU cc: ietf-ppp@MERIT.EDU Subject: Re: Last Call: The PPP Compression Control Protocol (CCP) to Proposed Standard Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9604081343.aa21737@THOR.ARL.MIL> Resent-Message-ID: <"TeYgp1.0.MM4.X9LQn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1487 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There was no reply to this message that I sent during the Last Call on draft-ietf-pppext-deflate-00.txt. Please remove references to the material on "quest.jpl.nasa.gov". The "official" copies are on ftp.uu.net. > Date: Wed, 14 Feb 96 22:09:06 GMT > From: Glenn Randers-Pehrson ARL-WTD-TED-TIB > Subject: Re: Last Call: The PPP Compression Control Protocol (CCP) to > > > To: ietf-ppp@merit.edu > > The I-D is also related to the > PPP Deflate Protocol. It doesn't duplicate, but supplements your > document by providing the technical specs for deflate. > > With reference to draft-ietf-pppext-deflate-00.txt, "references": > > [3] Deflate is now at level 1.3, draft documentation is also available > as an Internet-Draft, draft-deutsch-zlib-spec-01.txt> (work in progress) > > [4] Zlib is now at level 0.99. The reference "C" code is > available in ftp.uu.net:/pub/archiving/zip/zlib/ and the zlib draft > documentation, at level 3.3, is available in available in > ftp.uu.net:/pub/archiving/zip/doc/ and as an Internet-Draft, > (work in progress) > > There is documentation for gzip (mentioned in the introduction), also > available at level 4.3 in ftp.uu.net:/pub/archiving/zip/doc/ > and as an Internet-Draft, draft-deutsch-gzip-spec-01.txt> (work in progr > ess) > > Please remove references to the material on "quest.jpl.nasa.gov". > The "official" copies are on ftp.uu.net. > > Glenn Randers-Pehrson or > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 8 14:41:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA19896; Mon, 8 Apr 1996 14:41:02 -0400 (EDT) Resent-Date: Mon, 8 Apr 1996 14:41:02 -0400 (EDT) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Protocol Action: The PPP Encryption Control Protocol (ECP) to Proposed Standard Date: Mon, 08 Apr 96 13:37:22 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9604081337.aa16167@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"Xp3Ip3.0.as4.qsLQn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1489 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Note: This announcement supercedes the previous CCP Announcement. Sorry for the mailbox clutter. The IESG has approved the Internet-Draft "The PPP Encryption Control Protocol (ECP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeff Burgan. The IESG also approved the publication of PPP DES Encryption Protocol (DESE) as an Informational RFC. Technical Summary The "PPP Encryption Control Protocol provides a standard method for negotiating encryption techniques to use over a point-to- point connection. The Encryption Control Protocol does NOT define any of the encryption algorithms which may be used. These algorithms will be defined in a separate set of Informational RFCs. Due to possible licensing, export, and other legal issues, it was felt by the working group, and the area directors have concurred, that it would not be proper to define any one algorithm to be a standard encryption algorithm. Working Group Summary This protocol is the result of an effort in the PPP Working group. During the development of this protocol, the Motorola Corporation advised the IETF that it owns patents which Motorola claims cover some of the techniques used by the protocol. The working group discussed alternate techniques that did not use encumbered technology but could not come to consensus on such a technique. Furthermore, Motorola was unwilling to provide the licensing agreements required by RFC 1602. A Variance to the requirements of RFC 1602, allowing the adoption of the CCP was requested by the working group and was received from the IETF, see RFC 1915. Protocol Quality This protocol has been reviewed by Frank Kastenholz and Susan Thomson (RET.), Co-Internet Area Directors. There is 1 known implementation of this protocol. There may be others. Special Note: On 5 June, 1995, the IESG received the following communication from Motorola Inc. Motorola, Inc. has advised the IETF that it holds two patents that it believes to be essential to the CCP and ECP standards, U.S. 5,245,614 and U.S. 5,130,993, and has declared its willingness to make licenses to these patents available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination. Parties interested in obtaining such a license may contact: Mr. John A. Fisher Vice President and Intellectual Property Licensing Counsel Motorola, Inc. 1303 E. Algonquin Road Schaumburg, Ill. 60196 The IESG and IETF make no statement on the validity of this claim. See also RFC 1915. Note to RFC Editor: The following references need to get updated... [1] Should now refer to the updated RFC 1661, July 1994. Also, the new chair's name and address should be include in the RFC. This will replace Fred Baker's name. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 10 15:12:50 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA05262; Wed, 10 Apr 1996 15:12:50 -0400 (EDT) Resent-Date: Wed, 10 Apr 1996 15:12:50 -0400 (EDT) From: Guy Cote To: ietf-ppp Subject: Numbered Mode Option and CCP. Date: Wed, 10 Apr 96 15:05:00 PDT Message-Id: <316C31FC@admin.eicon.com> Encoding: 24 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"oOQdw3.0.cH1.kV0Rn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1490 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We are currently implementing the numbered mode option and CCP. In the situation where, the PPP connection was established with the numbered mode option and that HDLC was started. If we later on re-negociate LCP on HDLC and we end up with a different HDLC address (maybe because the smaller magic number was not from the same side) or window in the numbered mode option then what was previously negociated. What should we do next ? We are suppose to go to the PPP interoperability workshop in San Ramon and I am currious to know the ratio of CCP implementation that are reliable (using Numbered Mode) compared to the one that are not. Do most of the implementations support both modes? Guy Cote email : guyc@eicon.com Eicon Technology http://www.eicon.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 10 18:23:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA11044; Wed, 10 Apr 1996 18:23:36 -0400 (EDT) Resent-Date: Wed, 10 Apr 1996 18:23:36 -0400 (EDT) Date: Wed, 10 Apr 1996 16:22:45 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604102222.QAA05072@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Numbered Mode Option and CCP Cc: guyc@eicon.com Resent-Message-ID: <"gVxo31.0.Ki2.MJ3Rn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1491 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Guy Cote > We are currently implementing the numbered mode option and CCP. > > In the situation where, the PPP connection was established with the numbered > mode option and that HDLC was started. If we later on re-negociate LCP on > HDLC and we end up with a different HDLC address (maybe because the smaller > magic number was not from the same side) or window in the numbered mode > option then what was previously negociated. > > What should we do next ? > > We are suppose to go to the PPP interoperability workshop in San Ramon and I > am currious to know the ratio of CCP implementation that are reliable (using > Numbered Mode) compared to the one that are not. > > Do most of the implementations support both modes? Since no one else has responded ... Is this for ISDN and modems or some other kind of private line? Is "numbered mode" the mechanism described in RFC 1663 or one of the flavors of LZS (Stac) compression? I guess it must be RFC 1663. I've never seen any PPP traces where the peer asked for numbered mode, with or without CCP. How many systems implement numbered mode at all? My guess is that essentially all CCP implementations use only ordinary HDLC or async-HDLC framing. All but one of the CCP compresson schemes that I have heard of being implemented, LZS, BSD-Compress, Predictor, and Deflate, have there their own mechanisms to deal with packet loss, ranging from resetting the compression state with each packet to packet sequence numbers. The one exception to my knowledge is Gandalf's FZA, but I'm not sure it was ever implemented, and I don't remember if it has its own loss detection mechanism. Vernon Schryver, vjs@sgi.com As they say, the best thing about standards is that there are so many from which to choose. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 10 23:10:44 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id XAA18430; Wed, 10 Apr 1996 23:10:44 -0400 (EDT) Resent-Date: Wed, 10 Apr 1996 23:10:44 -0400 (EDT) From: oka@isl.rdc.toshiba.co.jp (Toshio Okamoto) Message-Id: <199604110304.MAA06155@isl.rdc.toshiba.co.jp> Date: Thu, 11 Apr 1996 12:04:38 +0900 (JST) To: ietf-ppp@MERIT.EDU Subject: Moble IP support Resent-Message-ID: <"mHlSn3.0.RT4.tV7Rn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1492 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi! I just join PPP ML and I don't know the current discussions. Last IETF meeting, I heard about PPP extention for Mobile IP support or so. Do you have any information about that? --T.Okamoto@TOSHIBA - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 12 13:23:25 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA15305; Fri, 12 Apr 1996 13:23:25 -0400 (EDT) Resent-Date: Fri, 12 Apr 1996 13:23:25 -0400 (EDT) Message-ID: From: "Ken Crocker (Exchange)" To: "'ietf-ppp@MERIT.EDU'" Subject: FW: I-D ACTION:draft-gidwani-ppp-callback-cp-00.txt Date: Fri, 12 Apr 1996 10:17:57 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BB2859.53A82730" Resent-Message-ID: <"YzvJu1.0.Yk3.54fRn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1493 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BB2859.53A82730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit this was intended to be submitted as an informational not an draft. our apologies. ken crocker program manager windows nt internetworking >---------- >From: > Internet-Drafts@CNRI.Reston.VA.US[SMTP:Internet-Drafts@CNRI.Reston.VA.U >S] >Sent: Friday, April 12, 1996 6:30 AM >To: The recipient's address is unknown. >Subject: I-D ACTION:draft-gidwani-ppp-callback-cp-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : PPP Callback Control Protocol > > Author(s) : N. Gidwani > Filename : draft-gidwani-ppp-callback-cp-00.txt > Pages : 10 > Date : 04/11/1996 > >The Point-to-Point Protocol (PPP) provides a standard method for >transporting multi-protocol datagrams over point-to-point links. PPP >is >comprised of three main components: 1. A method for encapsulating >multi-protocol datagrams. 2. A Link Control Protocol (LCP) for >establishing, configuring, and testing the data-link connection. >3. A family of Network Control Protocols (NCPs) for establishing >and configuring different network-layer protocols. > >This document defines an interoperable method for negotiating >dial-up callback over PPP links. > >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-gidwani-ppp-callback-cp-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-gidwani-ppp-callback-cp-00.t >xt > >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 (193.205.245.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-gidwani-ppp-callback-cp-00.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_000_01BB2859.53A82730 Content-Type: Message/External-body; name="ATT12709.txt" Content-Transfer-Encoding: base64 Q29udGVudC10eXBlOiBtZXNzYWdlL2V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGRzLmludGVybmljLm5ldCINCg0KQ29udGVudC1U eXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MTk5NjA0MTExNDUyMjYuSS1EQENOUkkuUmVz dG9uLlZBLlVTPg0KDQpFTkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt Z2lkd2FuaS1wcHAtY2FsbGJhY2stY3AtMDAudHh0DQoNCg== ------ =_NextPart_000_01BB2859.53A82730 Content-Type: Message/External-body; name="draft-gidwani-ppp-callback-cp-00.txt.url" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZHMuaW50ZXJuaWMubmV0L2ludGVybmV0LWRy YWZ0cy9kcmFmdC1naWR3YW5pLXBwcC1jYWxsYmFjay1jcC0wMC50eHQNCg== ------ =_NextPart_000_01BB2859.53A82730-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 12 15:34:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA19363; Fri, 12 Apr 1996 15:34:34 -0400 (EDT) Resent-Date: Fri, 12 Apr 1996 15:34:34 -0400 (EDT) Message-Id: <9604121935.AA5158@shivaportal.shiva.com> To: ietf-ppp From: Craig Richards/Shiva Corporation Date: 12 Apr 96 15:32:13 Subject: BACP open issues Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"omlGp2.0.Fk4.31hRn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1494 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There's still a few open issues about BACP. Here's my thoughts on them: E.164 phone number format: While I understand that allowing an implementation to provide its phone number in E.164 format might work out well in certain cases, I believe it is undesireable to allow implementations to provide phone numbers in varying formats. This would mean an implementation would have to be configured for and coded to allow both phone number formats, which would increase the difficulty of implementing BACP. The weakness of the unique digits algorithm format is that a base phone number is required, but in most cases, an implementation that makes the first call will make subsequent calls. If having only one phone number format is unacceptable, I guess negotiation of the phone number format could be added to BACP, with the unique digits format being the default. Race conditions: The current race condition solution involves the authentication username and the Multilink endpoint discriminator. It has been pointed out to me that some implementations may not use either username or endpoint discriminator; furthermore, there is no guarantee that these values will be unique. One of the solutions to this is to negotiate the favored peer. I favor a different solution: changing the favored peer to be the originator of the initial link of the multilink bundle, and if both peers initiated a link in the bundle simultaneously, then each implementation should retry the request in a random time within x seconds, x doubling for each retry and starting at 10. Although this may not be the cleanest solution to this issue, I don't think race conditions will happen very often where both peers initiate a call to each other at the same time. Call-Status-Indication: There have been a few comments suggesting that the Call-Status-Indication should only be sent for call failures. However, one person commented to me that although at first he didn't understand why it was needed on successful calls, when he went to implement BAP he thought that receiving a Call-Status-Indication for every call simplified his code. Is there anyone else who thinks having Call-Status-Indications makes more sense after writing some code? Thrashing: Jim Gardner of Bay Networks pointed out in a previous message that the possibility of thrashing exists. I believe this can be solved by requiring an implementation that receives a Link-Drop-Query-Request to base its response on both transmit and receive heuristics if it is monitoring both transmit and receive. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Apr 13 05:01:44 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA06720; Sat, 13 Apr 1996 05:01:44 -0400 (EDT) Resent-Date: Sat, 13 Apr 1996 05:01:44 -0400 (EDT) X-Sender: stadler@mailhost.catapent.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Apr 1996 02:00:26 -0700 To: ietf-ppp@MERIT.EDU From: stadler@catapent.com (Andy Stadler) Subject: TCP timeouts, w.r.t. PPP Resent-Message-ID: <"v6gO.0.he1.6rsRn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1495 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, This is marginally related to PPP, so I apologize for the time & bandwidth. I'm setting up a system where a great many dsitributed small boxes would be - calling a central server and establishing PPP - opening a single TCP stream and chatting for about 30 sec. - closing and quickly hanging up This profile, if running on order-of-thousands of the small systems calling at completely random intervals, has some interesting implications for certain of TCP's requirements - specifically, regarding 2 minute time-waits, reuse of IP numbers, and obtaining clock-increasing ISS values from unsynchronized distributed systems. This is only marginally related to PPP, as I said, so I don't intend to begin a discussion here. However, if anyone can point me to references, discussions, or smart folk who've investigated these areas, it would be greatly appreciated. Thanks very much. Andy Stadler Catapult Entertainment, Inc. stadler@catapent.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 15 06:27:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA00466; Mon, 15 Apr 1996 06:27:02 -0400 (EDT) Resent-Date: Mon, 15 Apr 1996 06:27:02 -0400 (EDT) From: lasat-lh@inet.uni-c.dk Date: Mon, 15 Apr 1996 12:22:47 +0200 Message-Id: <199604151022.MAA23099@inet.uni-c.dk> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Comment to BACP To: ietf-ppp@MERIT.EDU X-Mailer: SPRY Mail Version: 04.10.06.22 Resent-Message-ID: <"fl8qM1.0.z6.IHYSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1496 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am emploed in a ISDN terminal adaptor for Basic Rate Acces, vendor company, and have interrest in the PPP BAP/BACP. I have som basic questions regarding which TA's are supposed to implement this protocol. 1. Is it right that Bacis Rate Acces TA's allso can use this BACP, when connecting to there Internet provider, or is it more ment to be used between PRI Routers? 2. Is it right that the link type can be both HDLC and V.120 and Analog modem over ISDN? 3. Is it right that when a new Multilink is to be added, a new Basic rate Call control SETUP is made, and a new B-channel is in use? 4. Is the PPPML header present when only one B-channel is in use? 5. You are stating that PPPML is increasingly common. Is this statment for US or is it global and therefore allso for Europe? I hopefully waits to get some answers. Kind Regards and Thanks Lars Hansen - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 15 15:16:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA17342; Mon, 15 Apr 1996 15:16:35 -0400 (EDT) Resent-Date: Mon, 15 Apr 1996 15:16:35 -0400 (EDT) Date: Mon, 15 Apr 1996 12:22:39 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604151822.MAA08073@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Comment to BACP Cc: lasat-lh@inet.uni-c.dk Resent-Message-ID: <"sMsFu1.0.5E4.S0gSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1497 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: lasat-lh@inet.uni-c.dk > I am emploed in a ISDN terminal adaptor for Basic Rate Acces, vendor company, > and have interrest in the PPP BAP/BACP. I have som basic questions regarding > which TA's are supposed to implement this protocol. > ... > 4. Is the PPPML header present when only one B-channel is in use? I don't know how BAP/BACP might be related, but if "PPPML" refers to the RFC 1717 PPP MP header, then there are some widely fielded commercial implementations that use the MP header only when necessary. That is when there are two or more links in a bundle, or for some time after there have been two or more links. > 5. You are stating that PPPML is increasingly common. Is this statment for US or > is it global and therefore allso for Europe? RFC 1717 is in use today, without any of BAP/BACP, MPPP, or MP+, in both the U.S. and Europe. It is most commonly used with ISDN links using raw HDLC framing, but it can be used with any serial link, include the v.120 flavor of HDLC. Judging from the netnews group comp.dcom.isdn, zillion inexpensive PPP/ISDN TA's such as the Motorola Bitsurfer Pro seem to have been put into service in the last 12 months. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 15 21:11:39 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA29294; Mon, 15 Apr 1996 21:11:39 -0400 (EDT) Resent-Date: Mon, 15 Apr 1996 21:11:39 -0400 (EDT) Message-Id: <9604160109.AA05171@fennel.acc.com> To: ietf-ppp@MERIT.EDU Cc: lisaa@chives.acc.com Subject: CCP over the multilink X-Mailer: exmh version 1.3gamma 3/18/94 Date: Mon, 15 Apr 1996 18:09:43 -0700 From: Lisa Anderson Resent-Message-ID: <"ohdnB1.0.I97.oDlSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1498 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In the CCP draft, it is stated that two types of the CCP method could be used while using multilink. One is to compress the data prior to sending it out through the multiple links (called CCP). The other is to treat each link as a separate connection, that may or may not have compression enabled (called ILCCP). What are the advantages and disadvantages of using CCP vs. ILCCP over multlink? Would we have an interoperability problem if we supported only ILCCP over the multilink? Are there many vendors who support both CCP and ILCCP over the multlink at the same time ? Thanks. Lisa - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 15 21:35:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA29892; Mon, 15 Apr 1996 21:35:48 -0400 (EDT) Resent-Date: Mon, 15 Apr 1996 21:35:48 -0400 (EDT) From: Scott Jackson Message-Id: <199604160134.SAA03663@puli.cisco.com> Subject: Re: BACP open issues To: ietf-ppp@MERIT.EDU Date: Mon, 15 Apr 1996 18:34:47 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_ZcNU3.0.oI7.nblSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1499 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig Richards [crichards@shiva.com]: > > Race conditions: The current race condition solution involves the > authentication username and the Multilink endpoint discriminator. It has been > pointed out to me that some implementations may not use either username or > endpoint discriminator; furthermore, there is no guarantee that these values > will be unique. One of the solutions to this is to negotiate the favored > peer. I favor a different solution: changing the favored peer to be the > originator of the initial link of the multilink bundle, and if both peers > initiated a link in the bundle simultaneously, then each implementation should > retry the request in a random time within x seconds, x doubling for each retry > and starting at 10. Although this may not be the cleanest solution to this > issue, I don't think race conditions will happen very often where both peers > initiate a call to each other at the same time. As there is only one instance of a BACP NCP for a multilink bundle, it would appear that the NCP phase offers one the opportunity to establish the favoured peer to be used in a race condition scenario through negotiation, before any BAP messages are exchanged. A technique could be employed (similar to that of the LCP magic number for instance) whereby both peers negotiate until each has a different value and the lowest is deemed to be favoured. Thus, both peers are privy to the knowledge of the favourite from the outset. > Call-Status-Indication: There have been a few comments suggesting that the > Call-Status-Indication should only be sent for call failures. However, one > person commented to me that although at first he didn't understand why it was > needed on successful calls, when he went to implement BAP he thought that > receiving a Call-Status-Indication for every call simplified his code. Is > there anyone else who thinks having Call-Status-Indications makes more sense > after writing some code? The Call-Status-Indication, although not strictly required, does indeed provide a useful notification to signal the end of the call, and provides both peers with the knowledge that they can proceed. Therefore, it should be sent upon the success of a call attempt as defined at present. Scott - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 15 21:44:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA00322; Mon, 15 Apr 1996 21:44:33 -0400 (EDT) Resent-Date: Mon, 15 Apr 1996 21:44:33 -0400 (EDT) From: Archie Cobbs Message-Id: <199604160144.SAA05588@bubba.tribe.com> Subject: Re: CCP over the multilink To: lisaa@chives.acc.com (Lisa Anderson) Date: Mon, 15 Apr 1996 18:44:18 -0700 (PDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9604160109.AA05171@fennel.acc.com> from "Lisa Anderson" at Apr 15, 96 06:09:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"xYcLN1.0.m4.yjlSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1500 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > What are the advantages and disadvantages of using CCP vs. ILCCP over > multlink? Someone correct me if I'm wrong, but the only advantage I can think of for having ILCCP is if you have some special hardware that operates only on the link layer. So I would suspect most people just implement regular CCP above the bundle layer. -Archie __________________________________________________________________________ Archie L. Cobbs, archie@tribe.com * Whistle Communications Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 16 04:40:04 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA09810; Tue, 16 Apr 1996 04:40:04 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 04:40:04 -0400 (EDT) Message-Id: From: roeck@conware.de (Guenter Roeck) Subject: where is mailing list archive ? To: ietf-ppp@MERIT.EDU Date: Tue, 16 Apr 1996 10:37:01 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL14 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"W_aI61.0.1O2.jorSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1501 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, does anyone know if and where I can find the PPP mailing list archive ? Thanks, Guenter - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 16 05:44:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA11489; Tue, 16 Apr 1996 05:44:15 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 05:44:15 -0400 (EDT) Date: Tue, 16 Apr 96 10:38:43 BST From: georgew@spider.co.uk (George Wilkie) Message-Id: <9604160938.AA12055@queenbee.spider.co.uk> To: ietf-ppp@MERIT.EDU Subject: Re: BACP open issues Organization: Shiva Europe Limited Resent-Message-ID: <"nUPDY1.0.9p2.1lsSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1502 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Scott Jackson writes: >Craig Richards [crichards@shiva.com]: >> >> Race conditions: The current race condition solution involves the >> authentication username and the Multilink endpoint discriminator. It has been >> pointed out to me that some implementations may not use either username or >> endpoint discriminator; furthermore, there is no guarantee that these values >> will be unique. One of the solutions to this is to negotiate the favored >> peer. I favor a different solution: changing the favored peer to be the >> originator of the initial link of the multilink bundle, and if both peers >> initiated a link in the bundle simultaneously, then each implementation should >> retry the request in a random time within x seconds, x doubling for each retry >> and starting at 10. Although this may not be the cleanest solution to this >> issue, I don't think race conditions will happen very often where both peers >> initiate a call to each other at the same time. > >As there is only one instance of a BACP NCP for a multilink bundle, it would >appear that the NCP phase offers one the opportunity to establish the favoured >peer to be used in a race condition scenario through negotiation, before any >BAP messages are exchanged. A technique could be employed (similar to that of >the LCP magic number for instance) whereby both peers negotiate until each >has a different value and the lowest is deemed to be favoured. Thus, both >peers are privy to the knowledge of the favourite from the outset. I agree with Scott. It's easier to negotiate favoured peer than implement back-off for first call. > >> Call-Status-Indication: There have been a few comments suggesting that the >> Call-Status-Indication should only be sent for call failures. However, one >> person commented to me that although at first he didn't understand why it was >> needed on successful calls, when he went to implement BAP he thought that >> receiving a Call-Status-Indication for every call simplified his code. Is >> there anyone else who thinks having Call-Status-Indications makes more sense >> after writing some code? > >The Call-Status-Indication, although not strictly required, does indeed >provide a useful notification to signal the end of the call, and provides both >peers with the knowledge that they can proceed. Therefore, it should be sent >upon the success of a call attempt as defined at present. > Yup. I go along with that too. -- George Wilkie georgew@europe.shiva.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 16 07:48:44 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA13837; Tue, 16 Apr 1996 07:48:44 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 07:48:44 -0400 (EDT) Date: Tue, 16 Apr 1996 12:42:24 +0100 From: Gerry Meyer Message-Id: <199604161142.MAA00567@orbweb.spider.co.uk> To: ietf-ppp@MERIT.EDU, isaa@chives.acc.com Subject: Re: CCP over the multilink Resent-Message-ID: <"7WYz.0.xN3.MauSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1503 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Lisa Anderson (lisaa@chives.acc.com) wrote: >In the CCP draft, it is stated that two types of the CCP method could be used >while using multilink. One is to compress the data prior to sending it out >through the multiple links (called CCP). The other is to treat each link as a >separate connection, that may or may not have compression enabled >(called ILCCP). >What are the advantages and disadvantages of using CCP vs. ILCCP over >multlink? CCP - Advantages of compression before multilink: 1) Compression is probably better this way (better coherence). 2) Less memory is used for dictionaries (for the bundle instead of for each link). 3) A better decision can be taken on how to chop the packet into equivalent sized fragments. ILCCP - Advantages of compression after multilink: A) You can distribute compression processing. B) Better performance when there is packet reordering (avoids processing 'lumpiness'). C) More resilient to packet loss (fewer frames need be discarded). In an ideal world one would choose compression before multilink (because it gives the better results in casual tests) ... However in my view point A, above, is the killer. Think of your ISP's big routers/servers. They don't have a hope in hell of being able to compress all channels centrally (through software OR hardware). So will you actually see that compress performance? >Would we have an interoperability problem if we supported only ILCCP >over the multilink? I suspect that most implementations will have chosen to support CCP rather than ILCCP. >Are there many vendors who support both CCP and ILCCP over the multlink >at the same time ? Thats one of the things I aim to find out at the upcoming CIUG interop. Shiva Lanrover and our next Integrator release support CCP and ILCCP options - but not simultaneously (since it is improbable that you will be able to apply compression twice). Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 16 10:31:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA19207; Tue, 16 Apr 1996 10:31:07 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 10:31:07 -0400 (EDT) Date: Tue, 16 Apr 1996 10:29:17 -0400 (EDT) From: John Shriver Message-Id: <199604161429.KAA24611@shiva-dev.shiva.com> To: lisaa@chives.acc.com CC: ietf-ppp@MERIT.EDU In-reply-to: <9604160109.AA05171@fennel.acc.com> (message from Lisa Anderson on Mon, 15 Apr 1996 18:09:43 -0700) Subject: Re: CCP over the multilink Resent-Message-ID: <"P5GTl3.0.nh4.WywSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1504 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Running compression on each link will probably cost you more computes than running it over the bundle. On the other hand, for many techniques, it will give you a larger effective dictionary for the bundle, and may offer a better overall compression ratio. I think compressing the bundle is more common. For many compressors, using both at once is a BAD idea. The Shiva LanRover ships with compression only enabled on the bundle, but there is configuration to enable it on the link. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 16 10:52:25 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA20069; Tue, 16 Apr 1996 10:52:25 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 10:52:25 -0400 (EDT) Message-Id: <199604161452.KAA20044@merit.edu> From: Stuart Venters Subject: Re: CCP over the multilink To: gerry@spider.co.uk (Gerry Meyer) Date: Tue, 16 Apr 96 9:31:25 CDT Cc: ietf-ppp@MERIT.EDU, sventers@adtrn722.adtran.com In-Reply-To: <199604161142.MAA00567@orbweb.spider.co.uk>; from "Gerry Meyer" at Apr 16, 96 12:42 (noon) Mailer: Elm [revision: 70.85] Resent-Message-ID: <"_jfEu1.0.Jv4.bGxSn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1505 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Greetings, With regard to the choice of CCP versus ILCCP. > ILCCP - Advantages of compression after multilink: > > A) You can distribute compression processing. > > However in my view point A, above, is the killer. > > Think of your ISP's big routers/servers. They don't have a hope in hell of > being able to compress all channels centrally (through software OR > hardware). So will you actually see that compress performance? > In most cases, I think so. It seems that the requirement is that all the channels in a given multilink bundle (as opposed to the whole server) need to be compressed in one place. If you have a big router/server supporting N users each having a multilink bundle then even with CCP you could distribute the compression processing to N places. This scheme should work as long as the bandwidth in a single bundle does not exceed some threshold. The threshold is where the bandwidth in a single bundle becomes too much to compress in a single unit. Above this threshold, I see that ILCCP could be necessary. With today's parts, I know the threshold is above 3Mbits total half duplex raw bundle speed. Perhaps a clever implentation could push it to 10M. How about the following guidelines? All boxes make every attempt to support CCP as a basis for interoperability. To support applications where a single bundle is composed of more than 2 whole T1 links then some boxes may also wish to support ILCCP. -Stuart - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 16 15:32:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA29366; Tue, 16 Apr 1996 15:32:48 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 15:32:48 -0400 (EDT) Date: Tue, 16 Apr 1996 12:31:47 -0700 (PDT) From: Ron Jeffery X-Sender: ronj@amadjuak Reply-To: Ron Jeffery To: John Shriver Cc: lisaa@chives.acc.com, ietf-ppp@MERIT.EDU Subject: Re: CCP over the multilink In-Reply-To: <199604161429.KAA24611@shiva-dev.shiva.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DeKjR.0.aA7.CN_Sn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1506 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 16 Apr 1996, John Shriver wrote: > Running compression on each link will probably cost you more computes > than running it over the bundle. Agreed, but if these computes are better distributed over the available processing resources, then the ILCCP solution could still be advantageous. Consider an architecture, designed to support a large number of ports, where compression processing is done in a distributed fashion by processors which are each associated with n interface ports. When subsequent links are added to a multilink bundle they may terminate on a port which is associated with a different compression processor than the first link in the bundle. If compression is done on the bundle as a whole then the compression processor for the added link can't do the compression and must just forward the traffic to the compression processor for the first link. The compression processor for the first link can become overloaded, while the compression processors for the additional links sit idle. If the design supports bundles of up to M links, then in the worst case the compression processors have to be "overdesigned" by a factor of M. This is the problem with compression on the whole bundle for distributed architectures. In an architecture where all processing is done in one place by one processor, the total processing requirements on that processor are less when the bundle is compressed as a whole. However, this architecture does not scale well. > On the other hand, for many > techniques, it will give you a larger effective dictionary for the > bundle, and may offer a better overall compression ratio. I think that this contradicts the conventional wisdom, but it is an interesting idea. Any other opions? > I think compressing the bundle is more common. > > For many compressors, using both at once is a BAD idea. > > The Shiva LanRover ships with compression only enabled on the bundle, > but there is configuration to enable it on the link. > Ron Jeffery - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 06:58:08 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA20586; Wed, 17 Apr 1996 06:58:08 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 06:58:08 -0400 (EDT) Date: Wed, 17 Apr 1996 11:51:12 +0100 From: Gerry Meyer Message-Id: <199604171051.LAA01003@orbweb.spider.co.uk> To: ietf-ppp@MERIT.EDU Subject: Re: CCP over the multilink Resent-Message-ID: <"s1zqC2.0.M15.7wCTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1507 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Stuart Venters wrote: >It seems that the requirement is that all the channels in a given multilink >bundle (as opposed to the whole server) need to be compressed in one place. >If you have a big router/server >supporting N users each having a multilink bundle then even with CCP >you could distribute the compression processing to N places. >This scheme should work as long as the bandwidth in a single bundle does >not exceed some threshold. The threshold is where the bandwidth in a >single bundle becomes too much to compress in a single unit. >Above this threshold, I see that ILCCP could be necessary. >With today's parts, I know the threshold is above 3Mbits total half duplex >raw bundle speed. Perhaps a clever implentation could push it to 10M. The products coming out today have (for example) multiple PRI lines (Each 2 Mbps x 2). And thats the compressed rates! With ILCCP it would seem logical and straightforward to lump compression processing 'in-line' on individual PRI cards. The alternative of distributing CCP processing around a number of compression processors, getting the output back and then distributing it to the appropriate PRI does not sound to me like a cost-effective hardware/software approach which will fly. >How about the following guidelines? > All boxes make every attempt to support CCP as a basis for interoperability. > To support applications where a single bundle is composed > of more than 2 whole T1 links then some boxes may also > wish to support ILCCP. I think the issue is that the ISP router/server will only be able to hack compression using distributed processing and ILCCP. But I fear that the clients calling in will only support CCP. Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 11:57:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA29321; Wed, 17 Apr 1996 11:57:07 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 11:57:07 -0400 (EDT) Message-ID: From: Robert Bell To: "ietf-ppp@MERIT.EDU" Subject: Ascend compression Date: Wed, 17 Apr 1996 17:03:41 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.1.611 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BB2C7F.D4AB5E90" Resent-Message-ID: <"UExNq.0.U97._IHTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1508 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Contact your mail administrator for information about upgrading your reader to a version that supports MIME. ------ =_NextPart_000_01BB2C7F.D4AB5E90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is there a specification available for Ascend's original Stac based compression? ------ =_NextPart_000_01BB2C7F.D4AB5E90-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 12:01:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA29569; Wed, 17 Apr 1996 12:01:35 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 12:01:35 -0400 (EDT) Message-Id: <9604171601.AA21550@chickadee.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: ietf-ppp@MERIT.EDU Subject: In oder delivery of packets. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Apr 1996 12:01:22 -0400 From: Baiju Patel Resent-Message-ID: <"TnFE11.0.lD7.RNHTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1509 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I was looking at the PPTP protocol (http://www.microsoft.com/intdev/inttech/ppt p.htm), and observed that PPTP does not ensure in order delivery of packets through the GRE tunnel Here is a portion of the Text from PPTP document 3.4.2.2 Out-of-Order Packets Occasionally packets lose their order across a complicated internetwork, as illustrated in Figure 7. Packet 3 arrives at the FEP after packet 4, although NTS sent them in order. The FEP acknowledges packet 4, and may assume packet 3 is lost. This acknowledgment grants credit beyond packet 4. When the FEP does receive packet 3, it should attempt to -------------------------------------------------------- transmit it to the remote PPP client. When packet 5 comes in, it is ------------------------------------- acknowledged by the FEP since it has a higher sequence number than 4, which was the last highest packet acknowledged by the FEP. Here is a portion of text from the RFC 1661: 1. Introduction The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order. It is intended that PPP provide a common solution ----------------- for easy connection of a wide variety of hosts, bridges and routers [1]. I also noticed that L2F ensures inorder delivery of tunneled packets. My question is: Will the PPP protocol (or its extension) break if packets are delivered out of order? Baiju (See Fig =============================================================================== Baiju V. Patel (external): http://www.research.ibm.com/people/b/baiju (internal): http://w3.watson.ibm.com/~baiju/baiju.html IBM T. J. Watson Research Center, H3-D36 30 Saw Mill River Road, Hawthorne, NY 10532 =============================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 12:11:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA00121; Wed, 17 Apr 1996 12:11:48 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 12:11:48 -0400 (EDT) Message-Id: <199604171611.MAA29992@merit.edu> From: Stuart Venters Subject: Re: CCP over the multilink To: gerry@spider.co.uk (Gerry Meyer) Date: Wed, 17 Apr 96 10:50:38 CDT Cc: ietf-ppp@MERIT.EDU, sventers@adtrn722.adtran.com In-Reply-To: <199604171051.LAA01003@orbweb.spider.co.uk>; from "Gerry Meyer" at Apr 17, 96 11:51 am Mailer: Elm [revision: 70.85] Resent-Message-ID: <"2s2CO2.0.d1.0XHTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1510 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Greetings, More on CCP versus ILCPP. From the ISP point of view: Gerry Meyer wrote: > The alternative of distributing CCP processing around a number of compression > processors, getting the output back and then distributing it to the > appropriate > PRI does not sound to me like a cost-effective hardware/software approach > which will fly. What I'm hearing is that this alternative works, is more complicated than ILCCP, but costs too much. I was thinking of an alternative which only moved the data once. If the compression resource was located where you do multilink then the extra distribution is unnecessary. You still have to move the data once, but I think you would have to do this anyway inorder to implement Multilink without CCP. Overnight I thought about it and I can now see that over time, as calls come up and go down, some processors would still end up with too many bundles. This problem gets worse as the size of the bundles increases. I think a solution might be to add the ability to transfer a bundle from a busy processor to a less busy one. This should have the same hardware cost as ILCCP but sure could make the software more complex. From the client end view: > But I fear that the clients calling in will only support CCP. I checked into this a little. As TA's get more features for less money, the available ram goes to zero. What this means is that inorder to add the second compression history to support IPCCP, some other feature has to be taken out. It seems to me that to decide the issue on total cost would lean toward CCP because there should be a lot more TA's than ISP box ports. To decide the issue on performance should lean toward CCP. To decide the issue on implementability could go either way. CCP is simpler but is possibly not implementable on big boxes with big bundles. One thing is for sure, if we don't decide, we will have to implement both which is not optimal. Again, I think that for small bundles, the rule should be CCP. For big bundles, maybe IPCCP. This seems like a fair, implentable compromise for everybody. -Stuart - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 16:27:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA08266; Wed, 17 Apr 1996 16:27:02 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 16:27:02 -0400 (EDT) Date: Wed, 17 Apr 1996 07:55:09 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604171355.HAA13679@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP over the multilink Resent-Message-ID: <"SdzOz3.0.t02.BGLTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1511 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gerry Meyer > ... > The products coming out today have (for example) multiple PRI lines (Each > 2 Mbps x 2). And thats the compressed rates! > With ILCCP it would seem logical and straightforward to lump compression > processing 'in-line' on individual PRI cards. > > The alternative of distributing CCP processing around a number of compression >processors, getting the output back and then distributing it to the appropriate > PRI does not sound to me like a cost-effective hardware/software approach > which will fly. I do not see why not. With 2 PRI's, you are talking about only 3 Mbit/sec being moved around. Current commodity CPU's can handle 20-80 Mbit/sec of IP (e.g. PC's with 100BASE-T). It should be no trick to shuffle bytes around on a private Ethernet, not to mention a private bus. Just use L2F. Or something simpler but proprietary. Such a scheme is obviously a lot more work to implement than ILCCP, but the following is unavoidable: > .... But I fear that the > clients calling in will only support CCP. Yes, there is little hope for getting clients to do ILCCP. The common compression performance advantage of CCP compared to ILCCP is magnified for clients, since they tend to have fewer upper layer streams multiplexed on their links. Also, for clients dealing with a single PPP peer and up to about 4 Basic Rate ISDN links, CCP is cheaper in CPU cycles, hardware cost, and software complexity. Whether the client uses pure software or special compression hardware such as Stac Electronic's, it seems to me cheaper and easier to put all of the PPP data through a single funnel. This applies to vendors building client Ethernet-ISDN bridges or routers as well as various workstation PPP products and freeware. The only hope for ILCCP from clients is with not with RFC 1717 MP, but 'round robin' or 'load balancing' multilink, where the equivalent of ILCCP is inevitiable. As I keep saying, I understand that Linux supports 'load balancing.' Given that version of PPP is based on Paul Mackerras's code, it must support CCP over each link in the bundle. Where ILCCP seems to me to make sense is between high speed dial-up PPP peers linking similar LANs. Consider a pair of boxes that use the equivalent of two PRI's to connect company networks. What do they call that form of ISDN that is something like 384 kbit/sec? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 16:49:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA08990; Wed, 17 Apr 1996 16:49:54 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 16:49:54 -0400 (EDT) From: stevek@dgii.com Date: Wed, 17 Apr 1996 21:49:17 +0100 Message-Id: <199604172049.VAA09850@dgii.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Commercial UNIX PPP packages To: ietf-ppp@MERIT.EDU Cc: Steve_Wahl@dgii.com X-Mailer: SPRY Mail Version: 04.00.06.14 Resent-Message-ID: <"szHau1.0.8C2.kbLTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1512 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anyone know of full-featured commercial PPP packages for UN*X platforms (Sun, SGI, SCO)? I've used Sun PPP but found it somewhat lacking. Specifically, I'm looking for Callback, Compression, Multilink, and maybe a GUI dialer, etc. ------------------------------------------------------------------------ Steven A. Klein Digi International Voice: (310) 328-9700 stevek@dgii.com 2730 Monterey St. Suite 105 Fax: (310) 328-9696 Torrance, CA 90503 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Apr 17 20:41:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA15810; Wed, 17 Apr 1996 20:41:34 -0400 (EDT) Resent-Date: Wed, 17 Apr 1996 20:41:34 -0400 (EDT) Message-Id: <9604180041.AA0185@hqsmtp.ops.3com.com> To: ietf-ppp , Lisa Anderson From: Leemay Yen/HQ/3Com Date: 17 Apr 96 17:20:47 EDT Subject: Re: CCP over the multilink Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"AZEwe1.0.ks3.o-OTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1513 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Lisa Anderson (lisaa@chives.acc.com) wrote: >Are there many vendors who support both CCP and ILCCP over the multlink >at the same time ? 3Com's AccessBuilder 4000 release 6.0 supports both CCP and ILCCP with Stac LZS compression. The CCP is supported above the multilink and ILCCP is below the multilink. Since our product is a remote access server, it's up to the remote dialin client to do CCP or ILCCP. However, they can't be ON at the same time. So far, I couldn't find any vender and product to do the interoperability test with our ILCCP. Leemay - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 18 11:37:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA07313; Thu, 18 Apr 1996 11:37:45 -0400 (EDT) Resent-Date: Thu, 18 Apr 1996 11:37:45 -0400 (EDT) From: abbott@can.nl Date: Thu, 18 Apr 96 17:34:22 +0200 Message-Id: <9604181534.AA01666@ruby.can.nl> To: ietf-ppp@MERIT.EDU Subject: rfc1661 Resent-Message-ID: <"DqDw33.0.Jn1.V5cTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1514 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, In section 5.4 the document says: > Additionally, the Configuration Options in a Configure-Reject MUST > be a proper subset of those in the last transmitted Configure- > Request. So, in particular, a Configure-Request specifying exactly one option can never produce a Configure-Reject. Is this your intention? If not then I suggest removing the word "proper". The document also contains a few spelling mistakes (e.g. occurance). I'm also mystified by the use of the word "octet" rather than "byte" (I guess it is fashionable for standards documents). John. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 18 12:21:39 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA08583; Thu, 18 Apr 1996 12:21:39 -0400 (EDT) Resent-Date: Thu, 18 Apr 1996 12:21:39 -0400 (EDT) From: Craig Fox Message-Id: <199604181620.JAA27731@greatdane.cisco.com> Subject: Re: rfc1661 To: abbott@can.nl Date: Thu, 18 Apr 96 9:20:58 PDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9604181534.AA01666@ruby.can.nl>; from "abbott@can.nl" at Apr 18, 96 5:34 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"41Vf21.0.r52.FmcTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1515 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Hi, > > In section 5.4 the document says: > > Additionally, the Configuration Options in a Configure-Reject MUST > > be a proper subset of those in the last transmitted Configure- > > Request. > So, in particular, a Configure-Request specifying exactly one option can > never produce a Configure-Reject. Is this your intention? > If not then I suggest removing the word "proper". > > The document also contains a few spelling mistakes (e.g. occurance). > I'm also mystified by the use of the word "octet" rather than "byte" > (I guess it is fashionable for standards documents). > > John. > > Wow. I am impressed. I didn't believe you were right so I checked the dictionary. What is truly amazing is that the phrase 'proper subset' was used in the original PPP document, RFC 1134, published in November of 1989. So countless nerds have read it for the last 6 1/2 years without reporting it. So much for reviews. :-) You are correct. We meant that a Configure Request with a single option could result in a Configure Reject with a single option. Thus the word "proper" should be removed from the text at that point. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 18 16:08:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA16242; Thu, 18 Apr 1996 16:08:54 -0400 (EDT) Resent-Date: Thu, 18 Apr 1996 16:08:54 -0400 (EDT) Date: Thu, 18 Apr 1996 14:07:35 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199604182007.OAA17923@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: In oder delivery of packets Cc: baiju@watson.ibm.com Resent-Message-ID: <"J5Hho2.0.Sz3.E5gTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1516 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Baiju Patel > ... > My question is: Will the PPP protocol (or its extension) break if packets > are delivered out of order? Since no one else has said anything ... All of the PPP state machines assume in order but potentially lossy delivery. Sometimes nothing noticable happens, as with Configure-Acks. In other cases you get nothing worse than an extra resetting (so to speak) of the state machines as when an old Configure-Request appears. Multilink (RFC 1717 MP) is quite intolerant of out-of-order delivery. (That's probably something that should be added to any test suites out there. I found my MP code didn't cope well with another implementation that did the equivalent of out-of-order sequence numbering.) Most of the CCP compression schemes will at least hiccup with out-of-order delivery. Some upper layer data streams can be delivered out of order. For example, standards compliant IP, TCP/IP, and UDP/IP implementations handle out-of-order delivery just fine. Others, especially those handled with briding cannot tolerate out-of-order delivery. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 18 19:08:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA21035; Thu, 18 Apr 1996 19:08:15 -0400 (EDT) Resent-Date: Thu, 18 Apr 1996 19:08:15 -0400 (EDT) Date: Thu, 18 Apr 1996 16:08:02 -0700 From: Lida Carrier Message-Id: <199604182308.QAA01961@apple.com> To: ietf-ppp@MERIT.EDU Subject: A question regarding PPP Resent-Message-ID: <"L7ILP3.0.O85.OjiTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1517 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Greetings, I have come across the following scenario for which I cannot find any references in RFC1661. I would appreciate it if someone can response to me directly instead of the mailing list (I am not on the list). Is it legal to receive a Protocol-Reject packet with an identifier field of LCP(C0 21)? I am receiving this from the UUNet server in response to a Protocol-Reject from the client with bogus Rejected-Protocol and Rejected-Information fields. It seems to me it should be silently dropped. What is the standard reply to badly formed packets? Thanks in avdnace! -- Lida Carrier lida@apple.com ~ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 18 19:35:16 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA21636; Thu, 18 Apr 1996 19:35:16 -0400 (EDT) Resent-Date: Thu, 18 Apr 1996 19:35:16 -0400 (EDT) From: Craig Fox Message-Id: <199604182332.QAA27103@greatdane.cisco.com> Subject: Re: A question regarding PPP To: lida@apple.com (Lida Carrier) Date: Thu, 18 Apr 96 16:32:25 PDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199604182308.QAA01961@apple.com>; from "Lida Carrier" at Apr 18, 96 4:08 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"ArGF5.0.kH5.m6jTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1518 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Greetings, > > I have come across the following scenario for which I cannot find any > references in RFC1661. I would appreciate it if someone can response > to me directly instead of the mailing list (I am not on the list). > I am doing both so that our peers can critique my response. :-) > Is it legal to receive a Protocol-Reject packet with an identifier > field of LCP(C0 21)? I am receiving this from the UUNet server in > response to a Protocol-Reject from the client with bogus > Rejected-Protocol and Rejected-Information fields. It seems to me > it should be silently dropped. > It should be silently dropped but logged so that someone can understand why you are failing to communicate. The Protocol Reject is saying that it does not do LCP. Me thinks both implementations are broken. Presumably, once you fix your client, the UUNet bug will go back into hiding. Of course, I am assuming that you mistyped your question above and meant the 'Rejected-Protocol' field since the identifier field is a single byte wide. [Of course, I will spend a little time tonight checking to see what our implementation does in this case. :-)] > What is the standard reply to badly formed packets? > Complain to the implementer! :-) > Thanks in avdnace! > > -- Lida Carrier > lida@apple.com > ~ > > Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 19 00:05:38 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA27150; Fri, 19 Apr 1996 00:05:38 -0400 (EDT) Resent-Date: Fri, 19 Apr 1996 00:05:38 -0400 (EDT) From: Karl Fox Date: Fri, 19 Apr 96 00:04:52 -0400 Message-Id: <9604190404.AA28363@gefilte.MorningStar.Com> To: Lida Carrier Cc: ietf-ppp@MERIT.EDU Subject: A question regarding PPP In-Reply-To: <199604182308.QAA01961@apple.com> References: <199604182308.QAA01961@apple.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"-jtjT2.0.vd6.94nTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1519 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Lida Carrier writes: > Greetings, > > I have come across the following scenario for which I cannot find any > references in RFC1661. I would appreciate it if someone can response > to me directly instead of the mailing list (I am not on the list). > > Is it legal to receive a Protocol-Reject packet with an identifier > field of LCP(C0 21)? I am receiving this from the UUNet server in > response to a Protocol-Reject from the client with bogus > Rejected-Protocol and Rejected-Information fields. It seems to me > it should be silently dropped. Look in RFC 1661, section 4.3, `Events': Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-) This event occurs when a Code-Reject or a Protocol-Reject packet is received from the peer. The RXJ+ event arises when the rejected value is acceptable, such as a Code-Reject of an extended code, or a Protocol-Reject of a NCP. These are within the scope of normal operation. The implementation MUST stop sending the offending packet type. The RXJ- event arises when the rejected value is catastrophic, such as a Code-Reject of Configure-Request, or a Protocol-Reject of LCP! This event communicates an unrecoverable error that terminates the connection. A received Protocol-Reject of LCP is an RXJ- event. Just feed this into your LCP negotiation FSM and it will do the right thing--tld,irc,str/5, which shuts LCP down and starts sending Terminate-Request packets. -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 19 04:57:23 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA02498; Fri, 19 Apr 1996 04:57:23 -0400 (EDT) Resent-Date: Fri, 19 Apr 1996 04:57:23 -0400 (EDT) Message-ID: <01BB2DD7.0B942F60@romulus.knx.co.uk> From: Ian Puleston To: "'abbott@can.nl'" Cc: "'IETF PPP Mailing List'" Subject: RE: rfc1661 Date: Fri, 19 Apr 1996 10:00:23 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"n31_83.0.mc.kLrTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1520 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I'm also mystified by the use of the word "octet" rather than "byte" > (I guess it is fashionable for standards documents). >=20 > John. The English dictionary's definition of the word byte is "Set of usually = eight binary digits (bits) considered as a unit". The inclusion of the = word "usually" therefore precludes its use in a standard. I think that I = have heard of some computers somewhere which have 9-bit bytes (parity = maybe?). The dictionary's definition of the word octet is "Group of eight (lines = of verse, electons, musicians etc.)". Therefore standards can use the = more precise word octet (unless of course your equipment might start = sending poetry down the line!). - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 19 08:32:23 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA06552; Fri, 19 Apr 1996 08:32:23 -0400 (EDT) Resent-Date: Fri, 19 Apr 1996 08:32:23 -0400 (EDT) Date: Fri, 19 Apr 1996 08:30:52 -0400 From: Patrick Klos Message-Id: <199604191230.IAA04139@linux.klos.com> To: ietf-ppp@MERIT.EDU, lida@apple.com Subject: Re: A question regarding PPP Resent-Message-ID: <"RwJTZ.0.-b1.WUuTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1521 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Is it legal to receive a Protocol-Reject packet with an identifier >field of LCP(C0 21)? I am receiving this from the UUNet server in >response to a Protocol-Reject from the client with bogus >Rejected-Protocol and Rejected-Information fields. It seems to me >it should be silently dropped. No. This is apparently a bug in Ascend's dialin server (I know UUNet uses alot of Ascend product). I've run across this myself when testing our PPP Protocol Analyzer and our PPP client for DOS. I've included a trace output below. Packet #90 is our PPP client sending a Protocol- Reject for MPPP. Packet #95 is the Ascend box sending a Protocol-Reject for our Protocol-Reject. They apparently need to fix something. >What is the standard reply to badly formed packets? I would expect that these bogus Protocol-Rejects should be silently discarded. Obviously both sides do support LCP or they wouldn't be communicating! ------------------------Output from SerialView follows------------------------ PPP: From Port A to Port B Size: 001C Number: 90 Type: C021 Time: 125.069 LCP: Code: Protocol-Reject (8) Identifier: 29 Length: 001C Protocol = 003D ---------------------- Original PPP Packet Follows --------------------- MPPP: Sequence = 1 Flags = Beg+End Protocol = 8021 ---------------------- Beginning PPP Packet Header --------------------- IPCP: Code: Configure-Request (1) Identifier: 1 Length: 0010 Option 2 - IP-Compression-Protocol Length = 6 Compression Protocol = 002D (VJ Compressed TCP/IP) Max Slot ID = 15 Comp Slot ID = 0 Option 3 - IP-Address Length = 6 IP Address = 204.177.253.14 ======================================================================== PPP: From Port B to Port A Size: 0022 Number: 95 Type: C021 Time: 125.445 LCP: Code: Protocol-Reject (8) Identifier: 7 Length: 0022 Protocol = C021 ---------------------- Original PPP Packet Follows --------------------- LCP: Code: Protocol-Reject (8) Identifier: 29 Length: 001C Protocol = 003D ---------------------- Original PPP Packet Follows --------------------- MPPP: Sequence = 1 Flags = Beg+End Protocol = 8021 ---------------------- Beginning PPP Packet Header --------------------- IPCP: Code: Configure-Request (1) Identifier: 1 Length: 0010 Option 2 - IP-Compression-Protocol Length = 6 Compression Protocol = 002D (VJ Compressed TCP/IP) Max Slot ID = 15 Comp Slot ID = 0 Option 3 - IP-Address Length = 6 IP Address = 204.177.253.14 ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 19 09:07:22 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA07461; Fri, 19 Apr 1996 09:07:22 -0400 (EDT) Resent-Date: Fri, 19 Apr 1996 09:07:22 -0400 (EDT) Date: Fri, 19 Apr 96 09:11:28 EST From: "Whelan, Bill" Message-Id: <9603198299.AA829930339@netx.nei.com> To: abbott@can.nl Cc: ietf-ppp@MERIT.EDU Subject: Re[2]: rfc1661 Resent-Message-ID: <"n95hL3.0.Fq1.60vTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1522 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> >> Hi, >> >> In section 5.4 the document says: >> > Additionally, the Configuration Options in a Configure-Reject MUST >> > be a proper subset of those in the last transmitted Configure- >> > Request. >> So, in particular, a Configure-Request specifying exactly one option can >> never produce a Configure-Reject. Is this your intention? >> If not then I suggest removing the word "proper". >> >> The document also contains a few spelling mistakes (e.g. occurance). >> I'm also mystified by the use of the word "octet" rather than "byte" >> (I guess it is fashionable for standards documents). >> >> John. >> >> >Wow. I am impressed. I didn't believe you were right so I checked >the dictionary. What is truly amazing is that the phrase 'proper >subset' >was used in the original PPP document, RFC 1134, published in November of >1989. So countless nerds have read it for the last 6 1/2 years without >reporting it. So much for reviews. :-) >You are correct. We meant that a Configure Request with a single option >could result in a Configure Reject with a single option. Thus the word >"proper" should be removed from the text at that point. Instead of removing the word "proper", replace it with "non-empty". While the word "proper" is incorrect in this context, I believe the intent was to preclude the empty set in the Configure Reject. >Craig Bill - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 19 09:59:22 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA08901; Fri, 19 Apr 1996 09:59:22 -0400 (EDT) Resent-Date: Fri, 19 Apr 1996 09:59:22 -0400 (EDT) From: Craig Fox Message-Id: <199604191358.GAA04182@greatdane.cisco.com> Subject: Re: Re[2]: rfc1661 To: bwhelan@nei.com (Whelan, Bill) Date: Fri, 19 Apr 96 6:58:30 PDT Cc: abbott@can.nl, ietf-ppp@MERIT.EDU In-Reply-To: <9603198299.AA829930339@netx.nei.com>; from "Whelan, Bill" at Apr 19, 96 9:11 am X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"alpDn.0.pA2.lmvTn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1523 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > >> > >> Hi, > >> > >> In section 5.4 the document says: > >> > Additionally, the Configuration Options in a Configure-Reject MUST > >> > be a proper subset of those in the last transmitted Configure- > >> > Request. > >> So, in particular, a Configure-Request specifying exactly one option can > >> never produce a Configure-Reject. Is this your intention? > >> If not then I suggest removing the word "proper". > >> > >> The document also contains a few spelling mistakes (e.g. occurance). > >> I'm also mystified by the use of the word "octet" rather than "byte" > >> (I guess it is fashionable for standards documents). > >> > >> John. > >> > >> > >Wow. I am impressed. I didn't believe you were right so I checked > >the dictionary. What is truly amazing is that the phrase 'proper > >subset' > >was used in the original PPP document, RFC 1134, published in November of > >1989. So countless nerds have read it for the last 6 1/2 years without > >reporting it. So much for reviews. :-) > > >You are correct. We meant that a Configure Request with a single option > >could result in a Configure Reject with a single option. Thus the word > >"proper" should be removed from the text at that point. > > Instead of removing the word "proper", replace it with "non-empty". > While the word "proper" is incorrect in this context, I believe the > intent was to preclude the empty set in the Configure Reject. > Yes. That was the intent. An empty Configure Nak or Configure Reject did not make any sense to us. Thank you for the clarification. I am beginning to remember a classroom from 25 years ago. :-) > >Craig > > Bill > > Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Apr 21 16:05:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA12664; Sun, 21 Apr 1996 16:05:49 -0400 (EDT) Resent-Date: Sun, 21 Apr 1996 16:05:49 -0400 (EDT) Message-Id: <317A94AA.6FEC@cisco.com> Date: Sun, 21 Apr 1996 13:03:54 -0700 From: Tom Nguyen Organization: Cisco Systems, Inc. X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: ietf-ppp@MERIT.EDU Cc: cs-ppp@cisco.com Subject: Mal-form LCP conf-req with suboption’s length > the entire conf-req’s length ... Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"OPhUZ1.0.a53.qJfUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1524 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Greetings, I wonder if any of you have seen the following problem and what your thoughts on this. The problem is that the remote end sends a LCP conf-req with a suboption of unknown (w.r.t the local end) option code (192) and its length is 35 which is larger than the whole LCP conf-req frame itself. Our (used to be Combinet's) current implementation is to silently discard this frame with the assumption that the frame is corrupted and hopefully the remote end will retry with a correct frame. But what happened was the remote end continues to retry with the mal-formed LCP conf-req until it gave up (after 10 retries ?). From the remote end’s point of view, it does not know why it sent a LCP conf-req and never got any response, be it an ACK, NAK or REJ response back so it know what to do next. The current solution of quietly discarding the frame is ok, but does not help the situation at all. I was thinking that maybe if I reject the suboption to help point out to the remote end the ‘bad’ portion then that may help the remote end to reformat it conf-req again. The problem is that the length of the suboption is bad (i.e. larger than the whole LCP conf-req frame itself,) So I have to reject the remaining of the frame (based on the LCP conf-req’s length) which may include other correct (good) suboptions. It’s worst if this suboption is the first appears in the LCP conf-req frame. That means I’ll have to reject the whole frame. This maybe better because the remote end would close the connection immediately (or operating with the default settings) instead of waiting for a number of retries and shut-down without knowing exactly what was wrong ? I want to hear other’s opinions on this. Your comments and suggestions are welcome and appreciated. Thanks, --Tom - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 06:50:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA01002; Mon, 22 Apr 1996 06:50:33 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 06:50:33 -0400 (EDT) Message-ID: <01BB3042.34109F60@romulus.knx.co.uk> From: Ian Puleston To: "'IETF PPP Mailing List'" Date: Mon, 22 Apr 1996 11:52:36 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"O2iTU.0.8C.cGsUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/1525 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The PPP Compression Control Protocol (CCP) - = draft-ieft-pppext-compression-04.txt - states that: Before any compressed packets may be communicated, PPP must reach = the=0A= Network-Layer Protocol phase, and the Compression Control = Protocol=0A= must reach the Opened state. This implies that any PPP packets sent after the Network-Layer Protocol = phase has been reached can be compressed, including LCP and NCP packets = (e.g. LCP echo requests, NCP configurations re-negotiation, NCP and LCP = termination packets). I suspect that what was meant by this was actually that just network = layer (data) protocols would be compressed, but with the above wording = an implementation would also need to allow for receiving compressed NCP = and LCP frames. I can envisage two situations where this would be a major problem (the = first is the problem which I have just hit, the second is theoretical, = but the architecture is an actual one): 1. A PPP line monitor would not be able to decode any compressed LCP/NCP = packets. 2. In an architecture where PPP was running on a card with a processor = of limited speed, inside a unit with a big fast processor, it may be = desirable to do the data compression in the fast processor, rather than = on the card where the PPP negotiations are handled. Does anyone have any thoughts on this. Should the RFC be re-worded to = explicitly prohibit compression of NCP / LCP packets ? One point though is that with ILCCP, NCP/LCP packets transferred on the = bundle would want to be compressed. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 08:48:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA03484; Mon, 22 Apr 1996 08:48:31 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 08:48:31 -0400 (EDT) Date: Mon, 22 Apr 1996 08:48:03 -0400 From: Patrick Klos Message-Id: <199604221248.IAA09273@linux.klos.com> To: ietf-ppp@MERIT.EDU, tcnguyen@cisco.com Subject: Re: Mal-form LCP conf-req with suboption’s length > the entire conf-req’s length ... Cc: cs-ppp@cisco.com Resent-Message-ID: <"B5Rvb2.0.7s.S0uUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1526 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >I was thinking that maybe if I reject the suboption to help point=20 >out to the remote end the =91bad=92 portion then that may help the=20 >remote end to reformat it conf-req again. The problem is that the >length of the suboption is bad (i.e. larger than the whole LCP=20 >conf-req frame itself,) So I have to reject the remaining of the=20 >frame (based on the LCP conf-req=92s length) which may include other=20 >correct (good) suboptions. It=92s worst if this suboption is the first >appears in the LCP conf-req frame. That means I=92ll have to reject=20 >the whole frame. This maybe better because the remote end would=20 >close the connection immediately (or operating with the default=20 >settings) instead of waiting for a number of retries and shut-down=20 >without knowing exactly what was wrong ? > >I want to hear other=92s opinions on this. >Your comments and suggestions are welcome and appreciated. I think your best bet is to leave you code alone - just silently discard the packet (aside from probably logging the packet/event). Next, I would try to contact the company that implemented the PPP in the peer device you're having trouble with and let them know what's happening. One this that strikes me funny, you said the option code was 192 and the length was 35. Oddly enough, that's C0 23 (hex), which is the protocol ID for PAP. Coincidence?? Maybe so, but I'll bet 2 donuts that it has something to do with the problem. Patrick ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 10:21:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA06847; Mon, 22 Apr 1996 10:21:06 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 10:21:06 -0400 (EDT) Date: Mon, 22 Apr 96 12:41:06 GMT From: "William Allen Simpson" Message-ID: <5249.wsimpson@greendragon.com> To: Tom Nguyen Cc: ietf-ppp@MERIT.EDU Subject: Re: Mal-form LCP conf-req with suboption’s length > the entire conf-req’s length ... Resent-Message-ID: <"ztrMN3.0.dg1.ENvUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1527 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Tom Nguyen > I wonder if any of you have seen the following problem and what your > thoughts on this. The problem is that the remote end sends a LCP > conf-req with a suboption of unknown (w.r.t the local end) option > code (192) and its length is 35 which is larger than the whole LCP > conf-req frame itself. Heck, that's unknown with regard to the universe! There's no 192 assigned yet. Who's the bogus vendor? In which case, the correct action is to "silently discard". See RFC-1661 page 27: Octets outside the range of the Length field are treated as padding and are ignored on reception. When a packet is received with an invalid Length field, the packet is silently discarded without affecting the automaton. And page 39: The end of the list of Configuration Options is indicated by the Length field of the LCP packet. > Our (used to be Combinet's) current implementation is to silently > discard this frame with the assumption that the frame is corrupted > and hopefully the remote end will retry with a correct frame. Correct! > But what happened was the remote end continues to retry with the > mal-formed LCP conf-req until it gave up (after 10 retries ?). > >From the remote end’s point of view, it does not know why it sent a > LCP conf-req and never got any response, be it an ACK, NAK or REJ > response back so it know what to do next. The current solution of > quietly discarding the frame is ok, but does not help the situation > at all. Sure, it helps the situation. It keeps bogus implementations off the net! ;-) > I was thinking that maybe if I reject the suboption to help point > out to the remote end the ‘bad’ portion then that may help the > remote end to reformat it conf-req again. The problem is that the > length of the suboption is bad (i.e. larger than the whole LCP > conf-req frame itself,) So I have to reject the remaining of the > frame (based on the LCP conf-req’s length) which may include other > correct (good) suboptions. It’s worst if this suboption is the first > appears in the LCP conf-req frame. That means I’ll have to reject > the whole frame. This maybe better because the remote end would > close the connection immediately (or operating with the default > settings) instead of waiting for a number of retries and shut-down > without knowing exactly what was wrong ? > That won't correctly, at least in my implementation, since the Code and Length won't match what was sent (I'm assuming that you trim the Length to something valid). Anyway, silent discard has another benefit: it takes some time trying to negotiate, which gives the user a clue that something is wrong, rather than just a bad line that didn't stay up. And gives many examples for the line trace. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com 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 Apr 22 11:21:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA09356; Mon, 22 Apr 1996 11:21:43 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 11:21:43 -0400 (EDT) Message-Id: <2.2.32.19960422152444.0072d2c0@rottie.cisco.com> X-Sender: tcnguyen@rottie.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 1996 08:24:44 -0700 To: Patrick Klos From: Tom Nguyen Subject: Re: Mal-form LCP conf-req with =?iso-8859-1?Q?suboption=92s_?= length > the entire =?iso-8859-1?Q?conf=2Dreq=92s_?= length ... Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"LEI0r3.0.qH2.sFwUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1528 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Patrick, At 08:48 AM 4/22/96 -0400, you wrote: >>I was thinking that maybe if I reject the suboption to help point=20 >>out to the remote end the =91bad=92 portion then that may help the=20 >>remote end to reformat it conf-req again. The problem is that the >>length of the suboption is bad (i.e. larger than the whole LCP=20 >>conf-req frame itself,) So I have to reject the remaining of the=20 >>frame (based on the LCP conf-req=92s length) which may include other=20 >>correct (good) suboptions. It=92s worst if this suboption is the first >>appears in the LCP conf-req frame. That means I=92ll have to reject=20 >>the whole frame. This maybe better because the remote end would=20 >>close the connection immediately (or operating with the default=20 >>settings) instead of waiting for a number of retries and shut-down=20 >>without knowing exactly what was wrong ? >> >>I want to hear other=92s opinions on this. >>Your comments and suggestions are welcome and appreciated. > >I think your best bet is to leave you code alone - just silently discard >the packet (aside from probably logging the packet/event). Next, I would >try to contact the company that implemented the PPP in the peer device >you're having trouble with and let them know what's happening. > >One this that strikes me funny, you said the option code was 192 and the >length was 35. Oddly enough, that's C0 23 (hex), which is the protocol ID for >PAP. Coincidence?? Maybe so, but I'll bet 2 donuts that it has something >to do with the problem. That is an interesting observation. Part of my own problem was that the tech-support just handled me the PPP (decoded) trace. I have not seen the raw data and we don't have the customer's equipments to reproduce the problem. I'm working this out. In the mean while, I want to consult this group to seek the most appropriate way to handle this case. > >Patrick >============================================================================ > Patrick Klos Email: klos@klos.com > Klos Technologies, Inc. Voice: (603) 424-8300 > 604 Daniel Webster Highway FAX: (603) 424-9300 > Merrimack, New Hampshire 03054 Web: http://www.klos.com/ >============================================================================ Regards, --Tom ==================================================================== Tom Nguyen Voice: (408) 526-4763 Fax: (408) 774-2878 Email: tcnguyen@cisco.com Cisco Systems, Inc. 455 W. Maude Ave. Sunnyvale, CA 94086 ==================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 11:27:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA09489; Mon, 22 Apr 1996 11:27:29 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 11:27:29 -0400 (EDT) Message-ID: <01BB3069.16F25460@romulus.knx.co.uk> From: Ian Puleston To: "'IETF PPP Mailing List'" Subject: Can CCP compress LCP/NCPs ? Date: Mon, 22 Apr 1996 16:30:58 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"JO6TQ1.0._J2.ULwUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1529 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Sorry about clogging up your inbox, but I'm sending this again since I = forgot to fill in the Subject field last time ! The PPP Compression Control Protocol (CCP) - = draft-ieft-pppext-compression-04.txt - states that: Before any compressed packets may be communicated, PPP must reach = the Network-Layer Protocol phase, and the Compression Control Protocol must reach the Opened state. This implies that any PPP packets sent after the Network-Layer Protocol = phase has been reached can be compressed, including LCP and NCP packets = (e.g. LCP echo requests, NCP configurations re-negotiation, NCP and LCP = termination packets). I suspect that what was meant by this was actually that just network = layer (data) protocols would be compressed, but with the above wording = an implementation would also need to allow for receiving compressed NCP = and LCP frames. I can envisage two situations where this would be a major problem (the = first is the problem which I have just hit, the second is theoretical, = but the architecture is an actual one): 1. A PPP line monitor would not be able to decode any compressed LCP/NCP = packets. 2. In an architecture where PPP was running on a card with a processor = of limited speed, inside a unit with a big fast processor, it may be = desirable to do the data compression in the fast processor, rather than = on the card where the PPP negotiations are handled. Does anyone have any thoughts on this. Should the RFC be re-worded to = explicitly prohibit compression of NCP / LCP packets ? One point though is that with ILCCP, NCP/LCP packets transferred on the = bundle would want to be compressed. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 13:17:55 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA13575; Mon, 22 Apr 1996 13:17:55 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 13:17:55 -0400 (EDT) Date: Mon, 22 Apr 96 12:02:44 CST From: "Kenneth Peirce" Message-Id: <9603228302.AA830200759@robogate.usr.com> To: ietf-ppp@MERIT.EDU Subject: LCP CONF-REJ Resent-Message-ID: <"L5MbP3.0.qJ3.kyxUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1530 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have found a client implementation that sends an initial config_reject with a non zero length but with no options following it. 1548 says that the options should be present. Is this some kind of grandfathered config_ack I haven't heard of or is the client broken? Ken Peirce kpeirce@usr.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 13:35:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA14280; Mon, 22 Apr 1996 13:35:36 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 13:35:36 -0400 (EDT) From: Craig Fox Message-Id: <199604221733.KAA12352@greatdane.cisco.com> Subject: Re: LCP CONF-REJ To: kpeirce@usr.com (Kenneth Peirce) Date: Mon, 22 Apr 96 10:33:51 PDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9603228302.AA830200759@robogate.usr.com>; from "Kenneth Peirce" at Apr 22, 96 12:02 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"Sx_Km3.0.qU3.aDyUn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1531 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > I have found a client implementation that sends an initial > config_reject with a non zero length but with no options following it. > 1548 says that the options should be present. Is this some kind of > grandfathered config_ack I haven't heard of or is the client broken? > Broken. I assume that you mean a length field greater than four, which is the size of an empty config request packet. What is the packet length? How do you know that options are not present? Starting off with a Config Reject is broken, regardless of the format of the packet. > Ken Peirce > > kpeirce@usr.com > > Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 22 15:52:32 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA19414; Mon, 22 Apr 1996 15:52:32 -0400 (EDT) Resent-Date: Mon, 22 Apr 1996 15:52:32 -0400 (EDT) Message-Id: In-Reply-To: <01BB3069.16F25460@romulus.knx.co.uk> References: Conversation <01BB3069.16F25460@romulus.knx.co.uk> with last message <01BB3069.16F25460@romulus.knx.co.uk> Priority: Normal To: Ian Puleston , "'IETF PPP Mailing List'" Mime-Version: 1.0 From: Mawuse Agbleze Subject: Re: Can CCP compress LCP/NCPs ? Date: Mon, 22 Apr 96 15:50:21 EDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"eKFCH.0.bk4.2C-Un"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1532 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Sorry about clogging up your inbox, but I'm sending this again since I > forgot to fill in the Subject field last time ! > > The PPP Compression Control Protocol (CCP) - > draft-ieft-pppext-compression-04.txt - states that: > > Before any compressed packets may be communicated, PPP must > reach the > Network-Layer Protocol phase, and the Compression Control > Protocol > must reach the Opened state. > > This implies that any PPP packets sent after the Network-Layer > Protocol phase has been reached can be compressed, including LCP and > NCP packets (e.g. LCP echo requests, NCP configurations > re-negotiation, NCP and LCP termination packets). > > I suspect that what was meant by this was actually that just network > layer (data) protocols would be compressed, but with the above > wording an implementation would also need to allow for receiving > compressed NCP and LCP frames. > > I can envisage two situations where this would be a major problem > (the first is the problem which I have just hit, the second is > theoretical, but the architecture is an actual one): > > 1. A PPP line monitor would not be able to decode any compressed > LCP/NCP packets. > > 2. In an architecture where PPP was running on a card with a > processor of limited speed, inside a unit with a big fast processor, > it may be desirable to do the data compression in the fast > processor, rather than on the card where the PPP negotiations are > handled. > > Does anyone have any thoughts on this. Should the RFC be re-worded > to explicitly prohibit compression of NCP / LCP packets ? > > One point though is that with ILCCP, NCP/LCP packets transferred on > the bundle would want to be compressed. > > > > Ian: I went back and read over the draft and it indeed did not make any mention of what packets are compressed. However, when you refer to the drafts for each compression type there you will find it stated that LCP/NCP packets should not be sent compressed. I checked LZS, DCP and Predictor types, though the Predictor types made no reference to NCP's. In some ways his makes sense, since CCP is the control protocol for compression you use it to configure/enable/disable compression. The various compression types that you negotiate provide the semantics for what you may or may not send/receive compressed. It may not hurt though to have it also explicitly stated in the CCP draft. Regards, -Mawuse - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 23 10:06:30 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA16811; Tue, 23 Apr 1996 10:06:30 -0400 (EDT) Resent-Date: Tue, 23 Apr 1996 10:06:30 -0400 (EDT) From: Karl Fox Date: Tue, 23 Apr 96 10:04:23 -0400 Message-Id: <9604231404.AA07904@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: Request for NetBIOS Frames Control Protocol (NBFCP) Experience Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"0ZTOg3.0.464.lEEVn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1533 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Before I can send in the request to take NBFCP to Draft Standard, I need to take a survey of implementations and interoperability experience. All NBFCP implementors please drop me a note indicating 1) that they have an implementation, and 2) who they have tested with and found interoperable. -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 23 21:54:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA07225; Tue, 23 Apr 1996 21:54:35 -0400 (EDT) Resent-Date: Tue, 23 Apr 1996 21:54:35 -0400 (EDT) Message-Id: <9604240156.AA7866@shivaportal.shiva.com> To: ietf-ppp From: Craig Richards/Shiva Corporation Date: 23 Apr 96 21:55:24 Subject: BACP open issues, continued Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"xWHzv1.0.Qm1.BdOVn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1534 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have a lot of yellow post-it notes cluttering up my desk, some of them deal with BACP issues. Here's the current crop of issues: 1. Favored peer for race conditions (continued from the previous chapter): It appears that favored peer negotiation is the preferred solution. This means that the favored peer MUST be negotiated during BACP link negotiation phase, and that every BACP implementation MUST be able to generate some sort of random number. Assuming that no one complains about these conditions, the favored peer negotiation will be BACP Configuration Option 1, and will have a similar format to the LCP Magic-Number option (one byte Type of 1, one byte Length of 6, and 4 bytes of number). In fact, it probably SHOULD be the Magic-Number value if it was negotiated during LCP. This MUST have a unique value in both directions to be Config-Acked. The lowest value is the favored peer. If this proposal is acceptable to everyone, I will write up something more specific. 2. Unique digits and ISDN sub-address: Some one pointed out that it is not clear if the unique digit value applies to the phone number sub-address. I think this should not be necessary, so I will clarify the spec to point out that the unique digits field does not apply to the phone number sub-address, if one is present. 3. Link type bits: Some one pointed out that the definition of the Link Type bits is non-intuitive. Currently, bit 0 refers to the high order bit of the Link Type field. If there are no objections, I will change this in the next draft, so that bit 0 refers to the low order bit of the Link Type octet. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 09:29:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA26536; Thu, 25 Apr 1996 09:29:07 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 09:29:07 -0400 (EDT) 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-netbios-fcp-08.txt Date: Thu, 25 Apr 96 09:22:40 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9604250922.aa12513@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"2yDz3.0.HU6.cttVn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1535 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. Title : The PPP NetBIOS Frames Control Protocol (NBFCP) Author(s) : G. Pall Filename : draft-ietf-pppext-netbios-fcp-08.txt Pages : 14 Date : 04/24/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms. 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-netbios-fcp-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-netbios-fcp-08.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 (193.205.245.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-netbios-fcp-08.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: <19960424172458.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-netbios-fcp-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960424172458.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 16:47:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA09543; Thu, 25 Apr 1996 16:47:20 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 16:47:20 -0400 (EDT) Date: Thu, 25 Apr 96 13:43:55 PDT From: Kam Lee Subject: CCP To: ietf-ppp X-Priority: 3 (Normal) X-Mailer: Chameleon 4.6, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"xCMjv.0.nK2.FJ-Vn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1536 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Can somebody tell me what is the status of CCP right now, the draft I found in IETF is dated back in 3/10/94, is this still valid or where can I find more updated one? Thanks in advance. ******************************************************** *Home of Chameleon--TCP/IP Applications for Windows *Home of Ecco --The Best Group Productivity Tools *Home of Swift --The Best Emulation--HostConnectivity *Home of NewtWatch--The Best Desktop Management System ******************************************************** Name: Kam Lee NetManage Inc. Phone: 408-973-7171 10725 N. De Anza Blvd. Fax: 408-257-6405 Cupertino, CA, 95014 e-mail: kam@netmanage.com ******************************************************* - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 17:09:16 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA10222; Thu, 25 Apr 1996 17:09:16 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 17:09:16 -0400 (EDT) X-Mailer: SuperTCP Suite for Windows Version 2.1 (Mailer Version 1.02) Message-ID: <317FE9E8-00000001@ns.frontiertech.com.frontiertech.com> From: Robert Gerrits Date: Thu, 25 Apr 1996 16:08:54 cst Subject: COMMON ISDN API CAPI To: ietf-ppp Reply-To: Bob@FrontierTech.COM MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII Resent-Message-ID: <"U8okD3.0.RV2.vd-Vn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1537 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Can somebody tell me where I might be able to find information on CAPI? I am looking for information to develop a driver or if available use a shim. ======================================== Robert J. Gerrits 10201 N. Port Washington Road. Mequon, WI 53092 Email: Bob@FrontierTech.COM ======================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 17:14:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA10446; Thu, 25 Apr 1996 17:14:49 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 17:14:49 -0400 (EDT) Message-ID: <01BB32CA.9CAD3440@davidc.isdnsys.com> From: "David C. Chiles" To: ietf-ppp , "'Kam Lee'" Cc: "'davidc@isdnsys.com'" Subject: RE: CCP Date: Thu, 25 Apr 1996 17:14:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Info: ISDN Technology Leaders Resent-Message-ID: <"xAlqP.0.uY2.4j-Vn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1538 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Can somebody tell me what is the status of CCP right now, the draft >I found in IETF is dated back in 3/10/94, is this still valid or >where can I find more updated one? Thanks in advance. Here's a copy of the latest info I received on April 8, 1996: ====================================================== Note: This announcement supercedes the previous CCP Announcement. Sorry for the mailbox clutter. The IESG has approved the Internet-Draft "The PPP Compression Control Protocol (CCP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeff Burgan. The IESG also approved the publication of the following ten Internet-Drafts as Informational RFCs: 1. PPP Stac LZS Compression Protocol 2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol 3. PPP Gandalf FZA Compression Protocol 4. PPP Predictor Compression Protocol' 5. PPP BSD Compression Protocol 7. PPP LZS-DCP Compression Protocol (LZS-DCP) 8. PPP Magnalink Variable Resource Compression 9. PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) 10. PPP Serial Data Transport Protocol (SDTP) Technical Summary The "PPP Compression Control Protocol provides a standard method for negotiating compression techniques to use over a point-to-point connection. This is of particular to those who use low speed serial connections and wish to obtain high throughput. The Compression Control Protocol does NOT define any of the compression algorithms which may be used. These algorithms will be defined in a separate set of Informational RFCs. Many of these algorithms are proprietary. It was felt by the working group, and the area directors have concurred, that it would not be proper to define any one algorithm to be the standard compression algorithm. Working Group Summary During the development of this protocol, the Motorola Corporation advised the IETF that it owns patents which Motorola claims cover some of the techniques used by the protocol. The working group discussed alternate techniques that did not use encumbered technology but could not come to consensus on such a technique. Furthermore, Motorola was unwilling to provide the licensing agreements required by RFC 1602. A Variance to the requirements of RFC 1602, allowing the adoption of the CCP was requested by the working group and was received from the IETF, see RFC 1915. Protocol Quality This protocol has been reviewed by Frank Kastenholz and Susan Thomson (RET.), Co-Internet Area Directors. There are at least 5 known implementations of this protocol, which have demonstrated varying levels of interoperability. There may be others. Special Note: On 5 June, 1995, the IESG received the following communication from Motorola Inc. Motorola, Inc. has advised the IETF that it holds two patents that it believes to be essential to the CCP and ECP standards, U.S. 5,245,614 and U.S. 5,130,993, and has declared its willingness to make licenses to these patents available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination. Parties interested in obtaining such a license may contact: Mr. John A. Fisher Vice President and Intellectual Property Licensing Counsel Motorola, Inc. 1303 E. Algonquin Road Schaumburg, Ill. 60196 The IESG and IETF make no statement on the validity of this claim. See also RFC 1915. Note to RFC Editor: The following references need to get updated... [1] Should now refer to the updated RFC 1661, July 1994. [2] Should now refer to RFC 1700, October 1994. [3] Should now refer to the published RFC 1663, July 1994. Also, the new chair's name and address should be include in the RFC. This will replace Fred Baker's name. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 18:36:11 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA12601; Thu, 25 Apr 1996 18:36:11 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 18:36:11 -0400 (EDT) From: Rob Friend To: ietf-ppp Subject: RE: CCP Date: Thu, 25 Apr 96 15:36:00 PDT Message-Id: <317FFE95@smtpgateway.stac.com> Encoding: 57 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"usvTJ1.0.d43.Jv_Vn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1539 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Thursday, April 25, 1996 5:14PM "David C. Chiles" wrote: > >Can somebody tell me what is the status of CCP right now, the draft > >I found in IETF is dated back in 3/10/94, is this still valid or > >where can I find more updated one? Thanks in advance. > > > Here's a copy of the latest info I received on April 8, 1996: > > ====================================================== > Note: This announcement supercedes the previous CCP Announcement. Sorry > for the mailbox clutter. > > > The IESG has approved the Internet-Draft "The PPP Compression Control > Protocol (CCP)" as a Proposed > Standard. This document is the product of the Point-to-Point Protocol > Extensions Working Group. The IESG contact persons are Frank Kastenholz > and Jeff Burgan. > > The IESG also approved the publication of the following ten > Internet-Drafts as Informational RFCs: > > > 1. PPP Stac LZS Compression Protocol > > 2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol > > 3. PPP Gandalf FZA Compression Protocol > > 4. PPP Predictor Compression Protocol' > > 5. PPP BSD Compression Protocol > 6. PPP Deflate Protocol > > 7. PPP LZS-DCP Compression Protocol (LZS-DCP) > > 8. PPP Magnalink Variable Resource Compression > > 9. PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) > > 10. PPP Serial Data Transport Protocol (SDTP) > So can anyone tell me what the rfc #'s for all these new standards are? I am also confused that I can find them under the "internet-drafts" subdirectory. I apoligize in advance for my ignorance. Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 18:43:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA12805; Thu, 25 Apr 1996 18:43:33 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 18:43:33 -0400 (EDT) Message-Id: <199604252242.PAA24242@valet.phx.mcd.mot.com> Subject: Re: COMMON ISDN API CAPI To: Bob@FrontierTech.COM Date: Thu, 25 Apr 1996 15:42:17 -0700 (MST) From: "Keith Williamson" Cc: ietf-ppp@MERIT.EDU In-Reply-To: <317FE9E8-00000001@ns.frontiertech.com.frontiertech.com> from "Robert Gerrits" at Apr 25, 96 04:08:54 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"IdL251.0.n73.I00Wn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1540 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Robert, Try http://alumni.caltech.edu/~dank/isdn/isdn_sw.html#API -Keith > > > Can somebody tell me where I might be able to find > information on CAPI? I am looking for information to > develop a driver or if available use a shim. > > ======================================== > Robert J. Gerrits > 10201 N. Port Washington Road. > Mequon, WI 53092 > Email: Bob@FrontierTech.COM > ======================================== > > -- +------------------------------------------------------------------------+ | Keith Williamson Motorola Computer Group | | keith_williamson@phx.mcd.mot.com 2900 S. Diablo Way | | Tel: (602) 438-3614 Tempe, AZ 85282 | | Pager: (602)244-3252 #1719 Mail Stop: DW220 | +------------------------------------------------------------------------+ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 19:54:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA14316; Thu, 25 Apr 1996 19:54:49 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 19:54:49 -0400 (EDT) Message-ID: <3180104E.253B@bryce.com> Date: Thu, 25 Apr 1996 18:52:46 -0500 From: "James Y. Bryce" X-Mailer: Mozilla 2.0GoldB2 (Win95; I) MIME-Version: 1.0 To: Bob@FrontierTech.COM CC: ietf-ppp Subject: Re: COMMON ISDN API CAPI References: <317FE9E8-00000001@ns.frontiertech.com.frontiertech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Egl9s1.0.NV3.531Wn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1542 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Robert Gerrits wrote: > > Can somebody tell me where I might be able to find > information on CAPI? I am looking for information to > develop a driver or if available use a shim. > > ======================================== > Robert J. Gerrits > 10201 N. Port Washington Road. > Mequon, WI 53092 > Email: Bob@FrontierTech.COM > ======================================== Check my book, "Special Edition, Using ISDN," (below) pp 141 et seq for a conceptual discussion of CAPI and a presentation of some of its essential syntax; this is a part of Chapter 6 "Unscrambling API's and also discusses WinISDN, TAPI and TSAPI. The entire CAPI spec is available through Dan Kegel's page at http://www.alumni.caltech.edu/~dank/isdn/capi/capi20.zip -- ------------------------------------------------------------------ JAMES Y. BRYCE bryce@bryce.com COMMUNICATIONS TECHNOLOGY FORECASTING ISDN 512 377-4225 6103 Shoal Creek Boulevard FAX 512 454-4060 Austin, Texas 78757-3129 Voice 512 454-6788 http://www.bryce.com/~bryce PRESENTATIONS + DOCUMENTATION + CONSULTATION + SYSTEMS INTEGRATION ------------------------------------------------------------------ Author "Special Edition, Using ISDN" (Que 1995 ISBN 0-7897-0405-6) Contributing Author "Special Edition, Using the Internet with Windows 95" (Que 1996) ------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Apr 25 19:54:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA14277; Thu, 25 Apr 1996 19:54:33 -0400 (EDT) Resent-Date: Thu, 25 Apr 1996 19:54:33 -0400 (EDT) From: Karl Fox Date: Thu, 25 Apr 96 19:52:15 -0400 Message-Id: <9604252352.AA20455@gefilte.MorningStar.Com> To: Rob Friend Cc: ietf-ppp Subject: RE: CCP In-Reply-To: <317FFE95@smtpgateway.stac.com> References: <317FFE95@smtpgateway.stac.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"fn7zt3.0.oU3.m21Wn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1541 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Rob Friend writes: > > The IESG has approved the Internet-Draft "The PPP Compression Control > > Protocol (CCP)" as a Proposed > > Standard. This document is the product of the Point-to-Point Protocol > > Extensions Working Group. The IESG contact persons are Frank Kastenholz > > and Jeff Burgan. > > > > The IESG also approved the publication of the following ten > > Internet-Drafts as Informational RFCs: ... > So can anyone tell me what the rfc #'s for all these new standards are? They haven't been assigned yet. I'm trying to find out why. -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 26 08:31:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA28286; Fri, 26 Apr 1996 08:31:54 -0400 (EDT) Resent-Date: Fri, 26 Apr 1996 08:31:54 -0400 (EDT) Date: Fri, 26 Apr 1996 08:31:13 -0400 Message-Id: <9604261231.AA27328@MAILSERV-D.FTP.COM> To: ietf-ppp@MERIT.EDU Subject: RE: 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 Fri Apr 26 08:31:11 1996] Originating-Client: d-cell.ftp.com Resent-Message-ID: <"YHjjC.0.Kv6.58CWn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1543 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Rob Friend writes: > > > The IESG has approved the Internet-Draft "The PPP Compression Control > > > Protocol (CCP)" as a Proposed > > > Standard. This document is the product of the Point-to-Point Protocol > > > Extensions Working Group. The IESG contact persons are Frank Kastenholz > > > and Jeff Burgan. > > > > > > The IESG also approved the publication of the following ten > > > Internet-Drafts as Informational RFCs: > ... > > So can anyone tell me what the rfc #'s for all these new standards are? > > They haven't been assigned yet. I'm trying to find out why. They are, as far as I know, on the RFC editor's desk. He will get them published when he gets them published. -- Frank Kastenholz - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 26 16:58:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA12445; Fri, 26 Apr 1996 16:58:36 -0400 (EDT) Resent-Date: Fri, 26 Apr 1996 16:58:36 -0400 (EDT) From: Gina.Deplanche@proteon.com (Gina DePlanche) Message-Id: <9604262057.AA08531@columbo.proteon.com> Subject: PFC and ACFC To: ietf-ppp@MERIT.EDU Date: Fri, 26 Apr 1996 16:57:36 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"OAkci3.0.v13.hZJWn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1544 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi! I've got a question regarding PPP Protocol Field Compression and Address and Control Field Compression. This is my understanding. Please correct me as appropriate: 1. When PFC is successfully negotiated, the Protocol field in the PPP header is of length 1 octet. 2. When PFC is not negotiated, the Protocol field in the PPP header is of length 2 octets. 3. When ACFC is successfully negotiated, the Address and Control Fields are not present in the PPP header (??) 4. When ACFC is not negotiated, the Address and Control Fields are each 1 octet? Actually, I'm not too clear on ACFC. I've gotten myself a bit confused because I have been using Figures 2 and 3 from RFC 1717 as a guide. I interpreted RFC 1717 to say that PFC and ACFC is assumed for packets transmitted using the multilink procedure. Yet, the figures in RFC 1717 show a protocol field with 2 octets. If someone could just straighten me out on this, I'd really appreciate it. Thanks, Gina -- Gina M. DePlanche | Proteon gmd@proteon.com | MailStop #23 (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 898-2547 | 01581-1799 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 26 18:24:08 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA14763; Fri, 26 Apr 1996 18:24:08 -0400 (EDT) Resent-Date: Fri, 26 Apr 1996 18:24:08 -0400 (EDT) From: Archie Cobbs Message-Id: <199604262223.PAA06191@bubba.tribe.com> Subject: Re: PFC and ACFC To: Gina.Deplanche@proteon.com (Gina DePlanche) Date: Fri, 26 Apr 1996 15:23:40 -0700 (PDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9604262057.AA08531@columbo.proteon.com> from "Gina DePlanche" at Apr 26, 96 04:57:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"H9Dxd2.0.Pc3.2qKWn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1545 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > 1. When PFC is successfully negotiated, the Protocol field in the PPP > header is of length 1 octet. I belive it can be of one OR two octets, that is, if you say that you will accept PFC then you're saying, "I will accept either one or two byte protocol fields". The way you tell the difference is that the first byte with bit zero set to one terminates the protocol field. I think certain critical, non-frequent packet types such as LCP often are *never* protocol compressed, for robustness. For the same reason they're not CCP compressed either. > 2. When PFC is not negotiated, the Protocol field in the PPP header is > of length 2 octets. Should be. > 3. When ACFC is successfully negotiated, the Address and Control Fields > are not present in the PPP header (??) For robustness you should accept either type of packet if you've negotiated ACFC. > 4. When ACFC is not negotiated, the Address and Control Fields are each > 1 octet? Should be. -Archie __________________________________________________________________________ Archie L. Cobbs, archie@tribe.com * Whistle Communications Corporation - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 26 18:48:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA15420; Fri, 26 Apr 1996 18:48:52 -0400 (EDT) Resent-Date: Fri, 26 Apr 1996 18:48:52 -0400 (EDT) Message-Id: <199604262252.AA11609@himagiri.NSD.3Com.COM> To: Gina.Deplanche@proteon.com (Gina DePlanche) Cc: ietf-ppp@MERIT.EDU Subject: Re: PFC and ACFC 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 Gina.Deplanche@proteon.com (Gina DePlanche) dated Fri, 26 Apr 1996 16:57:36 EDT <9604262057.AA08531@columbo.proteon.com> Date: Fri, 26 Apr 1996 15:52:18 -0700 From: Venkat Prasad Resent-Message-ID: <"h_Bob.0.gm3.HBLWn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1546 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Hi! >> I've got a question regarding PPP Protocol Field Compression and >> Address and Control Field Compression. >> This is my understanding. Please correct me as appropriate: >> 1. When PFC is successfully negotiated, the Protocol field in the PPP >> header is of length 1 octet. Not necessarily. When you negotiate PFC you are telling the peer that you are capable of receiving compressed protocol field ( 1 byte ). The sender can still send the protocol field uncompressed ( 2 bytes ) >> 2. When PFC is not negotiated, the Protocol field in the PPP header is >> of length 2 octets. That is correct. >> Actually, I'm not too clear on ACFC. >> I've gotten myself a bit confused because I have been using >> Figures 2 and 3 from RFC 1717 as a guide. I interpreted RFC 1717 to say >> that PFC and ACFC is assumed for packets transmitted using the multilink >> procedure. Yet, the figures in RFC 1717 show a protocol field with 2 >> octets. Again, it is OK to send the protocol field uncompressed ( 2 bytes ) even when using MLPPP ( RFC 1717 ). The receiver in MLPPP, however, must be capable of handling MLPPP packets with or without protocol field compressed. see the extract below [ extract from draft-ietf-pppext-multilink-12.txt page 4 According to the rules specified in RFC1661, this means that an | implementation MUST accept reassembled packets with and without | leading zeroes present in the Protocol Field of the reassembled | packet. Although it is explicitly forbidden below to include the | Address and Control fields (usually, the two bytes FF 03) in the | material to be fragmented, it is a good defensive programming | practice to accept the packet anyway, ignoring the two bytes if | present, as that is what RFC1661 specifies. ] >> If someone could just straighten me out on this, I'd really >> appreciate it. >> Thanks, >> Gina /Prasad Venkat Prasad 3Com Corp >> -- >> Gina M. DePlanche | Proteon >> gmd@proteon.com | MailStop #23 >> (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA >> Fax: (508) 898-2547 | 01581-1799 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Apr 26 22:31:00 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA19376; Fri, 26 Apr 1996 22:31:00 -0400 (EDT) Resent-Date: Fri, 26 Apr 1996 22:31:00 -0400 (EDT) From: khohh@westell.com (Ken Hohhof) To: ietf-ppp@MERIT.EDU (ietf-ppp) Message-Id: <1996Apr26.193239.1723.72813@zappa.westell.com> X-Conversion-Id: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Westell, Inc. Date: Fri, 26 Apr 1996 21:32:46 -0500 Subject: Re: PFC and ACFC Resent-Message-ID: <"ozbln2.0.Uk4.UROWn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1547 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I've got a question regarding PPP Protocol Field Compression and >Address and Control Field Compression. > > This is my understanding. Please correct me as appropriate: > >1. When PFC is successfully negotiated, the Protocol field in the PPP >header is of length 1 octet. > >2. When PFC is not negotiated, the Protocol field in the PPP header is >of length 2 octets. > >3. When ACFC is successfully negotiated, the Address and Control Fields >are not present in the PPP header (??) > >4. When ACFC is not negotiated, the Address and Control Fields are each >1 octet? > > > Actually, I'm not too clear on ACFC. > > I've gotten myself a bit confused because I have been using >Figures 2 and 3 from RFC 1717 as a guide. I interpreted RFC 1717 to say >that PFC and ACFC is assumed for packets transmitted using the multilink >procedure. Yet, the figures in RFC 1717 show a protocol field with 2 >octets. > > If someone could just straighten me out on this, I'd really >appreciate it. Gina - Here is my understanding: PFC and ACFC are configuration options by which a receiver informs the peer transmitter of its ability to receive compressed protocol and/or address & control fields. If an option has not been negotiated, the transmitter may not send compressed fields. If an option has been negotiated, the transmitter is not required to send compressed fields, it may still send uncompressed fields. For LCP packets, compression must never be used, to insure correct interpretation even if the 2 ends are confused about the configuration options. PFC allows most protocol fields to be sent as 1 octet instead of 2. The receiver is able to distinguish compressed from uncompressed protocol fields by the fact that the LSB tells you whether an octet is the last (LSB=1) or is extended with the next octet (LSB=0). Data packets will have compressible protocol fields, e.g. 0x0021 for IP. NCP packets will have protocol fields 0x8000-0xbfff, and LCP packets will have protocol fields 0xc000-0xffff. Thus, LCP protocol fields can't be compressed anyway. The following excerpt is from RFC1661: This Configuration Option provides a method to negotiate the compression of the PPP Protocol field. By default, all implementations MUST transmit packets with two octet PPP Protocol fields. PPP Protocol field numbers are chosen such that some values may be compressed into a single octet form which is clearly distinguishable from the two octet form. This Configuration Option is sent to inform the peer that the implementation can receive such single octet Protocol fields. As previously mentioned, the Protocol field uses an extension mechanism consistent with the ISO 3309 extension mechanism for the Address field; the Least Significant Bit (LSB) of each octet is used to indicate extension of the Protocol field. A binary "0" as the LSB indicates that the Protocol field continues with the following octet. The presence of a binary "1" as the LSB marks the last octet of the Protocol field. Notice that any number of "0" octets may be prepended to the field, and will still indicate the same value (consider the two binary representations for 3, 00000011 and 00000000 00000011). When using low speed links, it is desirable to conserve bandwidth by sending as little redundant data as possible. The Protocol- Field-Compression Configuration Option allows a trade-off between implementation simplicity and bandwidth efficiency. If successfully negotiated, the ISO 3309 extension mechanism may be used to compress the Protocol field to one octet instead of two. The large majority of packets are compressible since data protocols are typically assigned with Protocol field values less than 256. Compressed Protocol fields MUST NOT be transmitted unless this Configuration Option has been negotiated. When negotiated, PPP implementations MUST accept PPP packets with either double-octet or single-octet Protocol fields, and MUST NOT distinguish between them. The Protocol field is never compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. When a Protocol field is compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame. AFCF is somewhat misleading, since the address and control fields are not compressed, they are omitted. For PPP, the address field is always the "all stations" address 0xff, and the control field is always 0x03 for connectionless unnumbered information. Since they are always the same, it makes sense to "compress" (i.e. omit) them. The receiver is able to distinguish an address field from a protocol field, since the address field will always be 0xff, and neither octet of a protocol field will ever be 0xff. Again, compression should never be used for LCP packets. RFC1331 contained a good explanation of AFCF which for some reasons was deleted from later versions of PPP including RFC1661. The following excerpt is from RFC1331: This Configuration Option provides a way to negotiate the compression of the Data Link Layer Address and Control fields. By default, all implementations MUST transmit frames with Address and Control fields and MUST use the hexadecimal values 0xff and 0x03 respectively. Since these fields have constant values, they are easily compressed. This Configuration Option is sent to inform the peer that the implementation can receive compressed Address and Control fields. Compressed Address and Control fields are formed by simply omitting them. By definition the first octet of a two octet Protocol field will never be 0xff, and the Protocol field value 0x00ff is not allowed (reserved) to avoid ambiguity. On reception, the Address and Control fields are decompressed by examining the first two octets. If they contain the values 0xff and 0x03, they are assumed to be the Address and Control fields. If not, it is assumed that the fields were compressed and were not transmitted. If a compressed frame is received when Address-and-Control-Field- Compression has not been negotiated, the implementation MAY silently discard the frame. The Address and Control fields MUST NOT be compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. When the Address and Control fields are compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame. Hope this helps. - Ken ==================== Ken Hohhof Westell, Inc. khohh@westell.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 29 13:29:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA20275; Mon, 29 Apr 1996 13:29:43 -0400 (EDT) Resent-Date: Mon, 29 Apr 1996 13:29:43 -0400 (EDT) Date: Mon, 29 Apr 1996 10:27:30 -0700 (PDT) From: Ron Jeffery X-Sender: ronj@amadjuak Reply-To: Ron Jeffery To: Gina DePlanche Cc: ietf-ppp@MERIT.EDU Subject: Re: PFC and ACFC In-Reply-To: <9604262057.AA08531@columbo.proteon.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"25D2D2.0.2y4.VmFXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1548 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Fri, 26 Apr 1996, Gina DePlanche wrote: > > > Hi! > > I've got a question regarding PPP Protocol Field Compression and > Address and Control Field Compression. > > This is my understanding. Please correct me as appropriate: > > 1. When PFC is successfully negotiated, the Protocol field in the PPP > header is of length 1 octet. > > 2. When PFC is not negotiated, the Protocol field in the PPP header is > of length 2 octets. > > 3. When ACFC is successfully negotiated, the Address and Control Fields > are not present in the PPP header (??) > > 4. When ACFC is not negotiated, the Address and Control Fields are each > 1 octet? > > > Actually, I'm not too clear on ACFC. > > I've gotten myself a bit confused because I have been using > Figures 2 and 3 from RFC 1717 as a guide. I interpreted RFC 1717 to say > that PFC and ACFC is assumed for packets transmitted using the multilink > procedure. Yet, the figures in RFC 1717 show a protocol field with 2 > octets. > Hi, I agree with your understanding of PFC and ACFC, and I think that the confusion comes from your interpretation of RFC1717. In multilink there are two PPP packet flows (considering just the direction from the network layers to the links): 1. Packets flowing from the network layers (NL1 and NL2 in rfc1717 figure 1) to the multilink procedure (MLCP in figure 1). 2. Packet flowing from the multilink procedure (MLCP) to the individual links. The multilink procedure sits in the middle of these two flows fragmenting packets from the network layer and adding multilink headers, a new protocol ID, and address and control fields, then passing the resulting packets to the individual links. My interpretation of RFC1717 is that the set of options listed at the bottom of page 4 (including ACFC and PFC) apply to packets passed to ML from the network layers. The packets shown in figures 2 and 3 refer to packets sent from ML down to the individual links. These links are free to negotiate whatever options they want to. Perhaps the sentence just before figure 2 about address & control and protocol compression should be removed in the new multilink draft. Ron. Ron Jeffery Newbridge Networks Corporation e-mail: ronj@newbridge.com phone: +(613) 599-3600 x3234 fax: +(613) 591-3680 > If someone could just straighten me out on this, I'd really > appreciate it. > > Thanks, > Gina > -- > Gina M. DePlanche | Proteon > gmd@proteon.com | MailStop #23 > (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA > Fax: (508) 898-2547 | 01581-1799 > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 29 15:10:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA23820; Mon, 29 Apr 1996 15:10:06 -0400 (EDT) Resent-Date: Mon, 29 Apr 1996 15:10:06 -0400 (EDT) Message-Id: <199604291909.MAA26524@vandys-lap.cisco.com> X-Authentication-Warning: vandys-lap.cisco.com: Host localhost.cisco.com [127.0.0.1] didn't use HELO protocol To: ietf-ppp@MERIT.EDU Subject: L2F, some proposals Date: Mon, 29 Apr 1996 12:09:12 -0700 From: Andy Valencia Resent-Message-ID: <"7OW1s3.0.No5._FHXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1549 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, 1. Sequence and offset fields Based on some feedback of the current spec, a couple significant changes to the header have been proposed. I'd like to give this some exposure. The sequence number is currently one byte. The proposal is to switch the sequence number and the offset field, resulting in a 16-bit sequence number and a 8-bit offset field. As fallout from this, the sequence number would only be physically present if the S bit is set in the header. The offset field would always be present, with a value of 0 if no offset is needed. The F bit would be freed for other uses, as there's no need to flag field presence. 2. Encryption One compelling argument for encryption has arisen: the case where L2F "NAS" functionality is actually within the remote node client software. This permits you to dial through *any* IP dialup POP, and tunnel into your home network. This scenario is quite plausible, and means that you will be arriving within your home network by way of a potentially completely unknown service provider and network path. Ultimately, the network security WG people are going to fix this comprehensively. Anything added to L2F would be a tactical, short-term solution. As such, it has been proposed that a bit in the header indicate encryption, the encryption would be the usual MD5 has XOR'd against the payload, and that a shared secret be assumed to exist between the NAS and the Home Gateway. No key management. If encryption doesn't converge shortly, I plan on decoupling the discussion from the rest of the L2F draft. 3. Further attributes There have been several requests for a sub-option indicating the type of media receiving the original call. BACP got buried trying to enumerate this, and appears to have fallen back to a very simple classification. L2F could include such a simple classification, along with a bandwidth estimate. This could help functions like BACP, as well as routing protocols where even a *guess* of the bandwidth is better than no data at all. I'm going to carve some sub-option values for vendor attributes. I'm also going to add some encoding so that "optional" attributes can be detected and known to be safely ignored. 4. Packet reordering With all the sequence number stuff, it becomes possible for L2F to handle out of order packets. Flow control and retransmission are nasty (and L2F avoids them), but handling some amount of reordering can make a big difference, especially for bridged environments. The current spec discards out of order packets, which technically allows bridging to work. However, this can cause quite a significant rate of packet loss. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 29 15:44:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA24858; Mon, 29 Apr 1996 15:44:29 -0400 (EDT) Resent-Date: Mon, 29 Apr 1996 15:44:29 -0400 (EDT) From: Karl Fox Date: Mon, 29 Apr 96 15:43:48 -0400 Message-Id: <9604291943.AA01208@gefilte.MorningStar.Com> To: Andy Valencia Cc: ietf-ppp@MERIT.EDU Subject: L2F, some proposals In-Reply-To: <199604291909.MAA26524@vandys-lap.cisco.com> References: <199604291909.MAA26524@vandys-lap.cisco.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"S9k9U2.0.846.QmHXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1550 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Andy Valencia writes: > 2. Encryption ... > Ultimately, the network security WG people are going to fix this > comprehensively. Anything added to L2F would be a tactical, short-term > solution. Why not use the IPSEC WG's ESP-DES-CBC and AH-MD5, which are both at Draft Standard? There are already over a dozen interoperable commercial implementations. -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 29 17:27:22 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA27962; Mon, 29 Apr 1996 17:27:22 -0400 (EDT) Resent-Date: Mon, 29 Apr 1996 17:27:22 -0400 (EDT) Date: Mon, 29 Apr 96 17:30:53 EDT From: rms@zircon.acc.com (Ron Stoughton) Message-Id: <9604292130.AA06487@zircon.acc.com> To: ietf-ppp@MERIT.EDU Subject: CCP/Stac LZS option parameters Resent-Message-ID: <"0WJqO1.0.eq6.pGJXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1551 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU If any vendors who have implemented, or are planning to implement, the Stac LZS option for CCP care divulge which check-modes they support, I would very much like to hear from you. "None" is required by default, and "Sequence Number" is recommended, so I am hoping there is nearly universal support for these. Does anyone also plan to support "LCB", "CRC" and/or "Extended Mode"? Also, since "None" is required by default, and since having no check mode seems only to be useful in the presence of a reliable link, am I correct to read between the lines and assume that anyone implementing the Stac LZS option MUST also implement the LCP reliable link option? Ron Stoughton rms@acc.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Apr 29 17:51:27 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA28702; Mon, 29 Apr 1996 17:51:27 -0400 (EDT) Resent-Date: Mon, 29 Apr 1996 17:51:27 -0400 (EDT) Date: Mon, 29 Apr 96 17:50:48 EDT From: Ben.McCann@proteon.com (Ben McCann) Message-Id: <9604292150.AA11854@kerplop.proteon.com> To: rms@zircon.acc.com Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9604292130.AA06487@zircon.acc.com> (rms@zircon.acc.com) Subject: Re: CCP/Stac LZS option parameters Resent-Message-ID: <"EoPHZ2.0.707.RdJXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1552 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Resent-Date: Mon, 29 Apr 1996 17:27:16 -0400 (EDT) Date: Mon, 29 Apr 96 17:30:53 EDT From: rms@zircon.acc.com (Ron Stoughton) Resent-Message-Id: <"0WJqO1.0.eq6.pGJXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1551 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU If any vendors who have implemented, or are planning to implement, the Stac LZS option for CCP care divulge which check-modes they support, I would very much like to hear from you. "None" is required by default, and "Sequence Number" is recommended, so I am hoping there is nearly universal support for these. Does anyone also plan to support "LCB", "CRC" and/or "Extended Mode"? Also, since "None" is required by default, and since having no check mode seems only to be useful in the presence of a reliable link, am I correct to read between the lines and assume that anyone implementing the Stac LZS option MUST also implement the LCP reliable link option? Ron Stoughton rms@acc.com Proteon is implementing the Sequence Number option only. We do not believe LCP reliable link is necessary because we discard any MAC layer frames which have CRC errors. (CRC is part of HDLC framing). The discarded frames are detected by STAC's sequence number mechanism. The receiving entity sends a Reset Request to the transmitting entity and then discards frames until it receives a Reset Ack. The reset itself flushes the dictionary at both ends so they become re-synchronized. Thus, HDLC CRC's (or PPP HDLC framing over async) detects errors and the STAC sequence numbers, plus Reset Request/Ack, recovers from them. -Ben McCann --- Ben McCann, bem@proteon.com Proteon, MailStop #21, 9 Technology Drive, Westborough, MA 01581-1799 Tel: (508) 898-2800 x2540 FAX: (508) 898-3176 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 30 14:43:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA28362; Tue, 30 Apr 1996 14:43:43 -0400 (EDT) Resent-Date: Tue, 30 Apr 1996 14:43:43 -0400 (EDT) From: Rob Friend To: ietf-ppp Subject: Re: CCP/Stac LZS option parameters Date: Tue, 30 Apr 96 11:41:00 PDT Message-Id: <31865F56@smtpgateway.stac.com> Encoding: 85 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"LOJFp.0.Xw6.aybXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1553 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Monday, April 29, 1996 5:50PM Ben.McCann@proteon.com (Ben McCann) wrote: > If any vendors who have implemented, or are planning to implement, the > Stac LZS option for CCP care divulge which check-modes they support, > I would very much like to hear from you. > > "None" is required by default, and "Sequence Number" is recommended, so > I am hoping there is nearly universal support for these. Does anyone > also plan to support "LCB", "CRC" and/or "Extended Mode"? > > Also, since "None" is required by default, and since having no check > mode seems only to be useful in the presence of a reliable link, am > I correct to read between the lines and assume that anyone implementing > the Stac LZS option MUST also implement the LCP reliable link option? > > Ron Stoughton > rms@acc.com > > Proteon is implementing the Sequence Number option only. We do not > believe LCP reliable link is necessary because we discard any MAC > layer frames which have CRC errors. (CRC is part of HDLC framing). The > discarded frames are detected by STAC's sequence number mechanism. The > receiving entity sends a Reset Request to the transmitting entity and > then discards frames until it receives a Reset Ack. The reset itself > flushes the dictionary at both ends so they become re-synchronized. > > Thus, HDLC CRC's (or PPP HDLC framing over async) detects errors and > the STAC sequence numbers, plus Reset Request/Ack, recovers from them. > > -Ben McCann > > > --- > Ben McCann, bem@proteon.com > Proteon, MailStop #21, 9 Technology Drive, Westborough, MA 01581-1799 > Tel: (508) 898-2800 x2540 FAX: (508) 898-3176 > I want to reiterate the decisions in the last IETF meeting in Los Angeles. Here are excerpts from the minutes: > Rob Friend - Stac Compression > > OPtion 17: > Rob is going to drop a note to the PPP list asking who is using 0x4021. If > it is not, the value will be pulled. I have found an 2 ISPs that uses this PID. I am still investigating. However, this spec will not be deleted. > Draft 6 addresses a backwards compatibility issue in draft 5, restores the > 0x00 deletion and insertion, and defines the extended (Windows '95) mode. > Windows '95 uses option 4 in a different way than the draft describes, and > uses a different data format. The question arises whether it is > appropriate to include in the draft. > > Draft 6 has five options for check mode, all of which (except extended > mode) seem to be widely implemented. The question was raised if we could > select one or two and make all others historical. The resolution, after > some discussion, was to require implementation ("MUST IMPLEMENT") of > option 3 - sequence number check mode - with at least one history. The > other four check modes are to be documented and made optional to implement. As can be seen here, the "default" of check mode "none" will be changed to a "requirement" of "sequence numbers". > The LCB and CRC configuration options were viewed as redundant with FCS. > > This implies that the implementation "MUST IMPLEMENT" the use of the CCP > RESET/RESPONSE mechanism, or reliable mode, or both. > > Other issues include clearly specifying the above paragraph in the current > text, defining transmitter & receiver processes in extended mode, deleting > the reference to mandating the same number history number bytes in both > directions, and other minor editorial updates. Stac-07.txt will be released shortly, making these updates. Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 30 15:33:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA29947; Tue, 30 Apr 1996 15:33:19 -0400 (EDT) Resent-Date: Tue, 30 Apr 1996 15:33:19 -0400 (EDT) From: Karl Fox Date: Tue, 30 Apr 96 15:32:28 -0400 Message-Id: <9604301932.AA02615@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: MONTREAL IETF: SCHEDULING UPDATE In-Reply-To: <9604301118.aa02961@CNRI.Reston.VA.US> References: <9604301118.aa02961@CNRI.Reston.VA.US> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"Pm4LD.0.bJ7.shcXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1554 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Here are our meeting times for the Montreal IETF: > WEDNESDAY, June 26, 1996 > 1300-1500 Afternoon Sessions I > INT pppext Point-to-Point Protocol Extensions WG > THURSDAY, June 27, 1996 > 1300-1500 Afternoon Sessions I > INT pppext Point-to-Point Protocol Extensions WG -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Apr 30 16:44:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA02526; Tue, 30 Apr 1996 16:44:59 -0400 (EDT) Resent-Date: Tue, 30 Apr 1996 16:44:59 -0400 (EDT) Date: Tue, 30 Apr 96 16:48:15 EDT From: rms@zircon.acc.com (Ron Stoughton) Message-Id: <9604302048.AA06918@zircon.acc.com> To: RFRIEND@stac.com, ietf-ppp@MERIT.EDU Subject: Re: CCP/Stac LZS option parameters Resent-Message-ID: <"eM8X2.0._c.vkdXn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1555 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Stac-07.txt will be released shortly, making these updates. > > Regards, > > Robert C. Friend Stac Electronics Any estimate on how shortly? It would be nice to have this prior to the Pac Bell back-off. Ron Stoughton rms@acc.com - - - - - - - - - - - - - - - - -