From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 1 12:30:00 1993 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15442; Mon, 1 Feb 93 12:07:41 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04734; Mon, 1 Feb 93 08:47:02 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08233; Mon, 1 Feb 93 08:32:33 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08054; Mon, 1 Feb 93 08:29:23 -0800 Received: by ftp.com id AA17268; Mon, 1 Feb 93 10:47:38 -0500 Date: Mon, 1 Feb 93 10:47:38 -0500 Message-Id: <9302011547.AA17268@ftp.com> To: bill.simpson@um.cc.umich.edu Subject: Re: Meeting in Columbus From: kasten@ftp.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.ucdavis.edu > We haven't finished the MIB work, yet. Bill, With the _current_ mib documents, what needs to be done to give them a start in life as a standard (i.e. Proposed)? These documents are having their SNMP Directorate Review at the IETF. If there is something that absolutely needs to be done for Proposed Standard, I need to know NOW. If you mean new mibs for new things, that's diferent -- we can deal with that at our leisure. -- Frank Kastenholz From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 1 13:29:07 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17715; Mon, 1 Feb 93 13:18:03 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08632; Mon, 1 Feb 93 12:41:15 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16159; Mon, 1 Feb 93 12:30:51 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [138.239.253.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15458; Mon, 1 Feb 93 12:08:19 -0800 Received: from calypso.emulex.com by emulex.emulex.com with SMTP id AA11106 (5.64+/IDA-1.3.4 for ietf-ppp@ucdavis.edu); Mon, 1 Feb 93 12:08:29 -0800 Received: from sjsun.emulex.com by calypso.emulex.com (4.1/SMI-4.0) id AA19401; Mon, 1 Feb 93 12:08:27 PST Received: by sjsun.emulex.com.emulex.com. (4.1/SMI-4.1) id AA01811; Mon, 1 Feb 93 11:24:58 PST Date: Mon, 1 Feb 93 11:24:58 PST From: cec@emulex.com (Cerafin E. Castillo) Message-Id: <9302011924.AA01811@sjsun.emulex.com.emulex.com.> To: ietf-ppp@ucdavis.ucdavis.edu Subject: unsubscribe Please unsubscribe me. Thank you. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Feb 2 11:03:58 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25040; Tue, 2 Feb 93 10:58:19 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15642; Tue, 2 Feb 93 01:29:39 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03814; Tue, 2 Feb 93 01:20:20 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from basil.xylint.co.uk by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03711; Tue, 2 Feb 93 01:12:56 -0800 Message-Id: <11758.9302020911@basil.xylint.co.uk> Received: by basil.xylint.co.uk (4.1/UK-2.1-930112) id AA11758; Tue, 2 Feb 93 09:11:01 GMT From: lawley@xylint.co.uk (Ian Lawley) Date: Tue, 2 Feb 1993 09:11:00 +0000 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: ietf-ppp@ucdavis.ucdavis.edu Subject: Unsubscribe Please unsubscribe me. Thanks -- Ian Lawley tel: +44 908 222112 Technical Support - Networking Products fax: +44 908 222115 Xylogics International Limited email: lawley@xylint.co.uk Featherstone Rd, Wolverton Mill, MK12 5RD, UK. lawley@xylogics.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Feb 2 23:36:16 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22134; Tue, 2 Feb 93 23:24:01 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06924; Tue, 2 Feb 93 23:00:02 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21100; Tue, 2 Feb 93 22:55:36 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cayman.cayman.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20670; Tue, 2 Feb 93 22:44:22 -0800 Received: from cuba.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA24273; Tue, 2 Feb 93 17:58:55 EST Received: from stthomas.Cayman.COM by cuba.Cayman.COM (4.1/SMI-4.1) id AA15158; Tue, 2 Feb 93 17:58:54 EST Date: Tue, 2 Feb 93 17:58:54 EST From: ken@Cayman.COM (Ken Siegel) Message-Id: <9302022258.AA15158@cuba.Cayman.COM> Received: by stthomas.Cayman.COM (4.1/SMI-4.1) id AA04692; Tue, 2 Feb 93 17:51:38 EST To: bill.simpson@um.cc.umich.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Wed, 27 Jan 93 13:31:16 EDT <9042.bill.simpson@um.cc.umich.edu> Subject: Patent License Package for 48 bit CRC Bill, This is, in fact, the way that the patent office works. The way many companies go around this is to do a patent search in a foreign country to find out the contents of the application. However, good patent attorneys for big companies know that this will happen and so usually delay a foreign filing until such time as they will be able to get a definitive answer from the US patent office. I agree it is frustrating. What our lawyer told us is that the best you can do is ask for the text of the patent from the filing company in the very short term (lots of luck there). He also said that if you believe there is sufficient prior art to what you suspect may be claimed that you could ignore the filing and challenge the patent validity if they say you are infringing. Unfortunately, even being right here costs money. In any case, there is definitely no way you are going to get through the US patent office wall of voodoo. My experiences with the patent office are that they are not real good when it comes to software patents. They just don't have the level of expertise required to determine what a person skilled in the art would see as directly following from existing prior art. And that is the acid test for getting a patent. Ken ******************************************************************************* Ken Siegel Internet: ken@cayman.com Cayman Systems, Inc Phone: 617/494-1999 26 Landsdowne Street FAX: 617/494-9270 Cambridge, MA 02139 AppleLink: D0523 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 3 12:53:23 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01821; Wed, 3 Feb 93 12:20:04 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11930; Wed, 3 Feb 93 10:52:18 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22754; Wed, 3 Feb 93 10:45:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21992; Wed, 3 Feb 93 10:24:17 -0800 Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA06608 (5.65c+/IDA-1.4.4); Wed, 3 Feb 1993 13:18:36 -0500 Date: Wed, 3 Feb 93 13:09:36 EDT From: "William Allen Simpson" Message-Id: <898.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Meeting in Columbus > With the _current_ mib documents, what needs to be done to give them a > start in life as a standard (i.e. Proposed)? These documents are > having their SNMP Directorate Review at the IETF. If there is something > that absolutely needs to be done for Proposed Standard, I need to know > NOW. > Thanks for letting us know. The only MIB documents I've seen were posted last July and have expired (although they are still there). I had thought that you were going to make new ones based on your proposed interface revisions (MIB-III?) Perhaps there will be new versions after the review. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 3 17:41:46 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00428; Wed, 3 Feb 93 17:12:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18165; Wed, 3 Feb 93 16:35:14 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10266; Wed, 3 Feb 93 16:29:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09596; Wed, 3 Feb 93 16:08:08 -0800 Received: by ftp.com id AA07197; Wed, 3 Feb 93 19:05:26 -0500 Date: Wed, 3 Feb 93 19:05:26 -0500 Message-Id: <9302040005.AA07197@ftp.com> To: bill.simpson@um.cc.umich.edu Subject: Re: Meeting in Columbus From: kasten@ftp.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.ucdavis.edu > > With the _current_ mib documents, what needs to be done to give them a > > start in life as a standard (i.e. Proposed)? These documents are > > having their SNMP Directorate Review at the IETF. If there is something > > that absolutely needs to be done for Proposed Standard, I need to know > > NOW. > > > Thanks for letting us know. The only MIB documents I've seen were > posted last July and have expired (although they are still there). The drafts may have expired, however, the administrative process sometimes is a bit slower than the relentless march of time. Those drafts were the one's that got submitted and, regardless of the expiration timer, are the ones that are being considered. > I had thought that you were going to make new ones based on your > proposed interface revisions (MIB-III?) For various reasons (like doing what my employer pays me to do) this iftable work has not been started. What we got is what we will get. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 8 09:33:54 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12323; Mon, 8 Feb 93 09:21:35 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05967; Mon, 8 Feb 93 08:50:10 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10748; Mon, 8 Feb 93 08:41:49 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cayman.cayman.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10139; Mon, 8 Feb 93 08:25:50 -0800 Received: from cuba.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA08953; Mon, 8 Feb 93 11:24:26 EST Received: from montserrat.engineering by cuba.Cayman.COM (4.1/SMI-4.1) id AA01248; Mon, 8 Feb 93 11:24:24 EST Date: Mon, 8 Feb 93 11:24:24 EST From: rodney@Cayman.COM (Rodney Hess) Message-Id: <9302081624.AA01248@cuba.Cayman.COM> Received: by montserrat.engineering (4.1/SMI-4.1) id AA03957; Mon, 8 Feb 93 11:24:12 EST To: mathur@telebit.com, mlewis@telebit.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Update to draft-ietf-pppext-cipx-00.txt Will there be any time soon a `draft-ietf-pppext-cipx-01.txt' that incorporates suggestions and modificiations made by people thus far? - Rodney _/_/ _/ _/ _/_/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/_/ _/ _/ _/_/ _/ _/ _/_/_/_/ _/ _/ _/ _/ _/_/_/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ Cayman Systems, Inc. * 26 Landsdowne Street * Cambridge, MA 02139 Rodney P. Hess Read-Time Embedded Systems Engineer Phone: (617) 494-1999 FAX: (617) 494-5167 Internet: rodney@cayman.com AppleLink: D0523 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 8 12:23:12 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17134; Mon, 8 Feb 93 11:53:19 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07964; Mon, 8 Feb 93 11:11:36 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15101; Mon, 8 Feb 93 10:57:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14465; Mon, 8 Feb 93 10:35:35 -0800 Received: from america.TELEBIT.COM (america-bb.telebit.com) by apache (4.1/SMI-4.1/Telebit-Apache-Brent-921227) id AA13905 to ietf-ppp@ucdavis.edu; Mon, 8 Feb 93 10:33:49 PST Received: from yoyo.telebit.com by america.TELEBIT.COM (4.0/america.telebit.com-DBC-921227) id AA16768 to ietf-ppp@ucdavis.edu; Mon, 8 Feb 93 10:33:47 PST Date: Mon, 8 Feb 93 10:33:47 PST From: mlewis@america.Telebit.COM (Mark S. Lewis) Message-Id: <9302081833.AA16768@america.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA13787; Mon, 8 Feb 93 10:33:46 PST To: rodney@Cayman.COM Cc: mathur@Telebit.COM, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9302081624.AA01248@cuba.Cayman.COM> "rodney@Cayman.COM" Subject: Update to draft-ietf-pppext-cipx-00.txt > Will there be any time soon a `draft-ietf-pppext-cipx-01.txt' that > incorporates suggestions and modificiations made by people thus far? > - Rodney > _/_/ > _/ _/ _/_/ _/ _/ _/ _/ _/_/ _/ _/ > _/ _/ _/ _/ _/ _/_/ _/_/ _/ _/ _/_/ _/ > _/ _/_/_/_/ _/ _/ _/ _/ _/_/_/_/ _/ _/_/ > _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ > _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ > Cayman Systems, Inc. * 26 Landsdowne Street * Cambridge, MA 02139 > Rodney P. Hess Read-Time Embedded Systems Engineer > Phone: (617) 494-1999 FAX: (617) 494-5167 > Internet: rodney@cayman.com AppleLink: D0523 Yes, indeed. I would like to give people the month of February to make any comments. At the end of the month, I will update the draft. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Feb 9 19:37:14 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25379; Tue, 9 Feb 93 18:57:46 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04280; Tue, 9 Feb 93 18:37:31 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24446; Tue, 9 Feb 93 18:21:55 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from iha.compuserve.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23793; Tue, 9 Feb 93 18:05:56 -0800 Received: by iha.compuserve.com (5.65/5.930129sam) id AA00772; Tue, 9 Feb 93 19:32:18 -0500 Date: 09 Feb 93 18:55:40 EST From: Jeff Ramsey <70461.1071@CompuServe.COM> To: PPP Subject: PPP ISDN Support Message-Id: <930209235539_70461.1071_DHB30-2@CompuServe.COM> I am interested in finding companies who provide support for PPP on their ISDN products, either ISDN Basic or Primary Rate. Drew Perkins (CMU) suggested I send mail to this address. Thank you for your response, and best regards. Jeff Ramsey Link Technology, Inc. 215-357-3354 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Feb 12 12:51:14 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04335; Fri, 12 Feb 93 12:40:31 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13185; Fri, 12 Feb 93 12:07:03 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03358; Fri, 12 Feb 93 11:56:00 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01852; Fri, 12 Feb 93 11:11:49 -0800 Received: by mts-gw.pa.dec.com; id AA26963; Fri, 12 Feb 93 11:10:17 -0800 Message-Id: <9302121910.AA26963@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Fri, 12 Feb 93 11:10:19 PST Date: Fri, 12 Feb 93 11:10:19 PST From: Jesse Walker To: brad@fcr.com Cc: apple-ip@cayman.com, ietf-ppp@ucdavis.ucdavis.edu Apparently-To: brad@fcr.com, apple-ip@cayman.com, ietf-ppp@ucdavis.edu Subject: Re: current notes on ATCP (implementation notes) Brad Parker writes the following on the AppleTalk mailing list: >> - When negotiating addresses, it is recommended that network numbers >> conflict that both sides pick the lowest of the two conflicting >> network numbers. This will ensure that the negotiation will converge. >> >> - A zero address in a configure-request always requests that the peer >> provide the address information. An address-free link is negotiated by >> leaving out or rejecting the AppleTalk-Address option. In addition to the above, I expected to see a discussion of a configuration Brad and I have been discussing off-line. This is to fix the ATCP Address option (or to add a new option) so that it works in an acceptable manner for host multiplexing, where one device proxies for another. I will first summarize this concept for those who haven't been involved in our discussion, and then describe the problem. Our notion of a host multiplexor works as follows. We require clients attaching to a host multiplexor to play the role of the client in the "client/server" mode of operation, so the client always suggests address 0.0 for itself. When the client does this, the host multiplexor assigns it an address for the duration of the attachment. The host multiplexor would use the normal AppleTalk address acquisition mechanism of its EtherTalk network to allocate the address it assigns the client. When ATCP negotiation completes successfully, the client sends DDP datagrams over its link in the normal way, and the host multiplexor forwards them onto the EtherTalk network for the client. The client receives DDP datagrams from other AppleTalk nodes that are forwarded to it by the host multiplexor. Other nodes know to send packets for the client to the host multiplexor, because the host multiplexor proxy AARPs for the attached client. Now, why does RFC 1378 create problems for this type of arrangement? The reason is the silly requirement for both ends of the link to agree on a "common" network number. If the client and multiplexor really must agree on a common network number, then a real bind occurs. The host multiplexor allocates the address for the attached client from the network range of its EtherTalk. On a large network with a densely packet address space it is rarely possible that the host multiplexor could acquire all the addresses it needs for its attached hosts, and the customer's investment will be marginalized. It seems like the present restriction is needed only when two routers negotiate, and both want to come to some agreement on the network number to protect against, e.g., misconfiguration. But it is not acceptable to design the ATCP protocol so that it can be used only for real routers. This "requirement" instead seems like a completely artifical restriction in the host multiplexing case; there is aboslutely no technical reason I can think of why the client cannot have a network range instead of a single network number on its attachment to the host multiplexor; indeed, AppleTalk hosts have net ranges instead of single network numbers on all other types of media. This is a really onerous situation that needs immediate attention. The simplest thing I can think of is to say the sentence about reaching consensus on "the" network number should not apply in the case where only one side suggests address 0.0 for itself. If the client's peer can assign an address, the client should assume the peer knows what it's doing in this regard. If the peer cannot assign it an address, then it can fall back to the default, which is to operate without an address. Another approach is to introduce a new address option that does the right thing and to mark the existing address option as obsolete. There is a huge market that can be tapped by the host multiplexing style of technology instead. The current restriction on address negotiation cedes this potential application of PPP to ARA. Brad, you and I have talked about this before, and you indicated your willingness to fix the RFC. Will this happen? Jesse Walker Digital Equipment Corporation 550 King Street Littleton, MA (508) 486-7326 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Feb 12 16:57:14 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09672; Fri, 12 Feb 93 16:48:23 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17229; Fri, 12 Feb 93 16:29:41 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09080; Fri, 12 Feb 93 16:21:34 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gatekeeper.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08864; Fri, 12 Feb 93 16:10:16 -0800 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA17565 (5.65c/IDA-1.4.4-910725 for ); Fri, 12 Feb 1993 16:08:46 -0800 Received: by gw.3Com.COM id AA07200 (5.65c/IDA-1.4.4 for ietf-ppp@ucdavis.edu); Fri, 12 Feb 1993 16:08:45 -0800 Date: Fri, 12 Feb 93 15:55 PST From: Robert_Jeckell@3mail.3com.com Subject: ATCP: AURP over PPP (1 of 2) To: ietf-ppp@ucdavis.ucdavis.edu Message-Id: <930212.160912@3Mail.3Com.COM> Forwarded: Message from Robert Jeckell:HQ:3Com of 2-11-93 Folks, I copied the apple-ip list with the message below, but only got one direct response suggesting that maybe there ought to be an AURPCP instead. It certainly would simply the set of negotiable options and thus simplify option interaction considerations. Of course, this could be accomplished by clearly documenting subsets of options that work together and any hierarchical relationships between subset members. I will forward the other mail I sent to apple-ip containing old comments regarding AURP. /bob ------------------------ Forwarded Message ----------------------- Date: Thu, 11 Feb 93 09:51 PST From: Robert_Jeckell@3mail.3com.com Subject: Info on AURP over PPP? To: OPPENHEIME1@applelink.apple.com Cc: apple-ip@Cayman.COM ----------------------------------------------------------------- Although there is a constant defined in the ATCP document to allow negotiation of AURP as the routing protocol, I believe there is some ambiguity in that document concerning AURP. Brad still owes at least one more version of the ATCP document with implementation notes. I will follow this message with some earlier mail on this general area. /bob ---------------------- Replied Message Body ---------------------- Date: 11 Feb 93 00:38 GMT From: OPPENHEIME1@applelink.apple.com (Oppenheimer, Alan) Subject: Info on AURP over PPP? To: APPLE-IP@Cayman.COM Message-Id: <729398277.8167127@AppleLink.Apple.COM> ----------------------------------------------------------------- We are in the process of finalizing the AURP document for publication through APDA and as an Informational RFC. As some of you may have noticed, the section on AURP over point-to-point lines (page 21) is somewhat lacking. Do we have any more information on AURP over PPP? Has a protocol number been assigned for routing information packets? Does the AT-over-PPP RFC have a number? Does anyone have any additional information that should be included? Thanks in advance for any info that anyone can provide. (By the way, now is also the time for any last minute comments or technical corrections which people would like to see included in the document). From ietf-ppp-request@ucdavis.ucdavis.edu Fri Feb 12 17:03:36 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09845; Fri, 12 Feb 93 16:57:52 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17284; Fri, 12 Feb 93 16:35:33 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09083; Fri, 12 Feb 93 16:22:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gatekeeper.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08903; Fri, 12 Feb 93 16:12:55 -0800 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA17603 (5.65c/IDA-1.4.4-910725 for ); Fri, 12 Feb 1993 16:11:23 -0800 Received: by gw.3Com.COM id AA07445 (5.65c/IDA-1.4.4 for ietf-ppp@ucdavis.edu); Fri, 12 Feb 1993 16:11:21 -0800 Date: Fri, 12 Feb 93 16:07 PST From: Robert_Jeckell@3mail.3com.com Subject: ATCP: AURP over PPP (2 of 2) To: ietf-ppp@ucdavis.ucdavis.edu Message-Id: <930212.161149@3Mail.3Com.COM> Forwarded: Message from Robert Jeckell:HQ:3Com of 2-11-93 Here is the other message I also sent to apple-ip containing previous discussion on AURP. What I'm looking for is some confirmation, one way or another on how an IS to IS link should work when AURP is negotiated as the protocol. Very little discussion has appeared on the apple-ip list to straighten out this issue. I haven't seen a consensus on the list. Brad's last message may have come out prior to his seeing my latest mail. I haven't seen any response yet. His statement in the latest summary regarding AURP is present below with other comments. Has anyone implemented AURP over PPP? /bob ------------------------ Forwarded Message ----------------------- Date: Thu, 11 Feb 93 10:12 PST From: Robert_Jeckell@3mail.3com.com Subject: PPP ATCP & AURP To: apple-ip@Cayman.COM ----------------------------------------------------------------- Folks, Here is the promised compilation of earlier mail on ATCP/AURP - latest first. Excuse the repetition, but I don't feel up to spending time editing the material down. Another question: Is ATCP negotiation of a network address and AURP mutually exclusive? Should we assume that if you can handle AURP on a port, you don't need an associated AppleTalk node address for that port? Should we allow both just for flexibility of implementation? Do we want to encourage any particular approach? /bob ----------------------------------------------------------------- To: Robert_Jeckell@3mail.3com.com Subject: Re: summary of notes on ATCP Date: Thu, 05 Nov 92 21:41:29 EST From: Brad Parker ----------------------------------------------------------------- >> - A valid implementation of ATCP always accept "DDP in PPP". It must >> also accept EDDP if the AURP routing protocol is negotiated. Note that >> no number has been assigned to the proposed EDDP encapsulation scheme. >> I believe that this is Apple's responsibility since they control the >> AURP protocol. >> >> This still puzzles me. How can DDP and EDDP be mixed on an AURP >> negotiated connection. Doesn't the problem of ambiguity in >> packet interpretation exist? As I have said before, I think that AURP >> requires EDDP to differentiate between AppleTalk data packetes and AURP >> packets. you may have a point here. >> I think this needs to be spelled out in the ATCP document. There is >> the question I raised earlier whether the body of Brad's draft RFC on >> EDDP format should be incorporated into the ATCP document or kept >> separate. I have no problem with keeping it separate and referenced, >> but it is another piece of baggage that must go along with the ATCP >> document. humm. here too. -brad ----------------------------------------------------------------- Date: 11-5-92 11:14am From: Robert Jeckell:HQDev:3Com To: {brad@fcr.com}:ugate:3Com cc: {pshuen@na.novell.com}:ugate:3Com,{billw@regal.cisco.com}:ugate:3Com, {brian@lloyd.com}:ugate:3com, Robert Jeckell:HQDev:3Com Subj: summary of notes on ATCP ----------------------------------------------------------------------- [From Brad:] - A valid implementation of ATCP always accept "DDP in PPP". It must also accept EDDP if the AURP routing protocol is negotiated. Note that no number has been assigned to the proposed EDDP encapsulation scheme. I believe that this is Apple's responsibility since they control the AURP protocol. [ my response ] This still puzzles me. How can DDP and EDDP be mixed on an AURP negotiated connection. Doesn't the problem of ambiguity in packet interpretation exist? As I have said before, I think that AURP requires EDDP to differentiate between AppleTalk data packetes and AURP packets. I think this needs to be spelled out in the ATCP document. There is the question I raised earlier whether the body of Brad's draft RFC on EDDP format should be incorporated into the ATCP document or kept separate. I have no problem with keeping it separate and referenced, but it is another piece of baggage that must go along with the ATCP document. ----------------------------------------------------------------- To: Robert_Jeckell@3mail.3com.com Cc: apple-ip@Cayman.COM Subject: Re: PPP ATCP (EDDP and Routing Protocol option) Date: Fri, 09 Oct 92 21:33:43 -0400 From: Brad Parker ----------------------------------------------------------------- If I'm responding to a non-question, well.... laugh at me in washington! -brad >> At the risk of sounding stupid, I still don't understand how you >> can allow both EDDP encapsulated and straight DDP over PPP at the >> same time and tell the difference. Did I misread? "DDP over PPP" and "EDDP over PPP" must have different PPP protocol numbers. So, you demux and deencapsulate like any other protocol. >> As I understand it, AURP over any point to point link can only >> dispense with the EDDP header if separate channels exist for >> routing info and data. So I would think that negotiating AURP in >> ATCP means always using EDDP. glug. I don't understand this. I thought the src & dst DI would aid in demultiplexing. >> Whether a particular protocol/encapsulation is mainstream or not is >> beside the point. I'm looking for a non-ambiguous statememt of the >> meaning of each ATCP routing-protocol and what it means in terms of >> encapsulation. ok. I want to say this: You must always accept "DDP in PPP". You must also accept EDDP if you negotiate AURP. But my brain says I should say this: You must accept "DDP in PPP" unless you negotiate AURP, in which case you must accept EDDP and reject "DDP in PPP" since it's ambigous. I need to think about this a bit more (is it obvious? ;-) -brad ------------------------ Forwarded Message ----------------------- Date: Wed, 7 Oct 92 09:46 PDT From: Robert_Jeckell@3mail.3com.com Subject: Re: PPP ATCP (EDDP and Routing Protocol option) To: apple-ip@Cayman.COM Forwarded: Message from {brad@fcr.com}:ugate:3Com of 10-7-92 ----------------------------------------------------------------- A response from Brad below (thanks)... At the risk of sounding stupid, I still don't understand how you can allow both EDDP encapsulated and straight DDP over PPP at the same time and tell the difference. Did I misread? As I understand it, AURP over any point to point link can only dispense with the EDDP header if separate channels exist for routing info and data. So I would think that negotiating AURP in ATCP means always using EDDP. Whether a particular protocol/encapsulation is mainstream or not is beside the point. I'm looking for a non-ambiguous statememt of the meaning of each ATCP routing-protocol and what it means in terms of encapsulation. An update of the AppleTalk EDDP over PPP document may be useful. Should it be referenced in the ATCP document and vice versa? /bob ------------------------ Forwarded Message ----------------------- Subject: Re: PPP ATCP (EDDP and Routing Protocol option) Date: Wed, 07 Oct 92 08:24:49 -0400 From: Brad Parker ----------------------------------------------------------------- >> phil@Shiva.COM said: >> >> > From Chris: "Then I have some questions. AURP still in UDP/IP >> > is no sweat: use IPCP, not ATCP. >> >> > If you're assuming EDDP over ATCP, what do you use as the DI's >> > now that we don't have IP addresses? Has anyone built this?" >> >> You can't speak EDDP over ATCP (unless you assign it a DDP type)!! This >> is why Brad wrote a document for EDDP over PPP. >> >> What was never clear to me was what does the "AURP" routing protocol >> option in ATCP mean? Do you speak DDP over ATCP (with presumed NULL >> DI's) and AURP over EDDPCP????? >> >> Can anyone clear this up? I haven't heard anything on the list. My understanding was that negotiating the AURP routing protocol with ATCP implied that you would accept packets of the type defined for EDDP. (for which there is no assigned number, yet). My assumtion was that you would also be required to continue accepting stock ATCP encapsulated DDP datagrams also. I tried to bring this point out of obscurity in the document (and, obviously, I did not achieve this goal ;-) >> I guess I was under the impression that the AURP routing protocol option in >> ATCP indicated that all AppleTalk traffic would be in EDDP headers. I >> interpret Brad's document as filling a void in the ATCP document, although >> I don't see any explicit connections although the bottom of page 7 of ATCP >> does make reference to EDDP. >> >> Would it be appropriate to include the body of Brad's document in the ATCP >> document? I did not think so at the time, because it seemed that AURP and EDDP would not be the "mainstream" uses of ATCP. Perhaps this has changed. If you asked me, I would probably still say this is the case. I can ressurect my "EDDP over PPP encapsulation" and add some verbage to explain more how it will operate. -brad ps: Bob - I did not forward this to the list, since your message was not. If would not mind if you did forward this to the list - your option. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Feb 12 17:12:05 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10066; Fri, 12 Feb 93 17:07:12 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17736; Fri, 12 Feb 93 16:49:57 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09524; Fri, 12 Feb 93 16:43:21 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gatekeeper.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09130; Fri, 12 Feb 93 16:24:44 -0800 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA17659 (5.65c/IDA-1.4.4-910725 for ); Fri, 12 Feb 1993 16:23:11 -0800 Received: by gw.3Com.COM id AA07952 (5.65c/IDA-1.4.4 for ietf-ppp@ucdavis.edu); Fri, 12 Feb 1993 16:23:10 -0800 Date: Fri, 12 Feb 93 16:17 PST From: Robert_Jeckell@3mail.3com.com Subject: current notes on ATCP (implementation notes) To: ietf-ppp@ucdavis.ucdavis.edu Message-Id: <930212.162336@3Mail.3Com.COM> Forwarded: Message from {brad@fcr.com}:ugate:3Com of 2-12-93 I put out two previous messages under the assumption that Brad copied ietf-ppp with a message on ATCP. Since he only copied apple-ip, I'm taking the liberty of copying this list as well to provide a target for my previous references. Brad, I hope you don't mind. /bob ------------------------ Forwarded Message ----------------------- Date: Fri, 12 Feb 93 09:14:53 EST From: brad@fcr.com (Brad Parker) To: apple-ip@Cayman.COM Subject: current notes on ATCP (implementation notes) ----------------------------------------------------------------- Here's my current notes. No numbers have been assigned for AURP. Since no one else has jumped forward, I have taken it upon myself to get numbers assigned for both AURP and "smartbuffering". The requirement is that a small document be written for each protocol number. I have written these documents and will mail them to the list when I ask IANA for the numbers. ----- cut here ----- Notes on Implementing ATCP (AppleTalk over PPP) This document is intended as implementor's notes for RFC1378 brad@fcr.com Summary: - When negotiating addresses, it is recommended that network numbers conflict that both sides pick the lowest of the two conflicting network numbers. This will ensure that the negotiation will converge. - A zero address in a configure-request always requests that the peer provide the address information. An address-free link is negotiated by leaving out or rejecting the AppleTalk-Address option. - Configuring the link to use "half-routing" (i.e. rejecting any address option) is advantagous since it requires no address configuration. Configuring an address for the PPP link is only support for routers which can not support half-routing or links with no address. - When the link is configured for half-routing, all control packets (i.e. RTMP, ZIP) should be addressed to and from 0.0. The link is defined as non-extened phase 2, so RTMP packets should being with "0 0 8 0 0 0 0x82". Since the link has no network number, no zone information will be negotiated for the link. Someone suggested this be stated as, "AppleTalk RTMP and ZIP packets originating from either IS and destined to the other IS MUST use source and destination node addresses of 0.0. This also applies to the sender's network number and node id found in RTMP packets." - A question was raised about the "next hop" address used for received RTMP packets. I believe this is not relivant. Any routes aquired via an RTMP on a PPP link should point back to the PPP link. Packets forwarded using this route will be addressed to the destination. Since the encapsulation stops at DDP, and the "next hop" addresses the link layer (which in this case is PPP), the "next hop" address is not relivant to PPP. (since PPP is not multipoint) - When the link has a negotiated address, the zone for the network formed by the PPP link can be aquired using the ZIP protocol, sending the ZIP queries to the address of the other side of the link (this should be fairly obvious) - In the "ES-IS" case (end node connected to router/forwarder), if the router/forwarder is not routing, the network number can be zero. It is acceptable to forward datagrams to/from the ES with network number zero if the forwarder is connected to an appletalk network which has no router. If the forwarder is configured for phase 2 localtalk, it will pick a network number in the startup range, and the network number *will not* be zero. If, however, the forwarder is configured for phase 1, the network number *will* be zero. - A valid implementation of ATCP always accept "DDP in PPP". It must also accept EDDP if the AURP routing protocol is negotiated. Note that no number has been assigned to the proposed EDDP encapsulation scheme. I believe that this is Apple's responsibility since they control the AURP protocol. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 15 06:50:38 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17486; Mon, 15 Feb 93 06:49:48 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03064; Mon, 15 Feb 93 06:29:42 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16491; Mon, 15 Feb 93 06:21:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16376; Mon, 15 Feb 93 06:17:52 -0800 Received: by mts-gw.pa.dec.com; id AA00463; Mon, 15 Feb 93 06:16:15 -0800 Message-Id: <9302151416.AA00463@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Mon, 15 Feb 93 06:16:20 PST Date: Mon, 15 Feb 93 06:16:20 PST From: Jesse Walker To: brad@fcr.com Cc: apple-ip@cayan.com, ietf-ppp@ucdavis.ucdavis.edu Apparently-To: brad@fcr.com, apple-ip@cayan.com, ietf-ppp@ucdavis.edu Subject: Re: current notes on ATCP (implementation notes) Please recall the text that ellicited my diatribe last Friday; Brad Parker wrote the following on the AppleTalk mailing list: - When negotiating addresses, it is recommended that network numbers conflict that both sides pick the lowest of the two conflicting network numbers. This will ensure that the negotiation will converge. If you think about this for a moment, you'll see the ATCP address option is improperly formulated, because it does not permit the peers to exchange all the information they need to know to discover whether the addresses they negotiate are valid. The option is being overloaded to serve two distinct functions. It is being used to negotiate AppleTalk addresses at either end of a PPP link, but it is further being abused to negotiate the network range as well. However, an AppleTalk node really needs both pieces of information to establish the validity of an AppleTalk address. The problem exists because the option performs the second function in a technically sub-optimal way. The option does not really indicate the network range as a range, instead falsely assuming that a serial need have a network range of only a single number. While this is a natural hypothesis, potential applications exist which can exploit a larger range, as I indicated Friday. In order to deploy PPP as widely as possible, we need to fix the option so it does not arbitrarily restrict the applications it can support effectively. I can imagine at least three possible ways to fix the problem. (1) We could remove all restrictions on the network number portion of the address during ATCP negotiations. Once the negotiation concludes, each party could use ZIP or RTMP to learn the notion its peer has of the network range. If this notion of the range does not coincide with their own, they would have to re-enter ATCP negotiations, probably retaining state to guide the process; in this case, both parties would want to use some algorithm like Brad has proposed when suggesting new addresses for themselves. I do not see how to guarantee that both peers would be aware of what they have to do when renegotiation occurs, and suspect this technique is unworkable. (2) We can introduce a new option for negotiating the network range. Each party to an ATCP negotiation would be required to include this option whenever they also suggest the address option. The address an ATCP peer suggests for itself would have to fall within the network range it suggests. The range 0 to 0xfffe would be the "I don't care" range, indicating the party is willing to use any network range its peer proposes. And range conflicts would be resolved according to Brad's algorithm: the peer suggesting the lowest (non-zero) range start wins. An approach along these lines is clearly workable, but ties two options together is a somewhat unnatural way. (3) We could declare the ATCP address option obsolete, and replace it with a new option that proposes three fields: a network range start, a network range end, and an address in that range. It would combine the semantics of (2) above with the existing address option. I believe this is the simplest solution all around. Comments? Jesse Walker Digital Equipment Corporation 550 King Street LKG1-2/E19 Littleton, MA 01460-1289 (508) 486-7326 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Feb 16 17:27:55 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12731; Tue, 16 Feb 93 17:11:07 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25203; Tue, 16 Feb 93 16:42:01 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11500; Tue, 16 Feb 93 16:32:51 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11089; Tue, 16 Feb 93 16:17:36 -0800 Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA20275 (5.65c+/IDA-1.4.4); Tue, 16 Feb 1993 19:10:40 -0500 Date: Tue, 16 Feb 93 18:44:43 EDT From: "William Allen Simpson" Message-Id: <966.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: CIPX version S Over a month ago, I sent a pile of revisions to CIPX to Telebit. Since then, apparently Saroop isn't there anymore, and I haven't heard anything. In the hope of getting the discussion going on this, here's what I sent. The versions that Telebit and Novell have written are slightly different from each other, and not interoperable. Also, there were some serious errors in assumptions about packet length, and missing information about confirmation of NCP packets. This one is slightly different from each of them. It is interoperable with both Telebit and Novell for IPX compression, and probably with Telebit for NCP/IPX compression. I changed some of the names (Uncompressed -> Initial, Ack -> Confirm), improved the spelling and re-organized the sections. Network Working Group Saroop Mathur Internet Draft Mark S. Lewis Telebit Corp. Expires in six months January 1993 Compressing IPX Headers Over WAN Media (CIPX) Status of this Memo This draft is a proposed standard protocol for the Internet community and requests discussion and suggestions for improvement. This document is being submitted to the Internet Engineering Task Force (IETF) through the Point-to-Point Protocol Working Group. Comments should be sent to the authors and 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 IETF, its Areas, and it's Working Groups. Internet Drafts are valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. Abstract This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX will provide a compression ratio of approximately 2:1. This method can be used on various type of WAN media, including those supporting PPP and X.25. Mathur, Lewis expires in six months [Page 1] DRAFT CIPX January 1993 Introduction Internetwork Packet Exchange (IPX) is a protocol defined by the Novell Corporation. It is derived from the Internet Datagram Protocol (IDP) protocol of the Xerox Network Systems (XNS) family of protocols. IPX is a datagram, connectionless protocol that does not require an acknowledgment for each packet sent. The IPX protocol corresponds to the network layer of the ISO model. Usually, there is a transport layer protocol above IPX. In the case of IPX, by far the most common transport protocol is the Netware Core Protocol (NCP), which is used for file server access. The Sequenced Packet Exchange (SPX) is the reliable connection- based transport protocol commonly used by applications. The IPX packet consists of a 30 octet IPX header, usually followed by the transport layer protocol header. The NCP header is 6 octets. The SPX header is 12 octets. Two strategies are described below for compressing IPX headers. This specification requires that implementations of CIPX support both IPX header compression strategies. These algorithms are based on the header compression description for TCP/IP packets written by Van Jacobson [1]. The first strategy is to compress only the IPX header. This compression algorithm can be used to compress any IPX packet, without affecting the transport protocol. This algorithm compresses a 30 octet IPX header into a one to seven octet header. The second strategy is to compress the combined IPX and NCP headers. This algorithm compresses only NCP packets with NCP type of 0x2222 and 0x3333. This algorithm compresses a 36 octet NCP/IPX header into a one to eight octet header. Lastly, note that it is possible, and many times desirable, to use this type of header compression in conjunction with some type of data compression. After intelligently compressing the packet header, data compression can be effective in reducing packet size further. It is important that data compression should be done after header compression. Conversely, data decompression should be done before header decompression. Mathur, Lewis expires in six months [Page 2] DRAFT CIPX January 1993 IPX Compression Algorithm The normal IPX header consists of the following fields: checksum, packet length, transport control (hop count), packet type, destination and source address fields. +-----------------------+ | Checksum | +-----------------------+ | Packet Length | +-----------+-----------+ | Hops |Packet Type| +-----------+-----------+ | Destination | | Address | | (12 Octets) | +-----------------------+ | Source | | Address | | (12 Octets) | +-----------------------+ IPX PACKET HEADER The IPX header diagram above is shown without the unnecessary field alignment details. Consider each field of the IPX header separately, and how it typically changes. Historically, Novell has not used the Checksum field in the IPX header, and has required that this field be set to 0xFFFF. Since the checksum remains constant, it is clear that the checksum can currently be compressed. When Checksums are implemented, it will be necessary to include the checksum in each compressed packet. Recalculating the checksum would destroy the end-to-end reliability of the connection. For most links, the Packet Length can be determined from the MAC layer. There are cases in which the length cannot be determined from the MAC layer. For example, some hardware devices want to pad packets to a required minimum length. For links where it is not possible to determine the IPX packet length from the MAC layer, packet length needs to be included in the compressed packet. The Transport Control (Hops) field usually does not change between two end-points. For the purposes of compression, we will assume Mathur, Lewis expires in six months [Page 3] DRAFT CIPX January 1993 that it never changes, and will not examine this field when determining a connection. The Packet Type field is constant for any connection. The Destination and Source Address fields are each made up of 12 octets: Network (4 octets), Node (6 octets), and Socket (2 octets) fields. For any specific IPX connection, the Destination and Source Address fields are constant. Hence, the fields that may need to be included in the compressed IPX header are the checksum and the packet length. While using this IPX header compression algorithm, packets can be lost. The loss of an Initial packet presents a problem. In this case, if the sender later tries to send a compressed packet, the receiving end cannot decompress the packet correctly. There is not sufficient information in the IPX header alone to determine when a re-transmission has occured. For this reason, it is necessary that the sender of an Initial packet be guaranteed that the packet has been received. Therefore, we provide a mechanism for Confirmation of an Initial packet. Mathur, Lewis expires in six months [Page 4] DRAFT CIPX January 1993 NCP/IPX Header Compression Since most IPX packets are Netware Core Protocol packets (packet type 17), compressing the NCP header will give us added performance. +------------+ | NCP | | Type | +------------+ | Sequence | | Number | +------------+ | Connection | |(low octet) | +------------+ | Task | | Number | +------------+ | Connection | |(high octet)| +------------+ NCP HEADER The NCP header is 6 octets in length consisting of the following fields: NCP type, sequence number, connection number and task number. The NCP type field values that are currently defined are: 1111 Create Connection 2222 NCP request from workstation 3333 NCP reply from file server 5555 Destroy Connection 7777 Burst Mode Packet 9999 Server Busy Packet This NCP header compression algorithm only compresses packets that have a type field value of 0x2222 or 0x3333. All other types of packets are not compressed at the NCP level. If NCP type is 0x2222, then this packet is a request from the client to the server. If NCP type is 0x3333, then this is a Mathur, Lewis expires in six months [Page 5] DRAFT CIPX January 1993 response from the server to the client. The connection number is a constant for a given connection. The sequence number is increased by one for each new request. Hence the sequence number can be determined implicitly. The decompressor increments the sequence number for each compressed packet it receives for a connection. The task number can change unpredictably, although it might remain constant for several packets. If the NCP task number is different than the last one for this connection, then the NCP task number must be included. If the NCP packet is lost, it will be retransmitted through the normal transport layer mechanisms. The Initial NCP packet does not require confirmation, as a re-transmitted packet can be easily identified. This is accomplished by comparing the sequence number of the packet to the sequence number of the previous packet. If the sequence number is not exactly one greater than the previous packet, a new Initial packet must be sent, although the same connection slot may be used. NCP Burst Mode Packets The burst mode protocol uses the NCP type value of 0x7777. This type of packet does not have the normal NCP header described above. Instead, it has a 36 octet burst header. The above NCP header compression algorithm should not be used to compress this packet. The IPX header in this packet is still compressible with the IPX header compression algorithm described. SPX Packets SPX packets are typically used by applications which require reliable service such as print servers. It is possible to apply a similar NCP/IPX technique to SPX/IPX packets. At this time, we have not described such a mechanism. The IPX header in this packet is still compressible with the IPX header compression algorithm described. Mathur, Lewis expires in six months [Page 6] DRAFT CIPX January 1993 Compression Header IPX compression must be negotiated by some means (eg. IPXCP or IPXWAN). Each end must negotiate the desired options, such as the maximum number of concurrent connections which will be maintained in each direction. Once IPX compression is negotiated, all IPX packets sent over that link have a CIPX header added to the beginning of the packet. The one octet CIPX header is added even when a regular IPX packet is sent over the link. By including the CIPX header on every packet, we support the ability to run CIPX over various WAN links as if it were a normal IPX packet. It does not rely on any new link specific packet demultiplexing. Implementations of this compression protocol must maintain send and receive tables indicating the state of each connection. The original header for each connection is stored in a "slot". Typically, each client-server connection will use a separate slot. Both sides keep a copy of the full IPX header corresponding to each slot. The sending side (compressor) uses this information to determine the fields that have changed. The receiving side (decompressor) uses this information to reconstruct the original packet header. The CIPX packet header specifies the type of the packet and any options for that packet. The basic header is one octet in length. 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | | | | | | | | | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 0 Regular | | | | | 1 Compressed | | | | | 2 Confirmed Initial | | | | | 3 Confirmation | | | | | 4 Unconfirmed Initial | | | | | 5-6 Reserved | | | | | 7 Never Used | | | | | |__ |__ |__ |__ |_______________ Packet Type Dependent Flags FLAGS OCTET Mathur, Lewis expires in six months [Page 7] DRAFT CIPX January 1993 As can be seen above, the low order 3 bits specify the packet type. Note that the Flags octet MUST NOT contain the value 0xFF. This is necessary to distinguish the CIPX flags octet from a normal IPX header with a 0xFFFF checksum field. It is important to be able to recognize a normal IPX header regardless of the state of compression. It is possible with some link layer protocols such as X.25 Permanent Virtual Circuits that one end of the link may fail and start sending IPX packets. Therefore, Packet Type 7 is reserved to prevent the Flags octet from containing 0xFF. For each different packet type, there are associated flag bits, which are described below. All bits that are reserved or are not specified must be set to zero. Mathur, Lewis expires in six months [Page 8] DRAFT CIPX January 1993 Regular Packet The Regular packet type designates an IPX packet for which no compression is desired. This type of packet is sent when a packet cannot be compressed, or a decision is made not to compress. 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 0 Regular Packet | | | | | |__ |__ |__ |__ |_______________ Reserved (must be zero) The Regular packet is rarely sent. Usually, the Regular packet is sent when there isn't enough space for the extra overhead for a new compression slot. Also, this type is included for future unforeseen changes to the IPX protocol which defeat the effectiveness of compression. Implementation Note: The Regular Packet can be used for packets that are sporadic, which aren't worth tying up a compression slot. This is sometimes hard to determine for specific protocols, and various methods such as hold-down and least-recently-used timers are currently being used in early implementations. On receipt, the 1 octet header is simply removed and the packet passed up to IPX. The entire IPX packet follows the single Flags octet. Note for a Regular Packet (not compressed or uncompressed), the slot number field is not included. Mathur, Lewis expires in six months [Page 9] DRAFT CIPX January 1993 Compressed Packet This type of packet does not contain a packet header (either 30 byte IPX, or 36 byte NCP). A slot number indicates to the receiver which saved header to use to formulate the original packet header before passing the packet up to IPX. 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | | | | | 0 | 0 | 0 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 1 Compressed Packet | | | | | | | | | |_______________ Reserved (Must be zero) | | | | | | | |___________________ Task Number (NCP only) | | | 0 Assume same as last packet | | | 1 Included in packet | | | | | |_______________________ Length | | 0 Determine from MAC length | | 1 Included in packet | | | |___________________________ Checksum | 0 Assume 0xFFFF | 1 Included in packet | |_______________________________ Slot Number 0 Assume same as last packet 1 Included in packet Consider each flag in the flags octet, looking at the high order bits working toward the lower order bits. Each of the fields is optional, but if present will be found in the same order in the compressed packet header. Slot Number The slot number flag indicates the slot number field is included in the compressed packet. The slot number field is one octet in length and specifies the number of the slot which corresponds to the Initial packet header. Slots are numbered starting at zero and continue to the maximum number of slots Mathur, Lewis expires in six months [Page 10] DRAFT CIPX January 1993 minus one. By default, slot compression is disabled, and every packet has the slot number included. If negotiated, slot compression can be enabled for those slots which were created by the Unconfirmed Initial packet. When slot compression is enabled and the packet is from the same slot, the compressor clears the slot number flag and omits the slot number field. Implementation Note: Slot compression MUST only be enabled in a receiver which can account for all erroneous and discarded packets. When a packet has been discarded, the slot number is indeterminate for future packets. The decompressor MUST discard all further packets until a slot number is received. Checksum If the checksum flag is set, the compressed packet will include the 2 octet checksum. If this flag is not set, then the decompressor assumes the checksum is 0xFFFF. Note that meaningful checksums must be included in the packet with the flag set. The length flag indicates the inclusion of the IPX data length field in the compressed packet. If the length field is included, it specifies the length of IPX data in the packet prior to compression. It does not include the flags, slot number, the checksum, the length field, or the NCP task number. Note that it is preferable to determine the length field from the MAC layer whenever possible. Length Since every octet is significant over lower speed WAN links, an optimization is used in the specification of the length. It can be specified as a one, two or three octet field. If the length is in the range 0 to 127, then it is specified as a one octet field. If the length is in the range 128 to 16383, it is specified as a two octet field in high to low order, with the first octet in the range 128 to 191. Otherwise, if the length is greater than 16383, the first octet contains 192, and the second and third octets contain the full length. (This scheme is extensible to 8 octets, but nothing gets that big in IPX.) Mathur, Lewis expires in six months [Page 11] DRAFT CIPX January 1993 +-+-+-+-+-+-+-+-+ |0| length | 0 <= length < 128 +-+-+-+-+-+-+-+-+ ONE OCTET LENGTH FIELD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| length | 128 <= length < 16384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TWO OCTET LENGTH FIELD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0 0 0 0| length | 16384 <= length < 65536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ THREE OCTET LENGTH FIELD Task Number The NCP task number flag indicates the NCP task number is included in the compressed packet (see NCP/IPX compression above). Otherwise, we use the same NCP task number as that of last packet. Based upon the flags set in the flags octet, we will include optional portions of the compressed IPX header. The minimum compressed IPX header contains only the Flags octet. All fields in the original IPX header have been compressed out of the header. The maximum compressed IPX header can include up to 7 octets, the Flags, Slot, Checksum (2 octets), and Length (3 octets) fields, or 8 octets if the NCP Task Number is included. The minimum and maximum compressed IPX packets are shown below. Header fields are one octet in length except where noted. +--------+--------- | Flags | DATA ... | 0x01 | +--------+--------- MINIMUM COMPRESSED IPX PACKET Mathur, Lewis expires in six months [Page 12] DRAFT CIPX January 1993 +--------+--------+---------+---------+--------- | Flags | Slot |Checksum | Length | DATA ... | 0xE1 | Number |2 octets |3 octets | +--------+--------+---------+---------+--------- MAXIMUM COMPRESSED IPX PACKET +--------+--------+--------+--------+--------+--------- | Flags | Slot |Checksum| Length |NCP Task| DATA ... | 0xF1 | Number |2 octet |3 octet | Number | +--------+--------+--------+--------+--------+--------- MAXIMUM COMPRESSED NCP/IPX PACKET Mathur, Lewis expires in six months [Page 13] DRAFT CIPX January 1993 Confirmed Initial Packet The Confirmed Initial packet type is used by the compressor to inform the decompressor of the original packet header which will be used for subsequent compression, and request Confirmation. 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 2 Confirmed Initial Packet | | | | | |__ |__ |__ |__ |_______________ Reserved (must be zero) This type of packet is sent to inform the receiver to associate the IPX packet header with a slot number. This packet is sent each time a different header format is sent for a given slot, or when the sender has not received a Confirmation Packet from the receiver. The Flags octet is always followed by the Slot Number and an ID field. +---------+---------+---------+------------+---------- | Flags | Slot | ID | IPX | DATA ... | 0x02 | Number | | Header | +---------+---------+---------+------------+---------- CONFIRMED INITIAL PACKET For each slot, the ID will increment with every new header sent. Different slots may have the same ID. The combination of slot and ID uniquely identify a header. In practice, the ID octet can be any number which is unique for a "reasonably long period" of time. A reasonably long period is a function of transmission speed, round trip delays, and network load. There must be very little chance of duplicate IDs within this period. Otherwise, there is ambiguity as to which header is being identified. Note that a Confirmed Initial header is followed by a complete IPX packet. Mathur, Lewis expires in six months [Page 14] DRAFT CIPX January 1993 Confirmation Packet The Confirmation packet type is used by the decompressor to tell the compressor that it has received the Confirmed Initial packet. When the compressor receives this, it can start sending Compressed frames. 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 3 Confirmation Packet | | | | | |__ |__ |__ |__ |_______________ Reserved (must be zero) A Confirmation Packet is exactly 3 octets in length. It consist of the Flags, Slot Number and ID fields. The Slot Number field contains the number of the slot which is being acknowledged. The ID field contains the ID which is being acknowledged. +---------+---------+----------+ | Flags | Slot | ID | | 0x03 | Number | | +---------+---------+----------+ CONFIRMATION PACKET Mathur, Lewis expires in six months [Page 15] DRAFT CIPX January 1993 Unconfirmed Initial Packet The Unconfirmed Initial packet type is used by the compressor to inform the decompressor of the original packet header which will be used for subsequent compression, and without requesting confirmation. After sending an Unconfirmed Initial packet, the compressor may immediately send Compressed packets without confirmation. 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 4 Unconfirmed Initial Packet | | | | | |__ |__ |__ |__ |_______________ Reserved (must be zero) This type of packet is sent to inform the receiver to associate the IPX packet header with a slot number. This packet is sent each time a different header format is sent for a given slot. The Flags octet is always followed by the Slot Number. +---------+---------+------------+-----------+--------- | Flags | Slot | IPX | NCP | NCP | 0x04 | Number | Header | Header | DATA ... +---------+---------+------------+-----------+--------- INITIAL NCP/IPX PACKET Note that an Unconfirmed Initial header is followed by a complete IPX packet. Mathur, Lewis expires in six months [Page 16] DRAFT CIPX January 1993 Compression Negotiation over PPP Links For PPP links [2], the use of header compression can be negotiated by IPXCP [3]. By default, no compression is enabled. The IPX-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. The PPP Protocol field is set to the same value as the usual IPX packets, and all IPX packets sent over the link MUST conform to the compressed format. A summary of the IPX-Compression-Protocol Configuration Option format to negotiate Telebit IPX header compression (CIPX) is shown below. The fields are transmitted from left to right. 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 | Length | IPX-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot-Id | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 6 IPX-Compression-Protocol 0002 (hex) for Telebit Compressed IPX headers (CIPX). Max-Slot-Id The Max-Slot-Id field is one octet and indicates the maximum slot identifier. This is one less than the actual number of slots; the slot identifier has values from zero to Max-Slot-Id. Options Mathur, Lewis expires in six months [Page 17] DRAFT CIPX January 1993 The Options field is one octet, and is comprised of the "logical or" of the following values: 0 No options. 1 The slot identifer may be compressed. The slot identifier must not be compressed if there is no ability for the PPP link level to indicate an error in reception to the decompression module. Synchronization after errors depends on receiving a packet with the slot identifier. 2 A length field must be included. The length field MUST be included if there is no ability for the PPP link level to determine the amount of padding. It SHOULD NOT be included when there is no padding on the link, or the Self-Describing-Pad Configuration Option has been negotiated. Mathur, Lewis expires in six months [Page 18] DRAFT CIPX January 1993 Compression Negotiation over IPXWAN Links "IPXWAN" is the protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks [4]. To negotiate the Telebit compression option, we add an option to the IPXWAN timer request/response packet. The Timer Request packet contains the following Telebit compression option: WOption Number 80 - Define compression type WAccept Option 01 - 0=No, 1=Yes, 3=N/A WOption Data Len 00 03 - Length of option WOption Data 00 - Telebit's compression (CIPX) WOption Data XX - Compression options WOption Data NN - Compression slots Where the WOption Data fields are: 00 Telebit's compression option described in this document (CIPX). XX Compression options as defined below: 0x01 Compress slot ID when possible NN The requested # of compression slots. Accept Option (for compression type) must be set to YES if the option is supported and NO if the option is not supported. A Timer Response must respond with only one header compression type set to YES. The Timer Response packet that accepts the option will look like this: WOption Number 80 - Define compression type WAccept Option 01 - 0=No, 1=Yes, 3=N/A WOption Data Len 00 03 - Length of option WOption Data 00 - Telebit's compression (CIPX) WOption Data XX - Compression options WOption Data NN - Compression slots Where the WOption Data fields are: Mathur, Lewis expires in six months [Page 19] DRAFT CIPX January 1993 00 Telebit's compression option described in this document (CIPX). XX Compression options as defined below: 0x01 Compress slot ID when possible NN The negotiated # of slots (The lower of each side's requested number of slots) IPX packets (except of course IPXWAN packets) are not sent over the link until the IPXWAN negotiations are completed. Once IPXWAN negotiations are completed, regular IPX packets can be sent over the link. If both ends of the link agree on the compression options, then the IPX packets are sent using the specified options. If either end of the link does not accept a compression option, then this compression option will not be used. Compression will be done using any remaining options. Options, by definition, are not required. Implementations MUST support CIPX without any options. It is the responsibility of the router sending the IPXWAN Timer Response to inform the other router of the options that will be used. The Timer Response MUST contain a subset of the options received in a Timer Request. To be clear, IPXWAN is used to set up a symmetrical compression link. Compression is configured identically in both directions. Each end will use the same number of slots and same compression options. It is illegal for link ends to use different number of slots or different options. Mathur, Lewis expires in six months [Page 20] DRAFT CIPX January 1993 IPX Compression Performance The performance of this algorithm will depend on the number of active connections and the number of slots negotiated. If the number of slots is greater than the number of connections, the hit rate should be very high giving a very high compression ratio. The performance also depends on the average size of the IPX packets. If the average size of packets is small, then compression will result in a more noticeable performance improvement. avg_data_len + uncomp_header_len Compression ratio = ---------------------------------- avg_data_len + avg_comp_header_len Where 'avg_data_len' is the average length of data in the IPX packet, and 'uncomp_head_len' is the uncompressed header length which is fixed at 30 octets. Where 'avg_comp_header_len' is the average length of the compressed IPX header. The length of the minimum compressed IPX header is 1 octet. The length of the maximum compressed NCP/IPX header is 8 octets (including the NCP task number), but since nothing yet sends packets with a length greater than 16K, 7 octets is the reality. Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the inclusion of the flag and slot number octets. The minimum required maximum length of the data in an IPX packet is 546 octets (576 octets - 30 octet IPX header), although newer implementations often send packets of up to 4096. The minimum length of the data in an IPX packet is 1 octet. Within the normal distribution of small NCP packets, perhaps a reasonable 'avg_data_len' is 28 octets (6 octet NCP header and 22 octet NCP data). 546 + 30 Minimal Compression = -------- = 1.04 546 + 6 1 + 30 Maximal Compression = ------ = 15.50 1 + 1 Mathur, Lewis expires in six months [Page 21] DRAFT CIPX January 1993 28 + 30 Likely Compression = ------- = 1.93 28 + 2 Mathur, Lewis expires in six months [Page 22] DRAFT CIPX January 1993 Security Considerations Security issues are not discussed in this memo. References 1 Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990 2 Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1331, May 1992. 3 Simpson, W. A., "The PPP Internet Packet Echange Control Protocol (IPXCP)", an internet draft which is work in process, December 1992 4 Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]", RFC 1362, August 1992 Acknowledgements This compression algorithm incorporates many ideas from the Van Jacobson TCP/IP header compression algorithm. Michael Allen from Novell provided a lot of valuable feedback in the design of this algorithm. Marty Del Vecchio at Shiva Corp. made a couple of good observations. Bill Simpson was, as always, very helpful. Authors' Address Saroop Mathur Telebit Corp. 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 email: mathur@telebit.com Mark S. Lewis Telebit Corp. 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 email: Mark.S.Lewis@telebit.com Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 17 13:55:33 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21764; Wed, 17 Feb 93 13:19:34 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07504; Wed, 17 Feb 93 12:43:26 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19932; Wed, 17 Feb 93 12:33:05 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18964; Wed, 17 Feb 93 12:07:01 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA27617; Wed, 17 Feb 93 13:05:24 MST Received: by MHS.Novell.COM id CE87822B817F0170; Wed, 17 Feb 93 13:05:24 MST Return-Path: <-SMF71-@SJF-DHUB.MHS.Novell.COM> Precedence: first-class To: ietf-ppp@ucdavis.ucdavis.edu Message-Id: Subject: Re: CIPX version S From: -SMF71-@MHS.Novell.COM (Allen, Michael) Date: Wed, 17 Feb 93 10:51:51 MST Bill, Thanks for the updated CIPX Specification. Apart from a few points, the specification seems very complete and workable. Here are my comments: Page 11: Compressed packet descriptions The "Length" heading should come 1 paragraph earlier (before you discuss length). Within the length paragraph, I feel there is ambiguity which could cause implementors to calculate the length without the *IPX Header* checksums, length or NCP task numbers, where I know you really meant the CIPX Header lengths, checksums etc. I really don't like the three (3) byte length fields. Two bytes is totally adequate for a WAN link - it gives 32K anyway for a single packet. If the packet is larger than this, I would suggest that a *Regular* packet be send. There is no real benifit after all in compressing 20 bytes in 32K+? and it does simplify the implementation. Page 12: Also in the length field Your 3 octet description (which hopefully will disappear anyway :-) ) is missing the end of the line (and it exceeds the page width). Page 18: IPXCP option negotiation Is it really necessary to negotiate the length option (2)? The receiver needs to be able to determine whether the length flag is set in a compressed packet anyway, and Initial/Regular packets have the length in the IPX header. It should be up to the sender to *know* whether he is padding on the send, and therefore be responsible for including or not including the length option in the compressed frames. After all, the sender should know its own hardware configuration!! It looks like this was the descision anyway for the IPXWAN negotiation as this option does not exist. I think I will hold off for a few weeks & see other comments before attempting to try the modifications out. Regards, Michael Allen, Novell Inc. (mallen@novell.com) From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 17 17:54:17 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29885; Wed, 17 Feb 93 17:31:34 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12714; Wed, 17 Feb 93 17:03:33 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28769; Wed, 17 Feb 93 16:53:17 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28258; Wed, 17 Feb 93 16:35:38 -0800 Received: from america.TELEBIT.COM (america-bb.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930216) id AA04341 to ietf-ppp@ucdavis.edu; Wed, 17 Feb 93 16:33:59 PST Received: from yoyo.telebit.com by america.TELEBIT.COM (4.0/america.telebit.com-DBC-921227) id AA07824 to ietf-ppp@ucdavis.edu; Wed, 17 Feb 93 16:33:58 PST Date: Wed, 17 Feb 93 16:33:57 PST From: mlewis@america.Telebit.COM (Mark S. Lewis) Message-Id: <9302180033.AA07824@america.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA06604; Wed, 17 Feb 93 16:33:57 PST To: bill.simpson@um.cc.umich.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, ms@Telebit.COM In-Reply-To: <966.bill.simpson@um.cc.umich.edu> Subject: CIPX version S >>>>> On Tue, 16 Feb 93 18:44:43 EDT, "William Allen Simpson" said: Bill> Over a month ago, I sent a pile of revisions to CIPX to Telebit. Since Bill> then, apparently Saroop isn't there anymore, and I haven't heard Bill> anything. In the hope of getting the discussion going on this, here's Bill> what I sent. Bill> The versions that Telebit and Novell have written are slightly different Bill> from each other, and not interoperable. Also, there were some serious Bill> errors in assumptions about packet length, and missing information about Bill> confirmation of NCP packets. Bill> This one is slightly different from each of them. It is interoperable Bill> with both Telebit and Novell for IPX compression, and probably with Bill> Telebit for NCP/IPX compression. Bill> I changed some of the names (Uncompressed -> Initial, Ack -> Confirm), Bill> improved the spelling and re-organized the sections. We need to clarify a few things here. We made available the CIPX specification to Bill in order to get his input. He was very helpful in providing some renaming, reorganization, and corrections. However, Bill is not one of the authors of this specification but has contributed to this specification. It was not Bill's place to publish his version of this specification. Bill needs to understand that his time-table is not the only one to consider. Some of us have other duties besides writing internet documents and making public comments on various Internet issues. To be clear, we are the authors of this document. We will publish a revised version of the draft when we have completed review of suggestions and have examined interoperability issues. It is important that implementations of CIPX (Telebit, Novell & others) agree to modifications. We are not trying to be territorial but rather welcome comments. We have submitted two drafts already for public review. We have tried to be very open in providing specifications even before products have shipped. Mark & Saroop ==========-------------- Mark S. Lewis ----------========== Mark.S.Lewis@Telebit.com Telebit Corp. Voice (408) 745-3232 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 17 17:56:54 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29948; Wed, 17 Feb 93 17:34:02 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08222; Wed, 17 Feb 93 13:36:47 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21759; Wed, 17 Feb 93 13:19:20 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vangogh.CS.Berkeley.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20384; Wed, 17 Feb 93 12:45:10 -0800 Received: by vangogh.CS.Berkeley.EDU (ALPHA-6.22/6.1) id AA16938; Wed, 17 Feb 1993 12:43:08 -0800 Date: Wed, 17 Feb 1993 12:43:08 -0800 From: Keith Sklower Message-Id: <199302172043.AA16938@vangogh.CS.Berkeley.EDU> To: ietf-ppp@ucdavis.ucdavis.edu Subject: simple multilink for PPP in an ISDN context Cc: iplpdn@ietf.cnri.reston.va.us A suggestion has been made to mandate the use of either PPP or frame relay encapsulation for Internet protocols over ISDN. (When you receive the first correctly framed packet, you can tell which kind it is). A very common application will be a station with a basic rate interface calling a server router with primary rate, and existing ISDN interfaces do not have hardware for doing HDLC bit stuffing and unstuffing accross the two B channels for basic rate or random pairs of B channels in random orders on primate rate. So, as an interim term solution, I would like to propose a very simple method of combining two or more circuits into a logical channel. This method could also be applied to connections run over X.25 to get around bandwith-delay limitations due to small windows supported by the carriers. Most of the discussion on the IPLPDN list so far has been on the availability (or lack of ...) and imminent deployment of Nx64K or Nx56 synchronous bit traffic. I'm going to take the editorial license to point out that even if the switches & carriers support this mode of operation, if your local hardware doesn't support the combined HDLC bit stuffing & unstuffing you can't make use of it. The document proposes a change to Frame Relay encapsulation and an additional PPP protocol, so I'm sure people in both the PPP and IPLPDN groups will have comments, and you will probably want to include both groups on cc: or to: lines. The IPLPDN list has already seen the proposal, so I'm going to mail this short note to both groups to remind them of each others existence, and then mail the proposal to just the PPP list, so as not to unnecesarily clutter up people's mail boxes. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 17 17:58:30 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00184; Wed, 17 Feb 93 17:39:03 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08296; Wed, 17 Feb 93 13:40:08 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21784; Wed, 17 Feb 93 13:21:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vangogh.CS.Berkeley.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20516; Wed, 17 Feb 93 12:47:28 -0800 Received: by vangogh.CS.Berkeley.EDU (ALPHA-6.22/6.1) id AA17110; Wed, 17 Feb 1993 12:45:17 -0800 Date: Wed, 17 Feb 1993 12:45:17 -0800 From: Keith Sklower Message-Id: <199302172045.AA17110@vangogh.CS.Berkeley.EDU> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Simple Multilink Proceedure for PPP - the document Note: This is ****NOT***** yet an internet draft. It is only my random babblings. The boilerplate was handy . . . Draft Simple ISDN Multilink Feb. 1992 INTERNET DRAFT Expires: July 31st, 1993 A Simple Multilink Protocol for Synchronizing the Transmission of Multi-protocol Datagrams over Circuit-mode ISDN Keith Sklower Computer Science Department University of California, Berkeley 1. 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 appro- priate 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. 2. Abstract This document proposes a simple method for splitting and recombining datagrams accross multiple logical data links. Such facilities are desireable to exploit the potential for increased bandwith offered by multiple bearer channels in ISDN, yet to do so in such away that minimizes reordering of packets. More precisely, modifications to RFC1294[4] are proposed, and new PPP[2] options and protocols are suggested. Sklower [Page 1] Draft Simple ISDN Multilink Feb. 1992 3. Acknowledgements The author specifically wishes to thank the members of the IP over Large Public Data Networks working group, for much useful discussion on the subject. 4. 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. 5. Introduction At least in the US, at the time this draft was written, both 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]). The current internet draft for IP over ISDN has deferred discus- sion of this as a separate issue. There are proposals being discussed by communications providers for providing synchronization between multiple streams at the bit level; such features are not as yet widely deployed and it may be useful to have a relatively simple software solution as what may prove to be a stopgap measure. Furthermore, even if the ISDN service providers guarantee bit-synchronization between different switched circuits, there may not be sufficiently flexible hardware to combine the multiple bit streams in arbitrary orders for HDLC bit- unstuffing. 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 undesireable side effects due to reordering of packets. By relaxing some requirements of the packet segmentation and reassembly algorithm described in RFC1294, and introducing Sklower [Page 2] Draft Simple ISDN Multilink Feb. 1992 only a modest amount more complexity into implementations supporting it, one can split packets amongst parallel vir- tual circuits between systems in such a way that packets do not become reordered, or at least the likelihood of this is greatly reduced. Another method being considered by the PPP Extensions work- ing group is the multilink proposal described in ISO 7776. This method in particular requires again more complexity, and also requires that packets must be acknowledged at the link level. Any method for bandwidth aggregation would require some means of identifying which channels are to participate in such a process. This could be achieved specifically in the case of ISDN by use of the calling party information ele- ment, but more generally by methods discussed in the PNMI draft, such as by using PPP's authentication protocols[3]. For Frame Relay run over dedicated channels, some sort of manual configuration could suffice. 6. Principal Recommendations 6.1. RFC 1294 As stated above, the concept is to use the packet segmenta- tion/reassembly formats defined in RFC1294, but to allow the fragments to be transmitted over multiple virtual circuits (or potentially multiple physical links). We'll refresh the reader's memory by shamelessly paraphrasing the section on segmentation from that RFC: The general format of fragmented packets is the same as any other encapsulated protocol described in RFC1294; the most significant difference being that the fragmented packet will contain the encapsulation header. That is, a packet is first encapsulated according to normal RFC1294 procedures: large packets are then broken up into multiple frames sized appropriately for the mutliple physical links and encapsu- lated using the RFC1294 fragmentation format. In this way, a station receiving fragments may reassemble them. Within RFC1294 fragments are encapsulated using the SNAP format with an OUI of 0x00-80-C2 and a PID of 0x00-0D. Individual fragments will, therefore, have the following format: Sklower [Page 3] Draft Simple ISDN Multilink Feb. 1992 Figure 1: Fragment format for RFC1294 +---------------+---------------+ | Q.922 Address | +---------------+---------------+ | Control 0x03 | pad 0x00 | +---------------+---------------+ | NLPID 0x80 | OUI 0x00 | +---------------+---------------+ | OUI 0x80-C2 | +---------------+---------------+ | PID 0x00-0D | +---------------+---------------+ | sequence number | +-+-------+-----+---------------+ |F| RSVD |offset | +-+-------+-----+---------------+ | fragment data | | . | | . | | . | +---------------+---------------+ | FCS | +---------------+---------------+ The sequence field is a two octet identifier that is incre- mented every time a new complete message is fragmented. It allows detection of lost frames and is set to a random value at initialization. The reserved field is 4 bits long and is not currently defined. It must be set to 0. The final bit is a one bit field set to 1 on the last frag- ment and set to 0 for all other fragments. The offset field is an 11 bit value representing the logical offset of this fragment in bytes divided by 32. The first fragment must have an offset of zero. In RFC1294 a separate and single reassembly structure is assocated with each virtual circuit, and the sequence number is interpreted only in the context of that virtual circuit. We propose instead having a reassembly structure being asso- ciated with a group of virtual circuits and the sequence number is then interpreted in the context of the group. It is still possible to avoid a reassembly timeout if the number of packets being reassembled is limited to the number of circuits in the group (say G), at the expense of some dedicated buffer space. When the sender decides to fragment Sklower [Page 4] Draft Simple ISDN Multilink Feb. 1992 a packet (and for sake of disscussion assigns it a sequence number N), the sender should divide the packet in such a way that the all fragments are of roughly equal length, but transmit the largest fragment last. In the absence of manual configuration or appropriate nego- tiation, the sender MUST NOT admit any fragment with sequence number N + G to the transmission queues, until the sender is certain that all the fragments with sequence num- ber N have been transmitted. Note that this generally would require an implementation to keep track of the fragment number currently being transmit- ted on each participating link in a group, and to scan for the minimum number in that group. One would generally update the link-specific number on each transmission com- plete interrupt. As this was supposed to be a simple fragmentation/reassembly protocol, we'll just mention that it would be possible to have a more-elaborate timer and/or buffer size based imple- mentations (like the tradition IP reassembly queues in end- system implementations), but we'll leave that to more ambi- tious future extensions. 6.2. PPP [Editorial comment: this section is being submitted to PPP people in the spirit of ``here is something we need, and some very rough ideas of how one might go about doing it, but any counter-suggestions more consistent with the PPP architecture would be gratefully welcomed'']. The Point-to-Point Protocol (PPP) [5] provides a standard method of encapsulating Network Layer protocol information over (virtual) point-to-point links. PPP has four main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, config- uring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for estab- lishing and configuring different network-layer proto- cols. 4. A family of Network-Layer Protocols (NPs) which are the classes of data to be transmitted themselves. Sklower [Page 5] Draft Simple ISDN Multilink Feb. 1992 6.2.1. Crude Description of Overall Intent 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 before proceeding to the Network-Layer Protocol phase. Since the idea is to ``tie together'' mul- tiple circuits between a fixed pair of systems, and since both of the current PPP authentication protocols permit the side effect of assigning identifiers to both systems, it makes sense to require the use of one or the other of the existing authentication protocols (or any future authentica- tion protocol that assigns unique identifiers to communicat- ing systems) We suggest that multilink operation can be modeled as a sep- arate PPP Network-Layer protocol with its own control proto- col, which may be negotiated in the usual PPP manner. A slightly unusually (for PPP) convention might be that if the PPP-Simple Multilink (network-layer) Protocol were proposed and accepted in both directions between systems that had previously concluded all NCP negotiations on another cir- cuit, that the new ciruit ``inherit'' the results of the previous negotiation. and that both the old and new ciruit would then be combined into a single logical channel. To contruct the (network layer) packets (themselves) in this new ``protocol'' one would start with a complete PPP packet, prune the leaading HDLC address and UI designation bytes, divide it into roughly equal parts, and to each section prepend the usual PPP control header followed by an RFC1294 fragmentation header. An issue that was raised was whether fragmented packets could be reassembled and released in sequence, which is required by some network protocols such as VJ header com- pression for TCP/IP. Fred Baker also gave the example reconstructing the data dictionary when more general com- pression methods were in use. One could negotiate a guaran- tee of this based on the sequence number in the RFC1294 fragmentation header, agreeing not to release packets out of sequence order, but that would require that delivery accross the individual subchannels was reliable. However, even in the face of unreliable delivery, it is the guess of the author of this modest proposal that following the method described above of merely maintaining as many reassembly queues as there are physical channels, and not beginning the transmission of packet N+G until all fragments of packet N were known to have been sent should provide sequenced delivery in most cases. Sklower [Page 6] Draft Simple ISDN Multilink Feb. 1992 6.2.2. More detailed description of the ``Network Protocol'' In our description here, we will need to make use of a PPP, 16-bit network protocol identifier. Just for the sake of ease of description we will choose the numbers 0x3a to rep- resent the proposed fragmentation network protocol and 0x803a to represent the corresponding control protocal. These numbers will clearly need to be reassigned should this proposal be accepted. Individual fragments will thus be encoded in a PPP context according to the following format: Figure 2: Fragment format for PPP 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x3a + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |F| RSVD | Offset + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fragment data | ..... | ..... | ..... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The descriptions of the fields are exactly the same as they are for RFC1294: a 16 bit sequence number, a single bit representing the completing fragment, offset understood to be multiplied by 32. The execution of the protocol itself is exactly as specified above. 6.2.3. Fragmentation Protocol Control Protocol [Here, we equally shamelessly plagiarize RFC1220] The Fragmentation Protocol Control Protocol is responsible for establishing agreement to initiate multilink operation, and for setting a limited number of parameters. It is exactly the same as the Point-to-Point Link Control Protocol [2], with the following exceptions: Data Link Layer Protocol Field Exactly one Fragmentation Protocol Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indi- cates type hex 803a. [to be reassigned appropriately] Sklower [Page 7] Draft Simple ISDN Multilink Feb. 1992 Code field Only Codes 1 through 7 (Configure-Request, Configure- Ack, Configure-Nak, Configure-Reject, Terminate- Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Precedence FPCP packets may not be exchanged until the Link Con- trol Protocol has reached the network-layer Protocol Configuration Negotiation phase. The FPCP negotiation must precede any other network protocol negotation. Configuration Option Types The Fragmentation Protocol Control Protocol has a sepa- rate set of Configuration Options. These permit the negotiation of the following items: o Sequenced Delivery o Reassembly Timeout o Additional Packet Reassembly Queues o Alternative Packet Reassembly Buffering Limits [The author of this proposal realizes the title of it was the ***SIMPLE*** multilink protocol, and would not be gravely disappointed if none of the options were permitted, but is enumerating them here merely for completeness' sake.] 6.2.3.1. Sequenced Delivery Option Figure 3: Sequenced Delivery Option 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=1 | length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option, if present and accepted, instructs the system at the other end of the link not to deliver packets out of sequence. In the absence of reliable delivery and the absence of other options such as packet time outs, a missing fragment in the packet number N would delay the delay the delivery of packet number N+1 until receipt of any fragment for packet N+G. 6.2.3.2. Reassembly Timeout Figure 4: Reassembly Timeout Option 0 1 2 3 Sklower [Page 8] Draft Simple ISDN Multilink Feb. 1992 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=2 | length = 4 | Timeout in Milliseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option, if present and accepted permits the other sys- tem to descard any fragment that it has kept in a reassembly queue for longer than the specified timeout. 6.2.3.3. Packet Reassembly Queues Figure 5: Number of Queues 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=3 | length = 4 | Number of Requested Queues | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option requests the other system to attempt reassembly for at least the specified number of packets identified with distinct sequence numbers. 6.2.3.4. Alternative Buffering Strategy Figure 6: Total Buffering 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=4 | length = 4 | Requested Space in 2^10 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option permits the other system to limit the collection of packets identified with distinct sequence numbers to be bounded by a requested total amount of space. 6.3. RFC 1356/B-Channel X.25 If the underlying X.25 implementation support ISO 7776 oper- ation, clearly, there would be no need to replicate the functionality at a higher level. However, if the underlying X.25 implementation does not, RFC1356 can transmit packet formats found in RFC1294 either by specifying an NLPID of 0 in the Call User Data or by placing a common SNAP header in the Call User Data, and ommitting that initial segment on all packets subsequently transmitted over that virtual cir- cuit. In the case of NLPID 0, an in-band negotiation could be used to identify members of a reassembly group by use of the proposed parameter negotiation over the multiprotocol Sklower [Page 9] Draft Simple ISDN Multilink Feb. 1992 interconnect. If one is willing to settle for external manual configura- tion, as the RFC1294 fragmentation procedure employs SNAP encapsulated packets, one could open an X.25 virtual circuit with the fixed SNAP portion of the fragmentation header in the Call User Data, and with the reassembly group defined to be all virtual circuits having the same X.121 calling address. 7. References [1] Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork Control Protocol for ISDN Circuit-Switching" IPLPDN Working Group, Internet Draft (Expired), March 1991. [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-1294, January 1992. [5] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", Net- work Working Group, RFC-1356, August 1992. [6] Sklower, K. and Frost, C. "Recommendations for the Transmission of Multi-protocol Datagrams over Circuit- mode ISDN", IPLPDN Working Group, Committee Document, November 1992. [7] Sklower, K. "Parameter Negotiation for the Multiproto- col Interconnect" IPLPDN Working Group, Committee Docu- ment, November 1992. [8] Boland, F., editor, "Stable Implementation Agreements for Open Systems Interconnection Protocols: Version 2 Edition 1", NIST Workshop for Implementors of OSI, NIST, February 1989. [9] Internation Organisation for Standardization, "HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Procedures", Internation Standard 7776, 1988 Sklower [Page 10] Draft Simple ISDN Multilink Feb. 1992 8. Author's Address Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-9587 Email: sklower@cs.Berkeley.EDU 9. Expiration Date of this Draft July 31, 1993 Sklower [Page 11] From ietf-ppp-request@ucdavis.ucdavis.edu Thu Feb 18 02:40:34 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16054; Thu, 18 Feb 93 02:35:08 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16486; Thu, 18 Feb 93 02:19:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15404; Thu, 18 Feb 93 02:10:54 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15321; Thu, 18 Feb 93 02:08:46 -0800 Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA14391 (5.65c+/IDA-1.4.4); Thu, 18 Feb 1993 05:06:56 -0500 Date: Thu, 18 Feb 93 00:38:19 EDT From: "William Allen Simpson" Message-Id: <976.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: CIPX version S > We are not trying to be territorial but rather welcome comments. We > have submitted two drafts already for public review. We have tried to > be very open in providing specifications even before products have > shipped. > Am I to read into this that CIPX is a "product" spec? Last July, Telebit offered to come up with a Compressed IPX spec. They finally posted one back in September. A number of problems were discovered in it and subsequent versions. I have been trying to get the IPXCP and CIPX specs out the door since November. After long phone conversations with Telebit and Novell, I made this draft revision for Telebit in the second week of January. Mark Lewis hasn't returned my calls in 3 or 4 weeks. I do not know how to contact Saroop (the first author) since he has left Telebit. Like Shiva IPXCP, if you promise to do something and don't do it, it's likely to be taken out of your hands and done by others. I will note that this period (8 months) is even longer than the Shiva delay (7 months). Other companies are complaining to me that the IPX/PPP work isn't done. They have products to ship, too. 15 months is much too long to wait. As I have with other drafts in the past, I will leave Saroop and Mark as the principle authors, if they are willing to answer questions and help other companies with their implementations for many years to come. Credit where credit is due, but with fame comes responsibility. ---- Michael Allen, Thanks for the comments. You were the one who told me that the length text was wrong (Telebit stated that the maximum packet was 576). I'll fix the format line. I really think that we should handle compression of all lengths of packets. I don't believe there is any current IPX software that generates packets longer than 8K, so this is a far future item anyway. Let's think ahead. What do others think? You are right, we don't need that length configuration option anymore. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu Feb 18 12:28:30 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05158; Thu, 18 Feb 93 12:06:29 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22762; Thu, 18 Feb 93 11:40:48 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04053; Thu, 18 Feb 93 11:34:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03664; Thu, 18 Feb 93 11:22:21 -0800 Received: from america.TELEBIT.COM (america-bb.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930216) id AA09118 to ietf-ppp@ucdavis.edu; Thu, 18 Feb 93 11:20:41 PST Received: from yoyo.telebit.com by america.TELEBIT.COM (4.0/america.telebit.com-DBC-921227) id AA04836 to ietf-ppp@ucdavis.edu; Thu, 18 Feb 93 11:20:37 PST Date: Thu, 18 Feb 93 11:20:37 PST From: mlewis@america.Telebit.COM (Mark S. Lewis) Message-Id: <9302181920.AA04836@america.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA06689; Thu, 18 Feb 93 11:20:37 PST To: bill.simpson@um.cc.umich.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, ms@america.Telebit.COM In-Reply-To: <976.bill.simpson@um.cc.umich.edu> Subject: CIPX version S >>>>> On Thu, 18 Feb 93 00:38:19 EDT, "William Allen Simpson" said: Bill> I have been trying to get the IPXCP and CIPX specs out the door since Bill> November. After long phone conversations with Telebit and Novell, Bill> I made this draft revision for Telebit in the second week of January. Since you wrote IPXCP, you worry about getting that done. We will worry about CIPX. Bill> Other companies are complaining to me that the IPX/PPP work isn't done. Bill> They have products to ship, too. 15 months is much too long to wait. IPXCP is the essential piece for which people are waiting. The compression is advantageous but not required. Bill> As I have with other drafts in the past, I will leave Saroop and Mark as Bill> the principle authors, if they are willing to answer questions and help Bill> other companies with their implementations for many years to come. Bill> Credit where credit is due, but with fame comes responsibility. Bill> Bill.Simpson@um.cc.umich.edu I am very angry that you have abused your privledge. I entrusted you with this draft in an effort to get your comments only. Now I find myself defending our position as the authors of the specification. Bill> Michael Allen, Bill> Thanks for the comments. You were the one who told me that the length Bill> text was wrong (Telebit stated that the maximum packet was 576). I'll Bill> fix the format line. WE will make the appropriate changes here. Bill> I really think that we should handle compression of all lengths of Bill> packets. I don't believe there is any current IPX software that Bill> generates packets longer than 8K, so this is a far future item anyway. Bill> Let's think ahead. What do others think? Yes I would like to know who thinks we need a 3 octet length option. I tend to think it would be advisable to plan for larger packet sizes. It may be worth the small incremental complexity. Bill> You are right, we don't need that length configuration option anymore. Right. Michael and I agreed to drop this, but you were confused. In summary, I try and resist the temptation to engage in these flame wars. While there is some entertainment value, they are generally not productive. I would like to see these specifications move forward. We will update the CIPX specification. I would like to get your support in doing this, just like I have supported your efforts with IPXCP. Let's keep this discussion on the technical aspects and leave the politics out. ... Mark ==========-------------- Mark S. Lewis ----------========== Mark.S.Lewis@Telebit.com Telebit Corp. Voice (408) 745-3232 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 22 20:39:55 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06228; Mon, 22 Feb 93 19:48:08 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09532; Mon, 22 Feb 93 19:29:42 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05210; Mon, 22 Feb 93 19:11:58 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03736; Mon, 22 Feb 93 18:28:26 -0800 Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA25233 (5.65c+/IDA-1.4.4); Mon, 22 Feb 1993 18:37:10 -0500 Date: Sun, 21 Feb 93 16:56:41 EDT From: "William Allen Simpson" Message-Id: <991.bill.simpson@um.cc.umich.edu> To: Keith Sklower Cc: ietf-ppp@ucdavis.ucdavis.edu Cc: iplpdn@ietf.cnri.reston.va.us Subject: Parameter Negotiation (00) There are a few things in your recent draft which are different from what I remember in prior discussions, or which I thought we had resolved at the DC IETF. > Principally, we would like parameter negotiation as a whole > to be made optional. As we discussed, there is no reason that you cannot eliminate PPP parameter negotiation if you are already forced to hand configure both ends of the link. Just make it a configurable option. > We would also like to be able to renegotiate parameters at any time > during the course of an association. This is already a part of PPP. The LCP or any NCP can renegotiate at any time. It's built into the FSA. > An implementation MAY request any option specified by PPP, but > MAY decline to support any option. Yes, this is how PPP negotiations work -- see "Configure-Reject". > 7.1. Optionality and Separability of Negotiations > > As noted above, people have expressed the desire not to be > required to conduct any negotiations before transmitting > data packets in a public data network environment. Thus, an > implementation MAY silently ignore any SNAP encapsulated PPP > packet. If an implementation responds to LCP packets, it > MUST traverse the LCP state diagram according to RFC1331. This won't work. It has to be the other way around. If an implementation understands SNAP encapsulated PPP LCP packets, it MUST respond to them. It just isn't necessary to SEND them when the link is hand configured (or when negotiated by some outside means -- XID is mentioned). Here are a couple of reasons: 1) old implementations. The old implementation will start spewing data packets. The new implementation will be sending LCP packets to try to configure, and will "silently discard" the data packets. Therefore, the new links MUST NOT come up with old links unless hand configured to do so. In event of failure, the link MUST shut down. PPP LCP provides a means to detect old implementations and notify operations. 2) black hole detection. Some links (X.25) have no standard method of determining when a link has gone down or come back up. Sending the PPP LCP packets takes care of this problem. > Another reason is simplicity of implementation. For use of > small computers at home, people may wish to be able to only This is silly. I originally got involved with PPP for small computers at home. The size of the PPP negotiation code is negligible compared to the link setup and framing. > having to maintain state information for hundreds of virtual > point-to-point connections. Another bogus issue. Are you saying that you have a technique where you don't maintain state information for each link? How do you know it's there? How do you set it up? How do you know when to tear it down? Are you stating that it is easier to maintain static or hand configured information for hundreds of virtual connections? > 8.1. Protocol Summaries in NCP > > It has been suggested that there should be a PPP LCP option > to pre-emptively announce which protocols will be routed or I thought that I laid this one to rest at DC IETF. There is no savings over a null NCP configuration packet -- particularly in the presence of compound PPP framing. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 22 21:19:03 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07237; Mon, 22 Feb 93 20:26:53 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09101; Mon, 22 Feb 93 18:49:15 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02902; Mon, 22 Feb 93 18:01:41 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [141.210.10.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01430; Mon, 22 Feb 93 16:58:14 -0800 Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA25186 (5.65c+/IDA-1.4.4); Mon, 22 Feb 1993 18:36:18 -0500 Date: Sun, 21 Feb 93 16:05:01 EDT From: "William Allen Simpson" Message-Id: <988.bill.simpson@um.cc.umich.edu> To: Keith Sklower Cc: ietf-ppp@ucdavis.ucdavis.edu Cc: iplpdn@ietf.cnri.reston.va.us Subject: Re: Simple Multilink Proceedure for PPP - the document A little time for review on a Sunday afternoon in a snowstorm .... I found this one quite interesting. We had been talking/writing about some of the same needs last summer, when Fred Baker raised the issue. It seems to me that this proposal could be combined with Fred's work. His MLP negotiation was a separate LCP option, as I recall. There was some talk about a "group identifier" LCP option. First a single link would come up. When the second and subsequent links come up, they would include an option saying "I want to be in the same group as magic number X", which is the magic number of the first link. The magic number is guaranteed to be unique between two machines, so this would work long as the links were always between the same machines. However, that breaks down when the site is large, and there are several "network access servers" in the rotary. It seems to me that your proposal would fail in the same case. At the Boston IETF, it was decided that compression would have it's own control protocol, so it seems OK to have a control protocol for MLP, too. I'm not sure I like having the data packets show up as a separate PPP protocol though. I don't see a method for disambiguating the protocol of the packet which was split up. We already were discussing a layer for compression. Presumably this layer would wrap that layer or vice versa. Things are getting rather complicated. All in all, a very nice first stab. We need to add this to the Columbus agenda. Are you going to be there Keith? Are you Fred? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 22 21:45:50 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08057; Mon, 22 Feb 93 20:59:15 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10341; Mon, 22 Feb 93 20:46:25 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06821; Mon, 22 Feb 93 20:10:18 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vangogh.CS.Berkeley.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05638; Mon, 22 Feb 93 19:28:57 -0800 Received: by vangogh.CS.Berkeley.EDU (ALPHA-6.26/6.8) id AA19900; Mon, 22 Feb 1993 18:40:20 -0800 Date: Mon, 22 Feb 1993 18:40:20 -0800 From: Keith Sklower Message-Id: <199302230240.AA19900@vangogh.CS.Berkeley.EDU> To: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@ietr.cnri.reston.va.us Subject: lack of deadwood removal from Parameter Negotiation for Multiprotocol ... There are a few things in your recent draft which are different from what I remember in prior discussions, or which I thought we had resolved at the DC IETF. I had the distinct feeling that I was leaving out some points of resolution due to my faulty recollection. > Principally, we would like parameter negotiation as a whole > to be made optional. ... there is no reason that you cannot eliminate PPP parameter negotiation if you are already forced to hand configure both ends of the link... OK; this is probably poorly worded; The language derives from an attempt to assuage Robert Ullman's concerns that PNMI had to be done before data packets could be exchanged. I'll suggest alternate text a little later in this message. > We would also like to be able to renegotiate parameters > at any time during the course of an association. This is already a part of PPP. The LCP or any NCP can renegotiate at any time. It's built into the FSA. > An implementation MAY request any option specified by > PPP, but MAY decline to support any option. Yes, this is how PPP negotiations work -- see "Configure-Reject". OK.... I'll change the document so that this is a required feature that PNMI is using from PPP. > 8.1. Protocol Summaries in NCP > It has been suggested that there should be a PPP LCP > option to pre-emptively announce which protocols will be > routed or bridged I thought that I laid this one to rest at DC IETF. There is no savings over a null NCP configuration packet -- particularly in the presence of compound PPP framing. OK, but compound PPP framing is a change to RFC1331; I hope there won't be an objection just noting that. Can you live with the following wording for the introduction?: .... Both RFC's 1294 and 1331 specify details of framing and encapsulation in incompatible ways; however, one can accommodate PPP's encapsulation of control packets by prepending a SNAP header without otherwise chang- ing the description of the packets. Members of the iplpdn group expressed the desire that param- eter negotiation as a whole be made optional, and also wanted to be able to renegotiate parameters at any time dur- ing the course of an association. Both of these goals can be met without violating the current PPP spec. There was also expressed the desire to decrease the number of actual packets required to traverse PPP's state diagram. Some changes were proposed to the PPP-extensions working group for doing by emiting compound frames made up of multi- ple logical PPP packets. It was thought that this might reduce the negotation to an exchange of three actual link- level packets. > 7.1. Optionality and Separability of Negotiations Above, you agreed that parameter negotiation should be optional; but we seem to disagree on how to do it, or maybe we are disagreeing on the extent to which parameter negotiation can be optional. > ... an implementation MAY silently ignore any > SNAP encapsulated PPP packet. If an implementation > responds to LCP packets, it MUST traverse the LCP > state diagram according to RFC1331. This won't work. It has to be the other way around. If an implementation understands SNAP encapsulated PPP LCP packets, it MUST respond to them. It just isn't necessary to SEND them when the link is hand configured (or when negotiated by some outside means -- XID is mentioned). Here are a couple of reasons: 1) old implementations. The old implementation will start spewing data packets. The new implementation will be sending LCP packets to try to configure, and will "silently discard" the data packets. Therefore, the new links MUST NOT come up with old links unless hand configured to do so. In event of failure, the link MUST shut down. No, this is explicitly why certain people in the iplpdn group wanted parameter negotiation to be optional. They NEVER want to forbid a link from coming up because one end speaking option negotiation and the other one not. And you even add the phrase ``unless hand configured to do so''..... PPP LCP provides a means to detect old implementations and notify operations. Nice, but irrelevant for the people who have the concern I just expressed. 2) black hole detection. Some links (X.25) have no standard method of determining when a link has gone down or come back up. Sending the PPP LCP packets takes care of this problem. Yes, and when you get charged by the packet, this is another misfeature. You can tell a link has come back up when you get an X.25 call request, and you can tell that it has gone down by getting a X.25 Clear or Restart. > Another reason is simplicity of implementation. This is silly. I originally got involved with PPP for small computers at home. The size of the PPP negotiation code is negligible compared to the link setup and framing. I think we're gonna have to agree that we disagree. In my (BSD based) implementation, the amount of code required to prepend a few bytes based on packet type, and to strip it off is quite small compared to link management. > having to maintain state information for hundreds of > virtual point-to-point connections. Another bogus issue. Are you saying that you have a technique where you don't maintain state information for each link? How do you know it's there? How do you set it up? How do you know when to tear it down? Are you stating that it is easier to maintain static or hand configured information for hundreds of virtual connections? No, but I am stating that some people have told me they want to minimize the amount of per-circuit information. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 22 21:56:47 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08406; Mon, 22 Feb 93 21:14:24 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10355; Mon, 22 Feb 93 20:48:03 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06873; Mon, 22 Feb 93 20:12:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05696; Mon, 22 Feb 93 19:30:09 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA18217; Mon, 22 Feb 93 17:44:24 PST Date: Mon, 22 Feb 93 17:44:24 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9302230144.AA18217@saffron.acc.com> To: sklower@vangogh.cs.berkeley.edu Subject: Re: Simple Multilink Proceedure for PPP - the document Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@IETF.CNRI.Reston.VA.US >> would it be so very terrible to have two ways to do multi-link? In my opinion (which is not always right), yes. It would be terrible if, in order to fully interoperate with all the different vendors in the world everybody has to implement two different ways to do the same thing, because somewhere there's somebody that thinks they only need one of the ways and somewhere there's somebody else who only thinks that they need the other one. Interoperability is better served by making hard choices than by making options available to everybody. If you disagree, consider the set of choices available in ISO networking. Does everyone implement both CONS and CLNS, and implement TP0, TP1, TP2, TP3, and TP4? Where folks have made different implementation choices, what has been required to make them interoperate? (BTW, I am neither an ISO advocate nor foe; I think they've done some things right and made some bad choices.) Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Feb 22 22:00:46 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08583; Mon, 22 Feb 93 21:19:06 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10421; Mon, 22 Feb 93 20:51:41 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06943; Mon, 22 Feb 93 20:14:56 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05796; Mon, 22 Feb 93 19:32:12 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA16006; Mon, 22 Feb 93 16:15:44 PST Date: Mon, 22 Feb 93 16:15:44 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9302230015.AA16006@saffron.acc.com> To: bsimpson@morningstar.com, sklower@vangogh.cs.berkeley.edu Subject: Re: Simple Multilink Proceedure for PPP - the document Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@IETF.CNRI.Reston.VA.US >> All in all, a very nice first stab. We need to add this to the >> Columbus agenda. Are you going to be there Keith? Are you Fred? I will be there. >> There was some talk about a "group identifier" LCP option. First a >> single link would come up. When the second and subsequent links come >> up, they would include an option saying "I want to be in the same group >> as magic number X", which is the magic number of the first link. The >> magic number is guaranteed to be unique between two machines, so this >> would work long as the links were always between the same machines. >> >> However, that breaks down when the site is large, and there are several >> "network access servers" in the rotary. It seems to me that your >> proposal would fail in the same case. There's another issue with the "hunt group" approach as you outlined it; it depends on two guys each doing one line first and the others later. OK, suppose that you choose line 1 (which is my line C) followed by lines 2 and 3 (my lines A and B). I choose to start with line A, followed by B and C. Oops, we have a deadlock. I suspect that, in the end, membership in multi-line groups will have to be validated by the authentication logic, not the LCP configuration logic. I have one concern with the multi-link procedure Keith proposed (or I should say, the one that was described to me on the phone; I haven't read the document yet...). In the case of compression, we have a need (in at least the cases of the algorithms I have been considering) for reliable sequential delivery. Keith's approach provides sequentiality but not reliability. Therefore, it doesn't acheive my goals. The use of the MLAP procedure on LAPB or LAPF, on the other hand, provides reliable sequential delivery when it's needed, and contains the hooks to allow traffic which doesn't require sequentiality to slip past. If sequentiality is needed without relibility, MLAP on UI frames is as unreliable as ever. Therefore, I prefer the approach of last summer (yes, yes, I'm behind just a tad...) Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Feb 24 03:44:18 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03358; Wed, 24 Feb 93 02:43:56 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25330; Tue, 23 Feb 93 18:12:10 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26368; Tue, 23 Feb 93 18:05:00 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [128.32.130.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24561; Tue, 23 Feb 93 17:04:13 -0800 Received: by vangogh.CS.Berkeley.EDU (ALPHA-6.26/6.8) id AA07277; Tue, 23 Feb 1993 16:03:37 -0800 Date: Tue, 23 Feb 1993 16:03:37 -0800 From: Keith Sklower Message-Id: <199302240003.AA07277@vangogh.CS.Berkeley.EDU> To: iplpdn@ietf.cnri.reston.va.us Subject: Ahem; the subject is Parameter Negotiation for RFC1294 . . . Cc: ietf-ppp@ucdavis.ucdavis.edu All the talk about how well PPP can better cope with periodic loss of X.25 connectivity is diverting attention from a much, much more serious disagreement, and one that I would like to get some more feedback on besides just me and Bill Simpson. I apologize for leaving it buried in the middle of the document. The point of disagreement is "If a new system which has the optional parameter negotiation mechanism should connect to an old system not implementing parameter negotiation ****for RFC1294 & RFC1356**** should the new system refuse to pass packets of any kind to the old system?" Bill Simpson feels that this necessary to be consistent with PPP. I personally feel that this would be a disaster. Bill can no doubt justifyable accuse me of prejudicing the issue by the way I phrased the question, but I'm doing so not out of malice towards him or oneupsmanship, but because I think we lost that point of perspective..... If it is really and truly the case that any attempt to recover PPP's parameter negotiation mechanism requires this, and the sentiment of other people in iplpdn is strong enough for the ability to pass packets between old and new systems, then we should abandon the draft and do something else, but something is needed sooner rather than later!