Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03538; 1 Feb 94 9:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03534; 1 Feb 94 9:37 EST Received: from merit.edu by CNRI.Reston.VA.US id aa06753; 1 Feb 94 9:37 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id JAA27318 for ietf-ppp-rcpt; Tue, 1 Feb 1994 09:12:53 -0500 Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.6.5/8.6.5) with SMTP id JAA27315 for ; Tue, 1 Feb 1994 09:12:51 -0500 Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA12781; Tue, 1 Feb 94 09:12:19 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9402011412.AA12781@hobbit.gandalf.ca> Subject: Re: CCP: rough consensus and running code To: ietf-ppp Date: Tue, 1 Feb 1994 09:12:01 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 601 > compression above the multilink bundle or on each physical link. I have > proposed that we use the same compression protocol but with a different > protocol ID to indicated whether the compression negotiation is supposed to > apply to the link or the bundle. I believe that this should find its way > into the compression control protocol document. I'm with Brian on this issue. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04558; 1 Feb 94 10:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04554; 1 Feb 94 10:33 EST Received: from merit.edu by CNRI.Reston.VA.US id aa08436; 1 Feb 94 10:33 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id KAA01441 for ietf-ppp-rcpt; Tue, 1 Feb 1994 10:13:58 -0500 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA01435 for ; Tue, 1 Feb 1994 10:13:55 -0500 Received: from tripe.MorningStar.Com by volitans.MorningStar.Com (5.65a/94011701) id AA25101; Tue, 1 Feb 94 10:13:23 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karl Fox Received: by tripe.MorningStar.Com (5.65a/94012401) id AA09499; Tue, 1 Feb 94 10:13:22 -0500 Date: Tue, 1 Feb 94 10:13:22 -0500 Message-Id: <9402011513.AA09499@tripe.MorningStar.Com> To: ietf-ppp Subject: Re: CCP: rough consensus and running code In-Reply-To: <9402011412.AA12781@hobbit.gandalf.ca> References: <9402011412.AA12781@hobbit.gandalf.ca> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. From: dcarr@gandalf.ca (Dave Carr) Date: Tue, 1 Feb 1994 09:12:01 -0500 (EST) > I have proposed that we use the same compression protocol but > with a different protocol ID to indicated whether the compression > negotiation is supposed to apply to the link or the bundle. I'm with Brian on this issue. Me too.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05657; 1 Feb 94 11:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05653; 1 Feb 94 11:03 EST Received: from merit.edu by CNRI.Reston.VA.US id aa09372; 1 Feb 94 11:03 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id KAA03490 for ietf-ppp-rcpt; Tue, 1 Feb 1994 10:47:25 -0500 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA03487 for ; Tue, 1 Feb 1994 10:47:23 -0500 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <04243-0@relay1.pipex.net>; Tue, 1 Feb 1994 15:45:05 +0000 Received: by widow.spider.co.uk; Tue, 1 Feb 94 15:53:29 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerry Meyer Date: Tue, 1 Feb 94 15:45:51 GMT Message-Id: <4412.9402011545@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Tue, 1 Feb 94 15:45:51 GMT To: ietf-ppp@merit.edu Subject: Re: CCP: rough consensus and running code From: dcarr@gandalf.ca (Dave Carr) Date: Tue, 1 Feb 1994 09:12:01 -0500 (EST) > I have proposed that we use the same compression protocol but > with a different protocol ID to indicated whether the compression > negotiation is supposed to apply to the link or the bundle. I'm with Brian on this issue. I'll cast a vote for this also.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07485; 1 Feb 94 12:14 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07481; 1 Feb 94 12:14 EST Received: from merit.edu by CNRI.Reston.VA.US id aa11462; 1 Feb 94 12:14 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id LAA09147 for ietf-ppp-rcpt; Tue, 1 Feb 1994 11:52:06 -0500 Received: from xap.xyplex.com (xap.xyplex.com [140.179.50.201]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA09144 for ; Tue, 1 Feb 1994 11:52:04 -0500 Received: from sgw.xyplex.com by xap.xyplex.com id ; Tue, 1 Feb 94 11:50:23 -0500 Received: by eng.xyplex.com (4.1/SMI-4.1) id AA10581; Tue, 1 Feb 94 11:47:29 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Wasson Message-Id: <9402011647.AA10581@eng.xyplex.com> Subject: Re: CCP: rough consensus and running code To: karl@morningstar.com Date: Tue, 1 Feb 94 11:47:28 EST Cc: ietf-ppp@merit.edu In-Reply-To: <9402011513.AA09499@tripe.MorningStar.Com>; from "Karl Fox" at Feb 1, 94 10:13 am X-Mailer: ELM [version 2.3 PL8] According to Karl Fox: > > From: dcarr@gandalf.ca (Dave Carr) > Date: Tue, 1 Feb 1994 09:12:01 -0500 (EST) > > > I have proposed that we use the same compression protocol but > > with a different protocol ID to indicated whether the compression > > negotiation is supposed to apply to the link or the bundle. > > I'm with Brian on this issue. > > Me too. > What does it mean when different links of the same bundle negotiate different compression protocols, some on the link and some on the bundle?? +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07798; 1 Feb 94 12:23 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07794; 1 Feb 94 12:23 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11660; 1 Feb 94 12:23 EST Received: from merit.edu by IETF.CNRI.Reston.VA.US id aa07788; 1 Feb 94 12:23 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id MAA10280 for ietf-ppp-rcpt; Tue, 1 Feb 1994 12:05:02 -0500 Received: from combinetu.combinet.com (combinetu.combinet.com [192.216.55.10]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA10275 for ; Tue, 1 Feb 1994 12:04:59 -0500 Received: from snail.combinet.com by combinetu.combinet.com (5.67/1.00) id AA05786; Tue, 1 Feb 94 09:06:39 -0800 Received: from cc:Mail by snail.combinet.com (1.30/SMTPLink) id A03820; Tue, 01 Feb 94 09:03:32 PST Date: Tue, 01 Feb 94 09:03:32 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Fenton Message-Id: <9402010903.A03820@snail.combinet.com> To: ietf-ppp@merit.edu Subject: re: MLCP impacting CCP Keith Sklower writes: > Maybe would could do a straw poll on the net just on this specific > issue: > Do you believe that it is sufficient to conduct CCP negotiations > inside multilink headers to indicate a desire to run compression > above multilink, or do you believe that there should be a specific > option negotiated in CCP to indicate this? I expect that we will always do compression above multilink, for much the same reasons outlined by Thomas Dimitri in his recent message. There are undoubtedly good reasons for compressing individual links as well, but we don't have a reason for doing so. Since we would use only one of the "forms" of CCP, I vote "don't care" as far as how the two CCP/MLCP configurations are differentiated. -Jim Fenton Combinet, Inc., Sunnyvale, CA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08754; 1 Feb 94 13:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08747; 1 Feb 94 13:01 EST Received: from merit.edu by CNRI.Reston.VA.US id aa12629; 1 Feb 94 13:01 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id MAA12718 for ietf-ppp-rcpt; Tue, 1 Feb 1994 12:46:45 -0500 Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA12715 for ; Tue, 1 Feb 1994 12:46:42 -0500 Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA16587; Tue, 1 Feb 94 12:46:09 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9402011746.AA16587@hobbit.gandalf.ca> Subject: Re: CCP: rough consensus and running code To: ietf-ppp Date: Tue, 1 Feb 1994 12:45:49 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 978 > According to Karl Fox: > What does it mean when different links of the same bundle negotiate different > compression protocols, some on the link and some on the bundle?? Each link may chose its own compression algorithm using CCP and the corresponding Prot-id for compression at the link layer. For example, compression for an individual link would be negotiated with 80FE (I picked one arbitrarily) and the compressed packets would be sent encapsulated with 00FE protocol id. There can be only *one* CCP and (different) prot-id above the multilink. The compression over multilink would be negotiated with protocol 80FD, and compressed packets sent with 00FD protocol id. No multilink header is required, which is great when only a single link is in use. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12756; 1 Feb 94 14:00 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12752; 1 Feb 94 14:00 EST Received: from merit.edu by CNRI.Reston.VA.US id aa14271; 1 Feb 94 13:59 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id NAA16809 for ietf-ppp-rcpt; Tue, 1 Feb 1994 13:43:07 -0500 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA16804 for ; Tue, 1 Feb 1994 13:43:03 -0500 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA15632; Tue, 1 Feb 94 10:42:37 PST Message-Id: <9402011842.AA15632@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Feb 1994 10:42:47 -0800 To: Thomas Dimitri Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: re: MLCP impacting CCP Cc: ietf-ppp@merit.edu >For those reasons, Microsoft will always try to negotiate >compression ABOVE multlink fragmentation. I would like to >know who is planning to do below and why? Because: >2. Some links are soo fast they don't require compression - >or require a faster compression algorithm. For instance, >my 8 ISDN B-channels lines may want no compression >while my V.32 modem line may want some sort of compression. I think of compression algorithm as an attribute of the line, not of the multi-link. HOWEVER, I have not been pushing the issue as it appears to be counter to everyone else, and I can see the argument for having it above. Call it yielding a small point in the name of reaching consensus on the more pressing issues... ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12915; 1 Feb 94 14:07 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12909; 1 Feb 94 14:07 EST Received: from merit.edu by CNRI.Reston.VA.US id aa14534; 1 Feb 94 14:07 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id NAA17416 for ietf-ppp-rcpt; Tue, 1 Feb 1994 13:52:33 -0500 Received: from spock.retix.com (spock.retix.com [163.182.4.1]) by merit.edu (8.6.5/8.6.5) with ESMTP id NAA17412 for ; Tue, 1 Feb 1994 13:52:31 -0500 Received: from ss10.retix.com (ss10.retix.com [163.182.4.213]) by spock.retix.com (8.6.4/8.6.4) with SMTP id KAA00570 for ; Tue, 1 Feb 1994 10:52:28 -0800 Received: by ss10.retix.com (4.1/smail2.5/9-30-90) id AA03981; Tue, 1 Feb 94 10:52:25 PST Date: Tue, 1 Feb 94 10:52:25 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew John Macdonald Fawcett Message-Id: <9402011852.AA03981@ss10.retix.com> To: ietf-ppp@merit.edu Subject: Please remove from list. Please remove me from this list.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13647; 1 Feb 94 14:35 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13643; 1 Feb 94 14:35 EST Received: from merit.edu by CNRI.Reston.VA.US id aa15474; 1 Feb 94 14:35 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id OAA19709 for ietf-ppp-rcpt; Tue, 1 Feb 1994 14:23:33 -0500 Received: from digibd.com (digibd.digibd.com [192.83.159.205]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA19706 for ; Tue, 1 Feb 1994 14:23:32 -0500 Received: by digibd.com (5.65/DBI-1.19) id AA08445; Tue, 1 Feb 94 13:17:33 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Coradetti Message-Id: <9402011917.AA08445@digibd.com> Subject: Re: MLCP impacting CCP To: ietf-ppp@merit.edu Date: Tue, 1 Feb 1994 13:17:33 -0600 (CST) In-Reply-To: <9402011842.AA15632@fennel.acc.com> from "Fred Baker" at Feb 1, 94 10:42:47 am X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 90 I intend to compress both above and below the bundle. Not typically at the same time. tc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14316; 1 Feb 94 15:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14310; 1 Feb 94 15:13 EST Received: from merit.edu by CNRI.Reston.VA.US id aa16883; 1 Feb 94 15:13 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id OAA22311 for ietf-ppp-rcpt; Tue, 1 Feb 1994 14:59:53 -0500 Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.5/8.6.5) with ESMTP id OAA22308 for ; Tue, 1 Feb 1994 14:59:50 -0500 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id LAA22583 for ietf-ppp@merit.edu; Tue, 1 Feb 1994 11:50:24 -0800 Date: Tue, 1 Feb 1994 11:50:24 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402011950.LAA22583@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: Does anybody object to the following statement? "The working group agrees that Fred Baker should be directed to submit the CCP draft as it stands for IESG consideration. The interactions between compression and mutilink will be specified in the multilink draft. The present sense of the working group is that for those systems wishing to implement compression below multilink, that a secondary protocol ID for CCP be employed, but otherwise the identical protocol be run."   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16815; 1 Feb 94 16:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16811; 1 Feb 94 16:26 EST Received: from merit.edu by CNRI.Reston.VA.US id aa19535; 1 Feb 94 16:26 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id QAA27100 for ietf-ppp-rcpt; Tue, 1 Feb 1994 16:07:07 -0500 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA27097 for ; Tue, 1 Feb 1994 16:07:05 -0500 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #2) id m0pRSJ0-000CBBC; Tue, 1 Feb 94 13:06 PST Message-Id: Date: Tue, 1 Feb 94 13:06 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Scott Wasson , karl@morningstar.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Lloyd Subject: Re: CCP: rough consensus and running code Cc: ietf-ppp@merit.edu At 11:47 2/1/94 -0500, Scott Wasson wrote: >What does it mean when different links of the same bundle negotiate different >compression protocols, some on the link and some on the bundle?? It means that you will be running different compression protocols over the different links and yet another protocol over the bundle. You would have complete control over what compression gets used where. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17327; 1 Feb 94 16:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17321; 1 Feb 94 16:53 EST Received: from merit.edu by CNRI.Reston.VA.US id aa20196; 1 Feb 94 16:53 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id QAA29196 for ietf-ppp-rcpt; Tue, 1 Feb 1994 16:39:46 -0500 Received: from xap.xyplex.com (xap.xyplex.com [140.179.50.201]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA29192 for ; Tue, 1 Feb 1994 16:39:44 -0500 Received: from sgw.xyplex.com by xap.xyplex.com id ; Tue, 1 Feb 94 16:37:53 -0500 Received: by eng.xyplex.com (4.1/SMI-4.1) id AA12073; Tue, 1 Feb 94 16:35:01 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Wasson Message-Id: <9402012135.AA12073@eng.xyplex.com> Subject: Re: CCP: rough consensus and running code To: Brian Lloyd Date: Tue, 1 Feb 94 16:35:01 EST Cc: karl@morningstar.com, ietf-ppp@merit.edu In-Reply-To: ; from "Brian Lloyd" at Feb 1, 94 1:06 pm X-Mailer: ELM [version 2.3 PL8] According to Brian Lloyd: > > At 11:47 2/1/94 -0500, Scott Wasson wrote: > >What does it mean when different links of the same bundle negotiate different > >compression protocols, some on the link and some on the bundle?? > > It means that you will be running different compression protocols over the > different links and yet another protocol over the bundle. You would have > complete control over what compression gets used where. > That means the packet data to be sent over compressed links may be compressed twice -- first for the bundle and again for the link. We all know that to be at best useless, at worst the packet actually grows in size. How is this feature useful? +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18502; 1 Feb 94 17:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18498; 1 Feb 94 17:53 EST Received: from merit.edu by CNRI.Reston.VA.US id aa22667; 1 Feb 94 17:53 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id RAA03261 for ietf-ppp-rcpt; Tue, 1 Feb 1994 17:30:32 -0500 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA03215 for ; Tue, 1 Feb 1994 17:30:25 -0500 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #2) id m0pRTbs-000CBCC; Tue, 1 Feb 94 14:30 PST Message-Id: Date: Tue, 1 Feb 94 14:30 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Keith Sklower , ietf-ppp@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Lloyd Subject: Re: Does anybody object to the following statement? At 11:50 2/1/94 -0800, Keith Sklower wrote: >"The working group agrees that Fred Baker should be directed to submit >the CCP draft as it stands for IESG consideration. > >The interactions between compression and mutilink will be specified >in the multilink draft. The present sense of the working group is >that for those systems wishing to implement compression below multilink, >that a secondary protocol ID for CCP be employed, but otherwise the >identical protocol be run." I beg to differ. I believe that this needs to be specified in the CCP document, not in the multilink document since there are no interactions between multilink and CCP if there are two compression protocol IDs. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18581; 1 Feb 94 17:58 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18576; 1 Feb 94 17:58 EST Received: from merit.edu by CNRI.Reston.VA.US id aa22732; 1 Feb 94 17:58 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id RAA03439 for ietf-ppp-rcpt; Tue, 1 Feb 1994 17:30:48 -0500 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA03409 for ; Tue, 1 Feb 1994 17:30:43 -0500 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #2) id m0pRTbn-000CBAC; Tue, 1 Feb 94 14:30 PST Message-Id: Date: Tue, 1 Feb 94 14:30 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Scott Wasson , Brian Lloyd Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Lloyd Subject: Re: CCP: rough consensus and running code Cc: karl@morningstar.com, ietf-ppp@merit.edu At 16:35 2/1/94 -0500, Scott Wasson wrote: >That means the packet data to be sent over compressed links may be compressed >twice -- first for the bundle and again for the link. We all know that to >be at best useless, at worst the packet actually grows in size. How is this >feature useful? It is useful if you want to interoperate with someone who does link layer compression on one port and someone who does per-bundle compression on another port, especially if you don't want to run two different versions of code. I agree that it doesn't make sense to do both at the same time. I doubt that our implementation will ever do per-link compression but you never know what a customer might want. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19634; 1 Feb 94 19:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19630; 1 Feb 94 19:51 EST Received: from merit.edu by CNRI.Reston.VA.US id aa24681; 1 Feb 94 19:51 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id TAA11706 for ietf-ppp-rcpt; Tue, 1 Feb 1994 19:28:43 -0500 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA11703 for ; Tue, 1 Feb 1994 19:28:41 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA19940; Tue, 1 Feb 94 16:29:31 -0800 Message-Id: <9402020029.AA19940@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 01 Feb 94 16:29:30 PST X-Msmail-Message-Id: F9683CD4 X-Msmail-Parent-Message-Id: 9C55CDB7 X-Msmail-Conversation-Id: 18928FA5 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Tue, 1 Feb 94 16:26:29 TZ Subject: RE: Predictor/U.S. Patent 5,229,768 | For all you Predictor/Puddle Jumper fans, you may want to get a copy | of U.S. Patent 5,229,768, granted July 20, 1993. The patent description | could make the draft text redundant (of course the patent is written | in legaleze). I second that. I encourage any implementor to obtain the patent in question before shipping any Predictor/Puddle Jumper code. Of course, I have no opinion on the matter, except that you should look at the patent if you intend to use Predictor/Puddle Jumper code. Boy, I wonder if Dave Carr is currently doing a compression patent search? Either way, thanks for the pointer Dave. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19702; 1 Feb 94 19:58 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19695; 1 Feb 94 19:58 EST Received: from merit.edu by CNRI.Reston.VA.US id aa24827; 1 Feb 94 19:58 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id TAA11555 for ietf-ppp-rcpt; Tue, 1 Feb 1994 19:22:50 -0500 Received: from xap.xyplex.com (xap.xyplex.com [140.179.50.201]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA11549 for ; Tue, 1 Feb 1994 19:22:47 -0500 Received: from sgw.xyplex.com by xap.xyplex.com id ; Tue, 1 Feb 94 19:20:59 -0500 Received: by eng.xyplex.com (4.1/SMI-4.1) id AA13660; Tue, 1 Feb 94 19:18:04 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Wasson Message-Id: <9402020018.AA13660@eng.xyplex.com> Subject: Re: CCP: rough consensus and running code To: Brian Lloyd Date: Tue, 1 Feb 94 19:18:04 EST Cc: brian@lloyd.com, karl@morningstar.com, ietf-ppp@merit.edu In-Reply-To: ; from "Brian Lloyd" at Feb 1, 94 2:30 pm X-Mailer: ELM [version 2.3 PL8] According to Brian Lloyd: > > At 16:35 2/1/94 -0500, Scott Wasson wrote: > >That means the packet data to be sent over compressed links may be compressed > >twice -- first for the bundle and again for the link. We all know that to > >be at best useless, at worst the packet actually grows in size. How is this > >feature useful? > > It is useful if you want to interoperate with someone(***)who does link layer > compression on one port and someone(***)who does per-bundle compression on > another port, especially if you don't want to run two different versions of But both these someone's are the same someone. Links can only be bundled if they connect to the same partner. To have what you describe, the administrator would have to comfigure compression "on" for one link, "off" for another, and "on" for the bundle (with double-compression (!) on the compressed links) on both sides. I don't see any value in doing this. I like the idea of running compression over a bundle, just like your model for running the NCP's. It is elegant in its simplicity. For the purpose of expediting both the compression document and multilink (with respect to each other), I propose that compression negotiation should "float" transparently above the multilink, just like all NCP negotiation. IMHO, if we spec anything more complicated than that, then we'll all be old and grey before any two implementations fully interoperate. Before I start dodging flames on this issue, I'd like to raise one more question/point to everyone: does anyone honestly have a great need for a multilink that supports links of vastly differing speed? Say, T1 bundled with 56Kb? Here's the math: 1.544Mb + 56Kb = 1.60Mb. Whoopie. The aggregate rate of the multilink is at best approx. 4% faster than the T1 by itself. I can't get excited. If nobody can get too excited about such an aggregate improvement, then can we define all problems that crop up with such a setup as non-problems? Specifically, I'm referring to two issues: the desire to do compression on a vastly slower link within a bundle, and Tom C.'s issue of receiver overrun. These issues are greatly mitigated when dealing with links of "similar" performance. I'll leave the exact definition of "similar" to implementation experience, but intuitively it seems to me that we can tighten our scope and design a multilink that fits compression above multilink. This places compression negotiation level with all NCP negotiation. Everything is done the same way, with less probability for individual creativity (read: bugs). +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20177; 1 Feb 94 20:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20173; 1 Feb 94 20:51 EST Received: from merit.edu by CNRI.Reston.VA.US id aa26022; 1 Feb 94 20:51 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id SAA07618 for ietf-ppp-rcpt; Tue, 1 Feb 1994 18:36:56 -0500 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA07615 for ; Tue, 1 Feb 1994 18:36:55 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA28923; Tue, 1 Feb 94 15:36:50 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA17866; Tue, 1 Feb 94 16:31:41 -0700 Date: Tue, 1 Feb 94 16:31:41 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402012331.AA17866@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CCP: rough consensus and running code > From: sgw@sgw.xyplex.com (Scott Wasson) > ... > That means the packet data to be sent over compressed links may be compressed > twice -- first for the bundle and again for the link. We all know that to > be at best useless, at worst the packet actually grows in size. How is this > feature useful? I, for one, do not know it to be useless to have two compression algorithms at work at once. While one would hope and expect that running the same compression algorithm twice is at best useless, it is not necessary to use the same compression algorithm at both levels. For example, given typical UNIX binaries for traffic, running LZW or Predictor on the individual links and run-length on the entire bundle will do better than either run-length alone or LZW or Predictor alone. This is because both Predictor and LZW need significant text to get trained for repeated bytes such as zeros. Another case might be running Predictor (which is quite fast if somewhat memory intensive) on the bundle and something that requires many CPU cycles on the modem links in a bundle and nothing on the B-channels. I currently use yet another, not entirely related case. I have found that running "BSD Compress" on a pair of fast v.42bis modems is better than using only v.42bis. I see round trip delays for the ICMP echo requests of `ping` of about 162 ms over a pair of DSI 9624LE+'s. Turning on BSD-Compress in the hosts reduces the round trip time to 150 ms with occassional dips to 133 ms. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20522; 1 Feb 94 21:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20518; 1 Feb 94 21:28 EST Received: from merit.edu by CNRI.Reston.VA.US id aa26652; 1 Feb 94 21:28 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id VAA16835 for ietf-ppp-rcpt; Tue, 1 Feb 1994 21:02:06 -0500 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.5/8.6.5) with SMTP id VAA16830 for ; Tue, 1 Feb 1994 21:02:04 -0500 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #2) id m0pRWud-000CBAC; Tue, 1 Feb 94 18:01 PST Message-Id: Date: Tue, 1 Feb 94 18:01 PST X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Scott Wasson Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Lloyd Subject: Re: CCP: rough consensus and running code Cc: ietf-ppp@merit.edu >According to Brian Lloyd: >> >> At 16:35 2/1/94 -0500, Scott Wasson wrote: >> >That means the packet data to be sent over compressed links may be >>compressed >> >twice -- first for the bundle and again for the link. We all know that to >> >be at best useless, at worst the packet actually grows in size. How is this >> >feature useful? >> >> It is useful if you want to interoperate with someone(***)who does link layer >> compression on one port and someone(***)who does per-bundle compression on >> another port, especially if you don't want to run two different versions of > >But both these someone's are the same someone. Links can only be bundled if >they connect to the same partner. To have what you describe, the administrator >would have to comfigure compression "on" for one link, "off" for another, >and "on" for the bundle (with double-compression (!) on the compressed links) >on both sides. I don't see any value in doing this. I agree with you, but that is an implementation issue. Make sure that, in your implementation, you don't do this not-very-clever thing. I am not sure that changing a protocol is the right answer. Besides, someone may come up with complementary compressions schemes, you never know. ;^) >I like the idea of running compression over a bundle, just like your model >for running the NCP's. It is elegant in its simplicity. For the purpose >of expediting both the compression document and multilink (with respect to >each other), I propose that compression negotiation should "float" >transparently above the multilink, just like all NCP negotiation. IMHO, >if we spec anything more complicated than that, then we'll all be old and >grey before any two implementations fully interoperate. What you ask for is how I envision it working. There is a CCP option for "compression over the logical link." When you send that you negotiate compression "up there." It doesn't matter if the packet is encapsulated in a multilink header or if it is sent "in the clear." Keith Sklower suggested an elegent mechanism of using multilink to encapsulate the negotiation thus eliminating any confusion. However, in my mind a conflict occurs when you want to do link encryption. In this instance you have only one link up so all packets are going "in the clear." There is possible ambiguity on the part of the receiver when it receives the compression negotiation. Should the receiver interpret the request as meaning "compress over the virtual link" or "compress over the physical link?" Having two different protocol IDs removes all the ambiguity. So just because you CAN negotiate compression above and below the multilink, that doesn't mean you should. >Before I start dodging flames on this issue, I'd like to raise one more >question/point to everyone: does anyone honestly have a great need for a >multilink that supports links of vastly differing speed? Say, T1 bundled >with 56Kb? Here's the math: > >1.544Mb + 56Kb = 1.60Mb. > >Whoopie. The aggregate rate of the multilink is at best approx. 4% faster >than the T1 by itself. I can't get excited. > >If nobody can get too excited about such an aggregate improvement, then can >we define all problems that crop up with such a setup as non-problems? Yes! >Specifically, I'm referring to two issues: the desire to do compression on >a vastly slower link within a bundle, and Tom C.'s issue of receiver overrun. >These issues are greatly mitigated when dealing with links of "similar" >performance. I'll leave the exact definition of "similar" to >implementation experience, but intuitively it seems to me that we can >tighten our scope and design a multilink that fits compression above multilink. >This places compression negotiation level with all NCP negotiation. Everything >is done the same way, with less probability for individual creativity (read: >bugs). For you the answer is simple: when the peer offers you the "below multilink" compression option, just REJect it. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20920; 1 Feb 94 22:21 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20916; 1 Feb 94 22:21 EST Received: from merit.edu by CNRI.Reston.VA.US id aa27347; 1 Feb 94 22:21 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id VAA19285 for ietf-ppp-rcpt; Tue, 1 Feb 1994 21:56:29 -0500 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id VAA19282 for ; Tue, 1 Feb 1994 21:56:28 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA05361; Tue, 1 Feb 94 18:56:21 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA19490; Tue, 1 Feb 94 19:55:47 -0700 Date: Tue, 1 Feb 94 19:55:47 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402020255.AA19490@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CCP: rough consensus and running code > From: sgw@sgw.xyplex.com (Scott Wasson) > ... > But both these someone's are the same someone. Links can only be bundled if >they connect to the same partner. To have what you describe, the administrator > would have to comfigure compression "on" for one link, "off" for another, > and "on" for the bundle (with double-compression (!) on the compressed links) > on both sides. I don't see any value in doing this. > > I like the idea of running compression over a bundle, just like your model > for running the NCP's. It is elegant in its simplicity. For the purpose > of expediting both the compression document and multilink (with respect to > each other), I propose that compression negotiation should "float" > transparently above the multilink, just like all NCP negotiation. IMHO, > if we spec anything more complicated than that, then we'll all be old and > grey before any two implementations fully interoperate. It wouldn't take rocket science for a router-box to automatically, by default, with no manual configuration, negotiate no compression on links faster than T1 and patented-super-duper 100 cycles/Byte for speeds below 38.4. While I agree most of us will compress above multi-link, I'm confident there will be implementations that want to compress below multi-link, independently on each link. The cleanest way to support either one also cleanly supports doing both at once. "Layering" is not always babble from those who don't know the difference between an octet and a bit. I see no reason why any manual configuration would be need. Those that support either above- or below-multi-link will do the normal, entirly automatic CCP negotiating. Those that support both will be automatic as well. An advantage of the dual CCP protocol ID scheme is that if you don't want to implement it, then you don't do anything, and cannot possibly fail to interoperate. You'll simply respond with a protocol-reject. > Before I start dodging flames on this issue, I'd like to raise one more > question/point to everyone: does anyone honestly have a great need for a > multilink that supports links of vastly differing speed? Say, T1 bundled > with 56Kb? Here's the math: > > 1.544Mb + 56Kb = 1.60Mb. > > Whoopie. The aggregate rate of the multilink is at best approx. 4% faster > than the T1 by itself. I can't get excited. What about a router box that has a leased T1 and a couple of modems or an ISDNN interface, purely for redundancy? It seems to me that the cleanest way to such backups on a system that already has multi-link code is to use that multilink code. > If nobody can get too excited about such an aggregate improvement, then can > we define all problems that crop up with such a setup as non-problems? > Specifically, I'm referring to two issues: the desire to do compression on > a vastly slower link within a bundle, and Tom C.'s issue of receiver overrun. > These issues are greatly mitigated when dealing with links of "similar" > performance. I'll leave the exact definition of "similar" to > implementation experience, but intuitively it seems to me that we can >tighten our scope and design a multilink that fits compression above multilink. >This places compression negotiation level with all NCP negotiation. Everything > is done the same way, with less probability for individual creativity (read: > bugs). Differing link speeds do not make the receiver overrun significantly worse. It is so bad that it cannot get any worse. Compute the worst case with a pair of T1 circuits, one by satallite and one by ground, using an MRU of 1500 and minimum packet size of 10 (e.g. Telnet). Now think what an MMRU of 8192 implies. I continue to argue that the compelling reason to do compression below the bundle is not low speed but high speed, where you have no choice except put the compression hardware in your DMA engine. All of the schemes proposed to handle compression are straight forward. The implemenation problems with multilink as it is now defined have nothing to do with negotiating compression. Instead, worry about identifying bundles (how do you know what LCP and multilink parameters to use on an incoming link before you have exchanged authentication configure requests?). Instead, worry about your buffer management system, which can no longer be as simple as it could with a single stream (I'm told some common code uses one single 1500 byte PPP input buffer). Worry about your fragment assembly algorithm. Worry about your fragment timers. As for "tightening the scope (of multi-link)", if the dual protocol-ID solution (or kludge) is chosen, then the multi-link document need not mention the issue. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25087; 1 Feb 94 23:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25083; 1 Feb 94 23:36 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28433; 1 Feb 94 23:36 EST Received: from merit.edu by IETF.CNRI.Reston.VA.US id aa25078; 1 Feb 94 23:36 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id XAA23270 for ietf-ppp-rcpt; Tue, 1 Feb 1994 23:14:16 -0500 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id XAA23267 for ; Tue, 1 Feb 1994 23:14:14 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA25321; Tue, 1 Feb 94 20:15:03 -0800 Message-Id: <9402020415.AA25321@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 01 Feb 94 20:15:03 PST X-Msmail-Message-Id: 02BE74D3 X-Msmail-Conversation-Id: 02BE74D3 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Tue, 1 Feb 94 20:12:06 TZ Subject: Re: CCP: rough consensus and running code | From: Vernon Schryver | | I currently use yet another, not entirely related case. I have found | that running "BSD Compress" on a pair of fast v.42bis modems is better | than using only v.42bis. I see round trip delays for the ICMP echo | requests of `ping` of about 162 ms over a pair of DSI 9624LE+'s. | Turning on BSD-Compress in the hosts reduces the round trip time to | 150 ms with occassional dips to 133 ms. The compression algorithm we use does better than V.42bis too! But we get even better times when we turn off V.42bis but keep V.42 (error control). V.42bis also escapes out into "uncompressable" mode when it detects that it is expanding the data so I'm not sure what your proving here - just that BSD compresses better than V.42bis (which is not at all surprising). Like I said, turn off compression and keep on error control and you'll get slightly better times (at least for the modems we tested). This simply proves that compression over compression (in the case of V.42bis) is NOT a good idea (i.e. it's better to just go over error control). But the point is moot. Others have reasons for compressing on the link (the most common case is probably because the hardware does the compression), others for compressing above the link. Someone is bound to come up with a reason for doing both. Stupid configurations are allowed in order to simplify common configuration scenarios. I believe that this is the case, so I think we should allow it even though I find it difficult to imagine why anyone would want to configure both. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12070; 2 Feb 94 14:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12066; 2 Feb 94 14:22 EST Received: from merit.edu by CNRI.Reston.VA.US id aa11441; 2 Feb 94 14:22 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id NAA12210 for ietf-ppp-rcpt; Wed, 2 Feb 1994 13:45:12 -0500 Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA12200 for ; Wed, 2 Feb 1994 13:45:07 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA22958; Wed, 2 Feb 94 09:09:14 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA11119; Wed, 2 Feb 94 09:04:20 CST Date: Wed, 2 Feb 94 09:04:20 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9402021504.AA11119@anubis.network.com> To: ietf-ppp@merit.edu Subject: Re: CCP: rough consensus and running code Someone asked if anyone actually has need for Multi-link with links with very different speeds. The answer is yes. We frequently have customers with T1+Lower speed links which they would like to use together. Frequently, the lower speed one exists as backup. However, in the custoemrs mind, not using it the rest of the time is wasting resources. Therefore, they prefer product which supports such multi-links. There are more complex cases which arise in which the reasons exist in more than just the customers mind. Joel M. Halpern jmh@network.com Network Systems Corporation PS Not having discussed the compression question with customers, I do not know where this fits relative to the second half of the question, is it relevant to compression.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12197; 2 Feb 94 14:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12193; 2 Feb 94 14:31 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11655; 2 Feb 94 14:31 EST Received: from merit.edu by IETF.CNRI.Reston.VA.US id aa12188; 2 Feb 94 14:30 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id NAA12169 for ietf-ppp-rcpt; Wed, 2 Feb 1994 13:44:41 -0500 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA12166 for ; Wed, 2 Feb 1994 13:44:38 -0500 Received: from opal.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA21940; Wed, 2 Feb 94 10:43:45 PST Date: Wed, 2 Feb 94 10:43:44 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Art Berggreen Message-Id: <9402021843.AA21940@fennel.acc.com> To: sgw@sgw.xyplex.com Subject: Re: CCP: rough consensus and running code Cc: ietf-ppp@merit.edu > >Before I start dodging flames on this issue, I'd like to raise one more >question/point to everyone: does anyone honestly have a great need for a >multilink that supports links of vastly differing speed? Say, T1 bundled >with 56Kb? Here's the math: > >1.544Mb + 56Kb = 1.60Mb. > >Whoopie. The aggregate rate of the multilink is at best approx. 4% faster >than the T1 by itself. I can't get excited. The closest I can come, is a reliability rather than bandwidth situation. We have a customer who has a 56K link paired with a fractional T1 link. For network topology reasons (e.g. STP), it is desireable to have both links appear as a single virtual p-p link. Since the customer is paying for the bandwidth, they want to use it. Today, we would recommend that the user configure the backup link using dial-backup rather than paying for a nailed-up link, but some customer may not want the dial latency. Art   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13239; 2 Feb 94 14:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13235; 2 Feb 94 14:59 EST Received: from merit.edu by CNRI.Reston.VA.US id aa12493; 2 Feb 94 14:59 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id OAA15101 for ietf-ppp-rcpt; Wed, 2 Feb 1994 14:20:08 -0500 Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA15023 for ; Wed, 2 Feb 1994 14:19:51 -0500 Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA01681; Wed, 2 Feb 94 11:19:06 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9402021619.AA01681@hobbit.gandalf.ca> Subject: RE: Predictor/U.S. Patent 5,229,768 (fwd) To: ietf-ppp Date: Wed, 2 Feb 1994 10:14:52 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 652 > Boy, I wonder if Dave Carr is currently doing a compression patent search? I subscribe to an electronic update patent list, that gets issued monthly. I routinely get all new patents related to compression. This one happened to be on the list. For those interested in receiving the list of patents send mail to srctran@world.std.com. It's sent by Gregory Aharonian. I have one compression patent filed, and am working on another. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16144; 2 Feb 94 16:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16136; 2 Feb 94 16:48 EST Received: from merit.edu by CNRI.Reston.VA.US id aa15673; 2 Feb 94 16:48 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id QAA23856 for ietf-ppp-rcpt; Wed, 2 Feb 1994 16:11:28 -0500 Received: from gateway.ameritech.com (gateway.ameritech.com [192.111.51.17]) by merit.edu (8.6.5/8.6.5) with ESMTP id QAA23853 for ; Wed, 2 Feb 1994 16:11:23 -0500 Received: from nast0.bdy.wi.ameritech.com ([144.148.16.1]) by gateway.ameritech.com (8.6.4/8.6.4) with SMTP id OAA15738 for ; Wed, 2 Feb 1994 14:59:52 -0600 Received: from hopper by nast0.bdy.wi.ameritech.com with SMTP (5.65/25-eef) id AA01277; Wed, 2 Feb 94 15:06:11 -0600 Message-Id: <9402022106.AA01277@nast0.bdy.wi.ameritech.com> Date: 1 Feb 1994 15:59:53 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Loehndorf Subject: Multi-Link PPP WG To: Multi-link PPP Subject: Time:3:57 PM OFFICE MEMO Multi-Link PPP WG Date:2/1/94 Could you please add my name to you mail list? Thank you!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07700; 3 Feb 94 10:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07696; 3 Feb 94 10:48 EST Received: from merit.edu by CNRI.Reston.VA.US id aa09976; 3 Feb 94 10:48 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id KAA02823 for ietf-ppp-rcpt; Thu, 3 Feb 1994 10:17:37 -0500 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA02818 for ; Thu, 3 Feb 1994 10:17:34 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <04970-0@survis.surfnet.nl>; Thu, 3 Feb 1994 16:17:09 +0100 To: ietf-ppp@merit.edu Subject: question with regard to PPP over ISDN Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Thu, 03 Feb 1994 16:17:08 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Victor Reijs Message-ID: <"survis.sur.979:03.01.94.15.17.11"@surfnet.nl> Hello all of you, I just want to ask a question with regard to PPP over ISDN. I am not on the list, so I hope you would like to send me personal mail! I am looking for software that implements PPP over ISDN for PC's and MAc's. I have the following concept with regard to the PC implementation: > ODI/NDIS/packetdriver like interface > /_ > | > PPP software > /_ > | > CAPI (2.0) interface (coming out end february week) > /_ > | > ISDN card > /_ > | > S0 EuroISDN > So yo can see, I am European;-). I defined the two software interfaces (CAPI and NDIS/ODI/etc.), because you want to be independant of proprietary software/hardware. I wonder if the above concept is oke? Furthermore I would like to know if te CAPI software interface is a right choose for a PC? I also heard about the PCI. What about that? Is there some wisdom for choosing, other than which is now available? Furthermore, if there are implementations for PPP over ISDN for the Mac, please let me know (to be used for MACTCP/IP). Hope to hear from you. All the best, victor   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12177; 3 Feb 94 13:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12173; 3 Feb 94 13:10 EST Received: from merit.edu by CNRI.Reston.VA.US id aa14180; 3 Feb 94 13:10 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id MAA14794 for ietf-ppp-rcpt; Thu, 3 Feb 1994 12:54:45 -0500 Received: from spock.retix.com (spock.retix.com [163.182.4.1]) by merit.edu (8.6.5/8.6.5) with ESMTP id MAA14789 for ; Thu, 3 Feb 1994 12:54:36 -0500 Received: from ss10.retix.com (ss10.retix.com [163.182.4.213]) by spock.retix.com (8.6.4/8.6.4) with SMTP id JAA11401 for ; Thu, 3 Feb 1994 09:54:23 -0800 Received: by ss10.retix.com (4.1/smail2.5/9-30-90) id AA16558; Thu, 3 Feb 94 09:54:22 PST Date: Thu, 3 Feb 94 09:54:22 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew John Macdonald Fawcett Message-Id: <9402031754.AA16558@ss10.retix.com> To: ietf-ppp@merit.edu Subject: Remove Please remove my name from this mailing list. Thanks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17797; 7 Feb 94 13:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17793; 7 Feb 94 13:27 EST Received: from merit.edu by CNRI.Reston.VA.US id aa22151; 7 Feb 94 13:27 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id NAA21344 for ietf-ppp-rcpt; Mon, 7 Feb 1994 13:00:42 -0500 Received: from pm002-01.dialip.mich.net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA21296 for ; Mon, 7 Feb 1994 13:00:36 -0500 Date: Mon, 7 Feb 94 17:48:17 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-ID: <1950.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: sequence size > From: brian@lloyd.com (Brian Lloyd) > >Yes we should negotiate the sequence number, if some want it to be 32 > >bits, since I was happy with the old 12 bit sequence number. However, this > >is NOT a solution to the stuck skew problem. > > The number we came up with is 20-bits. Everybody seems to be happy with that. > Reading the list backwards (I simply don't have time for 1.2 Meg of email on one list in two weeks), I don't see any rationale for _not_ negotiating sequence size. 32-bits or 20-bits or even 12-bits is far more than _I_ need, and interferes with compression. Put me down as objecting. (joining Corradetti and Carr?) I want negotiation! Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26163; 7 Feb 94 17:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26159; 7 Feb 94 17:50 EST Received: from merit.edu by CNRI.Reston.VA.US id aa27945; 7 Feb 94 17:50 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id RAA13024 for ietf-ppp-rcpt; Mon, 7 Feb 1994 17:34:56 -0500 Received: from netmail.microsoft.com (netmail.microsoft.com [131.107.1.3]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA13017 for ; Mon, 7 Feb 1994 17:34:53 -0500 Received: by netmail.microsoft.com (5.65/25-eef) id AA28902; Mon, 7 Feb 94 14:32:49 -0800 Message-Id: <9402072232.AA28902@netmail.microsoft.com> Received: by netmail using fxenixd 1.0 Mon, 07 Feb 94 14:32:49 PST X-Msmail-Message-Id: FD6403EC X-Msmail-Conversation-Id: FD6403EC Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Mon, 7 Feb 94 13:47:14 TZ Subject: RE: sequence size | From: "William Allen Simpson" | To: | > From: brian@lloyd.com (Brian Lloyd) | > >Yes we should negotiate the sequence number, if some want it to be 32 | > >bits, since I was happy with the old 12 bit sequence number. However, this | > >is NOT a solution to the stuck skew problem. | > | > The number we came up with is 20-bits. Everybody seems to be happy with that. | > | Reading the list backwards (I simply don't have time for 1.2 Meg of | email on one list in two weeks), I don't see any rationale for _not_ | negotiating sequence size. 32-bits or 20-bits or even 12-bits is far | more than _I_ need, and interferes with compression. | | Put me down as objecting. (joining Corradetti and Carr?) | | I want negotiation! I am objecting as well. But I am being a real oaf by objecting to both negotiation and the 20 bit sequence number. Negotiation requires extra CP code and some extra multilink code to extract 12, 20, or even 32 bit sequence number (and then interop testing, and a way to change the parameters). I vote for fixing the sequence to 12 or 20 bits. I prefer 12, but I won't complain too much about 20. If the majority wants 20, I'll go along with that. Perhaps we should take a vote? That's my 2 bits. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01365; 8 Feb 94 6:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01361; 8 Feb 94 6:38 EST Received: from merit.edu by CNRI.Reston.VA.US id aa02581; 8 Feb 94 6:38 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id DAA22124 for ietf-ppp-rcpt; Tue, 8 Feb 1994 03:46:43 -0500 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.5/8.6.5) with SMTP id DAA22121 for ; Tue, 8 Feb 1994 03:46:40 -0500 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <27899-0@relay1.pipex.net>; Tue, 8 Feb 1994 08:46:16 +0000 Received: by widow.spider.co.uk; Tue, 8 Feb 94 08:54:56 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerry Meyer Date: Tue, 8 Feb 94 08:46:53 GMT Message-Id: <22311.9402080846@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Tue, 8 Feb 94 08:46:53 GMT To: ietf-ppp@merit.edu Subject: RE: sequence size >I am objecting as well. But I am being a real oaf by objecting to both >negotiation and the 20 bit sequence number. Negotiation requires >extra CP code and some extra multilink code to extract 12, 20, or >even 32 bit sequence number (and then interop testing, and a way to >change the parameters). I vote for fixing the sequence to 12 or 20 bits. >I prefer 12, but I won't complain too much about 20. If the majority >wants 20, I'll go along with that. Perhaps we should take a vote? >That's my 2 bits. --Thomas 12 bits default and implementations may (or may not) negotiate.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14785; 9 Feb 94 14:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14781; 9 Feb 94 14:29 EST Received: from merit.edu by CNRI.Reston.VA.US id aa15088; 9 Feb 94 14:28 EST Received: from localhost (daemon@localhost) by merit.edu (8.6.5/8.6.5) id OAA03873 for ietf-ppp-rcpt; Wed, 9 Feb 1994 14:06:31 -0500 Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA03870 for ; Wed, 9 Feb 1994 14:06:22 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA18258; Wed, 9 Feb 94 13:09:15 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA06364; Wed, 9 Feb 94 13:04:12 CST Date: Wed, 9 Feb 94 13:04:12 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9402091904.AA06364@anubis.network.com> To: ietf-ppp@merit.edu Subject: Frame Relay After the November IETF, and Fred Baker's analysis of the resulting "agreements", I have tried to find a common ground where we can all agree on the required behavior. Below is a draft rfc, which I have sent to the secreteriat, which proposes a new LCP option to negotiate the behavior of the PPP entities with regard to the encapsulation of data over Frame Relay. It is intended to allow entities to exist without supporting the PPP encapsulation, while still making PPP encapsulation of data the default, so as to reduce the incidence of certain failure modes which were considered important. It is certainly possible that this document does not capture all of the goals/needs of the community, so please comment. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation ---------------------------------------------------------------------------- Network Working Group Joel M. Halpern Internet Draft Network Systems Corporation Expires in six months February 1994 PPP Option for Data Encapsulation Selection draft-ietf-pppext-dataencap-00.txt Status of this Memo This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. 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.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating the encapsulation to be used for the transfer of data by PPP. It applies only to media for which there exists a "native" data encapsulation outside of PPP. Joel M. Halpern expires in six months [Page i] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 Table of Contents 1. Introduction .......................................... 1 2. The Data Encapsulation Option ......................... 2 2.1 Usage ........................................... 2 3. Configuration Option Format ........................... 3 4. Loss of State ...................................... 4 SECURITY CONSIDERATIONS ................................... 5 REFERENCES ................................................ 5 ACKNOWLEDGEMENTS ............................................. 5 CHAIR'S ADDRESS .............................................. 6 AUTHOR'S ADDRESS ............................................. 6 Joel M. Halpern expires in six months [Page ii] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 1. Introduction As defined by the base RFCs [1], PPP is a set of state machines (semantics) and encapsulations (syntax). The use of this combination results in the robust and reliable negotiation of options and transmission of data over Point-to-Point links. In recent years, several wide area technologies with multi-point characteristics have developed. For each of these, data encapsulation syntax and operational semantics have been developed within the IETF ([2], [3], [4], [5]). The syntax used in each case was developed to meet a range of requirements. As work with these technologies has advanced, the desire for parameter negotiation, and additional capabilities, has become clear. Rather than redeveloping competing approaches, the use of the power of the PPP state machine and negotiation mechanism was sought. Simultaneously, the group developing the PPP specifications has tried to make the full power of PPP available on these new technologies. The first step in doing this was to define how to carry PPP negotiation frames over these technologies. A series of drafts have been written to address this. As these were discussed, it became clear that there was a further issue. Once one has a way to carry PPP negotiation frames, one could also carry PPP data frames using PPP syntax. The question then becomes one of inter-operation. It is clearly desirable, in the abstract, that stations use uniform encapsulation when practical. The first step towards resolving this was taken in the PPP drafts for the individual media. These documents state that even after the PPP LCP has entered the open state, data can be exchanged using the media "native" encapsulation for any protocol whose NCP has not been negotiated. This document proposes an LCP option which, when negotiated, allows appropriate data to be transferred in the media native encapsulation after the protocol NCP has been negotiated. Joel M. Halpern expires in six months [Page 1] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 2. The Data Encapsulation Option There exist several media for which there is an native data encapsulation, distinct from the PPP encapsulation, and over which there is a desire to use PPP. The goal of this is to provide two capabilities, full PPP operation and pure parameter negotiation. In starting to meeting these goals, the documents on PPP over the individual media state that after a PPP NCP is negotiated, the data transfer will take place using the PPP data encapsulation for that NCP. This gives strong operation of the PPP NCP and data transfer mechanisms over media which have underlying data encapsulations. In order to meet the goal of pure parameter negotiation, an indication is needed that the reduced behavior is desired. This option fills that role. When negotiated, this option indicates that even after an NCP is negotiated to the open state, the native data encapsulation will be used for that protocol. This option is incompatible with NCP options which affect the data transfer semantics. If this option is used, certain NCP options will be prohibited. For example, if the LCP Native-Data-Encapsulation option is negotiated, one may not use NCP options for header compression or Bridge LAN ID. 2.1. Usage As with all LCP options, use of this option is at the discretion of the end-station. For compatibility, it is important to note that while a station may not force another station to use an option, it may refuse to open the connection without it. Thus, a station desiring to use only the native data encapsulations may refuse to complete LCP negotiation unless the remote side accepts the LCP Native-Data-Encapsulation option. Alternatively, such a station may open the LCP, but refuse to perform any NCP negotiations, so as to prevent the usage of any data encapsulations other than the native. Joel M. Halpern expires in six months [Page 2] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 3. Configuration Option Format Description The LCP Native-Data-Encapsulation Configuration Option negotiates the use of the media native data encapsulation for NCP data, rather than the PPP encapsulation. If the LCP and NCP are opened without this option, the PPP encapsulation is used for any protocol whose NCP is open. A summary of the Native-Data-Encapsulation Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (14) Length = 2 Joel M. Halpern expires in six months [Page 3] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 4. Loss of State It should be understood that use of this option leaves the system open to a loss of shared state. If the two sides have negotiated a set of LCP and NCP options, this represents shared state between the two. If the two sides have agreed to use the LCP Native-Data- Encapsulation option, then they will be exchanging nata using the media specific encapsulation. If the "remote" unit is then transparently reset or replaced, it could choose to send data without initiating any LCP (or NCP) negotiation. Since it would use the same data format, communication would appear to be taking place properly, when in fact the shared state does not exist. This problem affects LCP shared state even in the absence of the LCP Native-Data-Encapsulation, since the native encapsulation is used for any protocols for which no NCP has been negotiated. The use of the LCP Native-Data-Encapsulation option causes the problem to apply to shared LCP state as well. This would include such attributes as authentication, IP address assignment, Multi-Link operation, ... Joel M. Halpern expires in six months [Page 4] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 Security Considerations As outlined in the section on Loss of State, the use of the LCP Native-Data-Encapsulation option leaves the systems open to certain undetected restart or replacement scenarios. In particular, the strength of the identity associated with any initial authentication protocol is weakened, since there is the possibility of replacement of the remote system transparently. Said replacement includes redirection of the underlying communications technology. References [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in progress. [2] RFC 1294 - Multi-Protocol over Frame Relay [3] RFC 1209 - Multi-Protocol over SMDS [4] RFC 1356 - Multi-Protocol over X.25 [5] RFC 1483 - Multi-Protocol over ATM Acknowledgments Joel M. Halpern expires in six months [Page 5] RFC DRAFT PPP Option for Data Encapsulation Selection February 1994 Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Author's Address Questions about this memo can also be directed to: Joel M. Halpern Network Systems Corporation 7600 Boone Avenue North Brooklyn Park, MN 55428 +1 612 424-1606 EMail: jmh@network.com Joel M. Halpern expires in six months [Page 6]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03477; 10 Feb 94 8:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03473; 10 Feb 94 8:53 EST Received: from merit.edu by CNRI.Reston.VA.US id aa05667; 10 Feb 94 8:53 EST Received: from worldlink.worldlink.com (worldlink.com [38.8.1.2]) by merit.edu (8.6.5/8.6.5) with SMTP id IAA12077 for ; Thu, 10 Feb 1994 08:39:54 -0500 Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA24882; Thu, 10 Feb 94 08:38:15 -0500 Date: Thu, 10 Feb 94 08:38:15 -0500 Message-Id: <9402101338.AA24882@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Piscitello (Core Competence) To: Joel Halpern Cc: ietf-ppp@merit.edu Subject: Re: Frame Relay Hi, some comments. A nice compromise, ISO would be proud (only kidding, ISO would have introduced classes of PPP, say 5..., and would have recommended several combinations for conformance:-) Ahem...back to business. Shouldn't the abstract mention that this is applies to frame relay, etc.? > In order to meet the goal of pure parameter negotiation, an > indication is needed that the reduced behavior is desired. ^ ^ data encapsulation | | upon completion of parameter negotiation (the words may not be perfect, but I'm trying to find a more precise way to say this). > This option is incompatible with NCP options which affect the data > transfer semantics. If this option is used, certain NCP options will > be prohibited. For example, if the LCP Native-Data-Encapsulation > option is negotiated, one may not use. I think you mean to say that this option cannot be used in conjunction with certain NCP options (i.e., if this LCP option is used, you may not use NCP options for header compression or Bridge LAN ID). If I have this right, could you state more clearly? If I've got it wrong, can you explain? > Encapsulation option, then they will be exchanging nata using the nata = data > This problem affects LCP shared state even in the absence of the > LCP Native-Data-Encapsulation, since the native encapsulation is ^ Configuration Option > used for any protocols for which no NCP has been negotiated. The > use of the LCP Native-Data-Encapsulation option causes the problem > to apply to shared LCP state as well. This would include such > attributes as authentication, IP address assignment, Multi-Link > operation, ... I can't determine from this wording whether you're referring to a problem inherent in the use of PPP LCP negotiation or one inherent to using native encapsulation, please clarify? Also, complete the last sentence, if only with an "etc.".   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06120; 10 Feb 94 11:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06116; 10 Feb 94 11:04 EST Received: from merit.edu by CNRI.Reston.VA.US id aa09134; 10 Feb 94 11:04 EST Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA20600 for ; Thu, 10 Feb 1994 10:35:35 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA25067; Thu, 10 Feb 94 09:39:03 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA15231; Thu, 10 Feb 94 09:34:02 CST Date: Thu, 10 Feb 94 09:34:02 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9402101534.AA15231@anubis.network.com> To: wk04464@worldlink.com Subject: Re: Frame Relay Cc: ietf-ppp@merit.edu [In response to Dave Piscitello's comments:] Thank you for the wording correction suggestions. Clarity is one of the important goals. With regard to incompatibility, what I am trying to say is indeed that the native data encapsulation can not be used in conjunction with certain NCP options. I will add words to clarify this. The problem (undetected loss of state) is an interaction between the PPP LCP/NCP and the use of native data encapsulation. When native encapsulation is used, either because the NCP has not been negotiated, or because the Native-Data-Encapsulation option was negotiated, there is the possibility for invisible loss of state. If this is not clear from the text, suggestions for wording clarification would be helpful. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06295; 10 Feb 94 11:11 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09332; 10 Feb 94 11:10 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06200; 10 Feb 94 11:10 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05797; 10 Feb 94 10:52 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ppp@ucdavis.edu Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-dataencap-00.txt Date: Thu, 10 Feb 94 10:52:08 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9402101052.aa05797@IETF.CNRI.Reston.VA.US> --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 Option for Data Encapsulation Selection Author(s) : J. Halpern Filename : draft-ietf-pppext-dataencap-00.txt Pages : 6 Date : 02/09/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating the encapsulation to be used for the transfer of data by PPP. It applies only to media for which there exists a "native" data encapsulation outside of PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-dataencap-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: venera.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-dataencap-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940209140910.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-dataencap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-dataencap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940209140910.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08056; 12 Feb 94 20:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08052; 12 Feb 94 20:48 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15477; 12 Feb 94 20:48 EST Received: from merit.edu by IETF.CNRI.Reston.VA.US id aa08046; 12 Feb 94 20:48 EST Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.5/8.6.5) with ESMTP id UAA23550 for ; Sat, 12 Feb 1994 20:34:40 -0500 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id RAA15994 for ietf-ppp@merit.edu; Sat, 12 Feb 1994 17:34:21 -0800 Date: Sat, 12 Feb 1994 17:34:21 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402130134.RAA15994@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: Yet Another Multilink Draft Here is an attempt to incorporate some sweeping architectural revisions proposed by Brian Lloyd & Glenn McGregor. This draft waffles on some unresolved issues. I was encouraged by Fred Baker and Vern Schryver to put something in writing so that when these issues are discussed specific text can be cited & changed or added. The unresolved issues include: 1.) Whether the sequence space should be fixed at 20 bits or negotiated. 2.) Whether a packet loss detection algorithm should be mandated or a choice left up to the implementation, or if there should be an option for saying the receiver wants the sender to obey the increasing packet rule. 3.) Whether there should be a "Maximum Outstanding Frames" parameter negotiated. Dave Carr persuaded me that this was not necessary for correct operation over LAPB, and my own personal view for the best effort case is that even if you know what the receiver is doing in the way of buffering, slippage between links may be out of your control. Maybe a simple "show of hands" around the mailing list can decide this. I'm calling this draft -06.5 so that when the inevitable comments come in, I can file a draft -07. Network Working Group Keith Sklower INTERNET DRAFT University of California, Berkeley Expires: August 12, 1994 Brian Lloyd Glenn McGregor Lloyd Internetworking Dave Carr Gandalf Data Limited The PPP Multilink Protocol (MP) draft-ietf-pppext-multilink-06.5.txt Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. 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.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories to learn the current status of any Internet Draft. Abstract This document proposes a method for splitting and recombining datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two system, including async links. This is accomplished by means of new PPP [2] options and protocols. This draft reflects major architectural revisions by Brian Lloyd & Glen McGregor of Lloyd Internetworking. Draft PPP Multilink February 1994 Acknowledgements The authors specifically wish to thank Fred Baker of ACC, Craig Fox of Network Systems, Gerry Meyer of Spider Systems, Tom Coradetti of Digiboard, Dan Brennan of Penril Datability Networks and the members of the IP over Large Public Data Networks and PPP Extensions working groups, for much useful discussion on the subject. Table of Contents 1. Introduction ................................................ 2 1.1. Motivation ................................................ 2 1.2. Functional Description .................................... 3 1.3. Conventions ............................................... 4 2. General Overview ............................................ 4 3. Packet Formats .............................................. 6 4. Trading Buffer Space Against Fragment Loss .................. 8 4.1. The increasing sequence number per link technique ......... 8 4.2. Timer based reassembly .................................... 9 4.3. Buffer Space Requirements ................................. 10 5. PPP Link Control Protocol Extensions ........................ 10 5.1. Configuration Option Types ................................ 10 5.1.1. Maximum Receive Reconstructed Unit ...................... 11 6. Closing Member links ........................................ 11 7. Interaction with Other Protocols ............................ 11 8. Security Considerations ..................................... 12 9. References .................................................. 12 10. Authors' Addresses ......................................... 13 11. Expiration Date of this Draft .............................. 14 1. Introduction 1.1. Motivation Basic Rate and Primary Rate ISDN both offer the possibility of opening multiple simultaneous channels between systems, giving users additional bandwidth on demand (for additional cost). Previous proposals for the transmission of internet protocols over ISDN have stated as a goal the ability to make use of this capability, (e.g. Leifer et al. [1]). There are proposals being advanced for providing synchronization between multiple streams at the bit level (the BONDING proposals); such features are not as yet widely deployed, and may require additional hardware for end system. Thus, it may be useful to have a purely software solution, or at least an interim measure. Sklower, Lloyd, McGregor & Carr [Page 2] Draft PPP Multilink February 1994 There are other instances where bandwidth on demand can be exploited, such as using a dialup async line at 28,800 baud to back up a leased synchronous line, or opening additional X.25 SVCs where the window size is limited to two by international agreement. The simplest possible algorithms of alternating packets between channels on a space available basis (which might be called the Bank Teller's algorithm) may have undesirable side effects due to reordering of packets. By means of a three-byte sequencing header, and simple synchronization rules, one can split packets among parallel virtual circuits between systems in such a way that packets do not become reordered, or at least the likelihood of this is greatly reduced. 1.2. Functional Description The method discussed here is similar to the multilink protocol described in ISO 7776, but offers the additional ability to split and recombine packets, thereby reducing latency, and potentially increase the effect maximum receive unit (MRU). Furthermore, there is no requirement here for acknowledged-mode operation on the link layer, although that is optionally permitted. Multilink is based on an LCP option negotiation that permits a system to indicate to its peer that it is capable of combining multiple physical links into a ``bundle''. Only one multilink ``bundle'' may exist between peer systems. Multilink is negotiated during the initial LCP option negotiation. A system indicates to its peer that it is willing to do multilink by sending the multilink option as part of the initial LCP option negotiation. This negotiation indicates three things: 1. The system offering the option is capable of combining multiple physical links into one logical link; 2. The system is capable of receiving upper layer protocol data units (PDU) fragmented using the multilink header (described later) and reassembling the fragments back into the original PDU for processing; 3. The system is capable of receiving PDUs of size N octets where N is specified as part of the option even if N is larger than the maximum receive unit (MRU) for a single physical link. Once multilink has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the Sklower, Lloyd, McGregor & Carr [Page 3] Draft PPP Multilink February 1994 multilink header. 1.3. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 2. General Overview In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an Authentication phase in which the authentication protocols can be used to determine identifiers associated with each system connected by the link. The goal of multilink operation is to ``bundle'' multiple independent links between a fixed pair of systems, providing a virtual link with greater bandwith than any of the constituent members. It is sufficient to use the pair of identifiers of the systems provided by PPP Authentication, in addition to the magic numbers negotiated as the means of naming the aggregate link. (These can be different physical links, as in multiple async lines, but may also be instances of multiplexed links, such as ISDN, X.25 or Frame Relay. The links may also be of different kinds, such as paring dialup async links with leased synchronous links). We suggest that multilink operation can be modeled as a virtual PPP link-layer entity wherein packets received over different physical link-layer entities are identified as belonging to a separate PPP network protocol (the Multilink Protocol, or MP) and recombined and sequenced according to information present in a multilink fragmentation header. All packets received over links identified as belong to the multilink arrangment are presented to the same network- layer protocol processing machine, whether they have multilink headers or not. The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP where the following Sklower, Lloyd, McGregor & Carr [Page 4] Draft PPP Multilink February 1994 options would have been manually configured: o No async control character Map o No Magic Number o No Link Quality Monitoring o Address and Control Field Compression Of course, individual links are permitted to have different settings for these options. LCP negotiations are not permitted on the bundle itself. An implementation MUST NOT transmit LCP packets via the multilink procedure, and an implementation receiving them MUST silently discard them. (By ``silently discard'' we mean to not generate any PPP packets in response; an implementation is free to generate a log entry registering the reception of the unexpected packet). The effective MRU for the logical-link entity is negotiated via an LCP option. It is irrelevant whether Network Control Protocol packets are encapsulated in multilink headers or not, or even over which link they are sent, once that link identifies itself as belonging to a multilink arrangement. Note that network protocols that are not sent using multilink headers cannot be sequenced. (And thus may be delivered in any convenient way). For example, consider the case in Figure 1. Link 1 has negotiated network layers NL 1, NL 2, and MP between two systems. The two systems then negotiate MP over Link 2. Frames received on link 1 are demultiplexed at the data link layer according the PPP network protocol identifier and can be sent to NL 1, NL 2, or MP. Link 2 will accept frames with all network protocol identifiers that Link 1 does. Frames received by MP are further demultiplexed at the network layer according to the PPP network protocol identifier and sent to NL 1 or NL 2. Any frames received by MP for any other network layer protocols are rejected using the normal protocol reject mechanism. Sklower, Lloyd, McGregor & Carr [Page 5] Draft PPP Multilink February 1994 Figure 1. Multilink Overview. Network Layer ------------- ______ ______ / \ / \ | NL 1 | | NL 2 | \______/ \______/ | | | | | | | | +-------------o-o-o-+ | +------+ +-----+ | | | | | | | | | | +------o--o-------+ + | | | |__|_ | | | | / \ | | | | MLCP| <--- Link Layer | | \______/ Demultiplexing | | | | | | | | | | | | | <--- Virtual Link | | | | | | | | | | | | | | | | | + | | ___|_| | ___|_| / \ | / \ | LCP |------+-----| LCP | <--- Link Layer \______/ \______/ Demultiplexing | | | | Link 1 Link 2 3. Packet Formats In this section we describe the layout of individual fragments, which are the ``packets'' in the Multilink Protocol. Network Protocol packets are first encapsulated (but not framed) according to normal PPP procedures, and large packets are broken up into multiple segments sized appropriately for the multiple physical links. A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header is inserted before each section. (Thus the first fragment of a multilink packet in PPP will have two headers, one for the fragment, followed by the header for the packet itself). Sklower, Lloyd, McGregor & Carr [Page 6] Draft PPP Multilink February 1994 Systems implementing the multilink procedure are not required to fragment small packets. There is also no requirement that the segments be of equal sizes. or that packets must be broken up at all. A possible strategy for contending with member links of differing transmission rates would be to divide the packets in to segments porportion to the transmission rates). Another strategy might be two divide them into rather many equal fragements and distribute the number proportional to speed. PPP multilink fragments are encapsulated using the protocol identifier 0x00-0x3d. Following the protocol identfier is a three byte header containing a sequence number, and two one bit fields indicating that fragment begins a packet or terminates a packet. Address & Control and Protocol ID compression are assumed to be in effect. Individual fragments will, therefore, have the following format (unless the transmitter wishes to omit a low order byte of protocol header for the purposes of causing a packet to have even total length): Figure 2: Fragment Format. +---------------+---------------+ PPP Header: | Address 0xff | Control 0x03 | +---------------+---------------+ | PID(H) 0x00 | PID(L) 0x3d | +-+-+-+-+-------+---------------+ MP Header: |B|E|0|0| sequence number | +-+-+-+-+-------+---------------+ | seq # low bits| | +---------------+---------------+ | fragment data | | . | | . | | . | +---------------+---------------+ PPP FCS: | FCS | +---------------+---------------+ The sequence field is a 20 bit number that is incremented for every fragment transmitted. The (B)eginning fragment bit is a one bit field set to 1 on the first fragment derived from a PPP packet and set to 0 for all other fragments from the same PPP packet. The (E)nding fragment bit is a one bit field set to 1 on the last fragment and set to 0 for all other fragments. A fragment may have Sklower, Lloyd, McGregor & Carr [Page 7] Draft PPP Multilink February 1994 both the (B)eginning and (E)nding fragment bits set to 1. The reserved field is 2 bits long and is not currently defined. It must be set to 0. In this multilink protocol, a separate and single reassembly structure is associated with each pair of authenticated entities. The multilink headers are interpreted in the context of this structure. It is permissible for a fragment to have both the (B)eginning and (E)ending fragment bits set. The FCS field shown in the diagram is inherited from the normal framing mechanism from the member link on which the packet is transmitted. There is no separate FCS applied to the reconstituted packet as a whole if transmitted in more than one fragment. 4. Trading Buffer Space Against Fragment Loss In a multilink procedure one channel may be delayed with respect to the other channels in the bundle. This can lead to fragments being received out of order, thus increasing the difficulty in detecting the loss of a fragment. The task of estimating the amount of space required for buffering on the receiver becomes more complex because of this. In this section we discuss techniques for declaring that a fragment is lost, with the intent of minimizing the buffer space required, yet minimizing the number of avoidable packet losses. 4.1. The increasing sequence number per link technique This strategy requires that the sender transmit fragments with increasing sequence numbers. That is, each multilink frame has a higher sequence number than the previous frame. (Clearly, this applies even when an implementation begins to transmits frames of a new PPP packet and frames in which both the (B)eginning and (E)nding bits are set.) The receiver keeps track of the incoming sequence numbers on each link a a bundle and maintains the current minimum of the most recently received sequence number over all the member links in the bundle (call this M). The receiver detects the end of a packet when it receives a fragment bearing the (E)nding bit. Reassembly of the packet is complete if all sequence numbers up to that fragment have been received. A lost fragment is detected when M advances past the sequence number of a fragment bearing an (E)nding bit of a packet which has not been completely reassembled (i.e., not all the sequence numbers between the fragment bearing the (B)eginning bit and the fragment bearing the Sklower, Lloyd, McGregor & Carr [Page 8] Draft PPP Multilink February 1994 (E)nding bit have been received). This is because of the increasing sequence number rule over the bundle. The detection of a lost fragment causes the receiver to discard all fragments up to M. If the fragment with sequence number M has the (B)eginning bit set then the receiver starts reassembling the new packet, otherwise the receiver resynchronizes on the next fragment bearing the (B)eginning bit. All fragments received while the receiver is attempting to resynchronize not bearing the (B)eginning bit SHOULD be discarded. Senders SHOULD avoid keeping any member links idle to maximize early detection of lost fragments by the receiver, since the value of M is not incremented on idle links. Senders SHOULD rotate traffic among the member links if there isn't sufficient traffic to overflow the capacity of one link to avoid idle links. Loss of the final fragment of a transmission can cause the receiver to stall until new packets arrive. The likelihood of this may be decreased by sending a null fragment over each member link in the bundle to increase M on the receiver and, hopefully, cause detection of the lost fragment. Otherwise the receiver SHOULD implement some type of link idle timer To prevent this case. This technique would prohibit the migrating of fragments queued up behind a failing link to a working one, a practice which is not unusual for implementations of ISO multilink over LAPB. Of course, receivers willing to receive out of order fragements must also be prepared to deal with duplicate packets. 4.2. Timer based reassembly For implementations wishing to migrate packets, an alternative technique employs the use of a reassembly timer. The timer is started under the following conditions: 1. a fragment is received and the timer was stopped; 2. the timer was stopped and there are fragments awaiting reassembly. The timer is stopped whenever a PDU is fully reassembled. If the timer expires before the PDU is reassembled, the receiver should begin to reassemble the next PDU by searching through and discarding the received fragments sequentially until it finds another fragment with the (B)egin bit set. The proper reassembly timer interval is very dependent upon the characteristics of the links Sklower, Lloyd, McGregor & Carr [Page 9] Draft PPP Multilink February 1994 involved. The interval should be adjusted to accommodate the speed and latency variations expected on the link. 4.3. Buffer Space Requirements There is no amount of buffering that will guarantee correct detection of fragment loss, in the face of deliberate attack. When all channels are transmitting, you can show that there is a minimum amount required for operation under the usual case of all member channels active. The ammount depends on the relative delay between the channels, (D[channel-i,channel-j]), the data rate of each channel, R[c], the maximum fragment size permitted on each channel, F[c], and the maximum permissible reassembled size, P. When using PPP, the delay between channels may be estimated by using LCP echo request and echo reply packets. (In the more complex case of combining links of different transmission rates, these packets should either be padded to maximum MTU on that link, or the round trip times should be adjusted to take this into account.) The slippage for each channel is defined as the bandwidth times the delay for that channel relative to the channel with the longest delay, S[c] = R[c] * D[c,c-worst]. Given these conditions, buffer space of P + (F[1] + ... F[N]) S[1] + S[2] + ... + S[N] should be sufficient to ensure that an incomplete packet has not been erroneously discarded before its final fragment arrives. (S[c-worst] will be zero, of course!) 5. PPP Link Control Protocol Extensions If reliable multilink operation is desired, PPP Reliable Transmission[11] (essentially the use of ISO LAPB[6]) MUST BE negotiated prior to the use of the Multilink Protocol on each member link. Whether or not reliable delivery is employed over member links, an implementation MUST present a signal to the clients of the multilink procedure that a loss has occurred. Compression may be used separately on each member link, or run over the bundle (as a logical group link). The use of a multiple compression streams under the bundle (i.e. on each link separately) is indicate by running the Compression Control Protocol[10] but with an alternative PPP protocol ID (to be assigned by IANA). 5.1. Configuration Option Types The Multilink Protocol introduces the use of an additional LCP Configuration Options. This permits the negotiation of the following Sklower, Lloyd, McGregor & Carr [Page 10] Draft PPP Multilink February 1994 item: o Maximum Received Reconstructed Unit 5.1.1. Maximum Receive Reconstructed Unit Figure 3: Maximum Receive Reconstructed Unit Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBA | length = 4 | Maximum-Receive-Rebuilt-Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option advises the peer that the implementation will be able to reconstruct a datagram consisting of the specified number of bytes. The default value is 8192 bytes. Note: this option corresponds to what would have been the MRU of the bundle when conceptualized as a PPP-like entity. 6. Closing Member links Member links may be terminated according to normal PPP LCP procedures using LCP terminate-request and terminate-ack packets. on that member link. Since it is assumed that member links usually do not reorder packets, receipt of a terminate ack is sufficient to assume that any multilink protocol packets ahead of it are at no special risk of loss. Receipt of an LCP terminate-request on one link does not conclude the procedure on the remaining links. So long as any member links in the bundle are active, the PPP state for the bundle persists as a separate entity. If the multilink procedure is used in conjunction with PPP reliable transmission, and a member link is not closed gracefully, the implementation should expect to receive packets which violate the increasing sequence number rule. 7. Interaction with Other Protocols In the common case, LCP, and the Authentication Control Protocol would be negotiated over each member link. The Network Protocols themselves and associated control exchanges would normally have been Sklower, Lloyd, McGregor & Carr [Page 11] Draft PPP Multilink February 1994 conducted once, on the bundle. In some instances it may be desirable for some Network Protocols to be exempted from sequencing requirements, and if the MRU sizes of the link did not cause fragmentation, those protocols could be sent directly over the member links. Although explicitly forbidden above, if there were several member links between two implementations and independent sequencing of two protocol sets was desired, but blocking of one by the other was not, one could describe two multilink procedures by assigning two authentication names to the same systems. Each member link, however, would only belong to one bundle. You could think of one physical router as housing two logically separate implementations each of which is independently configured. A simpler alternative may be to have one link refuse to join the bundle by config-reject'ing the Mutilink LCP option(s). 8. Security Considerations Operation of this protocol is no more and no less secure than operation of the PPP authentication protocols[3]. The reader is directed there for further discussion. 9. References [1] Leifer, D., Sheldon, S., and Gorsline B., ``A Subnetwork Control Protocol for ISDN Circuit-Switching'' IPLPDN Working Group, Committee Document, March 1991 (leifer@terminator.cc.umich.edu). [2] Simpson, W., ``The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links'', Network Working Group, RFC-1331, May 1992. [3] Lloyd, B., Simpson, W., ``PPP Authentication Protocols'', Networking Working Group, RFC-1334 [4] Bradley, T., Brown, C., and Malis, A., ``Multiprotocol Interconnect over Frame Relay'', Network Working Group, RFC-1490, January 1992. [5] Malis, A., Robinson, D., Ullman R., ``Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode'', Network Working Group, RFC-1356, August 1992. [6] Internation Organisation for Standardization, ``HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Sklower, Lloyd, McGregor & Carr [Page 12] Draft PPP Multilink February 1994 Procedures'', Internation Standard 7776, 1988 [7] Simpson, W., ``PPP over Frame Relay'', PPP Extensions Working Group, work in progress. [8] Simpson, W., ``PPP over X.25'', PPP Extensions Working Group, work in progress. [9] Sklower, K., ``Parameter Negotiation for the Multiprotocol Interconnect'', IP over Large Public Data Networks Working Group, work in progress. [10] Rand, D. ``The PPP Compression Control Protocol (CCP)'', PPP Extensions Working Group, work in progress. [11] Rand. D. ``PPP Reliable Transmission'', PPP Extensions Working Group, work in progress. 10. Authors' Addresses Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-9587 E-mail: sklower@cs.Berkeley.EDU Brian Lloyd Glenn McGregor Lloyd Internetworking 3031 Alhambra Drive Cameron Park, CA 95682 Phone: (916) 676-1147 Email: brian@lloyd.com glenn@lloyd.com Dave Carr Gandalf Data Limited 130 Colonnade Rd. S. Nepean, Ontario, Canada, K2E 7M4 Phone: (613) 723-6500 E-mail: dcarr@gandalf.ca Sklower, Lloyd, McGregor & Carr [Page 13] Draft PPP Multilink February 1994 11. Expiration Date of this Draft August 12th, 1994 Sklower, Lloyd, McGregor & Carr [Page 14]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23238; 13 Feb 94 22:07 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23234; 13 Feb 94 22:07 EST Received: from merit.edu by CNRI.Reston.VA.US id aa03735; 13 Feb 94 22:07 EST Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.5/8.6.5) with SMTP id VAA06583 for ; Sun, 13 Feb 1994 21:36:17 -0500 Received: from SMTP_Gateway_PC.Shiva.COM ([140.248.128.25]) by Shiva.COM (1.34b) Sun, 13 Feb 94 21:36:11 EST Received: from cc:Mail by SMTP-Gateway-PC (1.30/SMTPLink) id A11109; Sun, 13 Feb 94 21:43:58 EDT Date: Sun, 13 Feb 94 21:43:58 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Russ Gocht Message-Id: <9402132143.A11109@SMTP-Gateway-PC> To: ietf-ppp@merit.edu Subject: NBFCP Draft The following is an attached File item from cc:Mail. It contains eight bit information which had to be encoded to insure successful trans- mission through various mail systems. To decode the file use the UUDECODE program. --------------------------------- Cut Here --------------------------------- begin 644 NBFCP04.TXT MT,\1X*&Q&N$`````````````````````.P`#`/[_"0`&```````````````! M````/```````````$```3P````$```#^____`````#T```#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________]2`&\`;P!T`"``10!N`'0`<@!Y```````````` M````````````````````````````````````````````````%@`%`/______ M____`P`````)`@``````P````````$8```````````````"&S^82LKRX`04` M``"``P````````$`0P!O`&T`<`!/`&(`:@`````````````````````````` M```````````````````````````````````````2``(!________________ M`````````````````````````````````````````````````````&(````` M````5P!O`'(`9`!$`&\`8P!U`&T`90!N`'0````````````````````````` M`````````````````````````````!H``@'_____!````/____\````````` M```````````````````````````````````````'````%YH```````!/`&(` M:@!E`&,`=`!0`&\`;P!L```````````````````````````````````````` M````````````````````%@`!`0$````"````_____P`````````````````` M````````AB9@^+"\N`&&)F#XL+RX`0````````````````(```#]_____O__ M__[____^____!````/[___\(````"0````H````+````-`````T````.```` M#P```!`````1````$@```!,````4````%0```!8````7````&````!D````: M````&P```!P````=````'@```!\````@````(0```"(````C````)````"4` M```F````)P```"@````I````*@```"L````L````+0```"X````O````,``` M`#$````R````,P```&$````U````-@````P````X````.0```#H````[```` M!@```/__________/P```$````!!````0@```$,```!$````10```$8```!' M````2````$D```!*````2P```$P```!-````-P```/__________________ M____________________________________________________________ M______________________]B````8P```&0```!E````9@```&<```!H```` M/@```/______________________________________________________ M____________________________________________________________ M________!0!3`'4`;0!M`&$`<@!Y`$D`;@!F`&\`<@!M`&$`=`!I`&\`;@`` M`````````````````````````````````"@``@#_______________\````` M```````````````````````````````````````````"````_`(````````` M```````````````````````````````````````````````````````````` M`````````````````````````````/_______________P`````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````________________```````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````#_______________\````````````````````````````````` M```````````````````````````````!````_O___P,````$````!0````8` M```'````"`````D````*````"P````P````-````_O__________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________________VAT```` M````````````````````0````(8W0^NPO+@!```````````````````````` M````````0```````````````````````````````````````````````0``` M`(9G70FRO+@!`````````````````````````````````P`````````````` M`````````````````````````````````P`````````````````````````` M````````````````````0`````#J5OH````````````````````````````` M````````'@```!,```!-:6-R;W-O9G0@5V]R9"`V+C```````````````P`` M````````````````````````````````````````````'@````(````S```` M`````````````````````````````````P`````````````````````````` M````````````````````T,\1X/__________________________________ M____________________________________________________________ M____________________________________________________________ M________________`0#^_P,*``#_____``D"``````#`````````1AP```!- M:6-R;W-O9G0@5V]R9"`V+C`@1&]C=6UE;G0`"@```$U35V]R9$1O8P`0```` M5V]R9"Y$;V-U;65N="XV```````[``,`_O\)``8```````````````$````! M``````#^_P```PH````````````````````````!````X(6?\OE/:!"KD0@` M*R>SV3````#,`@``#0````<```"8`````@```-P````(````0`$```P```!D M`0``"P```(@!```-````K`$```\```#0`0``$````/0!```*````&`(``!(` M```\`@``#@```&`"```)````A`(``!,```"H`@`````````````````````` M`````````````````````````````````!X````H````0SI<35-/1D9)0T5< M5TE.5T]21%Q414U03$%415Q.3U)-04PN1$]4```````````````````````` M````'@```$D```!.971W;W)K(%=O"AL1KA`````````````````````#L``P#^_PD`!@`````` M`````````0```````````````!````,````!````_O___P`````!````____ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_]RE90`MP`D$```D`&4````````````````#``!0:P``%YH````````````` M``````````#G9P`````````````````````````````````````````````` ME```:@````"4``!J````:I0```````!JE````````&J4````````:I0````` M``!JE```%````)*5````````A)4```X```"2E0```````)*5````````DI4` M``````"2E0``"@```)R5``!V````DI4````````:F0``0P```!*6```````` M$I8````````2E@```````!*6````````$I8````````2E@```````!*6```` M````$I8````````+EP```@````V7````````#9<````````-EP``)@```#.7 M``#(````^Y<``,@```##F```'@```%V9``!4````L9D``&8```#AF```.0`` M``````````````````````!JE````````!*6```````````V`#<``0`3`!*6 M````````$I8`````````````````````````````$I8````````2E@`````` M`.&8````````$I8```````!JE````````&J4````````$I8````````````` M````````````````$I8````````2E@```````!*6````````$I8````````2 ME@```````&J4````````$I8```````!JE````````!*6````````"Y<````` M````````````````````````?I0``&(```#@E```I````&J4````````:I0` M``````!JE````````&J4````````$I8````````+EP```````!*6``#Y```` M$I8````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````T-3F5T=V]R:R!7;W)K:6YG($=R;W5P("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@(%0@2B!$:6UI=')I#4EN=&5R;F5T($1R M869T("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@($UI8W)O'!I"!M;VYT:',@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@($9E8G)U87)Y(#$Y.3,- M/&1R869T+6EE=&8M<'!P97AT+6YE=&)I;W,M9F-P+3`T+G1X=#X-#2`@("`@ M("`@("`@(%1H92!04%`@3F5T0DE/4R!&`T@("!M;VYT:',N("!);G1E2!T:6UE+B`@270@:7,@;F]T(&%P<')O<')I M871E('1O('5S92!);G1E2!);G1E'1E;G-I8FQE M($QI;FL@0V]N=')O;"!02!C86QL960@=&AE($YE=$)%54D@<')O=&]C;VP@86YD#2`@('=R96UE M;G1S#2`@(&]F('1H92!S<&5C:69I8V%T:6]N+B`@5&AEF5D+@T-("`@35535"`@("`@(%1H:7,@=V]R9"P@ M;W(@=&AE(&%D:F5C=&EV92`B'!I"!M;VYT:',@ M("`@("`@("`@("`@("`@("!;4&%G92`Q70T,1%)!1E0@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!&96)R M=6%R>2`Q.3DS#0T-,2XR+B`@5&5R;6EN;VQO9WD-#2`@(%1H:7,@9&]C=6UE M;G0@9G)E<75E;G1L>2!U2!O9B!L;V=G:6YG('1H92!E2!F&%M<&QE+`T@("`@("`@("`@("`@ M3F5T0DE/4R!P86-K971S(&9R;VT@86X@3D)&(&YE='=O&-E<'1I;VYS.@T-#0T-#41I M;6ET'!I"!M;VYT:',@ M("`@("`@("`@("`@("`@("!;4&%G92`R70T,1%)!1E0@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!&96)R M=6%R>2`Q.3DS#0T@("!&2!U=&EL:7IE(&%N>2!M;V1I9FEC871I;VYS('1O('1H92!B M87-I8R!F65R(%!R;W1O8V]L($9I96QD#0T@("`@("!%>&%C M=&QY(&]N92!.0D9#4"!P86-K970@:7,@96YC87!S=6QA=&5D(&EN('1H92!) M;F9O7!E(&AE>"`X,#,Y("A.0D8@0V]N=')O;"!02!$971E7!E2!B92!C;VUM=6YI M8V%T960L(%!04"!M=7-T(')E86-H('1H90T@("!.971W;W)K+4QA>65R(%!R M;W1O8V]L('!H87-E+"!A;F0@=&AE($Y"1B!#;VYT7!E(&AE>"`P,#,Y("A.0D8@9&%T86=R M86TI+@T-("`@4VEN8V4@3D)&(&1A=&%G&-E<'0@=VAE;B!396QF+41E9FEN:6YG+5!A M9&1I;F<@:7,@;F5G;W1I871E9"X-#0T-#0U$:6UI=')I("`@("`@("`@("`@ M("`@("`@97AP:7)E65R(&9R86UE+B`@4VEN8V4@=&AE&EB:6QI='DL(&)U="!R97%U:7-I=&4@#2`@(&-O M;7!L97AI='D@86YD(')E65R(%!R;W1O M8V]L('!H87-E(&%N9"!B;W1H('1H92!.0D8@0V]N=')O;"!07!E(&9I96QD(&%R92!S<&5C:69I960@:6X@=&AE M#2`@(&UO2!.971"24]3(&YA;65S($U54U0-("`@("`@0V]N9FEG=7)E M+5)E:F5C="!T:&4@3F%M92U02!T:&4-("`@("`@2!T:&4@;&]C86P@<&5EF5R;R!.971"24]3(&YA;65S(&)E8V%U2!T:&4@<&5EF5R;RX-("`@("`@5&AOF5R;R!R971U M2!D969A=6QT('1H92!R97-T87)T('1I;65R('1O M(#,@7!E#0T@("`@("`Q#0T@("!,96YG=&@- M#2`@("`@(#(@*R`H3G5M8F5R(&]F($YE=$))3U,@;F%M97,@*B`Q-RD-#2`@ M($YE=$))3U,M3F%M97,-#2`@("`@(%1H:7,@9W)O=7`@;V8@>F5R;R!O'1E96X@;V-T970@3F5T0DE/4RU.86UE(&9I96QD2!O;F4@;V-T970L(&]N;'D@,30@3F5T0DE/4R!N86UE M2!O9B!C;VUM;VX@7!E(&AE>"X-#2`@("`@("`@(#`P M("`@3F%M92!S=6-C97-S9G5L;'D@861D960N#2`@("`@("`@(#!$("`@1'5P M;&EC871E(&YA;64@:6X@;&]C86P@;F%M92!T86)L92X-("`@("`@("`@,$4@ M("!.86UE('1A8FQE(&9U;&PN#2`@("`@("`@(#$U("`@3F%M92!N;W0@9F]U M;F0@;W(@8V%N;F]T('-P96-I9GD@(BHB(&]R(&YU;&PN#2`@("`@("`@(#$V M("`@3F%M92!I;B!U7-T96T@7-T96TG2!O9B!T:&4@4&5E7!E("`@("`@?"`@("!,96YG=&@@("`@('P@ M("`@("`@("!0965R+6-L87-S("`@("`@("`@("`@?`T@("`K+2LM*RTK+2LM M*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*PT@("!\("`@("`@("!0965R+79E7!E M#0T@("`@("`R#0T@("!,96YG=&@-#2`@("`@(#X].`T-("`@4&5E'!I"!M;VYT:',@("`@("`@("`@ M("`@("`@("!;4&%G92`X70T,1%)!1E0@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!&96)R=6%R>2`Q.3DS M#0T-("`@("`@26YI=&EA;"!V86QU97,@87)E(&%S2!397)V M97(N#0T@("`@("`@(#(@("`@("`@("`@("`@1V5N97)I8R!04%`@3F5T0DE/ M4R!'871E=V%Y(%-E2!3 M97)V97(N#0T@("`@("`@(#4@("`@("`@("`@("`@4F5S97)V960N#0T@("`@ M("`@(#8@("`@("`@("`@("`@1V5N97)I8R!04%`@3D)&($)R:61G92X-#2`@ M("`@("`@-PD)("`@($UI8W)O2!T;R!N96=O=&EA=&4@=&AE('5S92!O9@T@ M("`@("!T:&4@375L=&EC87-T+49O2!T;R!N96=O=&EA=&4@:&]W('1O(&AA;F1L M90T@("`@("!M=6QI8V%S="!P86-K971S+B`@270@86QL;W=S('1H92!S96YD M97(@;V8@=&AE($-O;F9I9W5R92U297%U97-T#2`@("`@('1O('-T871E('1H M92!C=7)R96YT(&AA;F1L:6YG(&]F(&UU;'1I8V%S="!P86-K971S+B`@5&AE M('!E97(@8V%N#2`@("`@(')E<75E2!.04MI;F<@ M=&AE(&]P=&EO;BP@86YD(')E='5R;FEN9R!V86QI9`T@("`@("!-=6QT:6-A M'!I"!M;VYT M:',@("`@("`@("`@("`@("`@("!;4&%G92`Y70T,1%)!1E0@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!& M96)R=6%R>2`Q.3DS#0T-("`@("`@0GD@9&5F875L="P@=&AE('!E97(@:7,@ M<')E+6-O;F9I9W5R960@=&\@86X@861M:6YI"!T>7!E($9&1D8@:6X@80T@("`@("!#;VYF:6=U2!O9B!T:&4@375L=&EC87-T+49I M;'1E2`@("!\#2`@("LM*RTK+2LM*RTK+2LM*RTK#0T-("`@5'EP M90T-("`@("`@,PT-("`@3&5N9W1H#0T@("`@("`U#0T-#0T-#0T-#0T-#41I M;6ET'!I"!M;VYT:',@ M("`@("`@("`@("`@("`@(%M086=E(#$P70T,1%)!1E0@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!&96)R M=6%R>2`Q.3DS#0T-("`@375L=&EC87-T+49O&EM=6T@<&5R:6]D(&%T#2`@ M("`@('=H:6-H(&UU;'1I8V%S="!P86-K971S(&-A;B!B92!S96YT+B`@02!V M86QU92!O9B!H97@@='EP92!&1D9`@("`@(&EN9&EC871E0T-("`@("`@5&AE M(%!R:6]R:71Y(&9I96QD(&ES('1W;R!O8W1E=',@86YD(&EN9&EC871E65R($-O;F9I9W5R871I;VX@3W!T:6]N(&9O7!E("`@("`@?"`@("!, M96YG=&@@("`@('P-("`@*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM M*RTK#0T@("!4>7!E#0T@("`@("`U#0T@("!,96YG=&@-#2`@("`@(#(-#0T- M#0T-#0T-#0T-#0T-#0T-#0T-1&EM:71R:2`@("`@("`@("`@("`@("`@(&5X M<&ER97,@:6X@'1E90``WV4``.!E``#A90``XF4``.-E``#D M90``Y64``.9E``#^``'`(=@`_@```````/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV``````````````!```MYF4``.=E``#H90``Z64``.IE``#K M90``[&4``.UE``#N90``[V4``/!E``#Q90``.F8``(1F``"%9@``AF8``+-F M``"T9@``M68``/YF``!'9P``D&<``)%G``#:9P``(V@``"1H``!M:```MF@` M`/]H``!(:0``D6D``-II``#;:0``)&H``"5J``!N:@``;VH``+AJ``"Y:@`` M`FL```-K``!,:P``36L``$YK``!0:P``_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@```````/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`````````````````````````````$``"P.``\` M"``!`$L`#P``````&@``0/'_`@`:``9.;W)M86P``@````,`80D$```````` M`````````````````"(`04#R_Z$`(@`61&5F875L="!087)A9W)A<&@@1F]N M=````````````````````.=G```(`/____\(`/____\0``0A__\!```A__\" M``0A__\#```A__\$``0A__\%```A__\&``0A__\'```A__\(``0A__\)```A M__\*``0A__\+```A__\,``0@__\-```A__\.``0A__\/```A__\0``````!' M"```_1```$`9``"^(```B"8``&HO```9.```\3X``&9$``"G2P``4E(``(-9 M``!K7```:&```-)B``#G9P````!)`````0!)`````@!)`````P!)````!`!) M````!0!)````!@!)````!P!)````"`!)````"0!)````"@!)````"P!)```` M#`!)````#0!)````#@!)````#P``````,R0``.=G`````<`AV````P``:&L` M`#8```,``$$*``#3$```]A<``"(>``#B)```I"D``#DP``!6.```8#X``"Q$ M``#.1P``!4T``$!5``!O60``H5X``&Y@``"'8P``YF4``%!K```W`#@`.0`Z M`#L`/``]`#X`/P!``$$`0@!#`$0`10!&`$<`2`!)`/D`"E)U`!8R0```(```!C)````C0`````````2R0``&,D M``#F9P``YV<````(``,``````0A0:P``````",PG```````(3VL`````0P`5 M%I`!``!4:6UE'0``YAT``!(>```3'@``(1X``"(>``#^````````_@```````/X` M``````#^````````_@```````/X```````#^````````_@```````/X````` M``#^````````_@```````/X```````#^````````_@```````/X```````#^ M````````_@```````/X```````#^````````_@```````/X```````#^```` M````_@```````/X```````#^````````_@```````/X```````#^```````` M_@```````/X```````#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV``````````````!```M(AX` M`&(>``"J'@``[1X``",?```D'P``,!\``#$?``!T'P``M1\``/X?``!%(``` MBB```,H@``#+(```Z2```.H@```C(0``)"$``"4A```F(0``0B$``$,A``"% M(0``SB$``.,A``#D(0``+"(``'$B``"K(@``K"(``/,B```[(P``;R,``'`C M``!Q(P``*0``GRD``*`I M``"A*0``HBD``*,I``"D*0``_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@``````````````0``+:0I``"E*0``IBD``*D<``'M'``!\1P``?4<``'Y'``!_1P``@$<``(%'``""1P``@T<` M`(1'``"%1P``SD<``/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8``````````````$``"W.1P``&$@``!E(```:2```2$@` M`$E(``!E2```9D@``*)(``"C2```W4@``-Y(```<20``'4D``%E)``!:20`` M>DD``'M)``"I20``JDD``--)``#420```DH```-*```32@``%$H``%U*``"D M2@``[4H``#5+``!]2P``D$L``)%+``">2P``GTL``.%+```'3```"$P```E, M```C3```)$P``#-,```T3```>TP``,!,```%30``_@```````/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@``````````````0``+05- M``!,30``E$T``-=-``#]30``_DT``$5.``"-3@``Q4X``,9.```/3P``64\` M`%I/``!;3P``G$\``-5/```44```6E```(Y0``#14```%5$``%M1``",40`` MC5$``-)1```54@``.%(``#E2``!Y4@``L%(``/!2```U4P``-E,``#=3``!^ M4P``OE,``+]3```!5```150``(I4``#/5```%%4``"E5```^50``/U4``$!5 M``#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@```````/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV``````````````!```M0%4``$A5``!)50``454``%)5``!<50``754``&55 M``!F50``9U4``&A5``!I50``:E4``&M5``!L50``;54``&Y5``!O50``<%4` M`'%5``"Z50``!%8```56```&5@``(E8``"-6``!H5@``JU8``/!6```S5P`` M>%<``,!7```#6```*U@``"Q8```M6```.5@``#I8``!\6```Q5@```U9``!# M60``1%D``$59``!N60``;UD``/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@```````/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8``````````````$``"UO60``?ED``']9``#& M60``#%H``%):``":6@``WUH``!Y;```P6P``,5L``'9;``"]6P``REL``,M; M``#E6P``"5P``"Y<``!37```>%P``'E<``"!7```@EP``(I<``"+7```E5P` M`)9<``">7```GUP``*!<``"A7```HEP``.M<```U70``-ET``#==``!/70`` M4%T``%]=``!@70``IUT``.M=```:7@``&UX``&%>``"A7@``_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^````````_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@````````````` M`0``+:%>``"B7@``O%X``.!>```%7P``*E\``$]?``!07P``6%\``%E?``!A M7P``8E\``&Q?``!M7P``=5\``'9?``!W7P``>%\``'E?``!Z7P``>U\``'Q? M``!]7P``?E\``']?``"`7P``@5\``()?``"#7P``A%\``(5?``"&7P``AU\` M`(A?``")7P``BE\``--?```=8```'F```!]@```@8```(6```")@```Z8``` M.V```&Y@``#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^````````_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV``````````````!```M;F```&]@``!P8```>V```'Q@``#$8``` MW&```-U@```B80``-F$``#=A``!Y80``H&$``*%A``#F80``$&(``!%B```2 M8@``(F(``"-B``!I8@``LF(``-1B``#58@``$F,``%EC``!T8P``=6,``'9C M``!W8P``>&,``'EC``!Z8P``>V,``'QC``!]8P``?F,``']C``"`8P``@6,` M`()C``"#8P``A&,``(5C``"&8P``AV,``/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8``````````````$``"T%`%,`=0!M M`&T`80!R`'D`20!N`&8`;P!R`&T`80!T`&D`;P!N```````````````````` M````````````````*``"`/_______________P`````````````````````` M``````````````````````````(```#\`@`````````````````````````` M```````````````````````````````````````````````````````````` M````````````________________```````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``#_______________\````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````````/______ M_________P`````````````````````````````````````````````````` M``````````````$```#^____`P````0````%````!@````<````(````"0`` M``H````+````#`````T```#^____________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________:'0````````````````````` M``!`````AC=#Z["\N`$```````````````````````````````!````````` M``````````````````````````````````````!`````AD$WFKB\N`$````` M```````````````````````````#```````````````````````````````` M```````````````#```````````````````````````````````````````` M``!``````.RZ@P(````````````````````````````````````>````$P`` M`$UI8W)O`````@```#0````````````````````` M```````````````#```````````````````````````````````````````` M``#0SQ'@____________________________________________________ M____________________________________________________________ M__________________________________________________________\! M`/[_`PH``/____\`"0(``````,````````!&'````$UI8W)O````20```$YE M='=O``!N8```AV,``.9E``"4:P``C90``#<` M.``Y`#H`.P`\`#T`/@`_`$``00!"`$,`1`!%`$8`1P!(`$D`2P`=`0I2=7-S M($=O8VAT%D,Z7$-,245.5%Q-4UQ.0D9#4"Y46%0*4G5S(%``````0`$@`` M````````````````````!`"#$``````````````````````````````````` M)`-F````2$YE='=O````````!IX````````&G@````````:> M```*````$)X``'P````&G@```````)"B``!#````C)X```````",G@`````` M`(R>````````C)X```````",G@```````(R>````````C)X```````",G@`` M`````*F?```"````JY\```````"KGP```````*N?```F````T9\``,@```"9 MH```R````&&A```>````TZ(``%0````GHP``9@```'^A```1`0`````````` M``````````````"8````````C)X``````````#8`-P`!`!0`C)X```````", MG@````````````````````````````",G@```````(R>````````?Z$````` M``",G@````````"8`````````)@```````",G@`````````````````````` M``````",G@```````(R>````````C)X```````",G@```````(R>```````` M`)@```````",G@````````"8````````C)X```````"IGP`````````````` M```````````````4F```:````'R8``"N`````)@`````````F`````````"8 M`````````)@```````",G@```````*F?````````C)X``!T!``",G@`````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````````````````````#0U. M971W;W)K(%=O'0M;F5T8FEO&EM=6T@ M;V8@0T@("!O=&AE'0@;&ES=&EN9R!C;VYT86EN960@ M:6X@=&AE#2`@(&EN=&5R;F5T+61R869T2!#;VYS:61E M2`Q.3DR+@T-("`@6S-=("`@ M24)-($-O'!I"!M;VYT:',@ M("`@("`@("`@("`@("`@(%M086=E(#$S70T,1%)!1E0@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!&96)R M=6%R>2`Q.3DS#0T-0VAA:7(G2!$2!# M;VYS:61E2`Q.3DR+@T-("`@ M6S-=("`@24)-($-O'!I"!M M;VYT:',@("`@("`@("`@("`@("`@(%M086=E(#$S70T,1%)!1E0@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@ M("!&96)R=6%R>2`Q.3DS#0T-0VAA:7(G2!$'!I"!M;VYT:',@("`@("`@ M("`@("`@("`@(%M086=E(#$T70T,1%)!1E0@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@3D)&0U`@("`@("`@("`@("`@("`@("`@("!&96)R=6%R>2`Q M.3DS#0T-("`@("`@("`@("`@("`@("`@("`@("`@("`@5&%B;&4@;V8@0V]N M=&5N=',-#0T@("`@(#$N("`@("!);G1R;V1U8W1I;VX@+BXN+BXN+BXN+BXN M+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN("`@(#$-("`@("`@("`Q M+C$@("`@("`@4W!E8VEF:6-A=&EO;B!O9B!297%U:7)E;65N=',@+BXN+BXN M+BXN+BXN+BXN+BXN+B`@("`Q#2`@("`@("`@,2XR("`@("`@(%1E2`N M+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN("`@(#(-#2`@ M("`@,BX@("`@($$@4%!0($YE='=O0@``(((``"#"```P@@` M``L)``!4"0``G`D``+@)``"Y"0``_`D``$$*``#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV``````````````!```MAV,` M`-!C```:9```&V0``!QD```L9```+60``&ID``!K9```?&0``*-D``"Z9``` MX60``.)D``#^9```_V0```!E```190``$F4``$AE``!)90``864``'UE``"3 M90``L&4``+%E``#390``U&4``-5E``#690``UV4``-AE``#990``VF4``-ME M``#<90``W64``-YE``#?90``X&4``.%E``#B90``XV4``.1E``#E90``YF4` M`/X``<`AV`#^````````_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M``````````````$``"WF90``YV4``.AE``#I90``ZF4``.ME``#L90``[64` M`.YE``#O90``\&4``/%E```Z9@``A&8``(5F``"&9@``LV8``+1F``"U9@`` M_F8``$=G``"09P``D6<``-IG```C:```)&@``&UH``"V:```_V@``$AI``"1 M:0``VFD``-MI```D:@``)6H``&YJ``!O:@``N&H``+EJ```":P```VL``$QK M``!-:P``3FL``%!K``"4:P``_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8 M`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X` M`<`AV`#^``'`(=@`_@```````/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`A MV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^ M``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'` M(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@` M_@`!P"'8`/X``<`AV`#^``'`(=@`_@`!P"'8`/X``<`AV`#^``'`(=@`_@`! MP"'8`/X``<`AV`#^``'`(=@``````````````0``+0X`#P`(``$`2P`/```` M```:``!`\?\"`!H`!DYO Message-Id: <199402142112.QAA14586@merit.edu> To: ietf-ppp@merit.edu Subject: test, please ignore Hi. This is a test of the ietf-ppp@merit.edu mailing list. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12792; 14 Feb 94 16:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12788; 14 Feb 94 16:34 EST Received: from merit.edu by CNRI.Reston.VA.US id aa26553; 14 Feb 94 16:34 EST Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA14102 for ; Mon, 14 Feb 1994 16:06:14 -0500 Received: from SMTP_Gateway_PC.Shiva.COM ([140.248.128.25]) by Shiva.COM (1.34b) Mon, 14 Feb 94 16:05:45 EST Received: from cc:Mail by SMTP-Gateway-PC (1.30/SMTPLink) id A11174; Mon, 14 Feb 94 16:14:02 EDT Date: Mon, 14 Feb 94 16:14:02 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Russ Gocht Message-Id: <9402141614.A11174@SMTP-Gateway-PC> To: ietf-ppp@merit.edu Cc: brian@lloyd.com Subject: Re: NBFCP draft The following is an attached File item from cc:Mail. It contains eight bit information which had to be encoded to insure successful trans- mission through various mail systems. To decode the file use the UUDECODE program. --------------------------------- Cut Here --------------------------------- begin 644 NBFCP04.TXT M06X@871T96UP="!T;R!R97-O;'9E('1H92`B=VAA="!T;R!D;R!W:71H(`T* M=&AE($U!0R!A9&1R97-S(')E<75I`T*("`@;6]N=&AS+B`@26YT97)N970@1')A9G1S(&UA>2!B92!U<&1A=&5D M+"!R97!L86-E9"P@;W(@;V)S;VQE=&5D(&)Y#0H@("!O=&AE'1E;G-I M8FQE($QI;FL@0V]N=')O;"!02!O M9B!.971W;W)K($-O;G1R;VP@4')O=&]C;VQS(&9O'!L:6-I="!,0U`- M"B`@(&]R($Y"1D-0('!A8VME=',@8VQO'1E2!T:&4@2!E>&ES="!V M86QI9"!R96%S;VYS(&EN('!A2!W96EG:&5D(&)E9F]R92!C:&]O2`Q.3DS#0H-"@T*,2XR+B`@5&5R;6EN;VQO9WD-"@T*("`@5&AI2!O9B!L;V=G:6YG('1H92!E7-T96T@02!U7-T96US(BX-"@T*("`@8G)I9&=E("`@($%L;&]W2!F65R(%!R;W1O8V]L('!H87-E+B`@3D)&0U`- M"B`@('!A8VME=',@&-E<'1I;VYS.@T*#0H-"@T*#0H-"D1I;6ET'!I"!M;VYT:',@("`@("`@("`@ M("`@("`@("!;4&%G92`R70T*#0I$4D%&5"`@("`@("`@("`@("`@("`@("`@ M("`@("`@("!.0D9#4"`@("`@("`@("`@("`@("`@("`@($9E8G)U87)Y(#$Y M.3,-"@T*("`@1G)A;64@36]D:69I8V%T:6]N2!U=&EL:7IE(&%N>2!M;V1I9FEC871I;VYS('1O('1H92!B87-I M8R!F&%C=&QY(&]N92!.0D9#4"!P86-K970@:7,@96YC87!S=6QA=&5D(&EN('1H M92!);F9O65R(&9R86UE('=H97)E('1H92!02!$ M971E0T*("`@("`@869T97(@=7-E2!.0D8@<&%C:V5T2!O;F4@3D)&('!A8VME="!I'!I"!M;VYT:',@("`@("`@("`@("`@("`@ M("!;4&%G92`S70T*#0I$4D%&5"`@("`@("`@("`@("`@("`@("`@("`@("`@ M("!.0D9#4"`@("`@("`@("`@("`@("`@("`@($9E8G)U87)Y(#$Y.3,-"@T* M#0H@("!4:&4@;6%X:6UU;2!L96YG=&@@;V8@86X@3D)&(&1A=&%G&EM=6T@;&5N9W1H(&]F('1H92!);F9O65R(&9R86UE+B`@4VEN8V4@=&AE M2P@8G5T(')E<75I'!I"!M;VYT:',@("`@("`@("`@ M("`@("`@("!;4&%G92`T70T*#0I$4D%&5"`@("`@("`@("`@("`@("`@("`@ M("`@("`@("!.0D9#4"`@("`@("`@("`@("`@("`@("`@($9E8G)U87)Y(#$Y M.3,-"@T*#0HS+B`@3D)&0U`@0V]N9FEG=7)A=&EO;B!/<'1I;VYS#0H-"B`@ M($Y"1D-0($-O;F9I9W5R871I;VX@3W!T:6]N65R('!R;W1O8V]L('1O(&)E(&YE9V]T:6%T960N("!) M9B!A#0H@("!#;VYF:6=U2!K;F]W;B!A8V-E<'1A8FQE('9A;'5E+B`@ M5&AE(')E;6]T92!P965R(&UA>2!T:&5N('1E2!T:&4@<&5E2!F86EL:6YG M+`T*("`@("`@=&AE(&EM<&QE;65N=&%T:6]N('-H;W5L9"!T97)M:6YA=&4@ M3D)&0U`@8GD@2!D969A M=6QT('1H92!R97-T87)T('1I;65R('1O(#,@7!E#0H-"B`@("`@(#$-"@T*("`@3&5N M9W1H#0H-"B`@("`@(#(@*R`H3G5M8F5R(&]F($YE=$))3U,@;F%M97,@*B`Q M-RD-"@T*("`@3F5T0DE/4RU.86UE2`Q-"!.971"24]3(&YA;65S#0H@("`@("!C86X@8F4@861D960@<&5R($YA M;64M4')O:F5C=&EO;B!O<'1I;VXN("!)9B!M;W)E('1H86X@,30@3F5T0DE/ M4PT*("`@("`@;F%M97,@2!O9B!C;VUM;VX@2!A M9&1E9"X-"@D@,$0@("!$=7!L:6-A=&4@;F%M92!I;B!L;V-A;"!N86UE('1A M8FQE+@T*"2`P12`@($YA;64@=&%B;&4@9G5L;"X-"@D@,34@("!.86UE(&YO M="!F;W5N9"!O2`B*B(@;W(@;G5L;"X-"@D@,38@ M("!.86UE(&EN('5S92!O;B!R96UO=&4@3F5T0DE/4RX-"@D@,3D@("!.86UE M(&-O;F9L:6-T(&1E=&5C=&5D+@T*"2`S,"`@($YA;64@9&5F:6YE9"!B>2!A M;F]T:&5R(&5N=FER;VYM96YT+@T*"2`S-2`@(%)E<75I2P@:70@:7,- M"B`@("`@('-U9V=E2!T M;R!P2!O9B!T:&4@4&5E7!E("`@ M("`@?"`@("!,96YG=&@@("`@('P@("`@("`@("!0965R+6-L87-S("`@("`@ M("`@("`@?`T*("`@*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2L-"B`@('P@("`@("`@ M(%!E97(M=F5R'!I"!M;VYT:',@("`@("`@("`@("`@("`@("!;4&%G92`X70T*#0I$4D%& M5"`@("`@("`@("`@("`@("`@("`@("`@("`@("!.0D9#4"`@("`@("`@("`@ M("`@("`@("`@($9E8G)U87)Y(#$Y.3,-"@T*#0H@("`@("!);FET:6%L('9A M;'5E2!397)V M97(N#0H-"@DT("`@("`@("`@("`@($=E;F5R:6,@4%!0($QO8V%L($%C8V5S M2!T M;R!N96=O=&EA=&4@:&]W('1O(&AA;F1L90T*("`@("`@;75L:6-A2!.04MI;F<@=&AE(&]P=&EO;BP@86YD(')E M='5R;FEN9R!V86QI9`T*("`@("`@375L=&EC87-T+49I;'1E2`Q M.3DS#0H-"@T*("`@("`@0GD@9&5F875L="P@=&AE('!E97(@:7,@<')E+6-O M;F9I9W5R960@=&\@86X@861M:6YI2X@($$-"B`@ M("`@($UU;'1I8V%S="U&;W)W87)D+5!E2!A('9A;'5E('9I82!#;VYF:6=U&ES=',N("!!($UU;'1I8V%S="U&;W)W87)D+5!E M2!O;B!A;&P@;75L=&EC87-T('!A8VME=',@9F]R=V%R M9&5D(%-(3U5,1`T*("`@("`@"!M;VYT:',@ M("`@("`@("`@("`@("`@(%M086=E(#$P70T*#0I$4D%&5"`@("`@("`@("`@ M("`@("`@("`@("`@("`@("!.0D9#4"`@("`@("`@("`@("`@("`@("`@($9E M8G)U87)Y(#$Y.3,-"@T*#0H@("!-=6QT:6-AF5R;R!I;F1I8V%T97,@=&AA="!T:&5R92!I"!T>7!E($9&1D8-"B`@("`@(&EN9&EC M871E2!F:65L9"!I2!D969A=6QT+"!T:&4@0G)I9&=I;F<@0V]N=')O M;"!065R(&]P=&EO;B!-55-4($Y/5"!B92`- M"B`@("`@(&YE9V]T:6%T960N#0H-"B`@($$@2!O9B!T:&4@0G)I M9&=I;F<@0V]N=')O;"!0'!I"!M;VYT:',@("`@("`@("`@("`@("`@(%M086=E(#$Q70T*#0I$4D%&5"`@ M("`@("`@("`@("`@("`@("`@("`@("`@("!.0D9#4"`@("`@("`@("`@("`@ M("`@("`@($9E8G)U87)Y(#$Y.3,-"@T*#0HS+C4N("!);F-L=61E($U!0R!, M87EE<@T*#0H@("!$97-C2!O9B!T:&4@26YC;'5D92!-04,@3&%Y97(@0V]N9FEG=7)A=&EO;B!/ M<'1I;VX@9F]R;6%T(&ES(`T*("`@'0@:6X@=&AI2!$; Tue, 15 Feb 1994 15:54:11 -0500 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id MAA14169 for ietf-ppp@merit.edu; Tue, 15 Feb 1994 12:53:52 -0800 Date: Tue, 15 Feb 1994 12:53:52 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402152053.MAA14169@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: partial retransmission of revised draft Over the weekend I sent a lengthy message to the PPP mailing list that doesn't appear to have been received by all of its members. It announced yet another multilink draft, incorporating recent fundamental architectural changes proposed by Brian Lloyd & Glen McGregor. In fact it included the revised draft, and a possible explanation for the lack of transmission was due to its size. (No smirks on that one, please! ;-) The draft can be retreived via anonymous ftp from vangogh.CS.Berkeley.EDU in the directory pub/ppp-iplpdn/ as draft-ietf-pppext-multilink-06.5.txt. The cover note read as follows: To: ietf-ppp@merit.edu Subject: Yet Another Multilink Draft Here is an attempt to incorporate some sweeping architectural revisions proposed by Brian Lloyd & Glenn McGregor. This draft waffles on some unresolved issues. I was encouraged by Fred Baker and Vern Schryver to put something in writing so that when these issues are discussed specific text can be cited & changed or added. The unresolved issues include: 1.) Whether the sequence space should be fixed at 20 bits or negotiated. 2.) Whether a packet loss detection algorithm should be mandated or a choice left up to the implementation, or if there should be an option for saying the receiver wants the sender to obey the increasing packet rule. 3.) Whether there should be a "Maximum Outstanding Frames" parameter negotiated. Dave Carr persuaded me that this was not necessary for correct operation over LAPB, and my own personal view for the best effort case is that even if you know what the receiver is doing in the way of buffering, slippage between links may be out of your control. Maybe a simple "show of hands" around the mailing list can decide this. I'm calling this draft -06.5 so that when the inevitable comments come in, I can file a draft -07.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16328; 15 Feb 94 16:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16324; 15 Feb 94 16:50 EST Received: from merit.edu by CNRI.Reston.VA.US id aa21612; 15 Feb 94 16:50 EST Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA24617 for ; Tue, 15 Feb 1994 16:42:24 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA05747; Tue, 15 Feb 94 15:45:46 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA03064; Tue, 15 Feb 94 15:40:40 CST Date: Tue, 15 Feb 94 15:40:40 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9402152140.AA03064@anubis.network.com> To: ietf-ppp@merit.edu, sklower@vangogh.cs.berkeley.edu Subject: Re: partial retransmission of revised draft 1) I think that the 20 bit sequence number is better, but if enough people want to negotiate it, it isn't that much harder to support more than one size. 2) I think that a packet loss detection algorithm should be described. (Note: Packet loss is more general than just Fragment loss.) (Second note: I think the text does have such a description.) The sender behavior required for this, increasing sequence numbers within a link, should be mandated. Receiver behavior can be optional/flexible. 3) I do not see value in the "Maximum Outstanding Frames" parameter, but the memory models I tend to use most commonly are more flexible than many others have available. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17619; 15 Feb 94 17:55 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17615; 15 Feb 94 17:55 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23429; 15 Feb 94 17:55 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA29062 for ; Tue, 15 Feb 1994 17:48:03 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB17568; Tue, 15 Feb 94 14:47:40 PST Message-Id: <9402152247.AB17568@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Feb 1994 14:47:37 -0800 To: Keith Sklower Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: partial retransmission of revised draft Cc: ietf-ppp@merit.edu >Here is an attempt to incorporate some sweeping architectural revisions >proposed by Brian Lloyd & Glenn McGregor. > >This draft waffles on some unresolved issues. I was encouraged by Fred >Baker and Vern Schryver to put something in writing so that when these >issues are discussed specific text can be cited & changed or added. Thanks, Keith. When you do said draft 7 (by March 1, please), please post it to internet-drafts@nri.reston.va.us. That is what I presume we will be discussing at the IETF. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17885; 15 Feb 94 18:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17881; 15 Feb 94 18:12 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23780; 15 Feb 94 18:12 EST Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA00286 for ; Tue, 15 Feb 1994 18:02:34 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA06668; Tue, 15 Feb 94 17:06:06 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA04154; Tue, 15 Feb 94 17:01:01 CST Date: Tue, 15 Feb 94 17:01:01 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9402152301.AA04154@anubis.network.com> To: ietf-ppp@merit.edu Subject: Multi-Link and Sequence Numbers After some discussion, I have a better understanding of why someone would want to violate the increasing sequence number rule. So as to avoid putting words in people's mouths, I will describe a hypothetical situation, and my reaction to it. The case in question appears to obtain when running LAPB on individual links within a multi-link group. This is presumably due to a desire for reliability within a link. 1) We immediately run into the question of what interpretation can be put by the sender on receipt of an acknowledgement. I would have assumed the ack met "I have received the packet". I have been told that some people think it has more meaning, when multi-link is running, and relates to the acceptance of the packet by multi-link. So, now that we are running LAPB on several links, LAPB on one link detects, quickly, that that link is down. However, there were packets queued up for transmission on that link, having already been processed by Multilink and given sequnce numbers. Given the desire for reliability, the desire is then to recover these packets, and send them on other links. However, they already have multi-link sequence numbers, and those numbers have already been exceeded on the other links. 2) For the folks who would like to be able to violate sequencing, is this the case you are interested in, or is it another? Assuming that this is correct, I note that in 1) above there was inconsistency in interpretation. This gets worse if non-sequenced delivery is permitted. If this is LAPB/multi-link coupling is to be permitted, it must at the very least be document so that we may produce inter-operable implementations. It seems that there are two reasonable answers here: 1) We have a hammer, so everything is a nail. Therefore, multi-link should be able to "handle" this case. If so: A) We need an option to negotiate that a receiver is prepared to accept frames on a single link which do not have increasing sequence numbers, and a warning to transmitters about using it. B) We need an annex/appendix that describes how to use/interpret LAPB in conjunction with Multi-Link. It would describe the conculsions/behaviors based on acks, the interaction between link failures and out-of-order frames, and any other meaningful operational behaviors. or 2) We have something different. In that case we say that Multi-Link applies to unreliable transmission with a sequence preserving capability. LAPB/Multi-Link would be a different protocol, with a separate description. Both of these are probably reasonable options. We must at least be clear about the desired behaviors, and document them. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation PS If there are other cases/reasons for sequence violation, I would like to hear about them.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18429; 15 Feb 94 19:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18425; 15 Feb 94 19:15 EST Received: from merit.edu by CNRI.Reston.VA.US id aa25329; 15 Feb 94 19:15 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA03530 for ; Tue, 15 Feb 1994 19:00:47 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA16026; Tue, 15 Feb 94 16:01:40 -0800 Message-Id: <9402160001.AA16026@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 15 Feb 94 16:01:40 PST X-Msmail-Message-Id: 6AAC1A51 X-Msmail-Conversation-Id: BAE0B2AF X-Msmail-Parent-Message-Id: BAE0B2AF Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Tue, 15 Feb 94 15:57:52 TZ Subject: New NBFCP draft I have talked to Russ and Marty at Shiva. I have revised the NBFCP draft based on their suggestions. I submitted the draft yesterday, and it will probably be released tomorrow. I hope that everyone interested in NBFCP (which is only a handful of people) is satisfied with this revision. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03971; 16 Feb 94 9:08 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03967; 16 Feb 94 9:08 EST Received: from merit.edu by CNRI.Reston.VA.US id aa07372; 16 Feb 94 9:08 EST Received: from xap.xyplex.com (xap.xyplex.com [140.179.50.201]) by merit.edu (8.6.5/8.6.5) with SMTP id IAA13573 for ; Wed, 16 Feb 1994 08:52:56 -0500 Received: from sgw.xyplex.com by xap.xyplex.com id ; Wed, 16 Feb 94 08:50:43 -0500 Received: by eng.xyplex.com (4.1/SMI-4.1) id AA15378; Wed, 16 Feb 94 08:53:24 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Wasson Message-Id: <9402161353.AA15378@eng.xyplex.com> Subject: Re: Multi-Link and Sequence Numbers To: Joel Halpern Date: Wed, 16 Feb 94 8:53:24 EST Cc: ietf-ppp@merit.edu In-Reply-To: <9402152301.AA04154@anubis.network.com>; from "Joel Halpern" at Feb 15, 94 5:01 pm X-Mailer: ELM [version 2.3 PL8] According to Joel Halpern: > > So, now that we are running LAPB on several links, LAPB on one link > detects, quickly, that that link is down. However, there were packets > queued up for transmission on that link, having already been processed > by Multilink and given sequnce numbers. Given the desire for reliability, > the desire is then to recover these packets, and send them on other links. > However, they already have multi-link sequence numbers, and those numbers > have already been exceeded on the other links. > The "desire for reliability" should pertain only to the LAPB link on which the packets had been queued. It isn't LAPB's place to coerce multilink to hold to the same values. Multilink does not/should not deliver packets reliably. If LAPB drops queued packets because the link went down, tough. LAPB's responsibilities of guaranteed delivery became null and void the instant the link dropped. If reliability of the type you described is a requirement, then that requires a reliable multilink. Then I agree 100% with your statement: > 2) We have something different. In that case we say that Multi-Link > applies to unreliable transmission with a sequence preserving > capability. LAPB/Multi-Link would be a different protocol, with > a separate description. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04401; 16 Feb 94 9:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04397; 16 Feb 94 9:36 EST Received: from merit.edu by CNRI.Reston.VA.US id aa08176; 16 Feb 94 9:36 EST Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.6.5/8.6.5) with SMTP id JAA14951 for ; Wed, 16 Feb 1994 09:16:17 -0500 Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA10003; Wed, 16 Feb 94 09:15:36 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9402161415.AA10003@hobbit.gandalf.ca> Subject: Multi-Link and Sequence Numbers To: ietf-ppp Date: Wed, 16 Feb 1994 09:15:07 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 6105 > The case in question appears to obtain when running LAPB on individual > links within a multi-link group. This is presumably due to a desire > for reliability within a link. > > 1) We immediately run into the question of what interpretation can > be put by the sender on receipt of an acknowledgement. I would > have assumed the ack met "I have received the packet". I have been > told that some people think it has more meaning, when multi-link is > running, and relates to the acceptance of the packet by multi-link. Sort of. Acceptance of the packet by LAPB also means that you had enough buffer space for it. If you had buffer limitations, you would have sent an RNR (or at least not rotating the LAPB window). Not sending an RNR implies the opposite. It is a reasonable assumption that if you had buffer space for the packet, then the multilink fragment would not get pitched in between the LAPB receiver and the multilink rings. The keyword is assumption. I cannot count on this assumption. > So, now that we are running LAPB on several links, LAPB on one link > detects, quickly, that that link is down. However, there were packets > queued up for transmission on that link, having already been processed > by Multilink and given sequnce numbers. Given the desire for reliability, > the desire is then to recover these packets, and send them on other links. > However, they already have multi-link sequence numbers, and those numbers > have already been exceeded on the other links. > 2) For the folks who would like to be able to violate sequencing, is this > the case you are interested in, or is it another? Exactly. But one needn't wait for the LAPB link to be declared dead. It may be advantageous to move the queued LAPB frames which need retransission over to another link so as to keep the multilink window rotating. This could be done after a few retransmissions, but sooner than waiting for N2 to expire. The earlier a problem on a link is detected, the sooner the multilink data can be delivered. If one link stalls, it brings everything down (in the compression above ML case). > Assuming that this is correct, I note that in 1) above there was > inconsistency in interpretation. This gets worse if non-sequenced > delivery is permitted. If this is LAPB/multi-link coupling is to > be permitted, it must at the very least be document so that we may > produce inter-operable implementations. Nonsense. Acceptance of the frame by LAPB does not guarantee the frame was accepted by the multilink. No design should expect otherwise. What we are trying to prevent is the multilink frame loss that is preventable. The receiver of the out-of-sequence frame can make it's own decision. If it choses to pitch frames whose sequence numbers are less than the minimum, it can do so. This is entirely consistent with the draft text. It is also perfectly consistent with ISO multilink. What would your non-LAPB implementation do if it received such a frame with the "ever-increasing" rule in effect? Choke? Panic? No, it would merely toss the frame. You require no extra code for this. > It seems that there are two reasonable answers here: > 1) We have a hammer, so everything is a nail. Therefore, multi-link > should be able to "handle" this case. If so: > A) We need an option to negotiate that a receiver is prepared to > accept frames on a single link which do not have increasing > sequence numbers, and a warning to transmitters about using it. Not required. Perhaps we should look at ISO multilink. It has no such "ever-increasing" rule. Yet, out-of-sequence delivery is permitted. The "ever-increasing" rule is merely a tool for frame loss detection. We are not mandating the "The increasing sequence number per link technique" frame loss detection. Timer based re-assembly and gaurd window approaches also work. Both are consistent with ISO. > B) We need an annex/appendix that describes how to use/interpret > LAPB in conjunction with Multi-Link. It would describe the > conculsions/behaviors based on acks, the interaction between > link failures and out-of-order frames, and any other meaningful > operational behaviors. Again, no explanation of LAPB is required. Perhaps some text, but certainly not about conclusions of what LAPB acks imply. Simply state that it is permissable to deliver frames out of sequence, as an *exception* to the rule. The rule should be followed in "normal operation". I couldn't imagine a reason for violating the rule in normal operation. > 2) We have something different. In that case we say that Multi-Link > applies to unreliable transmission with a sequence preserving > capability. LAPB/Multi-Link would be a different protocol, with > a separate description. Totally unnecessary. > Both of these are probably reasonable options. We must at least be clear > about the desired behaviors, and document them. But none are required. You make your decisions in your receiver. If I chose a different frame loss detection algorithm from you, there are no zero reprocussions. If I decide to keep an "out-of-sequence" frame, I can. You don't have to. This is merely a case of consenting implementations. You need only worry about what action you take when an "out-of-sequence" frame is received. You can take different actions based on the types of links in the bundle. If you never intend to run LAPB, then you could terminate the link. If you are running LAPB, bend the rule. Take what ever action you feel is appropriate. It's your decision, and not one which should be cast in stone. P.S. To date, no ML draft has specified what action is to be taken when an out of sequence frame is received. Do you think everyone has chosen the same recovery action? Is there any need to mandate the action? -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts.   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06536; 16 Feb 94 11:22 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11062; 16 Feb 94 11:22 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06522; 16 Feb 94 11:21 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06315; 16 Feb 94 11:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ppp@ucdavis.edu Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-netbios-fcp-04.txt Date: Wed, 16 Feb 94 11:19:15 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9402161119.aa06315@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP NetBIOS Frames Control Protocol (NBFCP) Author(s) : T. Dimitri Filename : draft-ietf-pppext-netbios-fcp-04.txt Pages : 14 Date : 02/15/1994 The Point-to-Point Protocol (PPP) provides a method for transmitting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol was originally called the NetBEUI protocol and was used in versions of DOS and OS/2 LAN Manager. It is now used in Microsoft Windows NT and Microsoft Windows for Workgroups. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-netbios-fcp-04.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: venera.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-netbios-fcp-04.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940215101801.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-netbios-fcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-netbios-fcp-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940215101801.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07012; 16 Feb 94 11:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07008; 16 Feb 94 11:41 EST Received: from merit.edu by CNRI.Reston.VA.US id aa11572; 16 Feb 94 11:41 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA24497 for ; Wed, 16 Feb 1994 11:25:35 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB24961; Wed, 16 Feb 94 08:25:28 PST Message-Id: <9402161625.AB24961@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Feb 1994 08:25:26 -0800 To: ietf-ppp@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: Multi-Link and Sequence Numbers >Assuming that this is correct, I note that in 1) above there was >inconsistency in interpretation. This gets worse if non-sequenced >delivery is permitted. If this is LAPB/multi-link coupling is to >be permitted, it must at the very least be document so that we may >produce inter-operable implementations. My $0.02: When a LAPB link goes down, it rarely takes down both ends and the middle simultaneously, and rarely takes the link down at the time of the catastrophic error. Generally, there are at least N2 T1 timeouts before the link is considered lost, something on the order of tens of seconds. When a LAPB link goes down, it is impossible to determine which of the enqueued frames were transmitted to the secondary and his acknowledgement lost, and which were not successfully transmitted. We don't know the state of the secondary at the time that the primary detects link loss. Hence, moving the frames from the failed link to an unfailed link has some probability of delivering a frame which the other guy has already received. It has a great probability of delivering a frame that the originator has already retransmitted, probably on the remaining link. Our experience with a LAPB multilink procedure doesn't argue very strongly for supporting out of sequence messages. Rather, you want to get the receiver to step past the sequence break and get on with life. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09683; 17 Feb 94 13:02 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13463; 17 Feb 94 13:02 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09670; 17 Feb 94 13:02 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07406; 17 Feb 94 11:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ppp@ucdavis.edu Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-for-bridging-03.txt Date: Thu, 17 Feb 94 11:23:23 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9402171123.aa07406@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Bridging Control Protocol (BCP) Author(s) : F. Baker, R. Bowen Filename : draft-ietf-pppext-for-bridging-03.txt Pages : 31 Date : 02/16/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-for-bridging-03.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: venera.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-for-bridging-03.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940216164535.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-for-bridging-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-for-bridging-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940216164535.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09841; 17 Feb 94 13:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09837; 17 Feb 94 13:06 EST Received: from merit.edu by CNRI.Reston.VA.US id aa13667; 17 Feb 94 13:06 EST Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA29822 for ; Thu, 17 Feb 1994 12:46:40 -0500 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <17518-0@relay1.pipex.net>; Thu, 17 Feb 1994 17:46:32 +0000 Received: by widow.spider.co.uk; Thu, 17 Feb 94 17:55:21 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerry Meyer Date: Thu, 17 Feb 94 17:46:36 GMT Message-Id: <7217.9402171746@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Thu, 17 Feb 94 17:46:36 GMT To: ietf-ppp@merit.edu, sklower@cs.berkeley.edu Subject: Re: multilink-06.5.txt Cc: gery@spider.co.uk Keith et al., Section 7 sort of skirts some of the following: My understanding is that each member of the bundle *may* negotiates MCP as part of its LCP negotiation, but if it it doesn't negotiate MCP it will inherit MCP from an existing member. What happens if members attempt to negotiate different MCP options (such as sequence space or MRU)? - or different LCP options, compression etc? The text appears to imply NCPs can be negotiated on any member and float to the others. Gut feel tells me problems will arise with collisions - where different ends of the bundle are trying to negotiate different things (or even the same things) on different members during MCP, LCP or NCP negotiation. Can anyone provide any clarifying text? Following the text: The reserved field is two bits long and is not currently defined. It must be set to zero. I would like added: Frames received with either of these bits set MUST be silently discard. Gerry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16531; 17 Feb 94 16:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16527; 17 Feb 94 16:22 EST Received: from merit.edu by CNRI.Reston.VA.US id aa18520; 17 Feb 94 16:22 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA15615 for ; Thu, 17 Feb 1994 16:06:39 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA01417; Thu, 17 Feb 94 13:06:34 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA00976; Thu, 17 Feb 94 14:05:58 -0700 Date: Thu, 17 Feb 94 14:05:58 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402172105.AA00976@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: inheritance >From: gerry@spider.co.uk (Gerry Meyer) >Section 7 sort of skirts some of the following: > >My understanding is that each member of the bundle *may* negotiates >MCP as part of its LCP negotiation, but if it it doesn't negotiate MCP >it will inherit MCP from an existing member. I thought we had agreed that unless an MCP packet appears on a link, it remains outside any existing bundle, that the inheritance happens only on links that both sides explicitly agree are parts of the bundle. >What happens if members attempt to negotiate different MCP options (such as >sequence space or MRU)? - or different LCP options, compression etc? As the doctor says, "if it hurts, don't do it." To resolve errors, do the usual. One (or both) peers will Configure-Reject or Configure-Request-NAK the unpalatable values. An implementation that Configure-ACK's different values and then expects to use those different values on various members of the bundle is obviously broken. Besides, accepting the notion of inheritance makes it impossible to talk about such situations. >The text appears to imply NCPs can be negotiated on any member and >float to the others. That's what inheritance is all about. I think the grudging consensus is to have exactly that much inheritance. To ensure mutual assured discontent, inheritance does not apply to links that are not part of the bundle, i.e. those that never carry an MCP packet. >Gut feel tells me problems will arise with collisions - where different >ends of the bundle are trying to negotiate different things (or even the >same things) on different members during MCP, LCP or NCP negotiation. > >Can anyone provide any clarifying text? What about the following sentence in the 2nd complete paragrap on page 4 in the 6.5 text: ] It is irrelevant whether Network Control Protocol ] packets are encapsulated in multilink headers or not, or even over ] which link they are sent, once that link identifies itself as ] belonging to a multilink arrangement. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17770; 17 Feb 94 17:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17766; 17 Feb 94 17:04 EST Received: from merit.edu by CNRI.Reston.VA.US id aa20289; 17 Feb 94 17:04 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA19915 for ; Thu, 17 Feb 1994 16:49:52 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA10804; Thu, 17 Feb 94 13:49:36 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA01263; Thu, 17 Feb 94 14:48:50 -0700 Date: Thu, 17 Feb 94 14:48:50 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402172148.AA01263@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: comments on the 6.5 version of the document I've been lazy and skipped the document that came directly from Lloyd and McGregor. If I've incorrectly inferred that Lloyd, McGregor, and Sklower privately came to terms, please let me know. On the top of page 4, it says that multi-link always implies address and control field compression and that there is no async. control character map. What about protocol field compression? I understand that it would be silly to have address and control fields or async. control character escaping inside packets that will have another layer of address & control fields and escaping. However, as long as we are non-negotiating things, how about doing as LCP should have done and always and forever allow the sender to omit the leading zero of protocol fields on the packet that have a preceding multi-link header? ...... I think the following paragraph on page 4 is contrary to the grudging consensus for inheritance of NCP's: ] For example, consider the case in Figure 1. Link 1 has negotiated ] network layers NL 1, NL 2, and MP between two systems. The two ] systems then negotiate MP over Link 2. Given inheritance of NCP's, the talk of virtual links on page 4 and 5 might be controversial. Since it is only motivating text that does not directly affect the standard, it might be better to remove it. ...... There is a typo on the 3rd line of page 6: ] segments be of equal sizes. or that packets must be broken up at ^^^^ ? segments be of equal sizes, or that packets must be broken up at ...... Given the text on pages 7 and 8 about how to detect lost packets given increasing sequence numbers, what more does anyone want? (I'm refering to recent requests for more text describing how to use strictly increasing sequence numbers to detect lost fragments.) ...... What is a "null fragment" in the following paragraph on page 8?: ] Loss of the final fragment of a transmission can cause the receiver ] to stall until new packets arrive. The likelihood of this may be ] decreased by sending a null fragment over each member link in the ] bundle to increase M on the receiver and, hopefully, cause detection ] of the lost fragment. Otherwise the receiver SHOULD implement some ] type of link idle timer To prevent this case. I can think of 2 or 3 different kinds of "null fragment." There may be others. Unless the document defines "null fragment, an implementation might treat a multi-link packet containing with zero (0) data bytes and no inner LCP header (i.e. protocol field) as an error instead of a null fragment intended to help the receiver detect lost fragments. The current text in that section is too weak if you want implmentations to actually transmit null fragments. Prudent implementors will write code that does not emit null fragments because of the dangers of bugs and of wasting bandwidth. Once you decide to transmit a null fragment, you've burned that bandwidth. If another packet comes along you might at best (but almost certainly will not) abort the current null fragment. You're more likely to just let the new packet wait for the null to be sent. ...... The discussion of timer-based fragment lost detection schemes on page 9 must mention likely worst delays for common channels. As we discovered in this mailing list, many people are unaware that the most common PPP physical link (v.32 and v.32bis modems) have worst case delays of about 8 seconds. Obviously, I'm not saying that the abstract computation in the document be replaced with a number based on 8 seconds of delay, but that the document more fully describe the delays of common links. ...... The first sentence in section 6 on page 10 has a typo: ] Member links may be terminated according to normal PPP LCP procedures ] using LCP terminate-request and terminate-ack packets. on that ^^^^ ] member link. ...... If those who use LAPB or other reliable links agree to use non-increasing sequence numbers, then the last paragraph in section 6 must be expanded to mention the consequences. It must mention algorithms to detect duplicate fragments: ] If the multilink procedure is used in conjunction with PPP reliable ] transmission, and a member link is not closed gracefully, the ] implementation should expect to receive packets which violate the ] increasing sequence number rule. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17812; 17 Feb 94 17:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17808; 17 Feb 94 17:04 EST Received: from merit.edu by CNRI.Reston.VA.US id aa20314; 17 Feb 94 17:04 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA20424 for ; Thu, 17 Feb 1994 16:51:44 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA11207; Thu, 17 Feb 94 13:51:40 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA01292; Thu, 17 Feb 94 14:50:54 -0700 Date: Thu, 17 Feb 94 14:50:54 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402172150.AA01292@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: 6.5 multilink text and padding What about Self-Describing-Padding? Some words about the implications of padding need to be in the document. Of course, I like the words I proposed. vjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23916; 17 Feb 94 22:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23910; 17 Feb 94 22:52 EST Received: from merit.edu by CNRI.Reston.VA.US id aa27800; 17 Feb 94 22:52 EST Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.5/8.6.5) with ESMTP id WAA14674 for ; Thu, 17 Feb 1994 22:35:13 -0500 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id TAA15224 for ietf-ppp@merit.edu; Thu, 17 Feb 1994 19:34:54 -0800 Date: Thu, 17 Feb 1994 19:34:54 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402180334.TAA15224@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: re: VJS's comments on the 6.5 draft Vernon - Thank you for taking the trouble to read the draft so closely. I agree in principle with most of your comments, but take issue with the following: VJS writes: }I think the following paragraph on page 4 is contrary to the grudging }consensus for inheritance of NCP's: } }] For example, consider the case in Figure 1. Link 1 has negotiated }] network layers NL 1, NL 2, and MP between two systems. The two }] systems then negotiate MP over Link 2. } }Given inheritance of NCP's, the talk of virtual links on page 4 and 5 }might be controversial. Since it is only motivating text that does not }directly affect the standard, it might be better to remove it. But this is exactly the common case - two systems will connect and will negotiate the multilink option(s) as part of their LCP exchange identifying the initial link as part of a multilink arrangment and should they bring up a second line, they will only negotiate the use of multilink on it because it is understood that the NCP negotiations have been conducted over the virtual LCP entity that the physical links are part of. Brian Lloyd doesn't seem to have a problem with the notion that a collection of physical links constitutes something that functions as a single point of attachment for network level protoocols sitting above it. Packets may either be sent on physical links with or without multilink headers and will be sequenced or reassembled or not. One of the *advantages* of writing IETF documents instead of IEEE or ISO documents is that we *are* allowed to include motivational discussions. If my language is unclear or misleading, however, I would welcome suggestions that offer replacement text. }... how about doing as LCP should have done and }always and forever allow the sender to omit the leading zero of }protocol fields on the packet that have a preceding multi-link header? Yes, Brian suggested this also, & I plum forgot. There used to be a separate MCP option for this, but Brian pointed out to me in a phone discussion that systems wanting to keep the high-order byte for allignment purposes were not required to compress it out if they didn't want to. }What is a "null fragment" in the following paragraph on page 8?: } }] The likelihood of [stalling due to loss of a fragment with (F) set] may be }] decreased by sending a null fragment over each member link ... } }I can think of 2 or 3 different kinds of "null fragment." .... I meant a fragment consisting soley of a multilink header with both the (B)egin and (E)nd bits set. }The current text in that section is too weak ... implementors will write }code that does not emit null fragments because of the dangers of bugs }and of wasting bandwidth..... Here, I inadvertently dropped a phrase that used to be there, it should have read "sending a null fragment over each link **that was otherwise going to become idle**" Try this on for size: "Loss of the final fragment of a transmission can cause the receiver to stall until new packets arrive. The likelihood of this may be decreased by sending a null fragment any each member link in a bundle that would otherwise become idle immediately after having transmitted a fragment bearing the (E)nding bit, where a null fragment is one soley consisting of a multilink header bearing both the (B)egin and (E)nding bits (i.e having no payload). Implementations concerned about either wasting bandwidth or per packet costs are not required to send null fragments and may elect to defer sending them until a timer expires, with the marginally increased possibility of lengthier stalls in the receiver. The receiver SHOULD implement some type of link idle timer to guard against indefinite stalls." } }If those who use LAPB or other reliable links agree to use non-increasing }sequence numbers, then the last paragraph in section 6 must be expanded }to mention the consequences. It must mention algorithms to detect }duplicate fragments: This was already mentioned in the paragraph discussion non-interoperability of migration and the increasing sequence number rule (last paragraph of 4.1.) "This technique would prohibit the migrating of fragments queued up behind a failing link to a working one, a practice which is not unusual for implementations of ISO multilink over LAPB. Of course, receivers willing to receive out of order fragements must also be prepared to deal with duplicate packets."   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25913; 17 Feb 94 22:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25907; 17 Feb 94 22:54 EST Received: from merit.edu by CNRI.Reston.VA.US id aa27879; 17 Feb 94 22:54 EST Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.5/8.6.5) with ESMTP id WAA15154 for ; Thu, 17 Feb 1994 22:44:34 -0500 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id TAA15255 for ietf-ppp@merit.edu; Thu, 17 Feb 1994 19:44:13 -0800 Date: Thu, 17 Feb 1994 19:44:13 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402180344.TAA15255@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: multilink draft updated to incorporate Vern's comments. find it via anonymous ftp at vangogh.cs.berkeley.edu:~ftp/pub/ppp-iplpdn/ draft-ietf-pppext-multilink-06.6.txt   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04837; 18 Feb 94 9:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04833; 18 Feb 94 9:59 EST Received: from merit.edu by CNRI.Reston.VA.US id aa08629; 18 Feb 94 9:59 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id JAA00818 for ; Fri, 18 Feb 1994 09:36:47 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA20941; Fri, 18 Feb 94 06:36:40 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA06338; Fri, 18 Feb 94 07:36:02 -0700 Date: Fri, 18 Feb 94 07:36:02 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402181436.AA06338@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: draft > From: sklower@vangogh.CS.Berkeley.EDU (Keith Sklower) > Try this on for size: > > "Loss of the final fragment of a transmission can cause the > receiver to stall until new packets arrive. The likelihood of > this may be decreased by sending a null fragment any each member > link in a bundle that would otherwise become idle immediately > after having transmitted a fragment bearing the (E)nding bit, > where a null fragment is one soley consisting of a multilink > header bearing both the (B)egin and (E)nding bits (i.e having > no payload). Implementations concerned about either wasting > bandwidth or per packet costs are not required to send null > fragments and may elect to defer sending them until a timer > expires, with the marginally increased possibility of lengthier > stalls in the receiver. The receiver SHOULD implement some type > of link idle timer to guard against indefinite stalls." That seems better to me, except that I do not see the value of the timer in the receiver, and would rather see the last "SHOULD" be a "MAY." What harm is there in having the receiver stall? We are talking about the case when a fragment has been lost. What does it matter if the receiver discards a dead packet immediately or later when new traffic arrives? > }If those who use LAPB or other reliable links agree to use non-increasing > }sequence numbers, then the last paragraph in section 6 must be expanded > }to mention the consequences. It must mention algorithms to detect > }duplicate fragments: > > This was already mentioned in the paragraph discussion non-interoperability > of migration and the increasing sequence number rule (last paragraph of 4.1.) > > "This technique would prohibit the migrating of fragments queued up > behind a failing link to a working one, a practice which is not > unusual for implementations of ISO multilink over LAPB. Of course, > receivers willing to receive out of order fragements must also be > prepared to deal with duplicate packets." I saw that sentence. All of the algorithms I've been able to think of for dealing with duplicate packets while also supporting the out-of-order delivery needed by very skewed sequence numbers are horrendous. We do not have something like the TCP segment number, which make dealing with duplicated TCP segments easy. If there is some easy algorithm, it needs to be mentioned. If it is as hard as I think it is, the text should suggest as much. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06511; 18 Feb 94 11:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06507; 18 Feb 94 11:15 EST Received: from merit.edu by CNRI.Reston.VA.US id aa10678; 18 Feb 94 11:15 EST Received: from digibd.com (digibd.digibd.com [192.83.159.205]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA07011 for ; Fri, 18 Feb 1994 10:49:49 -0500 Received: by digibd.com (5.65/DBI-1.19) id AA26517; Fri, 18 Feb 94 09:40:28 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Coradetti Message-Id: <9402181540.AA26517@digibd.com> Subject: Re: draft - harm of rcvr stall To: Vernon Schryver Date: Fri, 18 Feb 1994 09:40:27 -0600 (CST) Cc: ietf-ppp@merit.edu In-Reply-To: <9402181436.AA06338@rhyolite.wpd.sgi.com> from "Vernon Schryver" at Feb 18, 94 07:36:02 am X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 642 > What harm is there in having the receiver stall? We are talking about > the case when a fragment has been lost. What does it matter if the > receiver discards a dead packet immediately or later when new traffic > arrives? > Certainly the packet with the lost fragment is lost forever. However, in order to enforce sequentiality, other packets which have been completely reassembled are blocked until the preceeding doomed packet is disposed of. Since these other packets may be part of an entirely different session from the point of view of some higher layer, the loss of one packet should not disrupt these other sessions as well. tc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07513; 18 Feb 94 11:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07509; 18 Feb 94 11:51 EST Received: from merit.edu by CNRI.Reston.VA.US id aa11945; 18 Feb 94 11:51 EST Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA11078 for ; Fri, 18 Feb 1994 11:36:24 -0500 Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA07948; Fri, 18 Feb 94 11:35:43 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9402181635.AA07948@hobbit.gandalf.ca> Subject: 6.6 multilink comments To: ietf-ppp Date: Fri, 18 Feb 1994 11:35:11 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1377 vernon> I can think of 2 or 3 different kinds of "null fragment." There may be vernon> others. Unless the document defines "null fragment, an implementation vernon> might treat a multi-link packet containing with zero (0) data bytes and vernon> no inner LCP header (i.e. protocol field) as an error instead of a vernon> null fragment intended to help the receiver detect lost fragments. 6.6> to stall until new packets arrive. The likelihood of this may be 6.6> decreased by sending a null fragment any each member link in a bundle 6.6> that would otherwise become idle immediately after having transmitted 6.6> a fragment bearing the (E)nding bit, where a null fragment is one 6.6> soley consisting of a multilink header bearing both the (B)egin and 6.6> (E)nding bits (i.e having no payload). Implementations concerned This forces systems which use padding to negotiate self-describing pads, since this null fragment could be padded. The receiver cannot distinguish a padded NULL fragment from a real data fragment. How about using one of those spare bits in the header to create another frame type? That would remove any ambiguity. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07712; 18 Feb 94 12:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07708; 18 Feb 94 12:01 EST Received: from merit.edu by CNRI.Reston.VA.US id aa12223; 18 Feb 94 12:01 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA11195 for ; Fri, 18 Feb 1994 11:39:44 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA01280; Fri, 18 Feb 94 08:39:40 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA07038; Fri, 18 Feb 94 09:39:08 -0700 Date: Fri, 18 Feb 94 09:39:08 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402181639.AA07038@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: draft - harm of rcvr stall > From: tomc@digibd.com (Tom Coradetti) > > > What harm is there in having the receiver stall? We are talking about > > the case when a fragment has been lost. What does it matter if the > > receiver discards a dead packet immediately or later when new traffic > > arrives? > > > Certainly the packet with the lost fragment is lost forever. However, > in order to enforce sequentiality, other packets which have been > completely reassembled are blocked until the preceeding doomed packet > is disposed of. ... If you assume the peer follows the other SHOULD's, it's hard for that to happen. Packets assembled after the doomed packet "SHOULD" involve traffic on all links. The minimum of the maximum of the observed sequence numbers will pass the missing fragment and the packet will be discarded, all without any timing or stalling. The only way I can see to significantly delay other traffic is by assuming that the other traffic does not use the link that lost the fragment, and the only reasonable way to do that is to assume the good traffic was tiny packets and the bad one large. Oh, well. I guess it would not be too hard to after 8 or 10 seconds (v.32 retraining) of idleness on all links to set the compute minimum of the maximum of the sequence numbers to the maximum of the maximums, and discard fragments accordingly. 10 seconds is a long time, not going to make people happy to wait, and a rather long stretch of idle time in view of higher layer timeouts that will cause a retransmission of the bad packet and so break everything loose anyway. I trust no one seriously wants to keep per-fragment timers. vjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11209; 18 Feb 94 14:20 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11195; 18 Feb 94 14:20 EST Received: from merit.edu by CNRI.Reston.VA.US id aa16390; 18 Feb 94 14:20 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA22058 for ; Fri, 18 Feb 1994 14:03:48 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA25803; Fri, 18 Feb 94 11:03:41 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA07996; Fri, 18 Feb 94 12:02:40 -0700 Date: Fri, 18 Feb 94 12:02:40 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402181902.AA07996@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: padding and null fragments > From: dcarr@gandalf.ca (Dave Carr) > > vernon> I can think of 2 or 3 different kinds of "null fragment." There may be > vernon> others. Unless the document defines "null fragment, an implementation > vernon> might treat a multi-link packet containing with zero (0) data bytes and > vernon> no inner LCP header (i.e. protocol field) as an error instead of a > vernon> null fragment intended to help the receiver detect lost fragments. > > 6.6> to stall until new packets arrive. The likelihood of this may be > 6.6> decreased by sending a null fragment any each member link in a bundle > 6.6> that would otherwise become idle immediately after having transmitted > 6.6> a fragment bearing the (E)nding bit, where a null fragment is one > 6.6> soley consisting of a multilink header bearing both the (B)egin and > 6.6> (E)nding bits (i.e having no payload). Implementations concerned > > This forces systems which use padding to negotiate self-describing pads, > since this null fragment could be padded. The receiver cannot distinguish > a padded NULL fragment from a real data fragment. > > How about using one of those spare bits in the header to create another > frame type? That would remove any ambiguity. Why not let those systems that are forced to pad and want to transmit null fragments use self-describing-padding? How many such systems will there ever be? Instead of expending one of those precious bits, why not be creative in the definition of null packet? Consider one of the following: 1. How should a receiver interpret a PPP (not multi-link) packet consisting only of one or two zeros? After you strip the leading zeros from the protocol, you have nothing left. That is pretty null. Note that protocol field compression is non-negoiated, and so all multilink receivers must be willing to tolerate 0 or 1 byte of zero before a 1-byte protocol number. 2. How should a receiver interpret a PPP (not multi-link) packet with both start and end bits and a pay load consisting only of one byte of 0x21 or two bytes of 0x0021? In other words, a null IP packet? 3. How about an ICMP Echo-Reply with a destination address of 127.1? Or a destination address of 0.0 or 255.255.255.255? 4. What about an LCP Echo-Request? 5. etc. Maybe one or more of those non-null-null's needs to be mentioned, but we do not need to use a bit. More important, we should not impose the burden on all systems of interperting a "null bit" just to accomodate an unknown, possibly zero, but small number of systems that are forced to pad. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12006; 18 Feb 94 14:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12002; 18 Feb 94 14:53 EST Received: from merit.edu by CNRI.Reston.VA.US id aa17407; 18 Feb 94 14:53 EST Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA24296 for ; Fri, 18 Feb 1994 14:36:06 -0500 Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA10708; Fri, 18 Feb 94 14:35:33 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9402181935.AA10708@hobbit.gandalf.ca> Subject: padding and null fragments To: ietf-ppp Date: Fri, 18 Feb 1994 14:35:06 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2511 > > This forces systems which use padding to negotiate self-describing pads, > > since this null fragment could be padded. The receiver cannot distinguish > > a padded NULL fragment from a real data fragment. > > Why not let those systems that are forced to pad and want to transmit > null fragments use self-describing-padding? How many such systems will > there ever be? But it also negates all the effort we have expended on the padding issue. We actually reached a point where even those systems which needed padding didn't need self-describing pads. > Instead of expending one of those precious bits, why not be creative > in the definition of null packet? Consider one of the following: Spare bits are meant to be used to get out of a corner :-) > 1. How should a receiver interpret a PPP (not multi-link) packet > consisting only of one or two zeros? After you strip the > leading zeros from the protocol, you have nothing left. That > is pretty null. > Note that protocol field compression is non-negoiated, and so > all multilink receivers must be willing to tolerate 0 or 1 byte > of zero before a 1-byte protocol number. > 2. How should a receiver interpret a PPP (not multi-link) packet > with both start and end bits and a pay load consisting only of > one byte of 0x21 or two bytes of 0x0021? In other words, a > null IP packet? > 3. How about an ICMP Echo-Reply with a destination address of 127.1? > Or a destination address of 0.0 or 255.255.255.255? > 4. What about an LCP Echo-Request? > 5. etc. No good. You need to include the ML header and sequence number, to bump the sequence number on that link. Otherwise, the null fragment is useless, or at best a keep-alive (and an LCP echo or discard request would serve the same purpose). > Maybe one or more of those non-null-null's needs to be mentioned, but > we do not need to use a bit. None of the above advance the minimum sequence number on the link. > More important, we should not impose the burden on all systems of > interperting a "null bit" just to accomodate an unknown, possibly zero, > but small number of systems that are forced to pad. Or burden those systems which have no need for Null packets at all (such as a guard window or timer based algorithm)!!! -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13931; 18 Feb 94 16:23 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13926; 18 Feb 94 16:23 EST Received: from merit.edu by CNRI.Reston.VA.US id aa19840; 18 Feb 94 16:23 EST Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.5/8.6.5) with ESMTP id QAA00718 for ; Fri, 18 Feb 1994 16:03:55 -0500 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.6.Beta0/8.6.5.Beta12) id NAA23727; Fri, 18 Feb 1994 13:03:26 -0800 Date: Fri, 18 Feb 1994 13:03:26 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199402182103.NAA23727@vangogh.CS.Berkeley.EDU> To: dcarr@gandalf.ca, ietf-ppp@merit.edu Subject: Re: padding and null fragments } - Dave Carr commentS }> - VJS' comments }> 1. How should a receiver interpret a PPP (not multi-link) packet }> consisting only of one or two zeros? After you strip the }> leading zeros from the protocol, you have nothing left. That }> is pretty null. }> Note that protocol field compression is non-negoiated, and so }> all multilink receivers must be willing to tolerate 0 or 1 byte }> of zero before a 1-byte protocol number. }> 2. How should a receiver interpret a PPP (not multi-link) packet }> with both start and end bits and a pay load consisting only of Uh, Vern, I don't think normal PPP packets have start and end bits - but multilink ones do. Is that what you meant? }> one byte of 0x21 or two bytes of 0x0021? In other words, a }> null IP packet? }> 3. How about an ICMP Echo-Reply with a destination address of 127.1? }> Or a destination address of 0.0 or 255.255.255.255? }> 4. What about an LCP Echo-Request? }> 5. etc. } }No good. You need to include the ML header and sequence number, to bump the }sequence number on that link. Otherwise, the null fragment is useless ... }None of the above advance the minimum sequence number on the link. Well, Dave, what I think Vern was driving at was that you should have a multilink packet increasing the sequence number with a payload of 1 or 2 null bytes, or a multilink encoded empty IP packet or bending the rule about you can't put LCP headers behind mutlilink headers just for the case of LCP discard packets or . . .   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14156; 18 Feb 94 16:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14152; 18 Feb 94 16:39 EST Received: from merit.edu by CNRI.Reston.VA.US id aa20313; 18 Feb 94 16:39 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA02234 for ; Fri, 18 Feb 1994 16:26:36 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA26605; Fri, 18 Feb 94 13:26:30 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA09066; Fri, 18 Feb 94 14:25:52 -0700 Date: Fri, 18 Feb 94 14:25:52 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402182125.AA09066@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: padding and null fragments > From: dcarr@gandalf.ca (Dave Carr) > ... > > Why not let those systems that are forced to pad and want to transmit > > null fragments use self-describing-padding? How many such systems will > > there ever be? > > But it also negates all the effort we have expended on the padding issue. > We actually reached a point where even those systems which needed padding > didn't need self-describing pads. If and only if they they fragment carefully enough and stick to IP or similar protocols. Otherwise they need self-describing padding. > ... > > 1. How should a receiver interpret a PPP (not multi-link) packet > > consisting only of one or two zeros? After you strip the > > leading zeros from the protocol, you have nothing left. That > > is pretty null. > > Note that protocol field compression is non-negoiated, and so > > all multilink receivers must be willing to tolerate 0 or 1 byte > > of zero before a 1-byte protocol number. > > 2. How should a receiver interpret a PPP (not multi-link) packet > > with both start and end bits and a pay load consisting only of > > one byte of 0x21 or two bytes of 0x0021? In other words, a > > null IP packet? > > 3. How about an ICMP Echo-Reply with a destination address of 127.1? > > Or a destination address of 0.0 or 255.255.255.255? > > 4. What about an LCP Echo-Request? > > 5. etc. > > No good. You need to include the ML header and sequence number, to bump the > sequence number on that link. Otherwise, the null fragment is useless, > or at best a keep-alive (and an LCP echo or discard request would serve > the same purpose). > > > Maybe one or more of those non-null-null's needs to be mentioned, but > > we do not need to use a bit. > > None of the above advance the minimum sequence number on the link. > ... Why don't each and every one of those non-null-null's advance the minimum sequence number on the link? You couldn't use an old sequence number in the multilink header that precedes each and every one of them. A "null multilink packet" needs has the following characteristics: A. an increased sequence number. B. a payload that the receiver will practically ignore. A completely empty payload might satisfy (B), but so might many other things. I think the best idea is (1). Define a "null multilink fragment" as "a multilink packet with both start and end bits set and containing zero or more bytes of payload, all of which are zero". Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16313; 18 Feb 94 18:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16309; 18 Feb 94 18:42 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23425; 18 Feb 94 18:42 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA11909 for ; Fri, 18 Feb 1994 18:29:32 -0500 Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA29452; Fri, 18 Feb 94 15:29:30 PST Date: Fri, 18 Feb 94 15:29:30 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Message-Id: <9402182329.AA29452@fennel.acc.com> To: ietf-ppp@merit.edu Subject: draft-ietf-pppext-for-bridging-03.txt are we ready to send this off as a standard?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16337; 18 Feb 94 18:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16333; 18 Feb 94 18:44 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23475; 18 Feb 94 18:44 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA11904 for ; Fri, 18 Feb 1994 18:29:28 -0500 Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA29442; Fri, 18 Feb 94 15:29:19 PST Date: Fri, 18 Feb 94 15:29:19 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Message-Id: <9402182329.AA29442@fennel.acc.com> To: ietf-ppp@merit.edu Subject: draft-ietf-pppext-dataencap-00.txt are we ready to send this off as a standard?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16347; 18 Feb 94 18:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16343; 18 Feb 94 18:44 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23478; 18 Feb 94 18:44 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA11911 for ; Fri, 18 Feb 1994 18:29:38 -0500 Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA29446; Fri, 18 Feb 94 15:29:25 PST Date: Fri, 18 Feb 94 15:29:24 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Message-Id: <9402182329.AA29446@fennel.acc.com> To: ietf-ppp@merit.edu Subject: draft-ietf-pppext-netbios-fcp-04.txt are we ready to send this off as a standard?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16534; 18 Feb 94 19:14 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16530; 18 Feb 94 19:14 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23915; 18 Feb 94 19:14 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA14312 for ; Fri, 18 Feb 1994 19:03:55 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA13549; Fri, 18 Feb 94 16:04:53 -0800 Message-Id: <9402190004.AA13549@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 18 Feb 94 16:04:53 PST X-Msmail-Message-Id: 6B8BCED3 X-Msmail-Conversation-Id: 6B8BCED3 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Fri, 18 Feb 94 16:01:22 TZ Subject: Another multi-link issue There is one multi-link issue I have problems with. It is the very old issue of figuring out which bundle a new link goes on. The current proposal assumes that authentication must occur and that authentication suffices to distinguish the link. I think these assumptions are wrong on both counts. Forcing authentication is not necessary for private links and slows down how fast a link can be brought up (which is actually important for bringing up links on demand). So requiring it for bundle identification seems unnecessary. Secondly, the assumption that username is unique per machine is simply not true. Today (in fact, for the past year), I have users dialing in from home with basic rate ISDN lines (soon to be a multi-linked 2 B channel bundle). This user has one username. This user may also dial in again (simulaneously), from another site. This happens when the user wants to access his/her home machine and is also at another site and wants to dial-in from that site also. This occurs today. The problem also occurs frequently with 'guest' accounts or shared 'vendor' accounts. This also occurs today. Therefore, I propose that another LCP multilink option be added. This option includes the 'username' with a 32 bit unique machine indentifier (or perhaps 64 bit). The 32 bit identifier can be derived by several methods (ethernet addresses, unique machine names, assigned number, randomly generated). This option identifies the machine. If authentication is not necessay, this option is all that is needed to uniquely identify the machine. It seems easy enough to do and it solves my two problems. Any comments? --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18264; 18 Feb 94 21:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18260; 18 Feb 94 21:45 EST Received: from merit.edu by CNRI.Reston.VA.US id aa26469; 18 Feb 94 21:45 EST Received: from naiad.gordian.com (naiad.gordian.com [192.73.220.82]) by merit.edu (8.6.5/8.6.5) with ESMTP id VAA22540 for ; Fri, 18 Feb 1994 21:19:48 -0500 Received: from eris.gordian.com (eris.gordian.com [192.73.220.121]) by naiad.gordian.com (8.6.5/8.6.5) with SMTP id SAA29437 for ; Fri, 18 Feb 1994 18:19:13 -0800 Received: by eris.gordian.com (AIX 3.2/UCB 5.64/4.03) id AA28144; Fri, 18 Feb 1994 18:19:11 -0800 Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.eris.gordian.com.rs.aix31 via MS.5.6.eris.gordian.com.rs_aix31; Fri, 18 Feb 1994 18:19:11 -0800 (PST) Message-Id: Date: Fri, 18 Feb 1994 18:19:11 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jay Laefer To: ietf-ppp@merit.edu Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt In-Reply-To: <9402182329.AA29446@fennel.acc.com> References: <9402182329.AA29446@fennel.acc.com> I still have a problem with the Added field in the Name-Projection option in NBFCP. All other configuration options in LCP and other NCPs (that I've read) return Configure-Ack on an option without modifying the data that was sent. In my PPP implementation, rather than keep around the entire contents of the last Request for each [LN]CP, I just make a checksum. Then, if a get an Ack, I just compare the checksums. The NBFCP would require me to either: (a) keep all outstanding Requests, (b) re-derive what I think I sent, or (c) implicitly trust the Ack to match my Request. Unfortunately, I don't have a better suggestion for the Name-Projection option. -Jay Laefer jay@gordian.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00574; 19 Feb 94 2:58 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00570; 19 Feb 94 2:58 EST Received: from merit.edu by CNRI.Reston.VA.US id aa01277; 19 Feb 94 2:58 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id CAA09637 for ; Sat, 19 Feb 1994 02:44:51 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA21593; Fri, 18 Feb 94 23:44:44 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA12094; Sat, 19 Feb 94 00:43:28 -0700 Date: Sat, 19 Feb 94 00:43:28 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402190743.AA12094@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: padding and null fragments > From: sklower@vangogh.CS.Berkeley.EDU (Keith Sklower) > ... > Well, Dave, what I think Vern was driving at was that you should have > a multilink packet increasing the sequence number with a payload of > 1 or 2 null bytes, or a multilink encoded empty IP packet > or bending the rule about you can't put LCP headers behind mutlilink > headers just for the case of LCP discard packets or . . . Yes, that was my first idea. My second was formally suggest that the multi-link standard define a "null fragment" to mean "from zero to three zero bytes of payload following a multi-link header with both start and end bits set. It seems to me that is a natural outcome of the code needed to expand (or not) compressed protocol fields. If you don't like that definition, then how about "fewer than 4 bytes of payload after a multi-link header with both start and end bits set." That comes from guessing there should be few legimate packets with a 2-byte protocol fields and 1 byte of data. I also think the "ought to send null fragments" text should say something like "ought to send null fragments within X seconds after the last useful fragment" vjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00770; 19 Feb 94 3:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00766; 19 Feb 94 3:48 EST Received: from merit.edu by CNRI.Reston.VA.US id aa01851; 19 Feb 94 3:48 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id DAA12179 for ; Sat, 19 Feb 1994 03:31:38 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA24888; Sat, 19 Feb 94 00:31:28 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA12392; Sat, 19 Feb 94 01:30:56 -0700 Date: Sat, 19 Feb 94 01:30:56 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402190830.AA12392@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: re: Another multi-link issue > From: tommyd@microsoft.com (Thomas Dimitri) > ... > The current proposal assumes that authentication must occur > and that authentication suffices to distinguish the link. > > I think these assumptions are wrong on both counts. > Forcing authentication is not necessary for private links > and slows down how fast a link can be brought up (which > is actually important for bringing up links on demand). So > requiring it for bundle identification seems unnecessary. To what text are your referring? I just searched the most recent text I've seen, and I cannot find any such assumption or requirement. It says you can, if you wish, use authentication and/or magic numbers. It doesn't say you cannot use prior arrangement or interpretations of the PAP username. > Secondly, the assumption that username is unique per machine is > simply not true. Today (in fact, for the past year), I have users > dialing in from home with basic rate ISDN lines (soon to be a > multi-linked 2 B channel bundle). This user has one username. > This user may also dial in again (simulaneously), from another > site. > > This happens when the user wants to access his/her home > machine and is also at another site and wants to dial-in from > that site also. This occurs today. What kind of internetwork protocol do you use that allows two different hosts to have identical names and be connected simultaneously? If they are never connected simultaneously, there can be no question of what bundle a link joins. Why would you have the user type in the ID? Why not set up different "usernames" for each of the two machines, and have those "usernames" be the ASCII represenation of your 32-bit ID? > The problem also occurs frequently with 'guest' accounts or shared > 'vendor' accounts. This also occurs today. Would you really allow anonymous "guests" to connect to the Microsoft network and roam at will? PPP is not a remote terminal protocol. You are not granting access to a single machine but to all machines on your entire internet (modulo address filters). As has often been said: 1. a guest username for PAP does not need to be "guest". It can be "guest" concantenated with an 32-bit or 64-bit machine ID. The peer can notice the "guest" prefix and authenticate and authorize the prefix and do what you want with the suffix. 2. similar games are available with CHAP. 3. with PAP there is the string in the ACK to identify the machine. Are you sure you are not arguing based on a proprietary dicotomy between the system that handles authentication and the system that handles multi-link PPP? > Therefore, I propose that another LCP multilink option be > added. This option includes the 'username' with a 32 bit > unique machine indentifier (or perhaps 64 bit). The 32 > bit identifier can be derived by several methods (ethernet > addresses, unique machine names, assigned number, > randomly generated). This option identifies the machine. > If authentication is not necessay, this option is all that is needed > to uniquely identify the machine. > > It seems easy enough to do and it solves my two problems. > Any comments? --Thomas Do I understand what you are saying? That you want an exchange that looks like the following on both peers: 1a. send LCP config. request 1b. receive LCP config. request 2a. send LCP config. ACK 2b. receive LCP config. ACK 3a. send MCP config. request containing username+64-bit-ID 3b. receive MCP config. request containing username+64-bit-ID 4a. send MCP config. ACK containing username+64-bit-ID 4b. receive MCP config. ACK containing username+64-bit-ID That takes a total of about 4 round trip times, assuming reasonable behavior by both peers. It is also completely unacceptible for most real commercial networks because it completely lacks any authentication. From what you say the username and ID will be easy to guess from things like email headers. I know a big company that bought a pile of ISDN boxes, and then discovered they lacked both PAP and CHAP. Because you just can't have a router on your wide open, world-wide corporate network with either a modem or an ISDN port without any security, they decided not to use them. There may not be many ISDN-demon-dialers today, but there will be. Consider the required alternative, just for the sake of security: 1a. send LCP config. request 1b. receive LCP config. request 2a. send LCP config. ACK 2b. receive LCP config. ACK 3a. send PAP or CHAP config. request 3b. receive PAP or CHAP config. request 4b. send PAP or CHAP config. ACK 4b. receive PAP or CHAP config. ACK 5a. send MCP config. request with or without username+64-bit-ID 5b. receive MCP config. request with or without username+64-bit-ID 6a. send MCP config. ACK with or without username+64-bit-ID 6b. receive MCP config. ACK with or without username+64-bit-ID I don't see that the additional 2 round trip times will be a significant delay for starting an ISDN line. And they are absolutely required regardless of how you decide to add the link to which bundle purely for security reasons. And once you have the PAP or CHAP packets, you don't need the extra multilink option. Furthermore, you can instead do the entire thing with only 4 round-trip times, overlapping the authentication and MCP handshake: 1a. send LCP config. request 1b. receive LCP config. request 2a. send LCP config. ACK 2b. receive LCP config. ACK 3a. send PAP or CHAP config. request 3b. send MCP config. request with or without username+64-bit-ID 3c. receive PAP or CHAP config. request 3d. receive MCP config. request with or without username+64-bit-ID 4a. send PAP or CHAP config. ACK 4b. send MCP config. ACK with or without username+64-bit-ID 4c. receive PAP or CHAP config. ACK 4d. receive MCP config. ACK with or without username+64-bit-ID (I trust that at B-ISDN speeds you're worried mostly about round trip times caused by geographic separation and delays in the phone system, and not the time required to clock the bits in or out.) Still and all, as long as it is an option, for the sake of making some progress, why not throw in a variable length mult-link ID option with contents locally determined? It will not be used on multi-vendor links, and can easily be either ignored or NAK'ed by the vast majority as required. Please propose words for the standard that are sufficiently precise so that I can write code that correctly NAC's or ignores the option. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15497; 20 Feb 94 12:40 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15493; 20 Feb 94 12:40 EST Received: from merit.edu by CNRI.Reston.VA.US id aa24587; 20 Feb 94 12:40 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA16689 for ; Sun, 20 Feb 1994 12:28:59 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA29181; Sun, 20 Feb 94 09:29:49 -0800 Message-Id: <9402201729.AA29181@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 20 Feb 94 09:29:49 PST X-Msmail-Message-Id: 00EC2655 X-Msmail-Conversation-Id: 00EC2655 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Sun, 20 Feb 94 09:25:55 TZ Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt | From: Jay Laefer | I still have a problem with the Added field in the Name-Projection | option in NBFCP. All other configuration options in LCP and other | NCPs (that I've read) return Configure-Ack on an option without | modifying the data that was sent. Where did you read this? The spec says... If the packet is NOT a Configure-Request or a Configure-Ack the Added field should contain the NetBIOS return code for the NetBIOS Add Name or NetBIOS Add Group Name command as defined in the NetBIOS 3.0 specification [3]. A summary of common result codes is listed below in type hex. So for Config-Ack the data is NOT modified. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16398; 20 Feb 94 15:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16394; 20 Feb 94 15:13 EST Received: from merit.edu by CNRI.Reston.VA.US id aa26551; 20 Feb 94 15:13 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id PAA24103 for ; Sun, 20 Feb 1994 15:02:36 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA00253; Sun, 20 Feb 94 12:03:32 -0800 Message-Id: <9402202003.AA00253@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 20 Feb 94 12:03:32 PST X-Msmail-Message-Id: 222A464C X-Msmail-Conversation-Id: 222A464C X-Msmail-Fixed-Font: 0001 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Sun, 20 Feb 94 12:00:18 TZ Subject: re: Another multi-link issue | From: Vernon Schryver | > From: tommyd@microsoft.com (Thomas Dimitri) | > ... | > The current proposal assumes that authentication must occur | > and that authentication suffices to distinguish the link. | > | > I think these assumptions are wrong on both counts. | > Forcing authentication is not necessary for private links | > and slows down how fast a link can be brought up (which | > is actually important for bringing up links on demand). So | > requiring it for bundle identification seems unnecessary. | | To what text are your referring? | | I just searched the most recent text I've seen, and I cannot find any | such assumption or requirement. It says you can, if you wish, use | authentication and/or magic numbers. It doesn't say you cannot use | prior arrangement or interpretations of the PAP username. The text does not say "an assumption is made that authentication is used to identify the bundle", however, it does mention that authentication occurs on the link, not the bundle, and since the text provides no means identifying the bundle, it can be assumed that this will be the commonly used method of indentifying the bundle. If other vendors do this, they may have an interoperability problem with our implementation. | > Secondly, the assumption that username is unique per machine is | > simply not true. Today (in fact, for the past year), I have users | > dialing in from home with basic rate ISDN lines (soon to be a | > multi-linked 2 B channel bundle). This user has one username. | > This user may also dial in again (simulaneously), from another | > site. | > | > This happens when the user wants to access his/her home | > machine and is also at another site and wants to dial-in from | > that site also. This occurs today. | What kind of internetwork protocol do you use that allows two different hosts to have identical names and be connected simultaneously? I do not believe the internetwork protocol being used provides a means for indentifying the hosts name. I cannot find anywhere in TCP/IP or IPX/SPX internetwork protocols where hostname is mentioned. I believe the question is more related to the authentication mechanism. Although we do use TCP/IP, IPX/SPX, NetBEUI, and XNS, we prefer to use NT style, LanMan style or Kerberos style authentication. The database typically keys off of the username, not the host or machinename (although for some machines, the machinename is the username). | | If they are never connected simultaneously, there can be no question | of what bundle a link joins. | | Why would you have the user type in the ID? Why not set up | different "usernames" for each of the two machines, and have | those "usernames" be the ASCII represenation of your 32-bit ID? Because authentication occurs on the username not the machinename and Administrative persons like dealing with just ONE user account (or perhaps guest account or possibly even vendor account) as opposed to multiple machine account for the same person. | | > The problem also occurs frequently with 'guest' accounts or shared | > 'vendor' accounts. This also occurs today. | | Would you really allow anonymous "guests" to connect to the Microsoft | network and roam at will? Guest accounts are restricted, just like anonymous at FTP. | PPP is not a remote terminal protocol. You | are not granting access to a single machine but to all machines on your | entire internet (modulo address filters). I think you are assuming a PPP connection puts them on the Internet, this is not necessarily the case. Depending on how they connect, they can be reticted by several methods - including, but not limited to, allowing connections to a list of servers via a NetBIOS gateway. | As has often been said: | 1. a guest username for PAP does not need to be "guest". | It can be "guest" concantenated with an 32-bit or 64-bit machine ID. | The peer can notice the "guest" prefix and authenticate and authorize | the prefix and do what you want with the suffix. Unfortunately, once again, the database we authenticate with is per username, thus, we must have the username - not some funky concatenation. Also, it wouldn't make sense client wise to connect up to another vendor's PPP machine and concatentate this number because authentication would fail since the other vendor's PPP machine keys off the username/hostname as well. | 2. similar games are available with CHAP. | 3. with PAP there is the string in the ACK to identify the machine. | | Are you sure you are not arguing based on a proprietary dicotomy | between the system that handles authentication and the system that | handles multi-link PPP? I am sorry Vernon, but I do not understand your dichomatic question. What I am saying, is that a problem exists indentifying the bundle and I am attempting to propose a solution to that problem that some vendors may wish to consider implementing for interoperabilty purposes. Please allow me to restate my concerns: 1. Authentication via standard CHAP or PAP is not sufficient for some vendors to identify the bundle. 2. Furthermore, I do not think that authentication or a proprietary method should have to be run to identify the bundle. | | Do I understand what you are saying? That you want an exchange that | looks like the following on both peers: | | 1a. send LCP config. request | 1b. receive LCP config. request | 2a. send LCP config. ACK | 2b. receive LCP config. ACK | 3a. send MCP config. request containing username+64-bit-ID | 3b. receive MCP config. request containing username+64-bit-ID | 4a. send MCP config. ACK containing username+64-bit-ID | 4b. receive MCP config. ACK containing username+64-bit-ID | | That takes a total of about 4 round trip times, assuming reasonable | behavior by both peers. Um, yes, but I was thinking that the MCP option was an LCP option. Either way, this is what I am saying. The delay in doing authentication exists not only because extra packets are sent but because it may take time to access the database - say a second or two. This time, along with running CHAP/PAP may be enough to miss a protocol's resend packet if the link is dynamically brought up on the first send packet. This is not a big deal for me. It is only a minor point. Another point is the implication that CHAP or PAP be run to indentify the bundle. I think MCP should provide a means for indentifying the bundle. This means should *not* use authentication. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16917; 20 Feb 94 17:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16913; 20 Feb 94 17:50 EST Received: from merit.edu by CNRI.Reston.VA.US id aa28453; 20 Feb 94 17:50 EST Received: from Bill.Simpson.QualComm.com (sprite.qualcomm.com [129.46.36.36]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA02179 for ; Sun, 20 Feb 1994 17:41:37 -0500 Date: Sun, 20 Feb 94 13:31:27 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-ID: <1180.bsimpson@day.dreamer.oakland.mi.us> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: draft-ietf-pppext-dataencap-00.txt > Date: Fri, 18 Feb 94 15:29:19 PST > From: fbaker@acc.com (Fred Baker) > > are we ready to send this off as a standard? > Must be nice to get 1 week preferential treatment.... (I didn't even have time to read it until now). No, it is in need of substantial revision, and will need to wait for the pppext-framerelay to be updated to reference it. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16928; 20 Feb 94 17:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16924; 20 Feb 94 17:50 EST Received: from merit.edu by CNRI.Reston.VA.US id aa28458; 20 Feb 94 17:50 EST Received: from Bill.Simpson.QualComm.com (sprite.qualcomm.com [129.46.36.36]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA02177 for ; Sun, 20 Feb 1994 17:41:37 -0500 Date: Sun, 20 Feb 94 13:30:18 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-ID: <1179.bsimpson@day.dreamer.oakland.mi.us> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: draft-ietf-pppext-for-bridging-03.txt > Date: Fri, 18 Feb 94 15:29:30 PST > From: fbaker@acc.com (Fred Baker) > > are we ready to send this off as a standard? > Yes, I believe that it has been ready for some time. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16938; 20 Feb 94 17:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16934; 20 Feb 94 17:50 EST Received: from merit.edu by CNRI.Reston.VA.US id aa28463; 20 Feb 94 17:50 EST Received: from Bill.Simpson.QualComm.com (sprite.qualcomm.com [129.46.36.36]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA02181 for ; Sun, 20 Feb 1994 17:41:38 -0500 Date: Sun, 20 Feb 94 13:35:15 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-ID: <1181.bsimpson@day.dreamer.oakland.mi.us> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt > From: Thomas Dimitri > Date: Sun, 20 Feb 94 09:25:55 TZ > Where did you read this? The spec says... > > If the packet is NOT a Configure-Request or a Configure-Ack the > Added field should contain the NetBIOS return code for the NetBIOS > Add Name or NetBIOS Add Group Name command as defined in the > NetBIOS 3.0 specification [3]. A summary of common result codes > is listed below in type hex. > > So for Config-Ack the data is NOT modified. --Thomas > Why not just say "is a Configure-Nak"? The data cannot be modified for either the -Ack or -Reject. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17101; 20 Feb 94 18:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17097; 20 Feb 94 18:06 EST Received: from merit.edu by CNRI.Reston.VA.US id aa29005; 20 Feb 94 18:06 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA02650 for ; Sun, 20 Feb 1994 17:56:04 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA25942; Sun, 20 Feb 94 14:55:58 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA23326; Sun, 20 Feb 94 15:55:23 -0700 Date: Sun, 20 Feb 94 15:55:23 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402202255.AA23326@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: re: Another multi-link issue >From: tommyd@microsoft.com (Thomas Dimitri) > ... >The text does not say "an assumption is made that authentication >is used to identify the bundle", however, it does mention that >authentication occurs on the link, not the bundle, and since >the text provides no means identifying the bundle, it can be >assumed that this will be the commonly used method of >indentifying the bundle. If other vendors do this, they may have >an interoperability problem with our implementation. Almost all implementations will use authentication (PAP or CHAP), out-of-band authentication (e.g. getty/login or ISDN call ID), magic numbers, and/or network addresses (e.g. IP) to identify the remote machine, and will implicitly identify the bundle as the unique, otherwise unnamed bundle permitted between the two systems. I do not understand what you mean by "an interoperability problem," but if your implementation will not be able to work with systems that identify the link and the bundle containing the link from no more information than is available in the mechanisms of PAP or CHAP, magic numbers, and IP addresses, then you and Microsoft do have an interoperability problem. Why can't you use LCP magic numbers? Based on what seemed like the final answer from previous rides on the bundle-ID merry-go-round, I have already modified my code to ensure that the first magic number proposed is based on the system's serial number. (I don't think magic numbers are sufficient, but I also think it is formally impossible do anything to identify bundles that is not exactly equivalent to one or more of LCP magic numbers, IP addresses, and PAP or CHAP.) >... >| > multi-linked 2 B channel bundle). This user has one username. >| > This user may also dial in again (simulaneously), from another >| > site. >| > >| > This happens when the user wants to access his/her home >| > machine and is also at another site and wants to dial-in from >| > that site also. This occurs today. >| > >What kind of internetwork protocol do you use that allows two different > >hosts to have identical names and be connected simultaneously? > >I do not believe the internetwork protocol being used provides >a means for indentifying the hosts name. I cannot find anywhere >in TCP/IP or IPX/SPX internetwork protocols where hostname >is mentioned. I'm sorry. By "name" I meant the generic notion of unique identity, which in the IP universe is a 32-bit number, commonly called the "IP address." Other universes have other notions of unique identity, and I didn't want to complicate things by dragging in the notion of "address." My point was that in real life, I do not see why you need to identify a bundle that follows an individual person. If the person goes from one site to another (e.g. home to work) and leaves the bundle connecting the server to the first site alive and then tries to start a new bundle, something must create a new network "address." I seem to recall that you have previously mentioned some kind of automatic bundle ID assignment mechanism. Which seems a lot like IP address negotiation. Oh, well. >I believe the question is more related to the authentication mechanism. >Although we do use TCP/IP, IPX/SPX, NetBEUI, and XNS, we prefer >to use NT style, LanMan style or Kerberos style authentication. >The database typically keys off of the username, not the host >or machinename (although for some machines, the machinename is >the username). > ... >| > The problem also occurs frequently with 'guest' accounts or shared >| > 'vendor' accounts. This also occurs today. >| >| Would you really allow anonymous "guests" to connect to the Microsoft >| network and roam at will? > >Guest accounts are restricted, just like anonymous at FTP. > >| PPP is not a remote terminal protocol. You >| are not granting access to a single machine but to all machines on your >| entire internet (modulo address filters). > >I think you are assuming a PPP connection puts them on the Internet, >this is not necessarily the case. Depending on how they connect, >they can be reticted by several methods - including, but not limited >to, allowing connections to a list of servers via a NetBIOS gateway. I intentionally wrote "internet" instead of "Internet". I assumed that your goal in using PPP or PPP multilink was to connect one computer or a network of computers to distant network of computers (i.e. host-to-router or router-to-router, where "router" is anything that forwards "packets" including a "bridge.") If both ends of the links are computers and not networks, I do not see why one would use PPP. There are much more appropriate schemes. Ah, well. That's none of my business, except when your goals might force me to write and debug extra code. >What I am saying, is that a problem exists indentifying the bundle >and I am attempting to propose a solution to that problem that >some vendors may wish to consider implementing for interoperabilty >purposes. > >Please allow me to restate my concerns: > >1. Authentication via standard CHAP or PAP is not sufficient >for some vendors to identify the bundle. > >2. Furthermore, I do not think that authentication or a proprietary >method should have to be run to identify the bundle. > ... >The delay in doing authentication exists not only because extra packets >are sent but because it may take time to access the database - >say a second or two. This time, along with running CHAP/PAP >may be enough to miss a protocol's resend packet if the link >is dynamically brought up on the first send packet. This is not >a big deal for me. It is only a minor point. Another point >is the implication that CHAP or PAP be run to indentify >the bundle. I think MCP should provide a means for indentifying >the bundle. This means should *not* use authentication. Well, let's agree to disagree on much of that. Do you still agree that in almost all cases, authentication is still required, that indentifying bundles (or end-points or whatever) is not a substitute for PAP or CHAP unless the bundle-ID handshake occurs at the same time as PAP or CHAP and is functionally indentical to PAP or CHAP? Do you agree (I don't recall if you ever did) that most PPP machines do not have access to a unique identifying number or string, since most PPP machines are PC clones which: 1. do not have Ethernet, FDDI or Token Ring cards and so do not have local MAC addresses. 2. do not know their own telephone numbers. 3. might use IP address negotiation and so do not know their own IP addresses. 4. do not have built-in hardware serial numbers, such as are found on more expensive UNIX workstations such as those made by Sun Microsystems and Silicon Graphics. As I wrote last time, in the hope of making progress, please propose text describing the option you require. Please ensure that it is sufficiently precise so that I can write code for my implmentation that will reject or NAK the MCP option, as appropriate. (Or even, unlikely as it is, to implement the option.) Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17126; 20 Feb 94 18:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17122; 20 Feb 94 18:09 EST Received: from merit.edu by CNRI.Reston.VA.US id aa29034; 20 Feb 94 18:09 EST Received: from qualcomm.com (wizard-gw.qualcomm.com [129.46.64.14]) by merit.edu (8.6.5/8.6.5) with ESMTP id RAA02656 for ; Sun, 20 Feb 1994 17:57:28 -0500 Received: from Bill.Simpson.QualComm.com (bill.simpson.qualcomm.com [129.46.36.36]) by qualcomm.com (8.6.5/QC-main-2.3) via SMTP; id OAA17266 Sun, 20 Feb 1994 14:56:57 -0800 for Date: Sun, 20 Feb 94 14:00:32 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-ID: <1183.bsimpson@morningstar.com> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: dataencap-00 > of the PPP entities with regard to the encapsulation of data over Frame > Relay. It is intended to allow entities to exist without supporting > the PPP encapsulation, while still making PPP encapsulation of data the > default, so as to reduce the incidence of certain failure modes which > were considered important. It is certainly possible that this document > does not capture all of the goals/needs of the community, so please > comment. > The general goals seem fine. This follows the prior discussion fairly well. Needs some formatting, but seems well-written. I still object to the use of "native" through-out. It gives the feeling that PPP is somehow an intruder. PPP always follows the "native" encapsulation. That is, PPP uses the NLPID formats already defined for Frame-Relay and X.25 CUD. What it does not use are SNAP headers. I suggest the word "historic" instead, giving reference to the correct historic definition [2]. Alternatively, the word "multi-point" might be used, distinguishing it from "point-to-point" -- Multi-Point-Data-Format option. However, I am unaware that Frame-Relay has completed and published a true non-virtual circuit mechanism with broadcast and multicast capabilities. ---- Indeed, this shouldn't apply to X.25 at all. PPP only uses a separate VC, and therefore won't conflict with any other uses (in their respective VCs). It certainly will not apply to SMDS or ATM (which have no NLPID use). Please remove the references [3] [4] [5]. And update [1] to RFC-1548. ---- This part seems OK, with the changes requested by Dave P. > 4. Loss of State > > This problem affects LCP shared state even in the absence of the > LCP Native-Data-Encapsulation, since the native encapsulation is > used for any protocols for which no NCP has been negotiated. The > use of the LCP Native-Data-Encapsulation option causes the problem > to apply to shared LCP state as well. This would include such > attributes as authentication, IP address assignment, Multi-Link > operation, ... > Instead of the "...", I'd prefer a nice bulleted list: 1) Protocol-Reject (must be disabled, black-holes undetected) 2) header compression (requires shared state) 3) compression protocols (require PPP Protocol, shared state) 4) multi-link protocol (requires PPP Protocol, shared state) 5) self-defining-pad 6) combined-frames 7) protocol-field-compression > Security Considerations > > As outlined in the section on Loss of State, the use of the LCP > Native-Data-Encapsulation option leaves the systems open to > certain undetected restart or replacement scenarios. > > In particular, the strength of the identity associated with any > initial authentication protocol is weakened, since there is the > possibility of replacement of the remote system transparently. > Said replacement includes redirection of the underlying > communications technology. > I think the language is a bit stilted here, and stronger language is in order. More like: Implementations MUST NOT consider PPP authentication to apply to other data formats between the same two systems. This results in possible security lapses due to over-reliance on the integrity and security of switching systems and administrations. An insertion attack might be undetected. An attacker which is able to spoof the same calling identity might be able to avoid link authentication. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17349; 20 Feb 94 19:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17345; 20 Feb 94 19:25 EST Received: from merit.edu by CNRI.Reston.VA.US id aa29856; 20 Feb 94 19:25 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA07139 for ; Sun, 20 Feb 1994 19:15:24 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA02147; Sun, 20 Feb 94 16:16:22 -0800 Message-Id: <9402210016.AA02147@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 20 Feb 94 16:16:22 PST X-Msmail-Message-Id: 87DB2EB1 X-Msmail-Conversation-Id: 87DB2EB1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Sun, 20 Feb 94 16:12:50 TZ Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt | From: "William Allen Simpson" | Why not just say "is a Configure-Nak"? The data cannot be modified for | either the -Ack or -Reject. This is better wording. I can make the change. It seems like a waste to change one sentence (so that it reads better) though and resubmit a whole draft. Is there an easier way?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17524; 20 Feb 94 20:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17520; 20 Feb 94 20:12 EST Received: from merit.edu by CNRI.Reston.VA.US id aa00590; 20 Feb 94 20:12 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA10879 for ; Sun, 20 Feb 1994 20:00:59 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA02495; Sun, 20 Feb 94 17:01:57 -0800 Message-Id: <9402210101.AA02495@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 20 Feb 94 17:01:57 PST X-Msmail-Message-Id: BCC0DA95 X-Msmail-Conversation-Id: BCC0DA95 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Sun, 20 Feb 94 16:58:25 TZ Subject: re: Another multi-link issue | From: Vernon Schryver | >From: tommyd@microsoft.com (Thomas Dimitri) | | Almost all implementations will use authentication (PAP or CHAP), | out-of-band authentication (e.g. getty/login or ISDN call ID), magic | numbers, and/or network addresses (e.g. IP) to identify the remote | machine, and will implicitly identify the bundle as the unique, | otherwise unnamed bundle permitted between the two systems. Yes, *almost* all will. Actually, a lot of them do it out of band, which kinda sucks, but that's what evovled. I am trying to avoid the problem for those implementations that do it out of band or don't always do CHAP or PAP. Even if it is infrequent, it is still a problem that must be solved and dealt with. | I do not understand what you mean by "an interoperability problem," but | if your implementation will not be able to work with systems that | identify the link and the bundle containing the link from no more | information than is available in the mechanisms of PAP or CHAP, magic | numbers, and IP addresses, then you and Microsoft do have an | interoperability problem. It will work, the problem is that another user calling to our system with the same username will incur the bundling problem. Let's say I set up a vendor account and they use SGI machines to dial in over ISDN. Two people, by accident even, both decide to use the same vendor account to dial in. Ooops! The bundle gets screwed up. That is why I want to add it as a multilink option, so that this doesn't occur (or at leat the chance of it occuring is so ridiculously rare, we don't have to worry about it). | Why can't you use LCP magic numbers? Based on what seemed like the | final answer from previous rides on the bundle-ID merry-go-round, I | have already modified my code to ensure that the first magic number | proposed is based on the system's serial number. (I don't think magic | numbers are sufficient, but I also think it is formally impossible do | anything to identify bundles that is not exactly equivalent to one or | more of LCP magic numbers, IP addresses, and PAP or CHAP.) This is a possibility - however it forces LCP to be used and used in certain manner. That is, the same magic number must always be used until that machine goes down. If the multilink draft specifies this, that is cool with me. | | My point was that in real life, I do not see why you need to identify a | bundle that follows an individual person. If the person goes from one | site to another (e.g. home to work) and leaves the bundle connecting | the server to the first site alive and then tries to start a new bundle, | something must create a new network "address." I seem to recall that | you have previously mentioned some kind of automatic bundle ID | assignment mechanism. Which seems a lot like IP address negotiation. | Oh, well. Are we now tying identification to the some sort of unique network addess? Please, let's not do that. The bundle is up before NCP negotiation anyway. If you are suggesting that a unique ID be given, I agree!!! That is what I want. However, that unique ID should *not* be the username given in PAP or CHAP - because for some vendors, it is not necessarily unique. | | >What I am saying, is that a problem exists indentifying the bundle | >and I am attempting to propose a solution to that problem that | >some vendors may wish to consider implementing for interoperabilty | >purposes. | > | >Please allow me to restate my concerns: | > | >1. Authentication via standard CHAP or PAP is not sufficient | >for some vendors to identify the bundle. | > | >2. Furthermore, I do not think that authentication or a proprietary | >method should have to be run to identify the bundle. | | > ... | | >The delay in doing authentication exists not only because extra packets | >are sent but because it may take time to access the database - | >say a second or two. This time, along with running CHAP/PAP | >may be enough to miss a protocol's resend packet if the link | >is dynamically brought up on the first send packet. This is not | >a big deal for me. It is only a minor point. Another point | >is the implication that CHAP or PAP be run to indentify | >the bundle. I think MCP should provide a means for indentifying | >the bundle. This means should *not* use authentication. | | Well, let's agree to disagree on much of that. | | Do you still agree that in almost all cases, authentication is still | required, that indentifying bundles (or end-points or whatever) is not | a substitute for PAP or CHAP unless the bundle-ID handshake occurs at | the same time as PAP or CHAP and is functionally indentical to PAP or CHAP? Authentication is required whenever the system requires PAP or CHAP. It should not in anyway be tied to multilink. I agree that PAP or CHAP is typically required (although I have lots of vendor boxes that can do it out of band and can get dafaulted to just out of band authentication - which worries me a bit). | Do you agree (I don't recall if you ever did) that most PPP machines | do not have access to a unique identifying number or string, since most | PPP machines are PC clones which: | 1. do not have Ethernet, FDDI or Token Ring cards and so do not have | local MAC addresses. | 2. do not know their own telephone numbers. | 3. might use IP address negotiation and so do not know their own IP | addresses. | 4. do not have built-in hardware serial numbers, such as are found | on more expensive UNIX workstations such as those made by | Sun Microsystems and Silicon Graphics. No, I do not agree to this. If you are saying absolutely unique - then I do agree. But the problem is not that difficult for PCs, we need to generate a unique ID that has very high probability - say 10E6 or better of not matching another's. This we can do because we have already written the code to do it for PCs. It is based on a combination of supposedly unique or random numbers. For instance, a supposedly unique name (but not guaranteed) for our software is the machinename (not to be confused by the username which is what gets passed in PAP or CHAP). Another is BIOS serial numbers, another is the internal system clocks microsecond count, and so on. The combination makes for a sufficiently unique ID. | As I wrote last time, in the hope of making progress, please propose | text describing the option you require. Please ensure that it is | sufficiently precise so that I can write code for my implmentation that | will reject or NAK the MCP option, as appropriate. (Or even, unlikely | as it is, to implement the option.) I will do better. I will most likely implement it as well. However, my question is what do other people think? What if I write it up, implement it, and demonstrate it. Will others follow suit? Or will there be a big argument and consensus never develops? I am hoping proposing that a multi-link option be added to uniquely identify the bundle. I am proposing that this option simply pass a constant username+unique ID. The other machine must also do the same! Thus, whichever machine calls the other to add a new link to the bundle, the bundle will always (ok, not always but very very very likely) be identified. I find this option very simple and not difficult to envision. I also find it easy to implement. I also think it solves a real problem in the current multilink proposal. If you wish me to write up the option and submit it, I will do so. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18286; 20 Feb 94 22:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18282; 20 Feb 94 22:01 EST Received: from merit.edu by CNRI.Reston.VA.US id aa02008; 20 Feb 94 22:01 EST Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id VAA16967 for ; Sun, 20 Feb 1994 21:50:16 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@Merit.edu id AA14079; Sun, 20 Feb 94 18:50:09 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@Merit.edu id AA24678; Sun, 20 Feb 94 19:49:37 -0700 Date: Sun, 20 Feb 94 19:49:37 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Message-Id: <9402210249.AA24678@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: re: Another multi-link issue > From: tommyd@microsoft.com (Thomas Dimitri) > ... > | Almost all implementations will use authentication (PAP or CHAP), > | out-of-band authentication (e.g. getty/login or ISDN call ID), magic > | numbers, and/or network addresses (e.g. IP) to identify the remote > | machine, and will implicitly identify the bundle as the unique, > | otherwise unnamed bundle permitted between the two systems. > > Yes, *almost* all will. Actually, a lot of them do it out of band, > which kinda sucks, but that's what evovled. I am trying to avoid > the problem for those implementations that do it out of band > or don't always do CHAP or PAP. Even if it is infrequent, it is still > a problem > that must be solved and dealt with. I do not understand what you mean, what is being solved or dealt with. The only problem I understand is that you find using PAP or CHAP for identifying bundles too slow (because of 1 or 2 seconds of database lookup) and/or inconvenient, and you cannot use IP addresses (because I presume you do not always do IP). > | I do not understand what you mean by "an interoperability problem," but > | if your implementation will not be able to work with systems that > | identify the link and the bundle containing the link from no more > | information than is available in the mechanisms of PAP or CHAP, magic > | numbers, and IP addresses, then you and Microsoft do have an > | interoperability problem. > > It will work, the problem is that another user calling to our system > with the same username will incur the bundling problem. Let's > say I set up a vendor account and they use SGI machines to > dial in over ISDN. Two people, by accident even, both decide > to use the same vendor account to dial in. Ooops! The bundle > gets screwed up. That is why I want to add it as a multilink option, > so that this doesn't occur (or at leat the chance of it occuring > is so ridiculously rare, we don't have to worry about it). There is no need or use or purpose for a bundle ID in that particular case, because no matter what bundle identifying we do, there must be at least 3 IP addresses involved, or the SGI boxes will not be able to talk to the Microsoft box. The SGI boxes will not be happy unless reasonable authentications are exchanged. The SGI boxes will choose IP addresses based on those authentications as well as IPCP. The links will be bundled based on those authentications or the IP addresses. (yes, despite the fact that IPCP comes after LCP.) No bundle ID'ing will be needed or used in that particular case. Also, the chances are zilch that you would ever have such an anonymous guest or vendor PPP account with SGI boxes, because you would not want to open up the entire Microsoft IP internet to random guests and vendors. > | Why can't you use LCP magic numbers? ... > This is a possibility - however it forces LCP to be used and > used in certain manner. That is, the same magic number must > always be used until that machine goes down. If the multilink draft specifies > this, that is cool with me. It will only be used between Microsoft boxes, and maybe between Microsoft and Digiboard boxes, so you guys can "make it so." (Please forgive me if I've misremembered who else wanted bundle ID's) > | Do you still agree that in almost all cases, authentication is still > | required, that indentifying bundles (or end-points or whatever) is not > | a substitute for PAP or CHAP unless the bundle-ID handshake occurs at > | the same time as PAP or CHAP and is functionally indentical to PAP or CHAP? > > Authentication is required whenever the system requires PAP or CHAP. No! Authentication, whether PAP, CHAP, or out-of-band, is required whenever you do not want to let absolutely every bozo with a deamon dialer roam at will through your corporate internet (small 'i') looking for machines with open guest accounts or bad root passwords or .rhosts files or holes in sendmail or holes in rdist. > It should not in anyway be tied to multilink. I agree that PAP or CHAP > is typically required (although I have lots of vendor boxes that > can do it out of band and can get dafaulted to just out of band > authentication - which worries me a bit). The most common out-of-band authentication, login/getty is at least as strong as PAP. > | Do you agree (I don't recall if you ever did) that most PPP machines > | do not have access to a unique identifying number or string, since most > | PPP machines are PC clones which: > | 1. do not have Ethernet, FDDI or Token Ring cards and so do not have > | local MAC addresses. > | 2. do not know their own telephone numbers. > | 3. might use IP address negotiation and so do not know their own IP > | addresses. > | 4. do not have built-in hardware serial numbers, such as are found > | on more expensive UNIX workstations such as those made by > | Sun Microsystems and Silicon Graphics. > > No, I do not agree to this. If you are saying absolutely unique - then >I do agree. But the problem is not that difficult for PCs, we need to generate >a unique ID that has very high probability - say 10E6 or better of not matching > another's. This we can do because we have already written the > code to do it for PCs. It is based on a combination of supposedly unique > or random numbers. For instance, a supposedly unique name (but not > guaranteed) for our software is the machinename (not to be confused by > the username which is what gets passed in PAP or CHAP). Another is BIOS > serial numbers, another is the internal system clocks microsecond count, > and so on. The combination makes for a sufficiently unique ID. That doesn't sound unique enough for a professional grade implementation, but maybe it's good enough for PC's. What about the birthday paradox? I figure that at 1178 peers, you have a 50.02% chance of two peers that pick the same "unique" number among 1,000,000, provided their picks are uniformly distributed and unbiased. Of course, they won't be unbiased, for all of the familar cryptographic reasons: -chances are, a customer will have only 5 or 6 different BIOS's. -if the customer happens to put the dial-the-host command into autoexec.bat, the variations in the microsecond clock will vastly reduced. (do you really mean that BIOS clock interrupt, so you read the 8253? If so, that's not many bits and not at all random) -etc. etc. In other words, not good enough. > | As I wrote last time, in the hope of making progress, please propose > | text describing the option you require. Please ensure that it is > | sufficiently precise so that I can write code for my implmentation that > | will reject or NAK the MCP option, as appropriate. (Or even, unlikely > | as it is, to implement the option.) > > I will do better. I will most likely implement it as well. However, my > question is what do other people think? What if I write it up, implement > it, and demonstrate it. Will others follow suit? Or will there be a big > argument and consensus never develops? > > I am hoping proposing that a multi-link option be added to uniquely > identify the bundle. I am proposing that this option simply pass a constant > username+unique ID. The other machine must also do the same! > Thus, whichever machine calls the other to add a new link to the bundle, > the bundle will always (ok, not always but very very very likely) be > identified. > I find this option very simple and not difficult to envision. I also > find it easy to > implement. I also think it solves a real problem in the current multilink > proposal. If you wish me to write up the option and submit it, I will do so. Unless you manage to make the ID mandatory, it will be optional, and so reliable only among consenting machines. (Not that the lack of a genuinely unique ID strikes me as "reliable.") Most implementors have choosen different paths than you have, and do not need bundle-ID's. The "real problem in the current multilink proposal" seems to be only a problem with certain implementations, not strictly in the protocol. You started out saying that PAP or CHAP authentication is a sufficient solution. (I trust we agree is is not just "very very very likely" to be sufficient, but entirely sufficient). Those of us who do not have whatever implemenations problems you have with PAP and CHAP being fast enough can get along with only PAP or CHAP. We should be allowed to. Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10757; 22 Feb 94 14:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10753; 22 Feb 94 14:27 EST Received: from merit.edu by CNRI.Reston.VA.US id aa13762; 22 Feb 94 14:27 EST Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA02601 for ; Tue, 22 Feb 1994 14:11:30 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA24653; Tue, 22 Feb 94 13:15:06 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA04413; Tue, 22 Feb 94 13:09:55 CST Date: Tue, 22 Feb 94 13:09:55 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9402221909.AA04413@anubis.network.com> To: ietf-ppp@merit.edu Subject: Re: dataencap-00 Bill Simpsons raises some useful questions about the LCP Data Encapsulation draft. 1) The draft uses the term Native to refer to the encapsulation as defined by current RFCs. Bill objects on the groups that this casts PPP as somehow an intruder. While I am somewhat sympathetic, I have not been able to find a good alternative term. "Historic" is an IETF term with specific meaning which does not apply to this situation. Multi-point is not a relevant/distinguishing attitude. So what alternative term should be used, or do we stay with "native"? 2) I give an extensive list of media that this option might apply to, and Bill objects because of how PPP is/can be/ or is not used on these media. We could just restrict this option to Frame Relay. However, I was trying to keep it general, so we could use it as a tool in our toolkit in the future, when this same type of dispute arises again. What do other people think? (In reference to ATM Bill says it does not apply since ATM has no NLPID use. Aside from the fact that ATM does have a frame-relay compatibility mode which uses NLPIDs, the document never talks about NLPIDs. They are not a distinguishing characteristic.) 3) In the section on loss of state, there are potential confusions/issues with the short list of options I give. In part, there is the fact that certain LCP/NCP options simply can not be negotiated along with the native data encapsulation. That is commented on in an earlier part of the draft. This section is concerned about loss of state affecting options which can be negotiated along with "native data encapsulation". This text, while it refers to the LCP shared state shoudl actually be focussed on the NCP shared state, since that is what is affected by this option. (The second reference to shared LCP state should be shared NCP state.) So, should be elaborate on the LCP shared state problems which exist quite apart from this option? Secondly, there is the question of how much of a list we should have. I do not want to try to provide a "exhaustive" list, since then it will have to be updated any time a "relevant" option is created. On the other hand one needs enough of a sample to warn implementors. 4) With regard to security, I am reluctant to go to the degree Bill suggests, in specifying that one must not consider PPP Authentication to apply in this situation. In part, this reluctance stems from the the knowledge that the Authentication option was one of the original goals. In part, it stems from the fact that the overall strength of an authentication mechanism is very context dependent. Even without this option, the PPP Authentication is dependent on certain contextual assumptions about when/how replacement can take place. Particularly with regard to malicious attacks, we are not much weaker than we were. That is why I created the stilted language I did for this section. (I agree with Bill, it is stilted.) Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation PS Thanks to Bill for taking the time to comment on the issues here.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15158; 22 Feb 94 17:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15154; 22 Feb 94 17:54 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20117; 22 Feb 94 17:54 EST Received: from merit.edu by IETF.CNRI.Reston.VA.US id aa15149; 22 Feb 94 17:54 EST Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA01639 for ; Tue, 22 Feb 1994 17:40:21 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA26728; Tue, 22 Feb 94 14:41:18 -0800 Message-Id: <9402222241.AA26728@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 22 Feb 94 14:41:18 PST X-Msmail-Message-Id: 06D17F3C X-Msmail-Conversation-Id: 06D17F3C Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Tue, 22 Feb 94 14:34:15 TZ Subject: Re: dataencap-00 | From: Joel Halpern | | Bill Simpsons raises some useful questions about the LCP Data Encapsulation | draft. | | 1) The draft uses the term Native to refer to the encapsulation as defined | by current RFCs. Bill objects on the groups that this casts PPP as | somehow an intruder. While I am somewhat sympathetic, I have not been | able to find a good alternative term. "Historic" is an IETF term with | specific meaning which does not apply to this situation. Multi-point | is not a relevant/distinguishing attitude. So what alternative term | should be used, or do we stay with "native"? Personally, I do not like the term native data encapsulation, not so much because of the word "native" but because of the word "data" - which is very general. I could argue about other X.25, ISDN, or some evolving ATM data encapsulation modes which are not RFC 1356 or RFC 1483 compliant. I think one significance to all the RFCs you list is that is that they are all multiprotocol encapsulations, so I would change the word "data" to "multiprotocol". I also do not like the word native because it is only native with respect to the Internet community. Since I do not have my Thesaurus handy, I'm not sure what a better word would be. Here are some brainstorms to replace "native data encapsulation"... [another | other] [default | standard | native | common] [Internet | IAB] [multiprotocol] [data] encapsulation perhaps "standard Internet multiprotocol encapsulation" is a good one. I think I like "other multiprocotol encapsulation" best though since it implies no favoritism. | 2) I give an extensive list of media that this option might apply to, | and Bill objects because of how PPP is/can be/ or is not used on these | media. We could just restrict this option to Frame Relay. However, | I was trying to keep it general, so we could use it as a tool in our | toolkit in the future, when this same type of dispute arises again. | What do other people think? I don't think it should be restricted. | (In reference to ATM Bill says it does not apply since ATM has no | NLPID use. Aside from the fact that ATM does have a frame-relay | compatibility mode which uses NLPIDs, the document never talks | about NLPIDs. They are not a distinguishing characteristic.) Hmmm. Isn't it possible to distinguish 1483 from HDLC framing in the payload? The appear quite distinct encapsulation formats to me. --Thomas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13430; 23 Feb 94 17:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13426; 23 Feb 94 17:03 EST Received: from merit.edu by CNRI.Reston.VA.US id aa20570; 23 Feb 94 17:03 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA29672 for ; Wed, 23 Feb 1994 16:48:52 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB13258; Wed, 23 Feb 94 13:48:47 PST Message-Id: <9402232148.AB13258@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Feb 1994 13:48:40 -0800 To: ietf-ppp@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: draft-ietf-pppext-netbios-fcp-04.txt - last call Cc: bsimpson@morningstar.com Folks, this is the last call. Get you nits into Thomas Dimitri by March 8. He will update the draft accordingly and - barring issues - we will be in a position to ship the thing off to the IESG At 1:20 PM 2/23/94 +0000, Thomas Dimitri wrote: >That is fine with me. I think AndyNi has some grammar/spelling fixes for me >too. >---------- >| From: Fred Baker >| At 12:21 PM 2/23/94 -0800, William Allen Simpson wrote: >| >> This is better wording. I can make the change. It seems like a waste >| >> to change one sentence (so that it reads better) though and resubmit a >| >> whole draft. Is there an easier way? >| >> >| >Yeah, wait for more changes. I will try to send more next week. >| > >| >I try not to update more than once every few weeks. The best thing in >| >your case is ask Fred to issue a two week "last call", and then make >| >all the changes requested at once. >| >| Would you like me to do that? ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05865; 25 Feb 94 11:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05861; 25 Feb 94 11:01 EST Received: from merit.edu by CNRI.Reston.VA.US id aa10637; 25 Feb 94 11:01 EST Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA20197 for ; Fri, 25 Feb 1994 10:45:06 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB13378; Fri, 25 Feb 94 07:44:36 PST Message-Id: <9402251544.AB13378@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Feb 1994 07:44:36 -0800 To: ietf-ppp@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "by way of fbaker@acc.com (Fred Baker" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Announcement: Bake-Off '94 ANNOUNCEMENT The 1994 TCP/IP, Windows Sockets and PPP Bake-Off Microsoft would like to follow the successful example provided last year by FTP, TGV and InterCon Systems by hosting the 1994 TCP/IP bake-off. Implementors of TCP/IP, Windows Sockets applications, and PPP products are invited to come together in Redmond, WA to detect (and hopefully resolve) any interoperability problems between products. The "bake-off" is held in the spirit of multivendor cooperation with the goal of delivering customers the finest possible range of interoperable internetworking products. The bake-off is specifically an engineering gathering. Developers and architects should feel free to bring both present and beta implementations of products to test reliability and interoperability in mixed internet environments. Most implementors will choose to bring development and debugging systems along so that fixes can be made and tested in real time. The formal results of the interoperability testing will not be made public - the intent of this event is solely to enhance the quality and interoperability of the participants' products. We plan to hold this event the week of April 18-22 - this is two weeks following the Seattle IETF meeting, and two weeks before Spring Interop. Once we receive feedback, we will draft and circulate a preliminary agenda to the appropriate contact persons. We're hoping that we can expand the scope of this annual event to include PPP and Windows Sockets testing as well. Our current plan is to cover the following areas and protocols: Base TCP/IP (ARP,ICMP,IP,UDP,TCP) NetBIOS over TCP/IP (1001/1002) DHCP (1533/1534/1541/1542) Common IP Applications (FTP,Telnet,DNS, etc...) TCP/IP printing (1179) SLIP, PPP (both TCP/IP and IPX/SPX) Windows Sockets API testing (WSAT) Windows Sockets applications (interoperability matrix) Windows Sockets 2.0 discussion If you are interested please complete and return the following questionaire to bakeoff@microsoft.com. Once we receive the initial feedback from you, we will begin finalizing the schedule and logistics and communicate all details to the contact persons. Name of organization: Contact person: Contact e-mail: Contact phone: Will you be attending (Yes/No/Maybe): Number of engineers attending: What hardware will you be bringing: What protocols are you interested in testing: Special requirements: Additional comments: We're looking forward to hearing your comments and ideas on this year's bake-off. Thanks for your interest and help in making this event successful. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06153; 25 Feb 94 11:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06149; 25 Feb 94 11:17 EST Received: from merit.edu by CNRI.Reston.VA.US id aa10994; 25 Feb 94 11:17 EST Received: from babyoil.ftp.com (babyoil.ftp.com [128.127.2.105]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA21024 for ; Fri, 25 Feb 1994 10:58:39 -0500 Received: from tri-flow.ftp.com by babyoil.ftp.com with SMTP id AA19673; Fri, 25 Feb 94 10:59:03 -0500 Received: from stev.d-cell.ftp.com by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA28134; Fri, 25 Feb 94 10:58:15 EST Date: Fri, 25 Feb 94 10:58:15 EST Message-Id: <9402251558.AA28134@tri-flow.ftp.com.ftp.com> To: ietf-ppp@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: stev knowles X-Orig-Sender: stev@tri-flow.ftp.com Repository: slick-50.ftp.com Originating-Client: d-cell.ftp.com Content-Length: 224 in the process of writing up the ballots for ISDN and Sonet, i need to get some general information about implementations. if you have any implementations, please take a moment to let me know. thanx for your help.