From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 10:44:28 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08293 for ; Sun, 2 Jul 2000 10:44:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A3985DD8D; Sun, 2 Jul 2000 10:43:51 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 85C045DDA9; Sun, 2 Jul 2000 10:43:51 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id A76895DD8D for ; Sun, 2 Jul 2000 10:43:49 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28621; Sun, 2 Jul 2000 08:43:45 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA22198; Sun, 2 Jul 2000 10:43:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id KAA13534; Sun, 2 Jul 2000 10:43:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14687.21792.650458.298686@gargle.gargle.HOWL> Date: Sun, 2 Jul 2000 10:43:44 -0400 (EDT) From: James Carlson To: Craig Fox Cc: Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 , "'Stacy_Nichols@pmc-sierra.com'" Subject: Re: PPPmux and MP In-Reply-To: Craig Fox's message of 1 July 2000 13:10:05 References: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E48@il27exm02.cig.mot.com> <4.3.2.7.2.20000701123900.02284970@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Craig Fox writes: > This is PPP. You only agreed that the peer knows how to do PPP muxing > and has expressed a willingness to receive muxed frames. You are not > agreeing to send them. Of course. That's the problem. You're agreeing to receive them before you know whether or not you are able to. The paragraph reads in part: > >> [...] If the PPP Multiplexed Frame option is > >> negotiated on any link of a Multilink PPP bundle, then the > >> receiver has agreed to support the PPP Multiplexed Frame > >> option on the Multilink Bundle. [...] This implies that if you're willing to receive either Multilink or PPPmux, but not both, then you're stuck. Consider an access server that terminates some sessions locally (normal Internet access) and forwards others via L2TP. How can the NAS agree to do something on behalf of an MP bundle head that is located remotely and has unknown properties? That's why this should be an NCP. Putting it in LCP doesn't make sense to me. It doesn't need to be negotiated before authentication. > That works for me. Is this text acceptable? Assuming we can't agree to fix the PPPmux protocol to use an NCP for negotiation, that's the better remaining alternative. > frames MUST NOT contain PPP Multilink frames. As with a > non-Multilink link, the transmitter is not obligated to > send PPP Multiplexed frames. It's probably ok to repeat this idea in this last sentence, but this is certainly true of everything else. For example, agreeing to receive with address and control compression does not obligate the sender to compress, and so on. This isn't a special feature of PPPmux. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 12:09:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08689 for ; Sun, 2 Jul 2000 12:09:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9080A5DDC9; Sun, 2 Jul 2000 12:09:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F84B5DDC7; Sun, 2 Jul 2000 12:09:30 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 355A25DDA9 for ; Sun, 2 Jul 2000 12:09:29 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA328022 for ; Sun, 2 Jul 2000 12:07:33 -0400 From: jmartz@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id MAA254300 for ; Sun, 2 Jul 2000 12:09:23 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256910.0058C091 ; Sun, 2 Jul 2000 12:09:24 -0400 X-Lotus-FromDomain: IBMUS To: ietf-ppp@merit.edu Message-ID: <85256910.0058BF83.00@D51MTA04.pok.ibm.com> Date: Sun, 2 Jul 2000 11:09:21 -0500 Subject: Re: PPPmux and MP Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08689 I'd also suggest that if you update the draft-ietf-pppext-pppmux-00.txt to include a reference to the compound frames LCP option described in RFC 1570 and consider pros, cons and interoperability of pppmux versus the LCP compound frames option. The goals of both options seem to be related, no? Speaking as an implementer, I'd also appreciate more justification for adding extra complexity to my implementation to save a few bytes during transmission.  My personal opinion is that hacking off a few bytes from a packet never manifests itself as a performance improvement my customers will notice. I think optimizations such as this are more effectively performed by the hardware at the physical link layer, not by the protocol software. Consequently, I currently would never implement either of these LCP options. I'd be interested in hearing the opinions and/or experiences from anyone whose implementation does/would support either compound frames or pppmux. Is it "worth it"? Why? -john martz,   jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 12:48:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08852 for ; Sun, 2 Jul 2000 12:48:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36D2A5DDA9; Sun, 2 Jul 2000 12:47:51 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1A3725DDC7; Sun, 2 Jul 2000 12:47:51 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 132DF5DDA9 for ; Sun, 2 Jul 2000 12:47:49 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23111; Sun, 2 Jul 2000 09:47:44 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03468; Sun, 2 Jul 2000 12:47:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id MAA13686; Sun, 2 Jul 2000 12:47:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14687.29232.954665.840161@gargle.gargle.HOWL> Date: Sun, 2 Jul 2000 12:47:44 -0400 (EDT) From: James Carlson To: Craig Fox Cc: Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 , "'Stacy_Nichols@pmc-sierra.com'" Subject: Re: PPPmux and MP In-Reply-To: Craig Fox's message of 2 July 2000 10:57:21 References: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E48@il27exm02.cig.mot.com> <4.3.2.7.2.20000701123900.02284970@sigma.cisco.com> <4.3.2.7.2.20000702104435.02252f00@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Craig Fox writes: > You mean that you would not send the option until you knew whether > you are going to be in a bundle or not? Yes, or until I know who the user is. > You are also negotiating > MLP at that point. If MLP is rejected, you can add/remove the > other options as you see fit. If MLP is accepted, then you will be > in a bundle or disconnected, correct? If it's accepted, then both MP (MRRU) and PPPmux are enabled at once. Other than renegotiating LCP (which is avoided everywhere possible for obvious reasons), I'm stuck. If I offer both MRRU and PPPmux to my peer, I have to be prepared for him to accept both. I can't allow just one or the other. > >This implies that if you're willing to receive either Multilink or > >PPPmux, but not both, then you're stuck. > > Huh? I don't understand. Are you referring to the link being able > to receive a PPPmux vs a Multilink frame while part of a bundle? > Why would you want to do that? The entity doing the MP reassembly might not be the same one doing individual links. They may well have different capabilities. I can think of reasons why I might want PPPmux at the link layer, but if I want to offer that, then I have a choice between also implementing at the bundle level or simply foregoing PPPmux. > >Consider an access server that terminates some sessions locally > >(normal Internet access) and forwards others via L2TP. How can the > >NAS agree to do something on behalf of an MP bundle head that is > >located remotely and has unknown properties? > > How does it do it today? LCP will be renegotiated if the HGW/LNS is > unhappy with the options negotiated by the NAS/LAC. And the user's brain-damaged PC promptly hangs up. I'd very much like to avoid LCP renegotiation if at all possible. > >That's why this should be an NCP. Putting it in LCP doesn't make > >sense to me. It doesn't need to be negotiated before authentication. > > Hmmm, different attitudes... I think that ECP/CCP are in the wrong > location. I think that they should be negotiated (along with the > peer name) during LCP. But that is water long over the dam... Right. Fortunately, PPPmux isn't over the dam yet. I agree completely that authentication should have been put into LCP. It would have fixed the complaints about callback (and the subsequent botch CBCP). I liked Funk's mechanism for LCP authentication. That's not what we're stuck with, though. As for ECP/CCP, it is odd that they require multiple protocol numbers and such, but at least, as NCPs, they're easier to configure separately. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 12:56:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08868 for ; Sun, 2 Jul 2000 12:56:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C0865DDC7; Sun, 2 Jul 2000 12:56:17 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5ACFA5DDCA; Sun, 2 Jul 2000 12:56:17 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7BD6B5DDC7 for ; Sun, 2 Jul 2000 12:56:15 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23451; Sun, 2 Jul 2000 09:56:13 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03546; Sun, 2 Jul 2000 12:56:12 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id MAA13689; Sun, 2 Jul 2000 12:56:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <14687.29742.345326.718690@gargle.gargle.HOWL> Date: Sun, 2 Jul 2000 12:56:14 -0400 (EDT) From: James Carlson To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu Subject: Re: PPPmux and MP In-Reply-To: jmartz@us.ibm.com's message of 2 July 2000 11:09:21 References: <85256910.0058BF83.00@D51MTA04.pok.ibm.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08868 jmartz@us.ibm.com writes: > I'd also suggest that if you update the draft-ietf-pppext-pppmux-00.txt to > include a reference to the compound frames LCP option described in RFC 1570 > and consider pros, cons and interoperability of pppmux versus the LCP > compound frames option. The goals of both options seem to be related, no? PPPmux is extremely similar, but a little better. It goes to some effort to eliminate as much overhead as possible by recognizing that most links have long chains of packets using a single protocol number. > Speaking as an implementer, I'd also appreciate more justification for > adding extra complexity to my implementation to save a few bytes during > transmission.  My personal opinion is that hacking off a few bytes from a > packet never manifests itself as a performance improvement my customers > will notice. I think optimizations such as this are more effectively It depends on what you're doing. The original justification for PPPmux was that it brings Voice over IP overhead more in line with the overhead expected for plain voice calls and thus makes it more practical for wireless use. I'm not an expert in wireless VoIP, so I really can't comment on that aspect. It does reduce the PPP overhead to the minimum possible, and at least I can imagine applications where bits on the wire are far more expensive than any computational complexity. Like compound-frames, I don't see a burning need for it either, and I'm not rushing to implement it. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 13:03:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08950 for ; Sun, 2 Jul 2000 13:03:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37DFD5DDE1; Sun, 2 Jul 2000 13:02:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 254C25DDA8; Sun, 2 Jul 2000 13:02:47 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 4EEF25DDDB for ; Sun, 2 Jul 2000 13:02:45 -0400 (EDT) Received: from tmima-homepc.cisco.com (tmima-dsl5.cisco.com [144.254.211.46]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA20116; Sun, 2 Jul 2000 10:02:13 -0700 (PDT) Message-Id: <4.3.1.2.20000702094435.021c9f00@omega.cisco.com> X-Sender: tmima@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 02 Jul 2000 09:59:33 -0700 To: jmartz@us.ibm.com, ietf-ppp@merit.edu From: Tmima Koren Subject: Re: PPPmux and MP In-Reply-To: <85256910.0058BF83.00@D51MTA04.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 11:09 AM 7/2/00 -0500, jmartz@us.ibm.com wrote: >I'd also suggest that if you update the draft-ietf-pppext-pppmux-00.txt to >include a reference to the compound frames LCP option described in RFC 1570 >and consider pros, cons and interoperability of pppmux versus the LCP >compound frames option. The goals of both options seem to be related, no? > >Speaking as an implementer, I'd also appreciate more justification for >adding extra complexity to my implementation to save a few bytes during >transmission. My personal opinion is that hacking off a few bytes from a >packet never manifests itself as a performance improvement my customers >will notice. I think optimizations such as this are more effectively >performed by the hardware at the physical link layer, not by the protocol >software. Consequently, I currently would never implement either of these >LCP options. > >I'd be interested in hearing the opinions and/or experiences from anyone >whose implementation does/would support either compound frames or pppmux. >Is it "worth it"? Why? Multiplexing is useful when the PPP packets are tunneled: the overhead of the tunneling header is amortized over the multiplexed packets see: http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-00.txt Tmima >-john martz, jmartz@us.ibm.com >IBM AS/400 TCP/IP PPP development (and stuff) > > > > From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 13:44:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09106 for ; Sun, 2 Jul 2000 13:44:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0038F5DDCB; Sun, 2 Jul 2000 13:44:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E12865DDCA; Sun, 2 Jul 2000 13:44:28 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 2333D5DDA8 for ; Sun, 2 Jul 2000 13:44:27 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id LAA27179 for ietf-ppp@merit.edu env-from ; Sun, 2 Jul 2000 11:44:26 -0600 (MDT) Date: Sun, 2 Jul 2000 11:44:26 -0600 (MDT) From: Vernon Schryver Message-Id: <200007021744.LAA27179@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPPmux and MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Tmima Koren > ... > >I'd be interested in hearing the opinions and/or experiences from anyone > >whose implementation does/would support either compound frames or pppmux. > >Is it "worth it"? Why? > > Multiplexing is useful when the PPP packets are tunneled: >the overhead of the tunneling header is amortized over the multiplexed packets > see: http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-00.txt Competent engineering is not about optimizing one single parameter while ignoring all others. Both of the proposals strain to remove a few bits of PPP overhead, but ignore their costs. Those costs include CPU cycles, implementation complexity including inevitable interoperability problems and bugs, complications for diagnostic tools such as PPP frame monitors and decoders, and the bandwidth spent negotiating the options (successfully or not). The old PPP multi-frame proposal was never significantly implemented, if at all. This new proposal will have the same fate. Both are like WAP and try to optimize bandwidth as if today were 1980, while ignoring other costs and not looking for a plausible 21st Century use. In other words, as I often say, albeit a little more colorfully, "Anyone can always find something to add to anything. The trick that requires a very thick skin, hard work, a little experience, some skill, and perhaps talent is leaving out everything but required features." However, this multi-frame PPP proposal is innocuous, because it will not be implemented, unlike some useless protocols like BAP/BACP it doesn't have a lot of marketing muscle flogging it, and it doesn't require crazy, incompatible, non-interoperable changes like the AO stuff. It will get an RFC number and be forgotten. Yes, I read http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-00.txt No, I'm not convinced. L2TP tunnels across the wide Internet?--Even if such things were good ideas and if this were 1990 when bandwidth was harder to get than low end-to-end latency over the public Internet, Microsoft, Cisco, a zillion other proprietary VPN vendors, and even ssh own that market. Another part of competent engineering is assessing and dealing with non-technical issues, from esthetics and economics in bridge building to the discouraging effects of existing good-enough network protocols on better ideas. For example and as James Carlson said, the world needs PPP authentication fixed (moved entirely into LCP) far more than PPP multi-frames, but there's no hope of fixing authentication. Having authentication separate continues to cause problems (e.g. forcing LCP renegotiations that waste time and don't work with junk PPP implementations), while PPP multi-frames would be at best a marginal optimization. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 14:13:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09230 for ; Sun, 2 Jul 2000 14:13:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3D4D5DDA8; Sun, 2 Jul 2000 14:13:01 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B83655DDCA; Sun, 2 Jul 2000 14:13:01 -0400 (EDT) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by segue.merit.edu (Postfix) with ESMTP id F1E785DDA8 for ; Sun, 2 Jul 2000 14:12:59 -0400 (EDT) Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e62ICvx26761; Sun, 2 Jul 2000 20:12:57 +0200 (MET DST) Received: (from cabo@localhost) by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id UAA14689; Sun, 2 Jul 2000 20:12:56 +0200 (MET DST) Date: Sun, 2 Jul 2000 20:12:56 +0200 (MET DST) Message-Id: <200007021812.UAA14689@dienstmann.informatik.uni-bremen.de> X-Authentication-Warning: dienstmann.informatik.uni-bremen.de: cabo set sender to cabo@informatik.uni-bremen.de using -f From: Carsten Bormann To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: PPPmux and MP In-Reply-To: <200007021744.LAA27179@calcite.rhyolite.com> References: <200007021744.LAA27179@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon Schryver writes: > Both of the proposals strain to remove a few bits > of PPP overhead, but ignore their costs. Those costs include CPU cycles, > implementation complexity including inevitable interoperability problems > and bugs, complications for diagnostic tools such as PPP frame monitors > and decoders, and the bandwidth spent negotiating the options (successfully > or not). True. Like header compression. > Both > are like WAP and try to optimize bandwidth as if today were 1980, while > ignoring other costs and not looking for a plausible 21st Century use. Nope. WAP changes entire end systems, warps security architectures, requires new boxes in the middle of the network. Header compression, PPPMUX and things like that change consenting routers and, if successful, cause localized changes in host stacks. Totally different space. Gruesse, Carsten PS.: It would help if certain PPP veterans would occasionally read up on the technical parameters of VoIP, all-IP fixed networks for wireless, etc. I'm not sure I like PPPMUX too much (even with my little change :-), but I can already guess who will be implementing it. From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 14:52:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09391 for ; Sun, 2 Jul 2000 14:52:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 224D95DDCA; Sun, 2 Jul 2000 14:52:17 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0FA895DDCD; Sun, 2 Jul 2000 14:52:17 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id EBF4F5DDCA for ; Sun, 2 Jul 2000 14:52:12 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA29907 for ietf-ppp@merit.edu env-from ; Sun, 2 Jul 2000 12:52:12 -0600 (MDT) Date: Sun, 2 Jul 2000 12:52:12 -0600 (MDT) From: Vernon Schryver Message-Id: <200007021852.MAA29907@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPPmux and MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Carsten Bormann > > Both of the proposals strain to remove a few bits > > of PPP overhead, but ignore their costs. Those costs include CPU cycles, > > implementation complexity including inevitable interoperability problems > > and bugs, complications for diagnostic tools such as PPP frame monitors > > and decoders, and the bandwidth spent negotiating the options (successfully > > or not). > > True. Like header compression. Yes and no; Like some but unllike some other kinds of header compression. Header compression over very low speed links (less than 32 Kbit/sec) is very valuable. However, even VJ header compression is uninteresting to the people who would pay for it over links fast enough to paint Mpixel displays or merely fetch any of the bazillions of web pages on the WWW. If even VJ header compression were valued today, it would be possible to find an ISP that supports it. That it is practically impossible to by VJ header compressed IP bandwidth says all that needs to be said about any new PPP header compression scheme that removes far fewer than the 37 bytes per frame of VJ header compression. > > Both > > are like WAP and try to optimize bandwidth as if today were 1980, while > > ignoring other costs and not looking for a plausible 21st Century use. > > Nope. WAP changes entire end systems, warps security architectures, > requires new boxes in the middle of the network. Header compression, > PPPMUX and things like that change consenting routers and, if > successful, cause localized changes in host stacks. > Totally different space. On the contrary, you're mixing technical and non-technical issues. Besides the technical foolishness of WAP, WAP assumes characteristics of networks, users, and end user equipment that seem silly to anyone outside the old mass media and the telephone industry. WAP assumes that surfing the web over postage stamp sized monochrome screens is useful to other employees of telcos and telco suppliers. The rest of the world won't care about "web enabled" wireless (or land line) telephones until they have mega-pixel (or close) displays. Those bit displays won't be useful until they also have the bandwidth required to paint them. Thus, WAP, like this proposal, makes economic or marketing sense only if you assume nonsense, starting with such a dearth of bandwidth to the fancy wireless phones of the future that no one will buy them or pay for air time. > PS.: It would help if certain PPP veterans would occasionally read up > on the technical parameters of VoIP, all-IP fixed networks for > wireless, etc. I'm not sure I like PPPMUX too much (even with my > little change :-), but I can already guess who will be implementing > it. It would help even more if there were less mindless advocacy for the last gasps and brainclouds of the telephants, as well as presumptions that no one outside the telephone industry ever looks at the latest telco definitions of IP and the Intenet. That telephone history, teleco business models and plans, and telco service guarantees are based on the assumption and claim that PSTN connections to customers can carry at most 1200 bit/sec (or in recent years, 14 kbit/sec) of digital data matters less and less to the rest of the universe. Yes, I suppose PPPMUX will be implemented by the same outfits that are trying to reduce their market capitalization enough so that they can be taken private with capital raised by passing a hat at an IETF meeting, which is to say the same outfits pushing WAP. In 18 months or 2 years, when it is obvious even to enthusiastic telco and telco supplier stockholders that the vast sums spent are WAP are completely wasted, what will happen? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 15:29:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09642 for ; Sun, 2 Jul 2000 15:29:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30D615DDD6; Sun, 2 Jul 2000 15:28:39 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F1B05DDD1; Sun, 2 Jul 2000 15:28:39 -0400 (EDT) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by segue.merit.edu (Postfix) with ESMTP id 714EB5DDD0 for ; Sun, 2 Jul 2000 15:28:37 -0400 (EDT) Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e62JSZx01140; Sun, 2 Jul 2000 21:28:36 +0200 (MET DST) Received: (from cabo@localhost) by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id VAA15155; Sun, 2 Jul 2000 21:28:34 +0200 (MET DST) Date: Sun, 2 Jul 2000 21:28:34 +0200 (MET DST) Message-Id: <200007021928.VAA15155@dienstmann.informatik.uni-bremen.de> X-Authentication-Warning: dienstmann.informatik.uni-bremen.de: cabo set sender to cabo@informatik.uni-bremen.de using -f From: Carsten Bormann To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: PPPmux and MP In-Reply-To: <200007021852.MAA29907@calcite.rhyolite.com> References: <200007021852.MAA29907@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This will be my last message in this thread. Vernon Schryver writes: > [lots of stuff that just makes we want to repeat what I said earlier:] > > PS.: It would help if certain PPP veterans would occasionally read up > > on the technical parameters of VoIP, all-IP fixed networks for > > wireless, etc. Hint: "average packet size", "cost of spectrum", "cost of bandwidth in access networks". Gruesse, Carsten PS.: > employees of telcos and telco suppliers. The rest of the world won't care > about "web enabled" wireless (or land line) telephones until they have > mega-pixel (or close) displays. Little do you know... (Hint: "i-mode".) From owner-ietf-ppp-outgoing@merit.edu Sun Jul 2 15:41:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09750 for ; Sun, 2 Jul 2000 15:41:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A46615DDD8; Sun, 2 Jul 2000 15:41:26 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 889F45DDD1; Sun, 2 Jul 2000 15:41:26 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id E2DE95DDD0 for ; Sun, 2 Jul 2000 15:41:24 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id NAA01046 for ietf-ppp@merit.edu env-from ; Sun, 2 Jul 2000 13:41:24 -0600 (MDT) Date: Sun, 2 Jul 2000 13:41:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200007021941.NAA01046@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPPmux and MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > This will be my last message in this thread. I find very distasteful avoid tatics like that are intended or whose only rationally expected result are to try to get the last word. When I have nothing more to say, I try to use the simplest engineering solution, which is to say nothing more. > > [lots of stuff that just makes we want to repeat what I said earlier:] > > > > PS.: It would help if certain PPP veterans would occasionally read up > > > on the technical parameters of VoIP, all-IP fixed networks for > > > wireless, etc. > > Hint: "average packet size", "cost of spectrum", "cost of bandwidth in > access networks". It's too bad you didn't bother to actually read and understand my point, that regardless of the reality of current and past costs of bandwidth, if the resulting service is not useful, people won't buy. If telco customers must choose between POTS and POTS with useless SuperHypeWay frills, they'll all choose the cheapest alternative, no matter how much marketing the telcos spew. > > employees of telcos and telco suppliers. The rest of the world won't care > > about "web enabled" wireless (or land line) telephones until they have > > mega-pixel (or close) displays. > > Little do you know... > (Hint: "i-mode".) I hope your retirement savings are not dependent on such notions. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Mon Jul 3 10:55:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02884 for ; Mon, 3 Jul 2000 10:55:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 747DD5DDAA; Mon, 3 Jul 2000 10:55:09 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 619935DDAD; Mon, 3 Jul 2000 10:55:09 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id A6DF55DDAA for ; Mon, 3 Jul 2000 10:55:07 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26771; Mon, 3 Jul 2000 08:54:54 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA11311; Mon, 3 Jul 2000 10:54:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id KAA14193; Mon, 3 Jul 2000 10:54:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14688.43326.596894.465536@gargle.gargle.HOWL> Date: Mon, 3 Jul 2000 10:54:54 -0400 (EDT) From: James Carlson To: Craig Fox Cc: Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 , "'Stacy_Nichols@pmc-sierra.com'" Subject: Re: PPPmux and MP In-Reply-To: Craig Fox's message of 2 July 2000 22:24:37 References: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E48@il27exm02.cig.mot.com> <4.3.2.7.2.20000701123900.02284970@sigma.cisco.com> <4.3.2.7.2.20000702104435.02252f00@sigma.cisco.com> <4.3.2.7.2.20000702221306.022e2de0@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Craig Fox writes: > OK. Don't you have the same problem with Multilink and every > other LCP option including Authentication? OK, you've convinced me. This problem occurs in enough places now that adding one more doesn't do obvious harm. > However, if we switch to an NCP, then it would not be possible to set > it at the link layer, correct? Or were you considering violating one > of the rules of PPP? If you need it also at the per-link level as well, I'd advocate using the CCP/ECP per-link model. At least that's a well-known, well- understood hack. (Unlike having LCP negotiation affect which NCPs are in use at the bundle level ...) > Of course, since we have an assigned LCP option, we could negotiate > with either an LCP or an NCP. > > That's a joke.... I took it that way. ;-} > Are we stuck? Or have we just accepted this? Are you absolutely sure > that it is too late to change? Given that current efforts seem to be directed towards apparent mistakes like EAP, I'd say yes, it's probably too late to add LCP authentication. > I distinctly remember early PPP meetings where the attitude was that PPP > was a short-lived protocol since the IPLPDN (I Plop Down/IP over Large > Public Data Networks) work was going to obsolete us. That was 8 to 9 > years ago. PPP is still here. IPLPDN plopped. Many have come and gone. I don't think that's the point. The last wg consensus that I understood was that the group was attempting to advance the remaining drafts and then, having completed its work, become dormant. > I would be willing to help work on an LCP Authentication scheme... I've put a copy of the Funk proposal here: ftp://ftp.workingcode.com/pub/carlson/draft-ietf-pppext-link-negot-00.txt -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Jul 3 14:17:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05635 for ; Mon, 3 Jul 2000 14:17:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C681E5DDFB; Mon, 3 Jul 2000 14:16:05 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B13535DE02; Mon, 3 Jul 2000 14:16:05 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by segue.merit.edu (Postfix) with ESMTP id 8BFD05DDFB for ; Mon, 3 Jul 2000 14:16:03 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA21239 for ; Mon, 3 Jul 2000 14:16:02 -0400 (EDT) Received: from alemsrv.micro.lucent.com (h135-14-2-122.lucent.com [135.14.2.122]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA21235 for ; Mon, 3 Jul 2000 14:16:02 -0400 (EDT) Received: by alemsrv.micro.lucent.com (8.8.6/EMS-1.2 sol2) id OAA01737; Mon, 3 Jul 2000 14:15:57 -0400 (EDT) Received: from lucent.com by alemsrv.micro.lucent.com (8.8.6/EMS-1.2 sol2) id OAA01696; Mon, 3 Jul 2000 14:15:45 -0400 (EDT) Message-ID: <3960D821.CD8AC2@lucent.com> Date: Mon, 03 Jul 2000 14:14:57 -0400 From: "Nevin R. Jones" X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org, nrjones@lucent.com, murton@nortelnetworks.com, ietf-ppp@merit.edu Subject: Re-send of Extending PPP with virtual concatenation Content-Type: multipart/mixed; boundary="------------C3FAB43C8276FA9A9DCDBC88" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. --------------C3FAB43C8276FA9A9DCDBC88 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All: Attached is an upload of the above internet draft. Any comments are welcome. Regards, -Nevin Jones --------------C3FAB43C8276FA9A9DCDBC88 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-pppext-posvcholo-02_062700.txt" Content-Disposition: inline; filename="draft-ietf-pppext-posvcholo-02_062700.txt" Content-Transfer-Encoding: 7bit PPP Extensions Working Group N. Jones, INTERNET DRAFT Lucent Microelectronics Category: Informational C. Murton, Expires: December 2000 Nortel Networks June 2000 R. Broberg, Lucent Technologies Optical Networking Group Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited. Jones Expires December 2000 1 Internet Draft POS with VC, HO & LO June 2000 Abstract The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This document proposes an extension to the mapping of PPP into SONET/SDH defined in RFC 2615 PPP over SONET/SDH (POS) [3], to include use of SONET/SDH SPE/VC virtual concatenation and use of both high order and low order payloads. The objective of this document is to provide the status of this proposal in the telecommunications standards definition process. The current situation is that work in ANSI, ETSI & ITU-T has resulted in a global standard for virtual concatenation. This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Table of Contents 1. Introduction................................................3 2. Rate Comparisons............................................4 3. Current Technologies........................................6 4. Virtual Concatenation Description...........................7 5. Emerging Benefits...........................................8 6. Standards Status............................................9 7. Security Considerations....................................10 8. References.................................................10 9. Acknowledgments............................................11 10. Author's Addresses.........................................11 11. Copyright Notice...........................................11 Jones Expires December 2000 2 Internet Draft POS with VC, HO & LO June 2000 1. Introduction A broad consensus has emerged among major market researchers indicating, that while voice traffic will continue to grow at a moderate clip, data will come to dominate most networks by the years 2002-2005. Moreover, recent network studies [4][5] have shown that this data traffic is overwhelmingly dominated by relatively short IP datagrams transported across network sessions that are in the tens of seconds duration range. In the face of the above trends, it is becoming increasingly more obvious that, although the existing SONET/SDH transport structures are sufficiently optimized to support traditional TDM voice type applications, they are bandwidth inefficient when confronted with the inherently bursty, statistical characteristics of data applications. In addition, new applications requiring transport in SONET/SDH concatenated payload envelopes run the risk of being unsupported. This is a result of the non-standardization and, consequently, non- availability of particular rates (e.g. SONET STS-2c, STS-4c, STS-24c or SDH VC-2-2c) or the unavailability in practice of particular concatenation rates even if they were standardized (e.g., STS-12c in SONET or VC-4-4c in SDH). Furthermore, even if the concatenated rates were defined in standards and supported by the network operator, the practical availability of such payload coverage is often dependent upon the non-fragmentation (i.e., the availability of contiguous time slots) of bandwidth in the SONET/SDH network. The SONET/SDH standards have been updated to include the mechanism for SONET/SDH payload virtual concatenation. This scheme can provide right sized link channelisation for ring and other SONET/SDH network topologies. The ITU-T has developed a standard for SDH High Order and Low Order payload Virtual Concatenation. This global standards development has been aligned with ANSI T1X1 (SONET) and ETSI. Further standards work on the subject of Variable Bandwidth Allocation (VBA) will make the dynamic re-sizing and hitless re- configuration of virtually concatenated paths possible. Jones Expires December 2000 3 Internet Draft POS with VC, HO & LO June 2000 For the convenience of the reader, the equivalent terms are listed below: SONET SDH --------------------------------------------- SPE VC VT (1.5/2/6) Low order VC (VC-11/12/2) STS-SPE Higher Order VC (VC-3/4/4-Nc) STS-1 frame STM-0 frame (rarely used) STS-1-SPE VC-3 STS-1 payload C-3 STS-3c frame STM-1 frame, AU-4 STS-3c-SPE VC-4 STS-3c payload C-4 STS-12c/48c/192c frame STM-4/16/64 frame, AU-4-4c/16c/64c STS-12c/48c/192c-SPE VC-4-4c/16c/64c STS-12c/48c/192c payload C-4-4c/16c/64c This table is an extended version of the equivalent table in RFC 2615 [3]. Additional information on the above terms can be found in Bellcore GR-253-CORE [6], ANSI T1.105 [7], ANSI T1.105.02 [8] and ITU-T G.707 [9]. 2. Rate Comparisons The original tributary bit rates chosen for SONET/SDH were intended for voice services. These rates have a coarse granularity, require duplicate network resources for protection and are not a good match to LAN bandwidths. Currently supported WAN bandwidth links for PPP: ANSI ETSI ----------------------------------------------------- DS1 (1.5Mbit/s) E1 (2Mbit/s) DS3 (45Mbit/s) E3 (34Mbit/s) STS-3c (150Mbit/s) STM-1 (150Mbit/s) STS-12c (620Mbit/s) STM-4 AU-4-4c (620Mbit/s) STS-48c (2.4Gbit/s) STM-16 AU-4-16c (2.4Gbit/s) Note that AU-4-4c and AU-4-16c are not generally available in SDH networks at present. With virtual concatenation the following additional WAN bandwidth links would be available for PPP : SONET VT-1.5-nv (n=1-64) 1.6Mbit/s-102Mbit/s STS-1-nv (n=1-64) 49Mbit/s-3.1Gbit/s STS-3c-nv (n=1-64) 150Mbit/s-10Gbit/s Jones Expires December 2000 4 Internet Draft POS with VC, HO & LO June 2000 SDH VC-12-nv (n=1-64) 2.2Mbit/s-139Mbit/s VC-3-nv (n=1-64) 49Mbit/s-3.1Gbit/s VC-4-nv (n=1-64) 150Mbit/s-10Gbit/s Higher levels of virtual concatenation are possible, but not necessarily useful. At present CONTIGUOUS concatenation caters for 4 or 16 VC-4s. Bit rates for Transparent LAN Services (TLS) are typically 10Mbit/s and 100Mbit/s. Bit rates of 1Gbit/s are also becoming more and more popular. Also other services (e.g. ATM cells stream) may vary from a few Mbit/s to several tens of Mbit/s. However there are no direct mappings for the transport of such bit rates over SONET/SDH. In order to transport the services mentioned above via a SONET/SDH transport network there is no match in the bandwidth granularity. Table 1 and Table 2,respectively depict the SONET/SDH transport structures that are currently available to carry various popular bit rates. Each table contains three columns. The first column shows the bit rates of the service to be transported. The next column contains two values: a) the logical signals that are currently available to provide such transport and, b) in parenthesis, the percent efficiency of the given transport signal without the use of virtual concatenation. Likewise, the final column also contains two values: a) the logical signals that are currently available to provide such transport and, b) in parenthesis, the percent efficiency of the given transport signal with the use of virtual concatenation. Note, that Table 1, contains SONET transport signals with the following effective payload capacity: VT-1.5 SPE = 1.600 Mbit/s, STS-1 SPE = 49.536 Mbit/s, STS-3c SPE = 149.760 Mbit/s, STS-12c SPE = 599.040 Mbit/s and STS-48c SPE = 2,396.160 Mbit/s. Table 1. SONET Virtual Concatenation Bit rate Without With ------------------------------------------------------------- 10Mbit/s STS-1 (20%) VT-1.5-7v (89%) 25Mbit/s STS-1 (50%) VT-1.5-16v(98%) 100Mbit/s STS-3c (67%) STS-1-2v (100%) or VT-1.5-63v (99%) 200Mbit/s STS-12c(33%) STS-1-4v (100%) or STS-3c-2v (66%) 1Gbit/s STS-48c(42%) STS-3c-7v (95%) Jones Expires December 2000 5 Internet Draft POS with VC, HO & LO June 2000 Similarly, Table 2, contains SDH transport signals with the following effective payload capacity: VC-11 = 1.600 Mbit/s, VC-12 = 2.176 Mbit/s, VC-2 = 6.784 Mbit/s, VC-3 = 48.960 Mbit/s, VC-4 = 149.760 Mbit/s and VC-4-4c = 599.040 Mbit/s. Table 2. SDH Virtual Concatenation Bit rate Without With ------------------------------------------------------------- 10Mbit/s VC-3 (20%) VC-12-5v (92%) 25Mbit/s VC-3 (50%) VC-12-12v (96%) 100Mbit/s VC-4 (67%) VC-3-2v (100%) or VC-12-46v (100%) 200Mbit/s VC-4-4c(33%) VC-3-4v (100%) or VC-4-2v (66%) 1Gbit/s VC-4-16c(42%) VC-4-7v (95%) The only currently supported SONET/SDH SPE/VCs in RFC 2615 [4] are the following: SONET SDH ---------------------------------------- STS-3c-SPE VC-4 STS-12c-SPE VC-4-4c STS-48c-SPE VC-4-16c STS-192c-SPE VC-4-64c Note that VC-4-4c and above are not widely supported in SDH networks at present. 3. Current Technologies Two existing standard technologies for making use of multiple physical paths to build a single logical link are Multi-link PPP (ML-PPP RFC 1990 [10]) and Inverse Multiplexing for ATM (IMA af-phy- 0086.001 [11]). These approaches use frame/cell level load balancing and typically use multiple T1/E1 paths to build a link. Virtual concatenation uses SONET/SDH SPE/VC directly and therefore does not have the inefficiency of mapping into asynchronous (T1/T3) or plesiochronous (E1/E3) payload first. In addition since virtual concatenation is a byte level inverse multiplexing technique, it has the characteristics of right sized bandwidth, improved granularity, cost, low delay, low jitter, re-use of protection bandwidth and high efficiency payload mapping. This makes it a suitable physical layer for a single PPP link. Note that virtual concatenation can also be of benefit for ATM for much the same reasons. SONET/SDH virtual concatenation operates at the physical layer below PPP. The main objective of virtual concatenation is to provide a Jones Expires December 2000 6 Internet Draft POS with VC, HO & LO June 2000 logical mesh of multiple right sized channels over a SONET/SDH network. It is therefore independent of any higher layer schemes for providing equal cost multi-path routing or load balancing. 4. Virtual Concatenation Description This section describes Concatenation of Virtual Containers and in particular describes Virtual Concatenation. Concatenation is a method for the transport, over SONET/SDH networks, of a payload of a bandwidth greater than the capacity of the information structure currently defined in standards. For example to transport a signal of bandwidth equivalent to four VC-4s the frame structure would be VC-4-4c. Concatenation is defined in ITU-T recommendation G.707 [9] as "A procedure whereby a multiplicity of Virtual Containers is associated one with another with the result that their combined capacity can be used as a single container across which bit sequence integrity is maintained". Two types of concatenation are proposed: contiguous and virtual. Contiguous concatenation Contiguous concatenation uses a concatenation indicator in the pointer associated with each concatenated frame to indicate that the SPE/VC with which the pointers are associated are concatenated. For example, four VC-4s contiguously concatenated in an information structure would have a data rate of VC-4-4C. The resulting signal has one valid path overhead (9-byte column) and three 9-byte columns of fixed stuff. The four payloads are byte interleaved in the VC-4- 4c payload area. For contiguously concatenated payload to pass through a network, all intermediate nodes must support contiguous concatenation. Virtual Concatenation Many installed network elements in SONET/SDH networks cannot support contiguous concatenation. The processing in these NEs is limited to processing only individual SPE/VC. To implement contiguous concatenation in such networks would require extensive hardware upgrade of the equipment and would be prohibitively expensive. Virtual Concatenation is one way of overcoming this problem. The main aim of virtual concatenation is to provide the SONET/SDH NEs at both ends of the signal path with the capability of sending/receiving individual SPE/VC that are associated in a concatenated group. In this way the cost of transporting concatenated signal is confined to the up-grade costs at the ends of the path. These cost are likely to be significantly lower than up- grading a whole network to handle contiguously concatenated signals. Jones Expires December 2000 7 Internet Draft POS with VC, HO & LO June 2000 At the sending end it will be necessary to provide each SPE/VC with information about its concatenated group identity and its position/sequence within the group, and to give each its own POH for processing in the intermediate nodes in the network. At the receiving end the equipment must be capable of identifying a SPE/VC as belonging to a particular concatenated group and identifying its position/sequence within that group. Because of the likelihood of different propagation and processing delays for each of the individual SPE/VC, it will be necessary for the receiving end equipment to provide buffers to store the incoming data until the latest SPE/VC arrives, when re-alignment can be performed. One method of providing group identification is to use the J1 byte (Path Trace). If each concatenated group used a different path trace identifier then the receiving equipment will know that a particular VC belongs to that group. The information of what sequence/position a SPE/VC has within the group must be conveyed in the POH. The receiving end will process this information and re-assemble the SPE/VC in the correct order. The difference in the arrival times at the receiver of given SPEs/VCs in a virtually concatenated group is known as the Differential Delay. It will be necessary for the receiving equipment to measure this parameter and to detect if it has gone beyond the range of the buffers, which have been provided to re-align the incoming data. Network Management of the virtually concatenated signal will not require the network equipment to be modified since the NEs are processing essentially standard SPE/VC. 5. Emerging Benefits The main objective of virtual concatenation is to provide multiple right sized channels over a SONET/SDH network. The benefit of virtual concatenation to PPP is the ability to provide channels in a SONET/SDH network that are more appropriate for IP. The advantages of these channels are bandwidth granularity, right sized capacity, efficient mapping into SONET/SDH SPE/VC, traffic scalability and channelized high capacity SONET/SDH interfaces. The characteristics of virtually concatenated links, which provide for bandwidth reduction in the event of a path failure, are a good match for Differentiated Services. The reason for this is that the loss of bandwidth will effect the lower priority traffic first and should allow the higher priority traffic to continue passing over the link. Jones Expires December 2000 8 Internet Draft POS with VC, HO & LO June 2000 Another benefit of virtual concatenation is the ability to add or remove a SPE/VC from the group without taking a PPP link using the group Out Of Service. The change in bandwidth should take place in a few milli-seconds, depending on the physical distance between the two ends of the link. Virtual concatenation could make better use of SONET/SDH path protection bandwidth. Consider a single path protected 45Mbit/s or 34Mbit/s circuit. The SONET/SDH bandwidth needed to support this would involve using two STS-1/VC-3s. When virtual concatenation is applied to this situation, a link of 100Mbit/s can be provided. In the event of a path failure this would be reduced to 50Mbit/s. 6. Standards Status ITU-T (SG13/SG15), ANSI T1X1 and ETSI TM1/WP3 have developed global standards for SONET/SDH High Order and Low Order payload Virtual Concatenation. These changes will appear in the following standards: ITU-T G.803 Architecture of transport networks based on the synchronous digital hierarchy (SDH) ITU-T G.707 Network Node Interface for the Synchronous Digital Hierarchy (SDH) ITU-T G.783 Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks ANSI T1.105 Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats ANSI T1.105.02 Synchronous Optical Network (SONET) - Payload Mappings ETSI EN 300 417-9-1 Transmission and Multiplexing (TM) Generic requirements of transport functionality of equipment Part 9: Synchronous Digital Hierarchy (SDH) concatenated path layer functions. Subpart 1: Requirements Work in ITU-T, ANSI T1X1 and ETSI TM1/WP3 has ensured global standards alignment. The completion of a standard for SONET/SDH SPE/VC virtual concatenation means it has become appropriate to consider the use of this standard for PPP. This could take the form of a backward compatible update to RFC 2615 [3]. Jones Expires December 2000 9 Internet Draft POS with VC, HO & LO June 2000 7. Security Considerations This document is for information only. Any protocol related documents that arise from it would contain security consideration. 8. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 1661, Daydreamer, July 1994. [2] Simpson, W., Editor, "PPP in HDLC-like Framing, "RFC 1662, Daydreamer, July 1994. [3] Malis, A. & Simpson, W., "PPP over SONET/SDH, "RFC 2615, June 1999. [4] K. Thompson, G. Miller, and R. Wilder, "Wide Area Internet Traffic Patterns and Characteristics" IEEE Network, Nov 1997. http://www.vbns.net/presentations/papers/MCItraffic.ps [5] K Claffy, Greg Miller, and Kevin Thompson, "The nature of the beast: Recent traffic measurements from an Internet backbone", INET'98 Conference, April 1998. http://www.caida.org/Papers/Inet98/index.html [6] Bellcore Publication GR-253-Core "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria" January 1999 [7] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats" ANSI T1.105-1995 [8] American National Standards Institute, "Synchronous Optical Network (SONET) - Payload Mappings" ANSI T1.105.02-1998 [9] ITU-T Recommendation G.707 "Network Node Interface for the Synchronous Digital Hierarchy" 1996 [10] Sklower, K. et al., "The PPP Multilink Protocol (MP)" RFC 1990, August 1996 [11] Inverse Multiplexing for ATM (IMA) Specification version 1.1 af-phy-0086.001, March 1999 Jones Expires December 2000 10 Internet Draft POS with VC, HO & LO June 2000 9. Acknowledgments Huub van Helvoort, Maarten Vissers (Lucent), Paul Langner (Lucent Microelectronics), Trevor Wilson (Nortel), Mark Carson (Nortel) and James McKee (Nortel) for their contribution to the development of virtual concatenation of SONET/SDH payloads. 10. Author's Addresses Nevin Jones Lucent Technologies Microelectronics Group 600 Mountain Avenue Murray Hill, New Jersey 07974 USA Email: nrjones@lucent.com Chris Murton Nortel Networks Harlow Laboratories London Road, Harlow, Essex, CM17 9NA UK Email: murton@nortelnetworks.com Robert Broberg Lucent Technologies Optical Networking Group 600 Mountain Avenue Murray Hill, New Jersey 07974 USA Email: rbroberg@lucent.com 11. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Jones Expires December 2000 11 --------------C3FAB43C8276FA9A9DCDBC88-- From owner-ietf-ppp-outgoing@merit.edu Mon Jul 3 14:34:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05846 for ; Mon, 3 Jul 2000 14:34:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53F235DDA2; Mon, 3 Jul 2000 14:33:37 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 379485DDAD; Mon, 3 Jul 2000 14:33:37 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 8AFB95DDA2 for ; Mon, 3 Jul 2000 14:33:35 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA21533 for ; Mon, 3 Jul 2000 14:33:35 -0400 (EDT) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA21508 for ; Mon, 3 Jul 2000 14:33:34 -0400 (EDT) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jul 2000 14:33:34 -0400 Message-ID: <2723E6389F55D311BDC200508B129547017E1F51@pai820exch003u.micro.lucent.com> From: "Jones, Nevin R (Nevin)" To: internet-drafts@ietf.org, murton@nortelnetworks.com, ietf-ppp@merit.edu Subject: RE: Re-send of Extending PPP with virtual concatenation Date: Mon, 3 Jul 2000 14:33:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFE51D.2F49C800" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFE51D.2F49C800 Content-Type: text/plain > All: > The preceding attachment was sent in error please disregard. I have attached the correct file for upload. Any comments are > welcome. > > Regards, > > -Nevin Jones > <> ------_=_NextPart_000_01BFE51D.2F49C800 Content-Type: text/plain; name="draft-ietf-pppext-posvcholo-02.txt" Content-Disposition: attachment; filename="draft-ietf-pppext-posvcholo-02.txt" Content-Description: draft-ietf-pppext-posvcholo-02 Content-Transfer-Encoding: quoted-printable PPP Extensions Working Group N. Jones, INTERNET DRAFT Lucent Microelectronics Category: Informational C. Murton, Expires: December 2000 Nortel Networks June 2000 Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited. Jones Expires December 2000 1 Internet Draft POS with VC, HO & LO June 2000 Abstract The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This document proposes an extension to the mapping of PPP into SONET/SDH defined in RFC 2615 PPP over SONET/SDH (POS) [3], to include use of SONET/SDH SPE/VC virtual concatenation and use of both high order and low order payloads. The objective of this document is to provide the status of this proposal in the telecommunications standards definition process. The current situation is that work in ANSI, ETSI & ITU-T has resulted in a global standard for virtual concatenation. This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Table of Contents 1. Introduction................................................3 2. Rate Comparisons............................................4 3. Current Technologies........................................6 4. Virtual Concatenation Description...........................7 5. Emerging Benefits...........................................8 6. Standards Status............................................9 7. Security Considerations....................................10 8. References.................................................10 9. Acknowledgments............................................11 10. Author's Addresses.........................................11 11. Copyright Notice...........................................11 Jones Expires December 2000 2 Internet Draft POS with VC, HO & LO June 2000 1. Introduction A broad consensus has emerged among major market researchers indicating, that while voice traffic will continue to grow at a moderate clip, data will come to dominate most networks by the years 2002-2005. Moreover, recent network studies [4][5] have shown that this data traffic is overwhelmingly dominated by relatively short IP datagrams transported across network sessions that are in the tens of seconds duration range. In the face of the above trends, it is becoming increasingly more obvious that, although the existing SONET/SDH transport structures are sufficiently optimized to support traditional TDM voice type applications, they are bandwidth inefficient when confronted with the inherently bursty, statistical characteristics of data applications. In addition, new applications requiring transport in SONET/SDH concatenated payload envelopes run the risk of being unsupported. This is a result of the non-standardization and, consequently, non- availability of particular rates (e.g. SONET STS-2c, STS-4c, STS-24c or SDH VC-2-2c) or the unavailability in practice of particular concatenation rates even if they were standardized (e.g., STS-12c in SONET or VC-4-4c in SDH). Furthermore, even if the concatenated rates were defined in standards and supported by the network operator, the practical availability of such payload coverage is often dependent upon the non-fragmentation (i.e., the availability of contiguous time slots) of bandwidth in the SONET/SDH network. The SONET/SDH standards have been updated to include the mechanism for SONET/SDH payload virtual concatenation. This scheme can provide right sized link channelisation for ring and other SONET/SDH network topologies. The ITU-T has developed a standard for SDH High Order and Low Order payload Virtual Concatenation. This global standards development has been aligned with ANSI T1X1 (SONET) and ETSI. Further standards work on the subject of Variable Bandwidth Allocation (VBA) will make the dynamic re-sizing and hitless re- configuration of virtually concatenated paths possible. Jones Expires December 2000 3 Internet Draft POS with VC, HO & LO June 2000 For the convenience of the reader, the equivalent terms are listed below: SONET SDH --------------------------------------------- SPE VC VT (1.5/2/6) Low order VC (VC-11/12/2) STS-SPE Higher Order VC (VC-3/4/4-Nc) STS-1 frame STM-0 frame (rarely used) STS-1-SPE VC-3 STS-1 payload C-3 STS-3c frame STM-1 frame, AU-4 STS-3c-SPE VC-4 STS-3c payload C-4 STS-12c/48c/192c frame STM-4/16/64 frame, AU-4-4c/16c/64c STS-12c/48c/192c-SPE VC-4-4c/16c/64c STS-12c/48c/192c payload C-4-4c/16c/64c This table is an extended version of the equivalent table in RFC 2615 [3]. Additional information on the above terms can be found in Bellcore GR-253-CORE [6], ANSI T1.105 [7], ANSI T1.105.02 [8] and ITU-T G.707 [9]. 2. Rate Comparisons The original tributary bit rates chosen for SONET/SDH were intended for voice services. These rates have a coarse granularity, require duplicate network resources for protection and are not a good match to LAN bandwidths. Currently supported WAN bandwidth links for PPP: ANSI ETSI ----------------------------------------------------- DS1 (1.5Mbit/s) E1 (2Mbit/s) DS3 (45Mbit/s) E3 (34Mbit/s) STS-3c (150Mbit/s) STM-1 (150Mbit/s) STS-12c (620Mbit/s) STM-4 AU-4-4c (620Mbit/s) STS-48c (2.4Gbit/s) STM-16 AU-4-16c (2.4Gbit/s) Note that AU-4-4c and AU-4-16c are not generally available in SDH networks at present. With virtual concatenation the following additional WAN bandwidth links would be available for PPP : SONET VT-1.5-nv (n=3D1-64) 1.6Mbit/s-102Mbit/s STS-1-nv (n=3D1-64) 49Mbit/s-3.1Gbit/s STS-3c-nv (n=3D1-64) 150Mbit/s-10Gbit/s Jones Expires December 2000 4 Internet Draft POS with VC, HO & LO June 2000 SDH VC-12-nv (n=3D1-64) 2.2Mbit/s-139Mbit/s VC-3-nv (n=3D1-64) 49Mbit/s-3.1Gbit/s VC-4-nv (n=3D1-64) 150Mbit/s-10Gbit/s Higher levels of virtual concatenation are possible, but not necessarily useful. At present CONTIGUOUS concatenation caters for 4 or 16 VC-4s. Bit rates for Transparent LAN Services (TLS) are typically 10Mbit/s and 100Mbit/s. Bit rates of 1Gbit/s are also becoming more and more popular. Also other services (e.g. ATM cells stream) may vary from a few Mbit/s to several tens of Mbit/s. However there are no direct mappings for the transport of such bit rates over SONET/SDH. In order to transport the services mentioned above via a SONET/SDH transport network there is no match in the bandwidth granularity. Table 1 and Table 2,respectively depict the SONET/SDH transport structures that are currently available to carry various popular bit rates. Each table contains three columns. The first column shows the bit rates of the service to be transported. The next column contains two values: a) the logical signals that are currently available to provide such transport and, b) in parenthesis, the percent efficiency of the given transport signal without the use of virtual concatenation. Likewise, the final column also contains two values: a) the logical signals that are currently available to provide such transport and, b) in parenthesis, the percent efficiency of the given transport signal with the use of virtual concatenation. Note, that Table 1, contains SONET transport signals with the following effective payload capacity: VT-1.5 SPE =3D 1.600 Mbit/s, STS-1 SPE =3D 49.536 Mbit/s, STS-3c SPE =3D 149.760 Mbit/s, STS-12c = SPE =3D 599.040 Mbit/s and STS-48c SPE =3D 2,396.160 Mbit/s. Table 1. SONET Virtual Concatenation Bit rate Without With ------------------------------------------------------------- 10Mbit/s STS-1 (20%) VT-1.5-7v (89%) 25Mbit/s STS-1 (50%) VT-1.5-16v(98%) 100Mbit/s STS-3c (67%) STS-1-2v (100%) or VT-1.5-63v (99%) 200Mbit/s STS-12c(33%) STS-1-4v (100%) or STS-3c-2v (66%) 1Gbit/s STS-48c(42%) STS-3c-7v (95%) Jones Expires December 2000 5 Internet Draft POS with VC, HO & LO June 2000 Similarly, Table 2, contains SDH transport signals with the following effective payload capacity: VC-11 =3D 1.600 Mbit/s, VC-12 = =3D 2.176 Mbit/s, VC-2 =3D 6.784 Mbit/s, VC-3 =3D 48.960 Mbit/s, VC-4 = =3D 149.760 Mbit/s and VC-4-4c =3D 599.040 Mbit/s. Table 2. SDH Virtual Concatenation Bit rate Without With ------------------------------------------------------------- 10Mbit/s VC-3 (20%) VC-12-5v (92%) 25Mbit/s VC-3 (50%) VC-12-12v (96%) 100Mbit/s VC-4 (67%) VC-3-2v (100%) or VC-12-46v (100%) 200Mbit/s VC-4-4c(33%) VC-3-4v (100%) or VC-4-2v (66%) 1Gbit/s VC-4-16c(42%) VC-4-7v (95%) The only currently supported SONET/SDH SPE/VCs in RFC 2615 [4] are the following: SONET SDH ---------------------------------------- STS-3c-SPE VC-4 STS-12c-SPE VC-4-4c STS-48c-SPE VC-4-16c STS-192c-SPE VC-4-64c Note that VC-4-4c and above are not widely supported in SDH networks at present. 3. Current Technologies Two existing standard technologies for making use of multiple physical paths to build a single logical link are Multi-link PPP (ML-PPP RFC 1990 [10]) and Inverse Multiplexing for ATM (IMA af-phy- 0086.001 [11]). These approaches use frame/cell level load balancing and typically use multiple T1/E1 paths to build a link. Virtual concatenation uses SONET/SDH SPE/VC directly and therefore does not have the inefficiency of mapping into asynchronous (T1/T3) or plesiochronous (E1/E3) payload first. In addition since virtual concatenation is a byte level inverse multiplexing technique, it has the characteristics of right sized bandwidth, improved granularity, cost, low delay, low jitter, re-use of protection bandwidth and high efficiency payload mapping. This makes it a suitable physical layer for a single PPP link. Note that virtual concatenation can also be of benefit for ATM for much the same reasons. SONET/SDH virtual concatenation operates at the physical layer below PPP. The main objective of virtual concatenation is to provide a Jones Expires December 2000 6 Internet Draft POS with VC, HO & LO June 2000 logical mesh of multiple right sized channels over a SONET/SDH network. It is therefore independent of any higher layer schemes for providing equal cost multi-path routing or load balancing. 4. Virtual Concatenation Description This section describes Concatenation of Virtual Containers and in particular describes Virtual Concatenation. Concatenation is a method for the transport, over SONET/SDH networks, of a payload of a bandwidth greater than the capacity of the information structure currently defined in standards. For example to transport a signal of bandwidth equivalent to four VC-4s the frame structure would be VC-4-4c. Concatenation is defined in ITU-T recommendation G.707 [9] as "A procedure whereby a multiplicity of Virtual Containers is associated one with another with the result that their combined capacity can be used as a single container across which bit sequence integrity is maintained". Two types of concatenation are proposed: contiguous and virtual. Contiguous concatenation Contiguous concatenation uses a concatenation indicator in the pointer associated with each concatenated frame to indicate that the SPE/VC with which the pointers are associated are concatenated. For example, four VC-4s contiguously concatenated in an information structure would have a data rate of VC-4-4C. The resulting signal has one valid path overhead (9-byte column) and three 9-byte columns of fixed stuff. The four payloads are byte interleaved in the VC-4- 4c payload area. For contiguously concatenated payload to pass through a network, all intermediate nodes must support contiguous concatenation. Virtual Concatenation Many installed network elements in SONET/SDH networks cannot support contiguous concatenation. The processing in these NEs is limited to processing only individual SPE/VC. To implement contiguous concatenation in such networks would require extensive hardware upgrade of the equipment and would be prohibitively expensive. Virtual Concatenation is one way of overcoming this problem. The main aim of virtual concatenation is to provide the SONET/SDH NEs at both ends of the signal path with the capability of sending/receiving individual SPE/VC that are associated in a concatenated group. In this way the cost of transporting concatenated signal is confined to the up-grade costs at the ends of the path. These cost are likely to be significantly lower than up- grading a whole network to handle contiguously concatenated signals. Jones Expires December 2000 7 Internet Draft POS with VC, HO & LO June 2000 At the sending end it will be necessary to provide each SPE/VC with information about its concatenated group identity and its position/sequence within the group, and to give each its own POH for processing in the intermediate nodes in the network. At the receiving end the equipment must be capable of identifying a SPE/VC as belonging to a particular concatenated group and identifying its position/sequence within that group. Because of the likelihood of different propagation and processing delays for each of the individual SPE/VC, it will be necessary for the receiving end equipment to provide buffers to store the incoming data until the latest SPE/VC arrives, when re-alignment can be performed. One method of providing group identification is to use the J1 byte (Path Trace). If each concatenated group used a different path trace identifier then the receiving equipment will know that a particular VC belongs to that group. The information of what sequence/position a SPE/VC has within the group must be conveyed in the POH. The receiving end will process this information and re-assemble the SPE/VC in the correct order. The difference in the arrival times at the receiver of given SPEs/VCs in a virtually concatenated group is known as the Differential Delay. It will be necessary for the receiving equipment to measure this parameter and to detect if it has gone beyond the range of the buffers, which have been provided to re-align the incoming data. Network Management of the virtually concatenated signal will not require the network equipment to be modified since the NEs are processing essentially standard SPE/VC. 5. Emerging Benefits The main objective of virtual concatenation is to provide multiple right sized channels over a SONET/SDH network. The benefit of virtual concatenation to PPP is the ability to provide channels in a SONET/SDH network that are more appropriate for IP. The advantages of these channels are bandwidth granularity, right sized capacity, efficient mapping into SONET/SDH SPE/VC, traffic scalability and channelized high capacity SONET/SDH interfaces. The characteristics of virtually concatenated links, which provide for bandwidth reduction in the event of a path failure, are a good match for Differentiated Services. The reason for this is that the loss of bandwidth will effect the lower priority traffic first and should allow the higher priority traffic to continue passing over the link. Jones Expires December 2000 8 Internet Draft POS with VC, HO & LO June 2000 Another benefit of virtual concatenation is the ability to add or remove a SPE/VC from the group without taking a PPP link using the group Out Of Service. The change in bandwidth should take place in a few milli-seconds, depending on the physical distance between the two ends of the link. Virtual concatenation could make better use of SONET/SDH path protection bandwidth. Consider a single path protected 45Mbit/s or 34Mbit/s circuit. The SONET/SDH bandwidth needed to support this would involve using two STS-1/VC-3s. When virtual concatenation is applied to this situation, a link of 100Mbit/s can be provided. In the event of a path failure this would be reduced to 50Mbit/s. 6. Standards Status ITU-T (SG13/SG15), ANSI T1X1 and ETSI TM1/WP3 have developed global standards for SONET/SDH High Order and Low Order payload Virtual Concatenation. These changes will appear in the following standards: ITU-T G.803 Architecture of transport networks based on the synchronous digital hierarchy (SDH) ITU-T G.707 Network Node Interface for the Synchronous Digital Hierarchy (SDH) ITU-T G.783 Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks ANSI T1.105 Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats ANSI T1.105.02 Synchronous Optical Network (SONET) - Payload Mappings ETSI EN 300 417-9-1 Transmission and Multiplexing (TM) Generic requirements of transport functionality of equipment Part 9: Synchronous Digital Hierarchy (SDH) concatenated path layer functions. Subpart 1: Requirements Work in ITU-T, ANSI T1X1 and ETSI TM1/WP3 has ensured global standards alignment. The completion of a standard for SONET/SDH SPE/VC virtual concatenation means it has become appropriate to consider the use of this standard for PPP. This could take the form of a backward compatible update to RFC 2615 [3]. Jones Expires December 2000 9 Internet Draft POS with VC, HO & LO June 2000 7. Security Considerations This document is for information only. Any protocol related documents that arise from it would contain security consideration. 8. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 1661, Daydreamer, July 1994. [2] Simpson, W., Editor, "PPP in HDLC-like Framing, "RFC 1662, Daydreamer, July 1994. [3] Malis, A. & Simpson, W., "PPP over SONET/SDH, "RFC 2615, June 1999. [4] K. Thompson, G. Miller, and R. Wilder, "Wide Area Internet Traffic Patterns and Characteristics" IEEE Network, Nov 1997. http://www.vbns.net/presentations/papers/MCItraffic.ps [5] K Claffy, Greg Miller, and Kevin Thompson, "The nature of the beast: Recent traffic measurements from an Internet backbone", INET'98 Conference, April 1998. http://www.caida.org/Papers/Inet98/index.html [6] Bellcore Publication GR-253-Core "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria" January 1999 [7] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats" ANSI T1.105-1995 [8] American National Standards Institute, "Synchronous Optical Network (SONET) - Payload Mappings" ANSI T1.105.02-1998 [9] ITU-T Recommendation G.707 "Network Node Interface for the Synchronous Digital Hierarchy" 1996 [10] Sklower, K. et al., "The PPP Multilink Protocol (MP)" RFC 1990, August 1996 [11] Inverse Multiplexing for ATM (IMA) Specification version 1.1 af-phy-0086.001, March 1999 Jones Expires December 2000 10 Internet Draft POS with VC, HO & LO June 2000 9. Acknowledgments Huub van Helvoort, Maarten Vissers (Lucent), Paul Langner (Lucent Microelectronics), Trevor Wilson (Nortel), Mark Carson (Nortel) and James McKee (Nortel) for their contribution to the development of virtual concatenation of SONET/SDH payloads. 10. Author's Addresses Nevin Jones Lucent Technologies Microelectronics Group 555 Union Boulevard Allentwon, PA 18103 USA Email: nrjones@lucent.com Chris Murton Nortel Networks Harlow Laboratories London Road, Harlow, Essex, CM17 9NA UK Email: murton@nortelnetworks.com 11. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Jones Expires December 2000 11 ------_=_NextPart_000_01BFE51D.2F49C800-- From owner-ietf-ppp-outgoing@merit.edu Wed Jul 5 19:28:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18604 for ; Wed, 5 Jul 2000 19:28:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE2BF5DDEC; Wed, 5 Jul 2000 19:27:50 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DD7C95DDEB; Wed, 5 Jul 2000 19:27:50 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 2F8315DDEA for ; Wed, 5 Jul 2000 19:27:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA22033 for ; Wed, 5 Jul 2000 16:27:49 -0700 (PDT) Date: Wed, 5 Jul 2000 16:27:48 -0700 (PDT) From: Dan Wing To: ietf-ppp@merit.edu Subject: Re: PPPmux and MP In-Reply-To: <200007021852.MAA29907@calcite.rhyolite.com> Message-ID: <0007051623420.1844-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Sun, 2 Jul 2000 12:52 -0600, Vernon Schryver wrote: > > From: Carsten Bormann > > > > Both of the proposals strain to remove a few bits > > > of PPP overhead, but ignore their costs. Those costs include CPU cycles, > > > implementation complexity including inevitable interoperability problems > > > and bugs, complications for diagnostic tools such as PPP frame monitors > > > and decoders, and the bandwidth spent negotiating the options (successfully > > > or not). > > > > True. Like header compression. > > Yes and no; Like some but unllike some other kinds of header compression. > Header compression over very low speed links (less than 32 Kbit/sec) is > very valuable. However, even VJ header compression is uninteresting to > the people who would pay for it over links fast enough to paint Mpixel > displays or merely fetch any of the bazillions of web pages on the WWW. > If even VJ header compression were valued today, it would be possible to > find an ISP that supports it. That it is practically impossible to by VJ > header compressed IP bandwidth says all that needs to be said about any > new PPP header compression scheme that removes far fewer than the 37 bytes > per frame of VJ header compression. Quite true for reasonably-sized IP payload sizes. But header compression remains useful when the payloads are 10 or 20 bytes such as with voice samples. -Dan Wing From owner-ietf-ppp-outgoing@merit.edu Wed Jul 5 19:57:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18810 for ; Wed, 5 Jul 2000 19:57:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B01935DE1F; Wed, 5 Jul 2000 19:55:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6D34D5DE56; Wed, 5 Jul 2000 19:55:32 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id D57445DE1F for ; Wed, 5 Jul 2000 19:55:24 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0.Beta3/calcite) id e65NtOX18874 for ietf-ppp@merit.edu env-from ; Wed, 5 Jul 2000 17:55:24 -0600 (MDT) Date: Wed, 5 Jul 2000 17:55:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200007052355.e65NtOX18874@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPPmux and MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Dan Wing > ... > Quite true for reasonably-sized IP payload sizes. > > But header compression remains useful when the payloads are 10 or 20 bytes > such as with voice samples. That assumes facts not in evidence. If (1) the link (or total path for some compression schemes) is carrying only 10-20 byte TCP/IP or UDP/IP payloads, (2) if nothing can be done to make those payloads larger and less frequent, and (3) if the link (or total path) is running at a significant fraction of its available capacity, then header compression sounds useful. However, failing to demonstrate all of those facts simultaneously in at least one plausible scenario invalidates claims about the utility of PPPMux and the new compression schemes. As it stands, PPPMux and the compression schemes somewhat less so are merely standarizing the optimum performance of flying pigs. If you assume pigs will be flying, they're good ideas. Good engineering ought to demand a little evidence that pigs can get airborne before writing standards--assuming that the purpose of the RFC's is to standardize technical stuff instead of only satisfying a publish-or-perish need. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jul 5 22:48:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23500 for ; Wed, 5 Jul 2000 22:48:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0D2B5DE25; Wed, 5 Jul 2000 22:46:39 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CDFEF5DE1E; Wed, 5 Jul 2000 22:46:39 -0400 (EDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 1B6835DE21 for ; Wed, 5 Jul 2000 22:46:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA12631 for ; Wed, 5 Jul 2000 19:46:38 -0700 (PDT) Date: Wed, 5 Jul 2000 19:46:37 -0700 (PDT) From: Dan Wing To: ietf-ppp@merit.edu Subject: Re: PPPmux and MP In-Reply-To: <200007052355.e65NtOX18874@calcite.rhyolite.com> Message-ID: <0007051914390.1844-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Wed, 5 Jul 2000 17:55 -0600, Vernon Schryver wrote: > > From: Dan Wing > > > ... > > Quite true for reasonably-sized IP payload sizes. > > > > But header compression remains useful when the payloads are 10 or 20 bytes > > such as with voice samples. > > That assumes facts not in evidence. > > If (1) the link (or total path for some compression schemes) is carrying > only 10-20 byte TCP/IP or UDP/IP payloads, A voice-only network would be designed for such short payloads. Some common compression algorithms provide 10 (G.729), 15 (G.729e), and 40 (G.726-32K) byte payloads every 10ms. There are tradeoffs with each compression type (generally the typical CPU-versus-quality). > (2) if nothing can be done to make those payloads larger and less > frequent, A larger payload can be had with (a) less efficient compression algorithms or (b) higher (longer) packetization interval. Of those, (a) isn't desirable because one of the benefits of voice over packet networks is its ability to save bandwidth. If packet voice continues to consume 64Kb of bandwidth there isn't a large win over traditional PSTN (which uses 64Kb). Solution (b) causes a degradation in voice quality. Additionally, losing a larger sound sample (due to a packet drop, for example) is more noticable than losing a smaller sound sample. > and (3) if the link (or total path) is running at a significant > fraction of its available capacity, then header compression sounds > useful. To save costs, customers prefer running links as close to capacity as possible. And some access technologies such as xDSL or cable become bandwidth constrained with multiple derived voice lines, so those links are running at capacity. CRTP can help here, but CRTP doesn't solve network core bandwidth utilization which, for a voice-only network, is quite a lot of overhead for tiny payloads. > However, failing to demonstrate all of those facts simultaneously in > at least one plausible scenario invalidates claims about the utility > of PPPMux and the new compression schemes. > > As it stands, PPPMux and the compression schemes somewhat less so are > merely standarizing the optimum performance of flying pigs. If you > assume pigs will be flying, they're good ideas. Good engineering ought > to demand a little evidence that pigs can get airborne before writing > standards--assuming that the purpose of the RFC's is to standardize > technical stuff instead of only satisfying a publish-or-perish need. As far as I'm aware, there is no publish-or-perish requirement at my employer. As to flying pigs, they should fly high and land softly. -Dan Wing From owner-ietf-ppp-outgoing@merit.edu Thu Jul 6 06:48:22 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11249 for ; Thu, 6 Jul 2000 06:48:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B0C85DF13; Thu, 6 Jul 2000 06:47:12 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3341B5DF15; Thu, 6 Jul 2000 06:47:12 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 5E24A5DF13 for ; Thu, 6 Jul 2000 06:47:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11207; Thu, 6 Jul 2000 06:47:09 -0400 (EDT) Message-Id: <200007061047.GAA11207@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-posvcholo-02.txt Date: Thu, 06 Jul 2000 06:47:08 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads Author(s) : N. Jones, C. Murton Filename : draft-ietf-pppext-posvcholo-02.txt Pages : 11 Date : 07-Jul-00 The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This document proposes an extension to the mapping of PPP into SONET/SDH defined in RFC 2615 PPP over SONET/SDH (POS) [3], to include use of SONET/SDH SPE/VC virtual concatenation and use of both high order and low order payloads. The objective of this document is to provide an update of the status of this proposal in the telecommunications standards definition process. The current situation is that work in ANSI, ETSI & ITU-T has resulted in a global standard for virtual concatenation. This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-posvcholo-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-posvcholo-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-posvcholo-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706064739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-posvcholo-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-posvcholo-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706064739.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Jul 6 07:36:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12533 for ; Thu, 6 Jul 2000 07:36:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F65A5DF18; Thu, 6 Jul 2000 07:36:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8ED395DF17; Thu, 6 Jul 2000 07:36:10 -0400 (EDT) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by segue.merit.edu (Postfix) with SMTP id 539AC5DF15 for ; Thu, 6 Jul 2000 07:36:08 -0400 (EDT) Received: from ppp-203-197-9-194.bom.vsnl.net.in (HELO muralidharan) (203.197.9.194) by smtp.mail.yahoo.com with SMTP; 6 Jul 2000 10:54:21 -0000 X-Apparently-From: Message-ID: <018601bfe738$c39267c0$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: "Jones, Nevin R (Nevin)" , , References: <2723E6389F55D311BDC200508B129547017E1F51@pai820exch003u.micro.lucent.com> Subject: Comments on draft on Extending PPP with virtual concatenation Date: Thu, 6 Jul 2000 16:25:53 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thanks for the draft version 2. This doc clearly indicates that ANSI, ITU-T etc have already established virtual concatenation as a global standard. Clarifications requested/comments are as follows: (1) Are the references in section 8 the latest? For e.g.. Does ANSI T1.105.02-1998 contain the mappings for virtual concatenation? (2) Section 3 on Current Technologies just states that ML-PPP is used for multiple physical paths to build a logical link. I understand that ML-PPP is also used to bundle VT1.5s in SONET STS-1 to achieve efficient granularity for 10Mbps channels. E.g.. is Cisco ONS 15303. If this is the case, would n't it be appropriate to mention this as well as provide comparison of ML-PPP bundling of VT1.5s in SONET frames vis-a-vis virtual concatenation? (3) Packet over Sonet RFC 2615) standard states that OC3c is a standard output. Does this mean that one cannot implement virtual concatenation in optical outputs of OC3? Would appreciate response. muralidharan > > All: > > > The preceding attachment was sent in error please disregard. I have > attached the correct file for upload. Any comments are > > welcome. > > > > Regards, > > > > -Nevin Jones > > > <> __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Thu Jul 6 13:20:35 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21462 for ; Thu, 6 Jul 2000 13:20:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 02A2E5DDE4; Thu, 6 Jul 2000 13:19:06 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E22B15DDB3; Thu, 6 Jul 2000 13:19:05 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 1F6855DDE3 for ; Thu, 6 Jul 2000 13:19:04 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA21491 for ; Thu, 6 Jul 2000 13:18:59 -0400 (EDT) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA21467 for ; Thu, 6 Jul 2000 13:18:59 -0400 (EDT) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 13:18:58 -0400 Message-ID: <2723E6389F55D311BDC200508B129547017E1F59@pai820exch003u.micro.lucent.com> From: "Jones, Nevin R (Nevin)" To: "R. Muralidharan" , murton@nortelnetworks.com, ietf-ppp@merit.edu, "'Steve Gorshe'" Cc: "Jones, Nevin R (Nevin)" Subject: RE: Comments on draft on Extending PPP with virtual concatenation Date: Thu, 6 Jul 2000 13:18:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Steve: Thanks for the clarification. Please note that we currently have a contribution for the 07/10/2000 T1X1 meeting proposing support for SONET virtual concatenation of STS-3c. Regards, -Nevin > ---------- > From: Steve Gorshe[SMTP:steveg@eluminant.com] > Sent: Thursday, July 06, 2000 1:00 PM > To: R. Muralidharan; Jones, Nevin R (Nevin); murton@nortelnetworks.com; > ietf-ppp@merit.edu > Subject: Re: Comments on draft on Extending PPP with virtual > concatenation > > As editor for ANSI T1.105 and T1.105.02, I can clarify a few points here: > > > At 3:55 AM -0700 7/6/2000, R. Muralidharan wrote: > >Thanks for the draft version 2. This doc clearly indicates that ANSI, > ITU-T > >etc have already established virtual concatenation as a global standard. > > > >Clarifications requested/comments are as follows: > > > >(1) Are the references in section 8 the latest? For e.g.. Does ANSI > >T1.105.02-1998 contain the mappings for virtual concatenation? > > ANSI is preparing to forward the virtual concatenation text for T1.105 and > T1.105.02 out of next weeks meeting for the formal ballot process. > > >(2) Section 3 on Current Technologies just states that ML-PPP is used for > >multiple physical paths to build a logical link. I understand that ML-PPP > is > >also used to bundle VT1.5s in SONET STS-1 to achieve efficient > granularity > >for 10Mbps channels. E.g.. is Cisco ONS 15303. If this is the case, > would > >n't it be appropriate to mention this as well as provide comparison of > >ML-PPP bundling of VT1.5s in SONET frames vis-a-vis virtual > concatenation? > >(3) Packet over Sonet RFC 2615) standard states that OC3c is a standard > >output. Does this mean that one cannot implement virtual concatenation in > >optical outputs of OC3? > > STS-3c is an explicitly concatenated payload for the OC-3. (STS refers to > the signal format and OC-N refers to the optical transport of an STS-N > signal.) Due to the explicit concatenation, there is no virtual > concatenation within an STS-3c. If the OC-3 is formatted as three STS-1s > or as the SDH STM-1, then virtual concatenation can occur at the STS and > VT/VC levels. > > Steve Gorshe > Chief Editor - ANSI T1X1 > > > > >Would appreciate response. > >muralidharan > > > >> > All: > >> > > >> The preceding attachment was sent in error please disregard. I have > >> attached the correct file for upload. Any comments are > >> > welcome. > >> > > >> > Regards, > >> > > >> > -Nevin Jones > >> > > >> <> > > > > > > > >__________________________________________________ > >Do You Yahoo!? > >Talk to your friends online with Yahoo! Messenger. > >http://im.yahoo.com > > > From owner-ietf-ppp-outgoing@merit.edu Mon Jul 10 13:24:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18392 for ; Mon, 10 Jul 2000 13:24:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA8305DE7E; Mon, 10 Jul 2000 13:23:48 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A64465DE67; Mon, 10 Jul 2000 13:23:48 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by segue.merit.edu (Postfix) with ESMTP id 7D3995DDD2 for ; Mon, 10 Jul 2000 13:23:47 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA95712 for ; Mon, 10 Jul 2000 13:21:28 -0400 From: jmartz@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA71304 for ; Mon, 10 Jul 2000 13:23:15 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256918.005F806F ; Mon, 10 Jul 2000 13:23:07 -0400 X-Lotus-FromDomain: IBMUS To: ietf-ppp@merit.edu Message-ID: <85256918.005F7D7F.00@D51MTA04.pok.ibm.com> Date: Mon, 10 Jul 2000 13:22:09 -0400 Subject: LCP option 0 with length 4?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Does anyone know why a peer would send me the following LCP option: 0x000400000 Option Code 0 Option Length 4 Option Value 0x0000 I looked at RFC 2153 and it states that the minimum length for the vendor specific option is supposed to 6 bytes. My implementation doesn't support option 0 so it just send a config reject for this without really noticing the length. But I'm curious so I figured I'd post this note to see if anyone else on the list had an insight. -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Mon Jul 10 13:38:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19251 for ; Mon, 10 Jul 2000 13:38:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A332B5DE7F; Mon, 10 Jul 2000 13:37:48 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8EA315DDD2; Mon, 10 Jul 2000 13:37:48 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E0F0A5DE67 for ; Mon, 10 Jul 2000 13:37:45 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10162; Mon, 10 Jul 2000 10:37:18 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA17719; Mon, 10 Jul 2000 13:27:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id NAA02146; Mon, 10 Jul 2000 13:27:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14698.1914.189824.525582@gargle.gargle.HOWL> Date: Mon, 10 Jul 2000 13:27:21 -0400 (EDT) From: James Carlson To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu Subject: Re: LCP option 0 with length 4?? In-Reply-To: jmartz@us.ibm.com's message of 10 July 2000 13:22:09 References: <85256918.005F7D7F.00@D51MTA04.pok.ibm.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jmartz@us.ibm.com writes: > Does anyone know why a peer would send me the following LCP option: > 0x000400000 > Option Code 0 > Option Length 4 > Option Value 0x0000 Yes. The peer is an old Ascend box, and it's trying to negotiate MP+. > I looked at RFC 2153 and it states that the minimum length for the vendor > specific option is supposed to 6 bytes. My implementation doesn't support > option 0 so it just send a config reject for this without really noticing > the length. But I'm curious so I figured I'd post this note to see if > anyone else on the list had an insight. That's the right way to handle it. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Jul 12 10:32:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24670 for ; Wed, 12 Jul 2000 10:32:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B08C15DDD3; Wed, 12 Jul 2000 10:31:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9FA255DD9A; Wed, 12 Jul 2000 10:31:55 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id BA6DE5DDC4 for ; Wed, 12 Jul 2000 10:31:53 -0400 (EDT) Received: from karl.extant.net (ns2.extant.net [216.28.121.133]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MXTVADLH; Wed, 12 Jul 2000 08:31:52 -0600 Message-Id: <4.3.2.7.2.20000712103014.04b981b0@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 10:31:50 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: No PPPEXT meeting in Pittsburgh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Due to the PPPEXT working group's de-emphasis on new protocols, we will not be meeting in Pittsburgh. However, I hope to see many of you in the hallways! Karl Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Jul 13 14:53:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05324 for ; Thu, 13 Jul 2000 14:53:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 821915DDE2; Thu, 13 Jul 2000 14:52:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3A4C25DDFE; Thu, 13 Jul 2000 14:52:58 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B59DF5DDE2 for ; Thu, 13 Jul 2000 14:52:50 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12575; Thu, 13 Jul 2000 11:52:46 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04530; Thu, 13 Jul 2000 14:52:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id OAA04539; Thu, 13 Jul 2000 14:52:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14702.4095.166093.268329@gargle.gargle.HOWL> Date: Thu, 13 Jul 2000 14:52:47 -0400 (EDT) From: James Carlson To: "Stacy Nichols (Ottawa)" Cc: Craig Fox , Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP In-Reply-To: Stacy Nichols (Ottawa)'s message of 13 July 2000 11:41:24 References: <336ECDAFDF7DD311B9E30090277AEE410210E124@nt-exchange-bby.pmc-sierra.bc.ca> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stacy Nichols (Ottawa) writes: > 1) PPP-Mux and ML-PPP should be orthogonal. That is > We should be able to perform PPP-Mux on a single > link of a Multi-link bundle. This is consistent with > RFC-1990 which permits single-link and multi-link traffic > on the same link. OK, then what do you do if you want PPPMux at the bundle level? I'd be happy with the current proposal (negotiate PPPMux at LCP) if we do NOT allow PPPMux to appear within a reassembled multilink frame. Otherwise, I'd rather see a new NCP. (I think a new NCP is cleaner in any case, but the LCP option is already there ...) I'd also be happy if we just said that MP and PPPMux may not be used at the same time on the same link. Period. You pick one or the other. > 2) LCP negotiation should be used for PPP-Mux (out on a limb here). > I think it gets trickier when we merge the two capabilities. > Do we need to negotiate link capabilities (PPP-Mux, ML-PPP) > and then negotiate combinations in follow on LCP/NCP messages. Only if we don't resolve the existing ambiguity in an explicit way. (There should also be definitions for where PPPMux appears with respect to CCP and ECP. ECP is probably a bit more troublesome.) Again, to keep the current model, PPPMux should appear as the outermost protocol number only. Not inside a decrypted packet, not inside a decompressed packet, and not inside a reassembled MP packet. > P.S. how do I subscribe to the mailing lists. Send mail to: ietf-ppp-request@merit.edu See http://www.ietf.org/html.charters/pppext-charter.html for more information. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jul 13 15:06:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05806 for ; Thu, 13 Jul 2000 15:06:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B6055DE54; Thu, 13 Jul 2000 15:06:12 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 66B8D5DEE0; Thu, 13 Jul 2000 15:06:12 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by segue.merit.edu (Postfix) with ESMTP id CAF1B5DE54 for ; Thu, 13 Jul 2000 15:06:09 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA01404; Thu, 13 Jul 2000 12:05:58 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <3Q6KZ022>; Thu, 13 Jul 2000 12:07:40 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE410210E12A@nt-exchange-bby.pmc-sierra.bc.ca> From: "Stacy Nichols (Ottawa)" To: "'James Carlson'" , "Stacy Nichols (Ottawa)" Cc: Craig Fox , Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP Date: Thu, 13 Jul 2000 12:07:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I think we are in agreement. I would suggest (possibly) a two level negotiation. LCP for the link and then NCP for the bundle. Also from a hardware perspective, RFC-1990 allows any PID to be encapsulated. I am not sure why PPP-MUX would be any different. Stace -----Original Message----- From: James Carlson [mailto:james.d.carlson@east.sun.com] Sent: Thursday, July 13, 2000 2:53 PM To: Stacy Nichols (Ottawa) Cc: Craig Fox; Ali Irfan-FIA225; 'ietf-ppp@merit.edu'; Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP Stacy Nichols (Ottawa) writes: > 1) PPP-Mux and ML-PPP should be orthogonal. That is > We should be able to perform PPP-Mux on a single > link of a Multi-link bundle. This is consistent with > RFC-1990 which permits single-link and multi-link traffic > on the same link. OK, then what do you do if you want PPPMux at the bundle level? I'd be happy with the current proposal (negotiate PPPMux at LCP) if we do NOT allow PPPMux to appear within a reassembled multilink frame. Otherwise, I'd rather see a new NCP. (I think a new NCP is cleaner in any case, but the LCP option is already there ...) I'd also be happy if we just said that MP and PPPMux may not be used at the same time on the same link. Period. You pick one or the other. > 2) LCP negotiation should be used for PPP-Mux (out on a limb here). > I think it gets trickier when we merge the two capabilities. > Do we need to negotiate link capabilities (PPP-Mux, ML-PPP) > and then negotiate combinations in follow on LCP/NCP messages. Only if we don't resolve the existing ambiguity in an explicit way. (There should also be definitions for where PPPMux appears with respect to CCP and ECP. ECP is probably a bit more troublesome.) Again, to keep the current model, PPPMux should appear as the outermost protocol number only. Not inside a decrypted packet, not inside a decompressed packet, and not inside a reassembled MP packet. > P.S. how do I subscribe to the mailing lists. Send mail to: ietf-ppp-request@merit.edu See http://www.ietf.org/html.charters/pppext-charter.html for more information. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jul 13 15:20:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06263 for ; Thu, 13 Jul 2000 15:20:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C02C75DDC0; Thu, 13 Jul 2000 15:19:36 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A468E5DE07; Thu, 13 Jul 2000 15:19:36 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by segue.merit.edu (Postfix) with ESMTP id 03AD85DDC0 for ; Thu, 13 Jul 2000 15:19:21 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA03989; Thu, 13 Jul 2000 12:17:39 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <3Q6KZ030>; Thu, 13 Jul 2000 12:19:22 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE410210E12B@nt-exchange-bby.pmc-sierra.bc.ca> From: "Stacy Nichols (Ottawa)" To: "Stacy Nichols (Ottawa)" , "'James Carlson'" Cc: "'Craig Fox'" , "'Ali Irfan-FIA225'" , "'ietf-ppp@merit.edu'" , "'Pazhyannur Rajesh-QA6283'" Subject: RE: PPP-Mux and ML-PPP-Re-send Date: Thu, 13 Jul 2000 12:19:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Re-Send as some of you may not have got the first one (I got 3 NACKs). Stace -----Original Message----- From: Stacy Nichols (Ottawa) Sent: Thursday, July 13, 2000 3:08 PM To: 'James Carlson'; Stacy Nichols (Ottawa) Cc: Craig Fox; Ali Irfan-FIA225; 'ietf-ppp@merit.edu'; Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP I think we are in agreement. I would suggest (possibly) a two level negotiation. LCP for the link and then NCP for the bundle. Also from a hardware perspective, RFC-1990 allows any PID to be encapsulated. I am not sure why PPP-MUX would be any different. Stace -----Original Message----- From: James Carlson [mailto:james.d.carlson@east.sun.com] Sent: Thursday, July 13, 2000 2:53 PM To: Stacy Nichols (Ottawa) Cc: Craig Fox; Ali Irfan-FIA225; 'ietf-ppp@merit.edu'; Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP Stacy Nichols (Ottawa) writes: > 1) PPP-Mux and ML-PPP should be orthogonal. That is > We should be able to perform PPP-Mux on a single > link of a Multi-link bundle. This is consistent with > RFC-1990 which permits single-link and multi-link traffic > on the same link. OK, then what do you do if you want PPPMux at the bundle level? I'd be happy with the current proposal (negotiate PPPMux at LCP) if we do NOT allow PPPMux to appear within a reassembled multilink frame. Otherwise, I'd rather see a new NCP. (I think a new NCP is cleaner in any case, but the LCP option is already there ...) I'd also be happy if we just said that MP and PPPMux may not be used at the same time on the same link. Period. You pick one or the other. > 2) LCP negotiation should be used for PPP-Mux (out on a limb here). > I think it gets trickier when we merge the two capabilities. > Do we need to negotiate link capabilities (PPP-Mux, ML-PPP) > and then negotiate combinations in follow on LCP/NCP messages. Only if we don't resolve the existing ambiguity in an explicit way. (There should also be definitions for where PPPMux appears with respect to CCP and ECP. ECP is probably a bit more troublesome.) Again, to keep the current model, PPPMux should appear as the outermost protocol number only. Not inside a decrypted packet, not inside a decompressed packet, and not inside a reassembled MP packet. > P.S. how do I subscribe to the mailing lists. Send mail to: ietf-ppp-request@merit.edu See http://www.ietf.org/html.charters/pppext-charter.html for more information. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jul 13 15:35:28 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06890 for ; Thu, 13 Jul 2000 15:35:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A1A65DDD0; Thu, 13 Jul 2000 15:35:04 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2FFA05DDBD; Thu, 13 Jul 2000 15:35:04 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 702405DDB6 for ; Thu, 13 Jul 2000 15:35:02 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14273; Thu, 13 Jul 2000 13:34:54 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA04494; Thu, 13 Jul 2000 15:34:52 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id PAA04665; Thu, 13 Jul 2000 15:34:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14702.6622.219796.422586@gargle.gargle.HOWL> Date: Thu, 13 Jul 2000 15:34:54 -0400 (EDT) From: James Carlson To: "Stacy Nichols (Ottawa)" Cc: Craig Fox , Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP In-Reply-To: Stacy Nichols (Ottawa)'s message of 13 July 2000 12:07:31 References: <336ECDAFDF7DD311B9E30090277AEE410210E12A@nt-exchange-bby.pmc-sierra.bc.ca> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stacy Nichols (Ottawa) writes: > I think we are in agreement. I think so. > I would suggest (possibly) a two level negotiation. > LCP for the link and then NCP for the bundle. Only if it's useful at all at the bundle level. I think the answer to that might be 'no.' At least I've heard no compelling argument for just prohibiting PPPMux outright at the bundle level. > Also from a hardware perspective, RFC-1990 allows any > PID to be encapsulated. I am not sure why PPP-MUX would be > any different. It may appear so, but it doesn't. For instance, CCP and ECP both define per-link variants. You don't run those over the bundle. Also, LCP negotiation (such as LCP Configure-Request) and CHAP rechallenge can't meaningfully be done at the bundle level. On input, it's even worse. Certain LCP Protocol-Reject messages, such as those for NCPs, must be forwarded to the bundle level (regardless of whether they're encapsulated or not), while others, such as those for per-link CCP, must be handled at the per-link level. There are warts all over this. It's just a matter of documenting them all correctly. ;-} -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Jul 14 06:57:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10986 for ; Fri, 14 Jul 2000 06:57:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A1B95DDAD; Fri, 14 Jul 2000 06:56:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 60A0A5DDB8; Fri, 14 Jul 2000 06:56:44 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 05F8B5DDAD for ; Fri, 14 Jul 2000 06:56:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10785; Fri, 14 Jul 2000 06:56:41 -0400 (EDT) Message-Id: <200007141056.GAA10785@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-lbd-02.txt Date: Fri, 14 Jul 2000 06:56:40 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Link Balancing Detection (LBD) Author(s) : J. Carlson Filename : draft-ietf-pppext-lbd-02.txt Pages : 5 Date : 13-Jul-00 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows the detection of optional link handling procedures, as well as a Multilink procedure (MP) [2], which allows operation over multiple parallel links. This document defines an extension to MP called Link Balancing Detection (LBD) and the LCP options that control this extension. This extension allows high-speed implementations to use the single-NCP negotiation model of MP without requiring prohibitive datagram buffering and reordering costs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-lbd-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-lbd-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lbd-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lbd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lbd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145840.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Fri Jul 14 11:20:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27985 for ; Fri, 14 Jul 2000 11:20:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35F985DD99; Fri, 14 Jul 2000 11:19:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2134D5DD92; Fri, 14 Jul 2000 11:19:45 -0400 (EDT) Received: from motgate3.mot.com (unknown [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id C64545DD8C for ; Fri, 14 Jul 2000 11:19:42 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA24595 for ; Fri, 14 Jul 2000 08:18:27 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA14262 for ; Fri, 14 Jul 2000 08:19:39 -0700 (MST)] Received: from dhruva.miel.mot.com (dhruva.miel.mot.com [217.1.125.31]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id UAA10727; Fri, 14 Jul 2000 20:54:24 +0530 (IST) Received: from miel.mot.com (dhruva.miel.mot.com [217.1.125.31]) by dhruva.miel.mot.com (8.9.1/8.9.1) with ESMTP id UAA23712; Fri, 14 Jul 2000 20:47:01 +0530 (IST) Message-ID: <396F2EED.90379396@miel.mot.com> Date: Fri, 14 Jul 2000 20:47:01 +0530 From: Muralidhar Rayapeddi X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: karl@Ascend.com, wsimpson@GreenDragon.com Cc: ietf-ppp@merit.edu Subject: Question on CHAP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit hi, I have a question on chap authentication to implement in our properitary stack. There is an authenticator and I act as the peer. During LCP negotiations the authenticator asks for chap which I ack modestly. (I do not request for any auth during my lcp request) Once the lcp negotiations are done, I (peer) expect a challenge to be received. If I never receive a challenge due to some reason, should I bring down the link after my restart counter waiting for chap expires or can I start ipcp immediately though the initial packets might get dropped because of authentication not being complete. Please clarify. Best Regards, Murali. From owner-ietf-ppp-outgoing@merit.edu Fri Jul 14 11:34:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03235 for ; Fri, 14 Jul 2000 11:34:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 270945DDC2; Fri, 14 Jul 2000 11:33:48 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 12C7D5DD90; Fri, 14 Jul 2000 11:33:48 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id DC83F5DDC2 for ; Fri, 14 Jul 2000 11:33:45 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09463; Fri, 14 Jul 2000 09:33:35 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA28362; Fri, 14 Jul 2000 11:32:12 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id LAA05839; Fri, 14 Jul 2000 11:32:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14703.12925.950222.625119@gargle.gargle.HOWL> Date: Fri, 14 Jul 2000 11:32:13 -0400 (EDT) From: James Carlson To: Muralidhar Rayapeddi Cc: ietf-ppp@merit.edu Subject: Re: Question on CHAP. In-Reply-To: Muralidhar Rayapeddi's message of 14 July 2000 20:47:01 References: <396F2EED.90379396@miel.mot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Muralidhar Rayapeddi writes: > Once the lcp negotiations are done, I (peer) expect a challenge to > be received. If I never receive a challenge due to some reason, should I > bring down the link after my restart counter waiting for chap expires or > can I start ipcp immediately though the initial packets might get > dropped > because of authentication not being complete. Please clarify. If the peer asked for CHAP but refuses to send a CHAP Challenge, you're free to do anything you like. Something is broken. The likely cause of this, assuming an async link, is that the ACCM negotiated doesn't actually work (you can test this by putting control characters into LCP Echo-Request messages). I would wait a fair amount of time (a few times the restart timeout) and then kill off LCP with a helpful error message. If the peer just launches into IPCP, well, you may as well do that, too. He must not have wanted to confirm your identity as much as he seemed to at first. This seems unlikely, though. (Sending IPCP at this point is harmless. If the peer really does want CHAP but is delaying the Challenge message, he'll silently ignore the IPCP messages. It'll make your implementation look bad on an analyzer, but it won't hurt the link.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Jul 17 16:33:07 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24840 for ; Mon, 17 Jul 2000 16:33:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E3D85DE3D; Mon, 17 Jul 2000 16:30:49 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2CD1D5DE68; Mon, 17 Jul 2000 16:30:49 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by segue.merit.edu (Postfix) with ESMTP id 16C255DE3D for ; Mon, 17 Jul 2000 16:30:47 -0400 (EDT) Received: from anfreema-pc (dhcp-l21-163.cisco.com [171.68.210.163]) by mailman.cisco.com (8.9.3/8.9.1) with SMTP id NAA28619; Mon, 17 Jul 2000 13:30:12 -0700 (PDT) Message-Id: <200007172030.NAA28619@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 17 Jul 2000 13:27:54 -0700 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: Application available for Sept 2000 VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_7250544==_.ALT" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --=====================_7250544==_.ALT Content-Type: text/plain; charset="us-ascii" The application for the September 2000 VPN Interoperability Workshop is now available at: http://www.calbug.org:8080/vpnworkshop/ The deadline for the VPN workshop application and hotel reservations is August 15, 2000. The VPN Interoperability Workshop will be held September 18-22, 2000, at the Paradise Point Resort in San Diego, California. The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The protocols being tested at this workshop are: IPsec IKE IPComp L2TP over Transport-Mode IPsec PPTP PPPoE PPPoATM L2TPoATM Hotel reservations may be made by calling Paradise Point Resort at 800-344-2626. Please register under the VPN Workshop room block for the discounted rate of $159 per night (plus tax). If you cannot access the web site above, please send an email to me and I will forward a text version of the application. Thanks, Anita Freeman --=====================_7250544==_.ALT Content-Type: text/html; charset="us-ascii" The application for the September 2000 VPN Interoperability Workshop is now
available at:

http://www.calbug.org:8080/vpnworkshop/

The deadline for the VPN workshop application and hotel reservations is
August 15, 2000.

The VPN Interoperability Workshop will be held September 18-22, 2000, at the
Paradise Point Resort in San Diego, California.

The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company.

The protocols being tested at this workshop are:

IPsec
IKE
IPComp
L2TP over Transport-Mode IPsec
PPTP
PPPoE
PPPoATM
L2TPoATM

Hotel reservations may be made by calling Paradise Point Resort at
800-344-2626.  Please register under the VPN Workshop room block for
the discounted rate of $159 per night (plus tax).

If you cannot access the web site above, please send an email to me and I will forward a text version of the application.

Thanks, Anita Freeman
--=====================_7250544==_.ALT-- From owner-ietf-ppp-outgoing@merit.edu Tue Jul 18 13:43:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18397 for ; Tue, 18 Jul 2000 13:43:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B72D75DE38; Tue, 18 Jul 2000 13:42:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 95FE15DE48; Tue, 18 Jul 2000 13:42:55 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 06E775DE38 for ; Tue, 18 Jul 2000 13:42:54 -0400 (EDT) Received: from karl.extant.net (ns2.extant.net [216.28.121.133]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MXTVALM4; Tue, 18 Jul 2000 11:42:47 -0600 Message-Id: <4.3.2.7.2.20000718134014.04edfba0@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 13:42:43 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: MPPE Key Derivation to Informational Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that MPPE Key Derivation, draft-ietf-pppext-mppe-keys-02.txt, be advanced to Informational. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Tue Jul 18 13:47:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19703 for ; Tue, 18 Jul 2000 13:47:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41A185DDBF; Tue, 18 Jul 2000 13:45:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 23E785DDC3; Tue, 18 Jul 2000 13:45:11 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 510365DDBF for ; Tue, 18 Jul 2000 13:45:05 -0400 (EDT) Received: from karl.extant.net (ns2.extant.net [216.28.121.133]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MXTVALMY; Tue, 18 Jul 2000 11:45:04 -0600 Message-Id: <4.3.2.7.2.20000718134310.04edea80@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 13:44:59 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: Microsoft Point-To-Point Encryption (MPPE) Protocol to Informational Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The PPPEXT Working Group recommends that Microsoft Point-To-Point Encryption (MPPE) Protocol, draft-ietf-pppext-mppe-04.txt, be advanced to Informational. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Jul 19 05:34:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01098 for ; Wed, 19 Jul 2000 05:34:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 623A85DDCA; Wed, 19 Jul 2000 05:34:02 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 451605DDD6; Wed, 19 Jul 2000 05:34:02 -0400 (EDT) Received: from nejimaki2.pfu.co.jp (nejimaki2.pfu.co.jp [202.248.171.130]) by segue.merit.edu (Postfix) with ESMTP id D546D5DDCA for ; Wed, 19 Jul 2000 05:33:59 -0400 (EDT) Received: from scansend.pfu.co.jp ([10.232.16.32]) by nejimaki2.pfu.co.jp (8.9.3/3.7W-99121211) with ESMTP id SAA26298 for ; Wed, 19 Jul 2000 18:33:52 +0900 (JST) Received: from capella.pfu.co.jp (interscan2.pfu.co.jp [10.232.16.31]) by scansend.pfu.co.jp (8.9.3/3.7W-99120918) with ESMTP id SAA05679 for ; Wed, 19 Jul 2000 18:33:52 +0900 (JST) Received: from network.trad.pfu.co.jp (naomi.trad.pfu.co.jp [10.232.77.53]) by capella.pfu.co.jp (8.9.3/3.7W-99120918) with ESMTP id SAA12432 for ; Wed, 19 Jul 2000 18:33:49 +0900 (JST) Received: from pfu.co.jp (eidan153.trad.pfu.co.jp [10.232.78.153]) by network.trad.pfu.co.jp (8.8.8+Sun/3.7W-07/05/00) with ESMTP id SAA14227 for ; Wed, 19 Jul 2000 18:33:52 +0900 (JST) Message-ID: <39757650.654EF943@pfu.co.jp> Date: Wed, 19 Jul 2000 18:35:12 +0900 From: Hirokazu Yamashita X-Mailer: Mozilla 4.7 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: MIB for IP Header Compression over PPP(RFC2509) Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I'm looking for the newest "The PPP IP Group" MIB specification. RFC1473: pppIpConfigCompression OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } -----------> no "IP Header Compression" definition ACCESS read-write STATUS mandatory DESCRIPTION "If none(1) then the local node will not attempt to negotiate any IP Compression option. Otherwise, the local node will attempt to negotiate compression mode indicated by the enumerated value. Changing this object will have effect when the link is next restarted." REFERENCE "Section 4.0, Van Jacobson TCP/IP Header Compression of RFC1332." DEFVAL { none } ::= { pppIpConfigEntry 2 } In RFC2509, new compression protocol(0x0061) is added . What the value for pppIpConfigCompression should be set, when IP header compression protocol is configured? Thanks, --- H.Yamashita From owner-ietf-ppp-outgoing@merit.edu Wed Jul 19 11:27:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17499 for ; Wed, 19 Jul 2000 11:27:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E86905DDEB; Wed, 19 Jul 2000 11:26:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D64A05DDD6; Wed, 19 Jul 2000 11:26:55 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 4EB7E5DDB8 for ; Wed, 19 Jul 2000 11:26:54 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA04316 for ; Wed, 19 Jul 2000 08:26:52 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA05697 for ; Wed, 19 Jul 2000 08:26:34 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jul 2000 10:26:50 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E8D@il27exm02.cig.mot.com> From: Ali Irfan-FIA225 To: "'ietf-ppp@merit.edu'" Subject: Native encapsulation in MP Date: Wed, 19 Jul 2000 10:26:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Situation: MP is used to bundle multiple links. My questions are: If a user packet is not fragmented, then can it be sent native on a link or is the MP encapsulation a must? From my understanding of RFC1990, native encapsulation is permitted. Am also wondering what is the most prevalent implementation: native or always MP encapsulated? If I do have a MP implementation which sends non-fragmented PPP frames in native form, will I have interoperability issues? Thanks for all the help. Regards Irfan From owner-ietf-ppp-outgoing@merit.edu Wed Jul 19 11:45:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23946 for ; Wed, 19 Jul 2000 11:45:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AED215DDD6; Wed, 19 Jul 2000 11:44:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9BB505DDC2; Wed, 19 Jul 2000 11:44:44 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B2BF55DDB8 for ; Wed, 19 Jul 2000 11:44:42 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13999; Wed, 19 Jul 2000 08:44:39 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA27762; Wed, 19 Jul 2000 11:44:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id LAA12466; Wed, 19 Jul 2000 11:44:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14709.52421.813796.499435@gargle.gargle.HOWL> Date: Wed, 19 Jul 2000 11:44:05 -0400 (EDT) From: James Carlson To: Ali Irfan-FIA225 Cc: "'ietf-ppp@merit.edu'" Subject: Re: Native encapsulation in MP In-Reply-To: Ali Irfan-FIA225's message of 19 July 2000 10:26:48 References: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E8D@il27exm02.cig.mot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Ali Irfan-FIA225 writes: > My questions are: If a user packet is not fragmented, then can it be sent > native on a link or is the MP encapsulation a must? It can be sent native. This is at the top of page 6, RFC 1990. > From my understanding of > RFC1990, native encapsulation is permitted. Am also wondering what is the > most prevalent implementation: native or always MP encapsulated? Most implementations I've used always encapsulate so that datagram order is preserved. > If I do > have a MP implementation which sends non-fragmented PPP frames in native > form, will I have interoperability issues? You *shouldn't* have interoperability problems with anything but broken peers. I haven't seen implementations that have trouble with network layer data sent unencapsulated. (I have seen peers that have odd behavior with respect to whether the PPP negotiation packets -- in particular, LCP and the NCPs -- are encapsulated. Unfortunately, this kind of strangeness seems to vary by vendor and by version number.) You may have performance problems. Reordering data on a link can lower TCP performance. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Jul 19 11:49:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25455 for ; Wed, 19 Jul 2000 11:49:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 479C75DE05; Wed, 19 Jul 2000 11:47:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 33C6D5DDF6; Wed, 19 Jul 2000 11:47:29 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 82A4C5DDEF for ; Wed, 19 Jul 2000 11:47:27 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0.Gamma0/calcite) id e6JFlL907373 env-from ; Wed, 19 Jul 2000 09:47:21 -0600 (MDT) Date: Wed, 19 Jul 2000 09:47:21 -0600 (MDT) From: Vernon Schryver Message-Id: <200007191547.e6JFlL907373@calcite.rhyolite.com> To: FIA225@email.mot.com, ietf-ppp@merit.edu Subject: Re: Native encapsulation in MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Ali Irfan-FIA225 > Situation: MP is used to bundle multiple links. > > My questions are: If a user packet is not fragmented, then can it be sent > native on a link or is the MP encapsulation a must? From my understanding of > RFC1990, native encapsulation is permitted. It depends. Some messages should never be sent with MP encapsulation. Others such as for bridging, must always be sent with MP encapsulation, unless you have some other mechanism to prevent reordering, because they do not tolerate any reordering. Still others such as IP should be sent with MP encapsulation when there is any chance of recordering, because TCP/IP lives but does poorly when reorderd. When there has been only one link in the bundle for a long time and a second link is not about to be added or some other conditions, you can skip MP encapsulation. > If I do > have a MP implementation which sends non-fragmented PPP frames in native > form, will I have interoperability issues? It depends on what you mean. Please consider buying a copy of James Carlson's book "PPP Design and Debugging" to answer such questions. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jul 19 15:12:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23132 for ; Wed, 19 Jul 2000 15:12:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 616895DDB8; Wed, 19 Jul 2000 15:12:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4AEE05DDDA; Wed, 19 Jul 2000 15:12:00 -0400 (EDT) Received: from motgate3.mot.com (unknown [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 56C225DDB8 for ; Wed, 19 Jul 2000 15:11:58 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA01387 for ; Wed, 19 Jul 2000 12:09:20 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA27819 for ; Wed, 19 Jul 2000 12:10:38 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jul 2000 14:10:37 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E95@il27exm02.cig.mot.com> From: Ali Irfan-FIA225 To: "'James Carlson'" , "Stacy Nichols (Ottawa)" Cc: Craig Fox , Ali Irfan-FIA225 , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP Date: Wed, 19 Jul 2000 14:10:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > I would suggest (possibly) a two level negotiation. > > LCP for the link and then NCP for the bundle. > > Only if it's useful at all at the bundle level. I think the answer to > that might be 'no.' At least I've heard no compelling argument for > just prohibiting PPPMux outright at the bundle level. > I have a different opinion here. The very reasons for using PPPmux on a single link apply to that for using it on a bundle: bandwidth efficiency. Infact if MP is used, and a MP header is applied for each packet (irrespective of whether the packet is fragmented or not) sent on a link, then the motivation to use PPPmux on the bundle level is even greater. The MP tax is now on a PPPmux frame than on individual frames. From previous discussions in the mailing-list, there does not appear to be a compelling reason for having PPPmux on each link of a bundle (i.e. on a link the PPPmux header should never be outside a MP header). I would recommend prohibiting it on the link. Moving PPPmux from an LCP to NCP option, results in the desired behavior, i.e. PPPmux used on a bundle and not on an individual link. Also the other arguments of doing PPPmux negotiations after authentication, in previous emails on this topic, are satisfied by having PPPmux as an NCP option. I am not sure of the next steps now. Do the authors of the draft now go to the chair of PPPext and ask for an NCP option number? Do we somehow giveup the LCP option number assigned to PPPmux? Suggestions would be most welcomed. > (There should also be definitions for where PPPMux appears with > respect to CCP and ECP. ECP is probably a bit more troublesome.) > > Again, to keep the current model, PPPMux should appear as the > outermost protocol number only. Not inside a decrypted packet, not > inside a decompressed packet, .... > I do not completely understand why this restriction is good. From a protocol perspective PPPmux could be inside a decrypted packet. On links with small packets, this MAY reduce the encryption/decryption and compression/decompression CPU processing and interrupts (I am not too sure of this). PPPmux in itself does not put any requirements of where it should exist with respect to either encryption or compression. I am not against requiring that PPPmux be the outermost protocol number wrt encryption and compression. I do not understand why. Irfan From owner-ietf-ppp-outgoing@merit.edu Wed Jul 19 15:42:20 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06864 for ; Wed, 19 Jul 2000 15:42:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 818745DDE9; Wed, 19 Jul 2000 15:41:52 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6EA515DDDC; Wed, 19 Jul 2000 15:41:52 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id A207D5DDD8 for ; Wed, 19 Jul 2000 15:41:50 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19116; Wed, 19 Jul 2000 13:41:47 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA14085; Wed, 19 Jul 2000 15:41:47 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id PAA13247; Wed, 19 Jul 2000 15:41:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14710.1147.377349.967900@gargle.gargle.HOWL> Date: Wed, 19 Jul 2000 15:41:47 -0400 (EDT) From: James Carlson To: Ali Irfan-FIA225 Cc: "Stacy Nichols (Ottawa)" , Craig Fox , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP In-Reply-To: Ali Irfan-FIA225's message of 19 July 2000 14:10:35 References: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E95@il27exm02.cig.mot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Ali Irfan-FIA225 writes: > I have a different opinion here. The very reasons for using PPPmux on a > single link apply to that for using it on a bundle: bandwidth efficiency. If bandwidth efficiency matters so much that an extra couple of bytes per packet matter, then why use MP at all? MP adds overhead. If you run PPPmux over MP, then you might remove some potential overhead, but you add fragmentation overhead, increased latency, and the obvious cost of complexity. How is that helpful? (The latency increases because MP fragments on arbitrary boundaries and you've now got to wait until you reassemble everything in a frame in order to begin plucking out anything safely. I was under the impression that telco folks asking for this feature didn't much appreciate added latency.) > Infact if MP is used, and a MP header is applied for each packet > (irrespective of whether the packet is fragmented or not) sent on a link, > then the motivation to use PPPmux on the bundle level is even greater. The > MP tax is now on a PPPmux frame than on individual frames. That's not so clear. You end up with PPPmux frames that are larger and need to be fragmented, and overhead added to each. This may end up being a wash. If the motivation is that you don't care about latency but you do want to handle excruciatingly tiny packets with slightly greater efficiency, then I now see why you want PPPmux over MP. But I don't see why those two assumptions should hold. > >From previous discussions in the mailing-list, there does not appear to be a > compelling reason for having PPPmux on each link of a bundle (i.e. on a link > the PPPmux header should never be outside a MP header). I would recommend > prohibiting it on the link. One could imagine a configuration in which a mix of tiny packets and very large packets flows over a PPP session. Everything goes through MP. The tiny packets result in tiny fragments that get grouped together on each link and sent using PPPmux. The larger fragments don't. That seems to work. It continues to work if the tiny frames are reordering insensitive and bypass MP. Of course, this is part of the problem. The folks who need this feature haven't really spoken up here. What's the application? > Moving PPPmux from an LCP to NCP option, results in the desired behavior, > i.e. PPPmux used on a bundle and not on an individual link. Also the other > arguments of doing PPPmux negotiations after authentication, in previous > emails on this topic, are satisfied by having PPPmux as an NCP option. MP is just the tip of the iceberg. PPPmux needs to be defined in relation to CCP and ECP as well, just as MP/CCP/ECP are defined to preserve compress-then-encrypt semantics and to identify clearly during negotiation what architecture is assumed. > I am not sure of the next steps now. Do the authors of the draft now go to > the chair of PPPext and ask for an NCP option number? Do we somehow giveup > the LCP option number assigned to PPPmux? Suggestions would be most > welcomed. You'd go to IANA. Of course, you have a ready-made NCP number -- 8059. > I do not completely understand why this restriction is good. From a protocol > perspective PPPmux could be inside a decrypted packet. On links with small > packets, this MAY reduce the encryption/decryption and > compression/decompression CPU processing and interrupts (I am not too sure > of this). PPPmux in itself does not put any requirements of where it should > exist with respect to either encryption or compression. I am not against > requiring that PPPmux be the outermost protocol number wrt encryption and > compression. I do not understand why. Allowing arbitrary (and mutual) encapsulation makes a mess out of the implementations and likely results in a lack of interoperability, which, I think, is what sparked the question in the first place. Can we have IP in PPPMux in MP in PPPMux in CCP in PPPMux in ECP in PPPMux? If you agree to do PPPMux, what exactly are you agreeing to do? If you allow LCP negotiation of PPPMux, but the actual multiplexing occurs above MP, then you need to amend RFC 1990 to indicate that if PPPMux is negotiated on one link, then it's negotiated on all links. I think that's really ugly, but otherwise, you likely run into trouble with multi-chassis systems. If you do PPPMux with an NCP above MP, that's doesn't need an update, but it probably does need the careful consideration given CCP and ECP. On the other hand, I'd argue that if we can't figure out where it belongs in the puzzle, then, like Compound-Frames, it doesn't belong at all. This isn't a telecommunications body. ;-} -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jul 20 00:02:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06012 for ; Thu, 20 Jul 2000 00:02:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E55EB5DE7B; Thu, 20 Jul 2000 00:00:21 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7ADD65DE77; Thu, 20 Jul 2000 00:00:20 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 1902C5DDFE for ; Thu, 20 Jul 2000 00:00:04 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id VAA14918 for ; Wed, 19 Jul 2000 21:00:04 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id VAA20864 for ; Wed, 19 Jul 2000 21:00:03 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jul 2000 23:00:03 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E97@il27exm02.cig.mot.com> From: Ali Irfan-FIA225 To: "'James Carlson'" Cc: "Stacy Nichols (Ottawa)" , Craig Fox , "'ietf-ppp@merit.edu'" , Pazhyannur Rajesh-QA6283 Subject: RE: PPP-Mux and ML-PPP Date: Wed, 19 Jul 2000 23:00:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > One could imagine a configuration in which a mix of tiny packets and > very large packets flows over a PPP session. Everything goes through > MP. The tiny packets result in tiny fragments that get grouped > together on each link and sent using PPPmux. The larger fragments > don't. That seems to work. It continues to work if the tiny frames > are reordering insensitive and bypass MP. > > Of course, this is part of the problem. The folks who need this > feature haven't really spoken up here. What's the application? > The key application we had in mind when formulating PPPmux was to transport 20 msec radio samples in a cellular system (cdma in particular) from base-stations to the infrastructure over T1 links. The radio samples are in the range of 10-30 bytes, which are encapsulated in IP/UDP. The IP/UDP header is compressed, so we still have a large number of very small packets to be transported over expensive (especially outside US) T1 links. (I do not want to argue with folks who say that bandwidth is on the increase; I agree. However, today and for the near future we have to contend with the issue of T1/E1/J1s.) A similar application is VoIP traffic over low speed WAN links. > > MP is just the tip of the iceberg. PPPmux needs to be defined in > relation to CCP and ECP as well, just as MP/CCP/ECP are defined to > preserve compress-then-encrypt semantics and to identify clearly > during negotiation what architecture is assumed. Definitely. The relation of PPPmux to encryption/compression needs to be added to the draft. If for simplicity, PPPmux should be outside of encryption and compression, this should get added to the draft. > > Allowing arbitrary (and mutual) encapsulation makes a mess out of the > implementations and likely results in a lack of interoperability, > which, I think, is what sparked the question in the first place. Can > we have IP in PPPMux in MP in PPPMux in CCP in PPPMux in ECP in > PPPMux? If you agree to do PPPMux, what exactly are you agreeing to > do? Agreed. We will add further details to the draft. > > If you allow LCP negotiation of PPPMux, but the actual multiplexing > occurs above MP, then you need to amend RFC 1990 to indicate that if > PPPMux is negotiated on one link, then it's negotiated on all links. > I think that's really ugly, but otherwise, you likely run into trouble > with multi-chassis systems. If you do PPPMux with an NCP above MP, > that's doesn't need an update, but it probably does need the careful > consideration given CCP and ECP. I agree that it is preferable to go with NCP rather than LCP and the draft will be updated to reflect this. Thanks Irfan From owner-ietf-ppp-outgoing@merit.edu Fri Jul 21 16:39:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14043 for ; Fri, 21 Jul 2000 16:39:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60C845DDD2; Fri, 21 Jul 2000 16:38:37 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4C7DB5DDD4; Fri, 21 Jul 2000 16:38:37 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id BBF2D5DDD2 for ; Fri, 21 Jul 2000 16:38:35 -0400 (EDT) Received: from karl.extant.net (ns2.extant.net [216.28.121.133]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PH8QVBPW; Fri, 21 Jul 2000 14:38:34 -0600 Message-Id: <4.3.2.7.2.20000721163633.05568360@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 16:38:29 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Always On Dynamic ISDN (AODI) - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to take Always On Dynamic ISDN (AODI) (draft-ietf-pppext-aodi-02.txt) to Informational on August 18, 2000 unless there is substantive comment raised on the list. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri Jul 21 20:05:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05595 for ; Fri, 21 Jul 2000 20:05:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 158AA5DDFB; Fri, 21 Jul 2000 20:04:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 036435DDF5; Fri, 21 Jul 2000 20:04:46 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 5AF1A5DDF1 for ; Fri, 21 Jul 2000 20:04:45 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/calcite) id e6M04iW15612 env-from ; Fri, 21 Jul 2000 18:04:44 -0600 (MDT) Date: Fri, 21 Jul 2000 18:04:44 -0600 (MDT) From: Vernon Schryver Message-Id: <200007220004.e6M04iW15612@calcite.rhyolite.com> To: ietf-ppp@merit.edu, karl@extant.net Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Karl Fox > This is last call. I will advise the area directors that we want to take > Always On Dynamic ISDN (AODI) (draft-ietf-pppext-aodi-02.txt) to > Informational on August 18, 2000 unless there is substantive comment raised > on the list. James Carlson's comments were substantive. Jim is too polite to come out and say that AODI is mediocore or at best unnecessary idea very poorly instantiated and designed to cause interoperability problems, but I lack that character strength. Advancing AODI as other than a caution of what not to do would be wrong. The continuing danger of the IETF endorsing nonsense such as AODI and the multi-frame thing (nonsense because it's based on the incredibly uninformed and completely wrong notion that 14000 kbit/sec is slow for IP services) are reasons to disband this working group. On the other hand, if this working group can retard some of the WAP-like publish-or-perish silliness, maybe it should endure. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Fri Jul 21 20:16:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08536 for ; Fri, 21 Jul 2000 20:16:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C8ED5DDFE; Fri, 21 Jul 2000 20:15:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F02C75DDF5; Fri, 21 Jul 2000 20:15:13 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 8214E5DDF1 for ; Fri, 21 Jul 2000 20:15:11 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/calcite) id e6M0FAh15768 for ietf-ppp@merit.edu env-from ; Fri, 21 Jul 2000 18:15:10 -0600 (MDT) Date: Fri, 21 Jul 2000 18:15:10 -0600 (MDT) From: Vernon Schryver Message-Id: <200007220015.e6M0FAh15768@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: bounces Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The last time I wrote to the PPP list, I received only one bounce like the enclosed. I wrote to the lists maintenance address asking that something be done. Well, someone did something, although perhaps not by the list maintainers. I'm now getting two bounces apparently from the same area for a single message sent to the list. Could someone please unsubscribe whoever it is? Or at least hold them up to public ridicule so that they'll fix their problem? If the Novell software isn't up to handling RFC 822 mail, then please do not allow people using it to subscribe. Vernon Schryver vjs@rhyolite.com > From MAILER-DAEMON Fri Jul 21 18:06:30 2000 > Return-Path: > Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) > by calcite.rhyolite.com (8.11.0/calcite) with SMTP id e6M06Tj15629 > for env-from <>; > Fri, 21 Jul 2000 18:06:29 -0600 (MDT) > Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com > with Novell_GroupWise; Fri, 21 Jul 2000 18:05:47 -0600 > Message-Id: > X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 > Date: Fri, 21 Jul 2000 18:05:47 -0600 > From: Mailer-Daemon@prv-mail20.provo.novell.com > To: vjs@calcite.rhyolite.com > Subject: Message status - undeliverable > Mime-Version: 1.0 > Content-Type: multipart/mixed; boundary="=_87DFCB4B.90F19BCB" > X-DCC-Warning: calcite.rhyolite.com calcite.rhyolite.com Sender=0/1 > env_From=0/1 From=0/1 Subject=0/1 body=0/1 fuz1=0/0 > > This is a MIME message. If you are reading this text, you may want to > consider changing to a mail reader or gateway that understands how to > properly handle MIME multipart messages. > > --=_87DFCB4B.90F19BCB > Content-Type: text/plain; charset=US-ASCII > Content-Disposition: inline > > The message that you sent was undeliverable to the following: > EXP+GREG LINN > > --=_87DFCB4B.90F19BCB > Content-Type: text/plain; charset=US-ASCII > > Information about your message: > Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call > > --=_87DFCB4B.90F19BCB-- > From MAILER-DAEMON Fri Jul 21 18:06:42 2000 > Return-Path: > Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) > by calcite.rhyolite.com (8.11.0/calcite) with SMTP id e6M06fj15633 > for env-from <>; > Fri, 21 Jul 2000 18:06:41 -0600 (MDT) > Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com > with Novell_GroupWise; Fri, 21 Jul 2000 18:05:48 -0600 > Message-Id: > X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 > Date: Fri, 21 Jul 2000 18:05:48 -0600 > From: Mailer-Daemon@prv-mail20.provo.novell.com > To: vjs@calcite.rhyolite.com > Subject: Message status - undeliverable > Mime-Version: 1.0 > Content-Type: multipart/mixed; boundary="=_80D8CC4C.96F79DCD" > X-DCC-Warning: calcite.rhyolite.com calcite.rhyolite.com Sender=0/2 > env_From=0/2 From=0/2 Subject=0/2 body=0/1 fuz1=0/1 > > This is a MIME message. If you are reading this text, you may want to > consider changing to a mail reader or gateway that understands how to > properly handle MIME multipart messages. > > --=_80D8CC4C.96F79DCD > Content-Type: text/plain; charset=US-ASCII > Content-Disposition: inline > > The message that you sent was undeliverable to the following: > EXP+RUTH TSAI > > --=_80D8CC4C.96F79DCD > Content-Type: text/plain; charset=US-ASCII > > Information about your message: > Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call > > --=_80D8CC4C.96F79DCD-- > From owner-ietf-ppp-outgoing@merit.edu Fri Jul 21 22:13:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17483 for ; Fri, 21 Jul 2000 22:13:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A93775DDF1; Fri, 21 Jul 2000 22:13:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 96C9E5DDD4; Fri, 21 Jul 2000 22:13:11 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id E88D25DDA4 for ; Fri, 21 Jul 2000 22:13:09 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id WAA24708; Fri, 21 Jul 2000 22:13:05 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14713.817.204392.508423@h006008986325.ne.mediaone.net> Date: Fri, 21 Jul 2000 22:13:05 -0400 (EDT) To: Vernon Schryver Cc: ietf-ppp@merit.edu, karl@extant.net Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call In-Reply-To: Vernon Schryver's message of 21 July 2000 18:04:44 References: <200007220004.e6M04iW15612@calcite.rhyolite.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Vernon Schryver writes: > Jim is too polite to come out and say that AODI is mediocore or at best > unnecessary idea very poorly instantiated and designed to cause > interoperability problems, but I lack that character strength. > Advancing AODI as other than a caution of what not to do would be wrong. It's awfully rare that some points me out as being polite, so, thank you. AODI is not merely mediocre; it intentionally breaks MP with the unnecessary link-idle mechanism, PPP over X.25 by changing the header format, and even tweaks BACP (which in itself is a bit of a feat). I'm certainly happy that it's not standards-track material anymore (as I think it was when I wrote my first comments). I don't think AODI works as a caution. The only substantive discussions I had on the topic were of the form, "well, we've already shipped it, so you can't change the design." This model has worked fine for RFCs 1877, 2433, and 2759 in the past, and is likely to continue in the future. Publishing as Informational has become, in my opinion, an "IETF inside" ad campaign. Some customers do realize that it means "proprietary stuff;" most either don't or don't care. (I just recently had a discussion with one gentleman who had decided that MacroMedia Flash wasn't proprietary because, well, he got it for free and it ran on *his* PC.) Something like AO/DI is doubtless needed for some applications, at least until xDSL or cable access wipe ISDN from the map entirely (which may already have happened). It represents something that is obsolescent enough to be not worth redesigning. And AO/DI does describe the solution created by one vendor. Perhaps those factors are enough to let it advance. (No, before I hear about it, I'm not a marketer of ISDN equipment anywhere, let alone in the corner of the world you call home. Yes, it may well be on the rise somewhere. No, that doesn't mean that the future for it is altogether bright.) > The continuing danger of the IETF endorsing nonsense such as AODI and the > multi-frame thing (nonsense because it's based on the incredibly uninformed > and completely wrong notion that 14000 kbit/sec is slow for IP services) There's a jello-like squishiness to this one. Every time I talk to someone working on the issue, the problem changes shape or moves from one part of the system to another. Have you seen the LIPE draft (draft-chuah-avt-lipe-00.txt)? This appears to be yet another solution to the problem, and is essentially RFC 1692 TMux warmed over and limited to just one application. Big grain of salt here, but this is what I understand so far: One of the issues appears to be that voice codecs, such as G.723.1, produce 20 bytes of data at (at most) about 39Hz. This represents a reasonably small fraction of the bandwidth of any modern modem and shouldn't present a problem (especially with RFC 2508/2509 header compression). They're planning to aggregate this VoIP data from cellular base stations over T1s back to some kind of (larger) gateway node that converts back to regular PCM circuit-switched voice. One of the issues is that bandwidth on the wireless side is low in comparison to regular POTS modems. This, I think, should be regarded as a temporary situation and probably should not be enshrined in a protocol. The other is that these T1 links will (they assert) see lots of tiny IP packets and be choked with the RTP/IP/PPP overhead. (I don't see, though, why the same point-to-point compression won't work there. Figuring 8.8Kbps per call [including some PPP overhead], you could fit perhaps 170 calls on a regular T1. 170 contexts isn't too many to deal with.) > are reasons to disband this working group. On the other hand, if this > working group can retard some of the WAP-like publish-or-perish silliness, > maybe it should endure. I don't think this is a case of academic publish-or-perish. This appears to me to be telco (wireless in particular) implementors trying to make an IETF-based solution that is as efficient as some (unmentioned) reference implementation. That voice traffic is flat or declining and that data traffic now far outstrips voice in bandwidth seems lost as a design criterion. If those links from the base stations are nearly overloaded dealing with voice and cannot tolerate a little extra overhead to comply with existing protocols, what will happen when web or video access comes to those little traffic accident instigators? One tiny 50KB web page is about the same size as a minute of non-stop talk on VoIP. All of that is to say that there appear to be strong, application- dependent assumptions being made here, and that's what I think we should be talking about. If the assumptions don't hold, then it doesn't much matter what the solutions look like. All voice and no data makes johnny a dull boy. ;-} -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Jul 21 22:39:07 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26113 for ; Fri, 21 Jul 2000 22:39:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF7CA5DDF5; Fri, 21 Jul 2000 22:38:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AF3A55DDD4; Fri, 21 Jul 2000 22:38:42 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 1A2855DDA4 for ; Fri, 21 Jul 2000 22:38:41 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/calcite) id e6M2ceW19509 for ietf-ppp@merit.edu env-from ; Fri, 21 Jul 2000 20:38:40 -0600 (MDT) Date: Fri, 21 Jul 2000 20:38:40 -0600 (MDT) From: Vernon Schryver Message-Id: <200007220238.e6M2ceW19509@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > One of the issues appears to be that voice codecs, such as G.723.1, > produce 20 bytes of data at (at most) about 39Hz. ... 20 Bytes/packet * 39 packets/sec = 780 Bytes/sec = 6240 bit/sec That sounds very low, but I'm ignorant of G.723. > ... > I don't think this is a case of academic publish-or-perish. This > appears to me to be telco (wireless in particular) implementors trying > to make an IETF-based solution that is as efficient as some > (unmentioned) reference implementation. That voice traffic is flat or > declining and that data traffic now far outstrips voice in bandwidth > seems lost as a design criterion. If those links from the base > stations are nearly overloaded dealing with voice and cannot tolerate > a little extra overhead to comply with existing protocols, what will > happen when web or video access comes to those little traffic accident > instigators? One tiny 50KB web page is about the same size as a > minute of non-stop talk on VoIP. > > All of that is to say that there appear to be strong, application- > dependent assumptions being made here, and that's what I think we > should be talking about. If the assumptions don't hold, then it > doesn't much matter what the solutions look like. There you go being too kind--or maybe the opposite. I give people more credit than to really think that 14 kbit/sec is slow. For another thing, if there really were an "(unmentioned) reference implementation" against which the WAP-like stuff were being measured, then it would have been mentioned after all these months. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Sat Jul 22 13:09:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25168 for ; Sat, 22 Jul 2000 13:09:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 862515DD9E; Sat, 22 Jul 2000 13:08:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 617115DDBE; Sat, 22 Jul 2000 13:08:30 -0400 (EDT) Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by segue.merit.edu (Postfix) with ESMTP id 9CB375DD9E for ; Sat, 22 Jul 2000 13:08:28 -0400 (EDT) Received: from MATT.ascend.com (ts021d04.lap-ca.concentric.net [64.1.213.16]) by tonnant.cnchost.com id NAA00811; Sat, 22 Jul 2000 13:08:04 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-Id: <4.3.1.2.20000722095709.00cb9a50@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 22 Jul 2000 10:07:30 -0700 To: James Carlson From: Matt Holdrege Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call Cc: Vernon Schryver , ietf-ppp@merit.edu, karl@extant.net In-Reply-To: <14713.817.204392.508423@h006008986325.ne.mediaone.net> References: <200007220004.e6M04iW15612@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 10:13 PM 7/21/00 -0400, James Carlson wrote: >Vernon Schryver writes: > >AODI is not merely mediocre; it intentionally breaks MP with the >unnecessary link-idle mechanism, PPP over X.25 by changing the header >format, and even tweaks BACP (which in itself is a bit of a feat). >I'm certainly happy that it's not standards-track material anymore (as >I think it was when I wrote my first comments). First of all, yes I moved to Informational due entirely to your comments about how it violates standard mechanisms. Secondly, it breaks those mechanisms for a reason and the resulting service does work. Thus, we are leaving the protocol as is for now (and likely forever giving the alternative access methods that have arisen to prominence recently. >I don't think AODI works as a caution. The only substantive >discussions I had on the topic were of the form, "well, we've already >shipped it, so you can't change the design." This model has worked >fine for RFCs 1877, 2433, and 2759 in the past, and is likely to >continue in the future. Publishing as Informational has become, in my >opinion, an "IETF inside" ad campaign. Some customers do realize that >it means "proprietary stuff;" most either don't or don't care. (I >just recently had a discussion with one gentleman who had decided that >MacroMedia Flash wasn't proprietary because, well, he got it for free >and it ran on *his* PC.) There is no cure-all for ignorance. We can't stop publishing for that reason. What the IESG does these days is add a disclaimer to the RFC stating all the objections. In this case, the PPP WG has a list of objections which can and should be added to the resulting Informational RFC. Why the IETF? Well the IETF is the authoritative resource for protocol specifications that carry IP traffic. Since this protocol doesn't meet IETF Standard guidelines, it is Informational. As you say, there is plenty of precedence and it will continue. It actually good practice despite how a few misapply it. >Something like AO/DI is doubtless needed for some applications, at >least until xDSL or cable access wipe ISDN from the map entirely >(which may already have happened). It represents something that is >obsolescent enough to be not worth redesigning. And AO/DI does >describe the solution created by one vendor. Perhaps those factors >are enough to let it advance. True, except there is not just one, but very many vendors who support it. From owner-ietf-ppp-outgoing@merit.edu Sun Jul 23 02:48:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04029 for ; Sun, 23 Jul 2000 02:48:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96E305DDAF; Sun, 23 Jul 2000 02:47:49 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7532E5DDA3; Sun, 23 Jul 2000 02:47:49 -0400 (EDT) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by segue.merit.edu (Postfix) with ESMTP id B9FD45DD94 for ; Sun, 23 Jul 2000 02:47:47 -0400 (EDT) Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e6N6lkx26336 for ; Sun, 23 Jul 2000 08:47:46 +0200 (MET DST) From: "Dr. Carsten Bormann" To: Subject: RE: Always On Dynamic ISDN (AODI) - Working Group Last Call Date: Sun, 23 Jul 2000 08:47:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.3.2.7.2.20000721163633.05568360@127.0.0.1> Importance: Normal Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit [Apologies if this is a duplicate -- I didn't get the usual barrage of vacation notices, so I have to assume my original message has been lost] Did anyone read this thing yet? It calls for an editing pass (both for formatting mistakes and for grammar errors). What is "the technical subcommittee"? Is it "the author" or "the authors"? Is it really true that there haven't been trial deployments yet that could supply "real-world experience"? Is the first CUD byte 0xCF or is it "to be selected from reserved values in ISO/IEC TR 9577"? Maybe the WG should supply proposed text for an IESG comment at the start of the RFC. The time constants (5 seconds queueing/5 seconds idle time) look like good candidates for a disclaimer... It is good to know that AO/DI is "inherently stable" even with these time constants :-) Wasn't there a rule that said proprietary documents should have the organization in the title? In any case, there should be text in the abstract/introduction that clearly identifies the provenance of this document and purpose of its publication as an RFC. Puzzled, Carsten > -----Original Message----- > From: owner-ietf-ppp@merit.edu [mailto:owner-ietf-ppp@merit.edu]On > Behalf Of Karl Fox > Sent: Friday, July 21, 2000 22:38 > To: ietf-ppp@merit.edu > Subject: Always On Dynamic ISDN (AODI) - Working Group Last Call > > > This is last call. I will advise the area directors that we want to take > Always On Dynamic ISDN (AODI) (draft-ietf-pppext-aodi-02.txt) to > Informational on August 18, 2000 unless there is substantive > comment raised > on the list. From owner-ietf-ppp-outgoing@merit.edu Mon Jul 24 13:23:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01591 for ; Mon, 24 Jul 2000 13:23:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0AFC5DDB4; Mon, 24 Jul 2000 13:23:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9F3CC5DDB6; Mon, 24 Jul 2000 13:23:14 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 3ABB65DDB4 for ; Mon, 24 Jul 2000 13:23:12 -0400 (EDT) Received: from karl.extant.net (ns2.extant.net [216.28.121.133]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PH8QVDG5; Mon, 24 Jul 2000 11:23:09 -0600 Message-Id: <4.3.2.7.2.20000724131657.057c6c20@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 13:22:59 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: AO/DI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi folks, It appears that the authors of AO/DI will not accept changes that affect bits on the wire, yet it is important that the protocol be documented for the benefit of future developers. So keep on offering your wording edits, but in the mean time the working group needs to develop a summary of objections (not too long) to hand to the IESG. I invite each of you who have objections to the way AO/DI works to write them down and send them to this mailing list, or to reply with comments to others who do. We'll send the resulting overall list up to our area directors. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Jul 26 23:49:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04693 for ; Wed, 26 Jul 2000 23:49:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DE765DE0D; Wed, 26 Jul 2000 23:48:49 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E42F75DE1F; Wed, 26 Jul 2000 23:48:48 -0400 (EDT) Received: from ws9.cdotb.ernet.in (unknown [202.41.72.121]) by segue.merit.edu (Postfix) with ESMTP id A9F875DE0D for ; Wed, 26 Jul 2000 23:48:43 -0400 (EDT) Received: from ws61.cdotb.ernet.in (ws61 [202.41.72.173]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id JAA01395 for ; Thu, 27 Jul 2000 09:14:27 +0500 (GMT+0500) Date: Thu, 27 Jul 2000 09:13:11 +0500 (GMT+0500) From: Suresh N To: ietf-ppp@merit.edu Subject: Multilink PPP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu hi i need more pointers on Multilink PPP other than RFC. can anybody give some information about this. thanx in advance, bye -----------------***************************************---------------- N.SURESH Research Engineer, Centre For Development of Telematics, 71/1,Sneha Complex, Bangalore-560052 -----------------***************************************---------------- From owner-ietf-ppp-outgoing@merit.edu Thu Jul 27 06:19:45 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17415 for ; Thu, 27 Jul 2000 06:19:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEB345DDF1; Thu, 27 Jul 2000 06:19:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B16BC5DDF5; Thu, 27 Jul 2000 06:19:14 -0400 (EDT) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by segue.merit.edu (Postfix) with SMTP id 5184C5DDF1 for ; Thu, 27 Jul 2000 06:19:12 -0400 (EDT) Received: from ppp-203-197-9-239.bom.vsnl.net.in (HELO muralidharan) (203.197.9.239) by smtp.mail.yahoo.com with SMTP; 27 Jul 2000 10:01:41 -0000 X-Apparently-From: Message-ID: <00d301bff7b1$e52459a0$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: "Suresh N" , References: Subject: Re: Multilink PPP Date: Thu, 27 Jul 2000 15:33:08 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Try the book by James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp muralidharan ----- Original Message ----- From: Suresh N To: Sent: Thursday, July 27, 2000 9:43 AM Subject: Multilink PPP > hi > i need more pointers on Multilink PPP other than RFC. can anybody > give some information about this. > thanx in advance, > bye __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Thu Jul 27 09:41:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25585 for ; Thu, 27 Jul 2000 09:41:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4871B5DDF9; Thu, 27 Jul 2000 09:40:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2B4F15DE06; Thu, 27 Jul 2000 09:40:47 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 3B2AF5DDF9 for ; Thu, 27 Jul 2000 09:40:44 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id JAA27028; Thu, 27 Jul 2000 09:40:40 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14720.15320.469063.448640@h006008986325.ne.mediaone.net> Date: Thu, 27 Jul 2000 09:40:40 -0400 (EDT) To: GAUCHE Francis FTRD/DAC/LAN Cc: "'James Carlson'" , Vernon Schryver , ietf-ppp@merit.edu, karl@extant.net Subject: RE: Always On Dynamic ISDN (AODI) - Working Group Last Call In-Reply-To: GAUCHE Francis FTRD/DAC/LAN's message of 27 July 2000 15:20:27 References: <7D59335FDAE0D011A3350060974B1C7202AAB9BA@l-mhs3.lannion.cnet.fr> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit GAUCHE Francis FTRD/DAC/LAN writes: > as we are in the D channel, layer 2 is LAPD (Q.921) and thus the > Address field in HDLC is composed of SAPI+TEI (2 octets), and > Control field is composed of N(S)+N(R) (2 octets). The X.25 header > remains the same as in PPP over X.25. This is correct. The X.25 header is a standard and is thus always the same and can't (reasonably) be modified by IETF documents. The part that's different is the payload. For AO/DI, you don't start with the PPP Protocol number as you should. Instead, you start with another (!) HDLC Address and Control field pair and then the PPP frame follows, starting with the PPP Protocol field. The two are incompatible for no good reason at all. The AO/DI draft says this: AO/DI recommends against header substitution by the transmitter. AO/DI uses the X.25 as a virtual PPP dial-up connection, so we recommend that the PPP header be part of the X.25 payload. This approach better isolates the protocol layers. It is desirable that X.25 receivers that expect the header substitution, also be able to properly function when the PPP header is included the X.25 payload. The "PPP header" that the author is referring to here is actually the standard HDLC header. RFC 1598 says this, among other things: Because the Address and Control field values are not constant, and are modified as the frame is transported by the network switching fabric, Address-and-Control-Field-Compression MUST NOT be negotiated. Clearly, AO/DI-speaking devices will speak a different protocol and attempt to negotiate incompatible options with RFC 1598-speaking devices. Given that there's fielded equipment that understands how to deal with Standards Track RFC 1598 encapsulation in a variety of scenarios, I think it's misguided at best to allow subsequent drafts to modify this procedure without at least providing some demonstrable and compelling benefit from the modification itself. The AO/DI draft does not do this. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jul 27 11:18:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15191 for ; Thu, 27 Jul 2000 11:18:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7107B5DE15; Thu, 27 Jul 2000 11:16:01 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5DC785DE12; Thu, 27 Jul 2000 11:16:01 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 844DD5DE0E for ; Thu, 27 Jul 2000 11:15:58 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id LAA24674; Thu, 27 Jul 2000 11:15:56 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14720.21035.147302.683351@h006008986325.ne.mediaone.net> Date: Thu, 27 Jul 2000 11:15:55 -0400 (EDT) To: GAUCHE Francis FTRD/DAC/LAN Cc: "'James Carlson'" , "'ietf-ppp@merit.edu'" Subject: RE: Always On Dynamic ISDN (AODI) - Working Group Last Call In-Reply-To: GAUCHE Francis FTRD/DAC/LAN's message of 27 July 2000 16:52:28 References: <7D59335FDAE0D011A3350060974B1C7202AAB9BD@l-mhs3.lannion.cnet.fr> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit GAUCHE Francis FTRD/DAC/LAN writes: > In the X.25 payload (we usually talk about X.25 user data information field) > you'll find the PPP frame wtih first 2 octets for the PPP protocol field > and the following Information and Padding fields. That's true for RFC 1598, but false for AO/DI. > As far as i understand, this final frame (which i described in my previous > email) looks exactly the same as the one in the RFC1598 (PPP over X.25). It is, but only because it's not what's specified in the AO/DI draft. The draft (and the authors, in several messages) clearly state that the X.25 payload for AO/DI includes a second copy of the HDLC Address and Control fields for PPP (fixed to FF 03). This is not compatible with RFC 1598. > By the way, i sent 2 days ago an email with some comments on AODI draft > (regarding Q.922/Q.921 and TEI/SAPI). I have not received a copy of this > message on the PPP Extension mailing list (maybe that's an option and thus > i'm not in carbon copy of my own emails sent to PPP extensions). Could you > please tell me if you have received it ? No. Nor can I find any such message in the mailing list archives. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Jul 31 19:23:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06325 for ; Mon, 31 Jul 2000 19:23:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 454215DD8C; Mon, 31 Jul 2000 19:19:37 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2BAF05DDA1; Mon, 31 Jul 2000 19:19:37 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by segue.merit.edu (Postfix) with ESMTP id AEB0C5DD8C for ; Mon, 31 Jul 2000 19:19:35 -0400 (EDT) Received: from anfreema-pc (dhcp-l21-163.cisco.com [171.68.210.163]) by mailman.cisco.com (8.9.3/8.9.1) with SMTP id QAA14257; Mon, 31 Jul 2000 16:19:00 -0700 (PDT) Message-Id: <200007312319.QAA14257@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 30 Jul 2000 16:18:13 -0700 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: Update for Sept 2000 VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_18187235==_.ALT" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --=====================_18187235==_.ALT Content-Type: text/plain; charset="us-ascii" First a reminder to make your hotel reservations for the VPN Interoperability Workshop, September 18-22, 2000 at the Paradise Point Resort in San Diego, California. The reservation number is 800-344-2626. Please register under the VPN Workshop room block for the discounted rate of $159 per night (plus tax). The cutoff date for this room block is August 15th. There are a few modifications to the application and schedule for the September 2000 VPN Workshop. The application for the workshop has been moved to a new server and is now available at: http://209.249.66.84/vpnworkshop/ On Tuesday evening, September 19, 2000, the California Broadband User's Group will sponsor an appreciation event for the workshop attendees. At 7 PM we will board a Sternwheeler, the William D. Evans, at the Bahia Resort Hotel for a two hour cocktail cruise in San Diego's Mission Bay. The cruise will replace the reception originally scheduled for September 20, 2000. The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The protocols being tested at this workshop are: IPsec IKE IPComp L2TP over Transport-Mode IPsec PPTP PPPoE PPPoATM L2TPoATM Thanks, Anita Freeman --=====================_18187235==_.ALT Content-Type: text/html; charset="us-ascii"
First a reminder to make your hotel reservations for the VPN Interoperability Workshop, September 18-22, 2000 at the Paradise Point Resort in San Diego, California.  The reservation number is 800-344-2626.

Please register under the VPN Workshop room block for the discounted rate of $159 per night (plus tax).  The cutoff date for this room block is August 15th.

There are a few modifications to the application and schedule for the September 2000 VPN Workshop.

The application for the workshop has been moved to a new server and is now available at:

http://209.249.66.84/vpnworkshop/

On Tuesday evening, September 19, 2000, the California Broadband User's Group will sponsor an appreciation event for the workshop attendees.  At 7 PM we will board a Sternwheeler, the William D. Evans, at the Bahia Resort Hotel for a two hour cocktail cruise in San Diego's Mission Bay. 

The cruise will replace the reception originally scheduled for September 20, 2000.

The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company.

The protocols being tested at this workshop are:

IPsec
IKE
IPComp
L2TP over Transport-Mode IPsec
PPTP
PPPoE
PPPoATM
L2TPoATM

Thanks, Anita Freeman

--=====================_18187235==_.ALT--