From ietf-ppp-request@ucdavis.ucdavis.edu Sat May 5 11:15:09 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA01986; Sat, 5 May 90 11:13:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02746; Sat, 5 May 90 10:48:06 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02681; Sat, 5 May 90 10:38:40 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Sat, 5 May 90 13:39:13 EDT Received: via switchmail; Sat, 5 May 90 13:39:07 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:34:56 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:34:51 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Sat, 5 May 90 13:34:51 -0400 (EDT) Resent-Message-Id: <4aEkuvC00iU4Q4dWB9@andrew.cmu.edu> Resent-Date: Sat, 5 May 90 13:34:51 -0400 (EDT) Resent-From: Drew Daniel Perkins Resent-To: ietf-ppp@ucdavis.ucdavis.edu Return-Path: Date: Thu, 3 May 90 19:54:06 EST From: Dave Katz Message-Id: <9005040054.AA00375@merit.edu> To: ddp@andrew.cmu.edu, forster@cisco.com, ie@merit.edu, rdhobby@ucdavis.ucdavis.edu Subject: PPP NCP for OSI NL Status: O I whipped up the following text tonight, describing how to use OSI network layer protocols over PPP. Please read and comment. If it looks OK, should I submit it as an Internet Draft, or should it be run past the PPP WG first? __________________________________________________________ Internet Engineering Task Force D. Katz Internet Draft Merit/NSFNET May 1990 The Point-to-Point Protocol: Network Control Protocol for OSI Network Layer Protocols Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1. A method for encapsulating datagrams over serial links. 2. An extensible Link Control Protocol (LCP). 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring OSI Network Layer Protocols (called the OSI Network Layer Control Protocol, OSINLCP). Status of this Memo This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to DKATZ@MERIT.EDU. Acknowledgements Many of the concepts and much of the text in this document is taken from the Point-to-Point protocol documents, written by Drew Perkins of Carnegie Mellon University and the Point-to-Point Protocol Working Group of the Internet Engineering Task Force. 1. Introduction 1.1 Overview of PPP PPP has three main components: 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point-to- point links. Katz [Page 1] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 2. An extensible Link Control Protocol (LCP) to establish, configure, and test the data-link connection. 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network-layer protocols. In order to establish communications over a point-to-point link, the originating PPP would first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, the originating PPP would send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network- layer protocols has been configured, datagrams from each network- layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (e.g., inactivity timer expires or user intervention). The encapsulation method, the LCP, and an NCP for the DoD IP protocol are all defined in [1]. Configuration Options for PPP are defined in [2]. 1.2 OSI Network Layer Protocols A number of protocols have been defined for the Network Layer of OSI, including the Connectionless Network Layer Protocol (CLNP, ISO 8473) [3], the End System to Intermediate System routing protocol (ES-IS, ISO 9542) [4], the Intermediate System to Intermediate System routing protocol (IS-IS, DP 10589) [5], and the Connection- Oriented Network Protocol (X.25 packet level protocol, ISO 8208) [6]. OSI Network Layer protocols can be discriminated according to the first octet in each PDU, known as the Network Layer Protocol Identifier (NLPID), defined in ISO/TR 9577 [7]. This allows the various protocols to be run over a common data link without any discriminator below the network layer. 2. A PPP NCP for OSI Network Layer Protocols The OSI Network Layer Control Protocol (OSINLCP) is responsible for configuring, enabling, and disabling the OSI protocol modules on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. Katz [Page 2] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 OSINLCP packets may not be exchanged until LCP has reached the Network-Layer Protocol Configuration Negotiation phase. OSINLCP packets received before this phase is reached should be silently discarded. Likewise, OSI NPDUs may not be exchanged until OSINLCP has first opened the connection (reached the Open state). The OSI Network Layer Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one OSI Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8023 (OSI Network Layer Control Protocol). 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. Timeouts OSINLCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types Currently, OSINLCP has no Configuration Options defined. 2.1 Sending OSI NPDUs Before any NPDUs may be communicated, both the Link Control Protocol and the OSI Network Layer Control Protocol must reach the Open state. Exactly one OSI NPDU is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0023 (OSI Network Layer). Katz [Page 3] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 The maximum length of an OSI NPDU transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger NPDUs must be segmented as necessary. If a system wishes to avoid segmentation and reassembly, it should use transport layer mechanisms to discourage others from sending large PDUs. 3. Exchanging Network Layer Addressing Information OSINLCP does not define a separate configuration option for the exchange of OSI Network Layer address information. Instead, the ES- IS protocol, ISO 9542, should be used. This protocol provides a mechanism for determining the Network Layer address(es) of the neighbor on the link, as well as determining if the neighbor is an End System or an Intermediate System. The ES-IS protocol does not currently support Network Layer address assignment. If address assignment is viewed as being desirable, it would be preferable to add this capability to ISO 9542, rather than creating a mechanism within PPP. This matter is for further study. References [1] Perkins, D., "The Point-to-Point Protocol: A Proposed Standard for the Transmission of Multi-Protocol Datagrams Over Point-to- Point Links", Internet Draft, IETF, April 1990. [2] Perkins, D., "The Point-to-Point Protocol (PPP) Initial Configuration Options", Internet Draft, IETF, April 1990. [3] ISO, "Information processing systems--Data communications-- Protocol for providing the connectionless-mode network service", ISO 8473, 1988. [4] ISO, "Information processing systems--Telecommunications and information exchange between systems--End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocol for providing the connectionless- mode network service (ISO 8473)", ISO 9542, 1988. [5] ISO, "Information processing systems--Telecommunications and information exchange between systems--Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", DP 10589, 1990. Katz [Page 4] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 [6] ISO, "Information processing systems--Data communications--X.25 packet level protocol for Data terminal equipment", ISO 8208, 1984. [7] ISO, "Information technology--Telecommunications and information exchange between systems--Protocol identification in the Network layer", ISO/TR 9577, to be published. Chairman's Address This proposal is within the purview of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair: Russ Hobby UC Davis Computing Services Davis, CA 95616 Phone: (916) 752-0236 EMail: rdhobby@ucdavis.edu Author's Address Questions about this memo can also be directed to the author: Dave Katz Merit/NSFNET 1075 Beal Ave. Ann Arbor, MI 48109 Phone: (313) 763-4898 EMail: dkatz@merit.edu Katz [Page 5] From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 8 12:31:18 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA22512; Tue, 8 May 90 12:20:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28319; Tue, 8 May 90 11:32:36 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28075; Tue, 8 May 90 11:19:21 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.03) id AA21951; Tue, 8 May 90 11:12:57 -0700 From: ccruss@aggie.ucdavis.edu (Russ Hobby) Date: Tue, 8 May 90 11:12:57 -0700 Message-Id: <9005081812.AA21951@aggie.ucdavis.edu> To: Subject: Re: OSI Network Layer and DECnet Phase IV over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu, dkatz@merit.edu Status: O Arthur, Welcome aboard PPP. Dave Katz at Merit just recently wrote a draft for OSI on PPP, so your job just became easier! I have included it below for review by the PPP WG. For those that didn't see Stev Knowles note, Stev is now chairing the PPP WG, since I have found that being Area Director for Applications is taking up much of my time. I will continue to work with the PPP WG however. I would like to compliment Stev on running the meeting at Pittsburgh. Although some might consider his style as "unique", he was fair to all and really got some things going. Russ Hobby INTERNET: rdhobby@ucdavis.edu IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS UUCP: ...!ucbvax!ucdavis!rdhobby __________________________________________________________ Internet Engineering Task Force D. Katz Internet Draft Merit/NSFNET May 1990 The Point-to-Point Protocol: Network Control Protocol for OSI Network Layer Protocols Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1. A method for encapsulating datagrams over serial links. 2. An extensible Link Control Protocol (LCP). 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring OSI Network Layer Protocols (called the OSI Network Layer Control Protocol, OSINLCP). Status of this Memo This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to DKATZ@MERIT.EDU. Acknowledgements Many of the concepts and much of the text in this document is taken from the Point-to-Point protocol documents, written by Drew Perkins of Carnegie Mellon University and the Point-to-Point Protocol Working Group of the Internet Engineering Task Force. 1. Introduction 1.1 Overview of PPP PPP has three main components: 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point-to- point links. Katz [Page 1] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 2. An extensible Link Control Protocol (LCP) to establish, configure, and test the data-link connection. 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network-layer protocols. In order to establish communications over a point-to-point link, the originating PPP would first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, the originating PPP would send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network- layer protocols has been configured, datagrams from each network- layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (e.g., inactivity timer expires or user intervention). The encapsulation method, the LCP, and an NCP for the DoD IP protocol are all defined in [1]. Configuration Options for PPP are defined in [2]. 1.2 OSI Network Layer Protocols A number of protocols have been defined for the Network Layer of OSI, including the Connectionless Network Layer Protocol (CLNP, ISO 8473) [3], the End System to Intermediate System routing protocol (ES-IS, ISO 9542) [4], the Intermediate System to Intermediate System routing protocol (IS-IS, DP 10589) [5], and the Connection- Oriented Network Protocol (X.25 packet level protocol, ISO 8208) [6]. OSI Network Layer protocols can be discriminated according to the first octet in each PDU, known as the Network Layer Protocol Identifier (NLPID), defined in ISO/TR 9577 [7]. This allows the various protocols to be run over a common data link without any discriminator below the network layer. 2. A PPP NCP for OSI Network Layer Protocols The OSI Network Layer Control Protocol (OSINLCP) is responsible for configuring, enabling, and disabling the OSI protocol modules on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. Katz [Page 2] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 OSINLCP packets may not be exchanged until LCP has reached the Network-Layer Protocol Configuration Negotiation phase. OSINLCP packets received before this phase is reached should be silently discarded. Likewise, OSI NPDUs may not be exchanged until OSINLCP has first opened the connection (reached the Open state). The OSI Network Layer Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one OSI Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8023 (OSI Network Layer Control Protocol). 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. Timeouts OSINLCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types Currently, OSINLCP has no Configuration Options defined. 2.1 Sending OSI NPDUs Before any NPDUs may be communicated, both the Link Control Protocol and the OSI Network Layer Control Protocol must reach the Open state. Exactly one OSI NPDU is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0023 (OSI Network Layer). Katz [Page 3] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 The maximum length of an OSI NPDU transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger NPDUs must be segmented as necessary. If a system wishes to avoid segmentation and reassembly, it should use transport layer mechanisms to discourage others from sending large PDUs. 3. Exchanging Network Layer Addressing Information OSINLCP does not define a separate configuration option for the exchange of OSI Network Layer address information. Instead, the ES- IS protocol, ISO 9542, should be used. This protocol provides a mechanism for determining the Network Layer address(es) of the neighbor on the link, as well as determining if the neighbor is an End System or an Intermediate System. The ES-IS protocol does not currently support Network Layer address assignment. If address assignment is viewed as being desirable, it would be preferable to add this capability to ISO 9542, rather than creating a mechanism within PPP. This matter is for further study. References [1] Perkins, D., "The Point-to-Point Protocol: A Proposed Standard for the Transmission of Multi-Protocol Datagrams Over Point-to- Point Links", Internet Draft, IETF, April 1990. [2] Perkins, D., "The Point-to-Point Protocol (PPP) Initial Configuration Options", Internet Draft, IETF, April 1990. [3] ISO, "Information processing systems--Data communications-- Protocol for providing the connectionless-mode network service", ISO 8473, 1988. [4] ISO, "Information processing systems--Telecommunications and information exchange between systems--End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocol for providing the connectionless- mode network service (ISO 8473)", ISO 9542, 1988. [5] ISO, "Information processing systems--Telecommunications and information exchange between systems--Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", DP 10589, 1990. Katz [Page 4] INTERNET-DRAFT PPP NCP for OSI Protocols May 1990 [6] ISO, "Information processing systems--Data communications--X.25 packet level protocol for Data terminal equipment", ISO 8208, 1984. [7] ISO, "Information technology--Telecommunications and information exchange between systems--Protocol identification in the Network layer", ISO/TR 9577, to be published. Chairman's Address This proposal is within the purview of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair: Russ Hobby UC Davis Computing Services Davis, CA 95616 Phone: (916) 752-0236 EMail: rdhobby@ucdavis.edu Author's Address Questions about this memo can also be directed to the author: Dave Katz Merit/NSFNET 1075 Beal Ave. Ann Arbor, MI 48109 Phone: (313) 763-4898 EMail: dkatz@merit.edu Katz [Page 5] From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 2 09:01:09 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA16434; Wed, 2 May 90 08:48:28 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08090; Wed, 2 May 90 08:16:07 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from att-in.att.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07951; Wed, 2 May 90 08:05:16 -0700 Message-Id: <9005021505.AA07951@ucdavis.ucdavis.edu> From: heather@arch3.att.com Date: Wed, 2 May 90 10:44 EDT Original-From: arch3!heather (Heather C Dee +1 201 949 5303) To: ietf-ppp@ucdavis.ucdavis.edu Subject: Proposal for PPP frame structure Status: O PROPOSAL FOR USING LAPD FRAME STRUCTURE IN PPP MOTIVATION The purpose of the Point-to-Point Protocol (PPP) is to provide standard data link protocol format & procedures for use by routers or hosts over point-to-point (private-line or dial-up) circuits, in order to achieve multivendor connectivity. It is desirable that this same protocol can be used when these routers or hosts are connected by means other than point-to-point circuits -- in particular, the future LAPD frame-relay virtual-circuit services. LAPD frame-relay is a high-performance packet-switching method which is capable of operating at NxDS0 (Nx64Kbps) to NxDS1 (Nx1.536Mbps) speeds and which is currently being standardized in ANSI (Subcommittees T1S1.1/2) and CCITT (Study Groups XI and XVIII). The ANSI frame-relay standards are currently expected to be positively ballotted in June this year. Frame-relay makes use of the (ISDN data link) LAPD protocol's addressing/multiplexing capability and enables network switches to perform multiplexing and switching at the link level without terminating the protocol (and hence to do so at higher speeds than current packet-switching techniques such as X.25). Because of its high-performance, frame-relay has the potential for becoming an important means for LAN interconnect. A number of major packet-switch and stat. mux vendors are actively implementing or have announced plans to implement frame-relay capabilities. These vendors have also stimulated bridge/router vendors to build frame-relay interfaces for their bridges/routers. This will enable these bridges/routers to use frame-relay virtual-circuits (switched or permanent) offered by public or private networks as "virtual private-lines" (much like the way many bridges/routers use X.25 virtual-circuits today) for interlocation connectivity. Having a common frame format for PPP and LAPD would enable bridges/routers to use real circuits and LAPD virtual circuits interchangeably without any hardware/software modification. In addition, a common frame format protocol that supports multiple needs and applications will encourage cost and implementation efficiencies in vendor products. The LAPD frame format is now standardized for the ISDN User-Network Interface for the D-channel (CCITT Q.921) and for peer-to-peer error correction modem communication (CCITT V.42). LAPD frame format is expected to be approved immediately by ANSI for the frame relay service. COMPARISON OF FRAME STRUCTURE OF PPP AND LAPD 8 bits 8 bits 16 bits 16 bits | | | | ___________________________________________________________ | | | | | | | | |Flag|Address|Control=UI| PID | Info | FCS |Flag| PPP frame |____|_______|__________|_____|_______________|______|____| \ | | Insert below | | | __________________________|___________________|____________ | | | | | | | |Flag| Address |Control=UI| Info | FCS |Flag| LAPD-UI frame |____|_________|__________|___________________|______|____| | | | 16 bits 8 bits 16 bits The current PPP data-link layer frame can be viewed as a LAPD frame carrying the higher-layer information consisting of the Protocol ID plus the user data datagram or message (as defined in RFC1134). The only differences are that in PPP the frame address field length is 1 octet and this value of this field is set to be all 1's. If we extend the PPP address field length to 2 octets and remove the restriction of it having to have a particular value, the PPP frame would become a LAPD frame that can be transported by LAPD frame-relay networks in addition to point-to-point links. When used with LAPD frame-relay services, the address field can be assigned a unique Data Link Connection Identifier (DLCI) value which would be used as the "virtual-circuit ID number" by the network to switch the LAPD frames toward the designated remote bridge/router or host. When used on a point-to-point circuit, the address field can be assigned a default value. It is important to note that these proposed changes involve only the frame structure for encapsulation and need not affect any other protocol aspects currently specified in RFC1134. SUMMARY We recommend that the address field length of the PPP frame be extended to 2 octets and that the restriction that it has to have the fixed "all 1's" value be removed. This would extend the applicability of the PPP for use with future frame-relay virtual-circuit services. Finally, because this proposal affects only the HDLC-based frame format of PPP, and the new format also belongs to the HDLC family of protocols, the change to router software would be minor. No delays would be expected in the availability of vendor implementations of PPP interfaces. ------------------------------------------------------------- Note: please send your comments/inputs on this proposal to: Heather Dee (AT&T-Bell Laboratories, Holmdel, NJ) e-mail address: heather@arch3.att.com ------------------------------------------------------------- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 2 23:15:17 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA23847; Wed, 2 May 90 23:10:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18893; Wed, 2 May 90 22:48:37 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ALLSPICE.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18857; Wed, 2 May 90 22:45:00 -0700 Received: by PTT.LCS.MIT.EDU id AA22706; Thu, 3 May 90 01:44:22 EDT Date: Thu, 3 May 90 01:44:22 EDT From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9005030544.AA22706@PTT.LCS.MIT.EDU> To: heather@arch3.att.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Proposal for PPP frame structure Cc: jnc@PTT.LCS.MIT.EDU Status: O Heather, I'm the IETF Area Director in whose area the PPP Working Group falls. Your proposal appears reasonable, but there are two issues. First, PPP was just about to go to Draft Standard, which is a point at which people start to deploy implementations, etc, and making a change at this point is not absolutely impossible but is much more difficult. (Too bad we didn't get this input a little earlier! :-). There was some discussion about support of 16 bit addresses at the time the protocol was put together, but since we weren't aware of the frame relay facet, and planned to use PPP only on dedicated single-point lines, we thought we could get away with restricting it to 8 bit addresses. We are under a lot of pressure to get PPP out (since it is already quite delayed), so it's not clear we can put a hold on this to slide this in. We will discuss this at the PPP Working Group Meeting (which happens to be tomorrow :-) and let you know what happens. Also, there are some more questions about the details of frame relay (which I'm not familiar with); for instance, will a vanilla PPP implementation be able to send packets over a frame relay network? I.e., do you have to go through some set-up phase where you send packets down the wire to set up the VC? If so, then existing PPP software cannot use frame relay off the shelf, and this change would be less interesting to us. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 3 10:47:45 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA27892; Thu, 3 May 90 10:39:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25960; Thu, 3 May 90 09:45:26 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO5.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25891; Thu, 3 May 90 09:39:42 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Thu, 3 May 90 12:39:14 EDT Received: via switchmail; Thu, 3 May 90 12:39:05 -0400 (EDT) Received: from unix3.andrew.cmu.edu via qmail ID ; Thu, 3 May 90 12:36:30 -0400 (EDT) Received: from unix3.andrew.cmu.edu via qmail ID ; Thu, 3 May 90 12:36:12 -0400 (EDT) Received: from BatMail.robin.v2.10.CUILIB.3.45.SNAP.NOT.LINKED.unix3.andrew.cmu.edu.vax.3 via MS.5.6.unix3.andrew.cmu.edu.vax_3; Thu, 3 May 90 12:36:06 -0400 (EDT) Message-Id: Date: Thu, 3 May 90 12:36:06 -0400 (EDT) From: Drew Daniel Perkins To: ietf-ppp@ucdavis.ucdavis.edu Subject: document changes Status: O As the result of discussions at the IETF (mostly regarding the frame relay proposal), we made a few small wording changes to the base ppp document: *** ppp.out Thu May 3 12:13:41 1990 --- ppp.old.out Thu May 3 12:24:45 1990 *************** *** 89,96 encapsulation scheme. Point-to-Point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in ! LAN environments, is especially difficult over circuit switched ! point-to-point circuits (e.g. dialups). Some additional issues addressed by this specification of PPP include asynchronous (start/stop) and bit-oriented synchronous encapsulation, --- 89,96 ----- encapsulation scheme. Point-to-Point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in ! LAN environments, is especially difficult over switched point-to- ! point circuits (e.g. dialups). Some additional issues addressed by PPP include asynchronous (start/stop) and bit-oriented synchronous encapsulation, network *************** *** 92,103 LAN environments, is especially difficult over circuit switched point-to-point circuits (e.g. dialups). ! Some additional issues addressed by this specification of PPP include ! asynchronous (start/stop) and bit-oriented synchronous encapsulation, ! network protocol multiplexing, link configuration, link quality ! testing, error detection, and option negotiation for such ! capabilities as network-layer address negotiation and data ! compression negotiation. PPP addresses these issues by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCP) to --- 92,102 ----- LAN environments, is especially difficult over switched point-to- point circuits (e.g. dialups). ! Some additional issues addressed by PPP include asynchronous ! (start/stop) and bit-oriented synchronous encapsulation, network ! protocol multiplexing, link configuration, link quality testing, ! error detection, and option negotiation for such capabilities as ! network-layer address negotiation and data compression negotiation. PPP addresses these issues by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCP) to *************** *** 108,113 PPP has three main components: - 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. At this time, PPP specifies the use of asynchronous or synchronous duplex circuits, either dedicated --- 107,113 ----- PPP has three main components: + 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. *************** *** 119,127 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- ! to-point links. At this time, PPP specifies the use of ! asynchronous or synchronous duplex circuits, either dedicated ! or circuit switched. 2. An extensible Link Control Protocol (LCP) to establish, configure, and test the data-link connection. --- 118,124 ----- uses HDLC as a basis for encapsulating datagrams over point- ! to-point links. 2. An extensible Link Control Protocol (LCP) to establish, configure, and test the data-link connection. *************** *** 182,193 The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the ! provision of a duplex circuit, either dedicated or circuit switched, ! which can operate in either an asynchronous (start/stop) or ! synchronous bit-serial mode, transparent to PPP Data Link Layer ! frames. PPP does not impose any restrictions regarding transmission ! rate, other than those imposed by the particular DTE/DCE interface in ! use. PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect --- 182,192 ----- The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the ! provision of a duplex circuit, either dedicated or switched, which ! can operate in either an asynchronous (start/stop) or synchronous ! bit-serial mode, transparent to PPP Data Link Layer frames. PPP does ! not impose any restrictions regarding transmission rate, other than ! those imposed by the particular DTE/DCE interface in use. PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect *************** *** 333,342 The Address field is a single octet and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not assign individual station addresses. The All- ! Stations address should always be recognized and received. The ! use of other address lengths and values may be defined at a later ! time, or by prior agreement. Frames with unrecognized Addresses ! should be reported through the normal network management facility. --- 333,340 ----- The Address field is a single octet and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not assign individual station addresses. The All- ! Stations address should always be recognized and received. Frames ! with other Addresses should be silently discarded. Control Field *************** The complete new document follows: Internet Engineering Task Force Drew D. Perkins Internet Draft Carnegie Mellon University May 3, 1990 DRAFT The Point-to-Point Protocol: A Proposed Standard for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1. A method for encapsulating datagrams over serial links. 2. An extensible Link Control Protocol (LCP). 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the encapsulation scheme, the basic LCP, and an NCP for establishing and configuring the Internet Protocol (IP) (called the IP Control Protocol, IPCP). The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET, OSI) are expected to be developed as needed. Status of this Memo This memo defines a proposed standard protocol for the Internet community. This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. Distribution of this memo is unlimited. Perkins May 3, 1990 [Page i] 1. Introduction 1. Introduction 1.1. Motivation 1.1 Motivation In the last few years, the Internet has seen explosive growth in the number of hosts supporting TCP/IP. The vast majority of these hosts are connected to Local Area Networks (LANs) of various types, Ethernet being the most common. Most of the other hosts are connected through Wide Area Networks (WANs) such as X.25 style Public Data Networks (PDNs). Relatively few of these hosts are connected with simple point-to-point (i.e., serial) links. Yet, point-to-point links are among the oldest methods of data communications and almost every host supports point-to-point connections. For example, asynchronous RS-232-C [1] interfaces are essentially ubiquitous. One reason for the small number of point-to-point IP links is the lack of a standard encapsulation protocol. There are plenty of non- standard (and at least one defacto standard) encapsulation protocols available, but there is not one which has been agreed upon as an Internet Standard. By contrast, standard encapsulation schemes do exist for the transmission of datagrams over most popular LANs. One purpose of this memo is to remedy this problem. But even more importantly, the Point-to-Point Protocol proposes more than just an encapsulation scheme. Point-to-Point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in LAN environments, is especially difficult over circuit switched point-to-point circuits (e.g. dialups). Some additional issues addressed by this specification of PPP include asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network-layer address negotiation and data compression negotiation. PPP addresses these issues by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCP) to negotiate optional configuration parameters and facilities. 1.2. Overview of PPP 1.2 Overview of PPP PPP has three main components: Perkins May 3, 1990 [Page 1] Internet Draft Point-to-Point Protocol 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. At this time, PPP specifies the use of asynchronous or synchronous duplex circuits, either dedicated or circuit switched. 2. An extensible Link Control Protocol (LCP) to establish, configure, and test the data-link connection. 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network- layer protocols. In order to establish communications over a point-to-point link, the originating PPP would first send LCP packets to configure and test the data link. After the link has been establish and optional facilities have been negotiated as needed by the LCP, the originating PPP would send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (e.g., inactivity timer expires or user intervention). 1.3. Organization of the document 1.3 Organization of the document This memo is divided into several sections. Section 2 discusses the physical-layer requirements of PPP. Section 3 describes the Data Link Layer including the PPP frame format and data link encapsulation scheme. Section 4 specifies the LCP including the connection establishment and option negotiation procedures. Section 5 specifies the IP Control Protocol (IPCP), which is the NCP for the Internet Protocol, and describes the encapsulation of IP datagrams within PPP packets. Appendix A summarizes important features of asynchronous HDLC, and Appendix B describes an efficient table-lookup algorithm for fast Frame Check Sequence (FCS) computation. Perkins May 3, 1990 [Page 2] Internet Draft Point-to-Point Protocol 2. Physical Layer Requirements 2. Physical Layer Requirements The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the provision of a duplex circuit, either dedicated or circuit switched, which can operate in either an asynchronous (start/stop) or synchronous bit-serial mode, transparent to PPP Data Link Layer frames. PPP does not impose any restrictions regarding transmission rate, other than those imposed by the particular DTE/DCE interface in use. PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and Data Terminal Ready (DTR). However, using such signals when available can allow greater functionality and performance. Perkins May 3, 1990 [Page 3] Internet Draft Point-to-Point Protocol 3. The Data Link Layer 3. The Data Link Layer The Point-to-Point Protocol uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) High-level Data Link Control (HDLC) procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/stop transmission" [5]. ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments. The PPP control procedures use the definitions and Control field encodings standardized in ISO 4335-1979 [3] and ISO 4335- 1979/Addendum 1-1979 [4]. The PPP frame structure is also consistent with CCITT Recommendation X.25 LAPB [6], since that too is based on HDLC. Note: ISO 3309:1984/PDAD1 is a Proposed Draft standard. At present, it seems that ISO 3309:1984/PDAD1 is stable and likely to become an International Standard. Therefore, we feel comfortable about using it before it becomes an International Standard. The progress of this proposal should be tracked and encouraged by the Internet community. The purpose of this memo is not to document what is already standardized in ISO 3309. We assume that the reader is already familiar with HDLC, or has access to a copy of [2] or [6]. Instead, this paper attempts to give a concise summary and point out specific options and features used by PPP. Since "Addendum 1: Start/stop transmission", is not yet standardized and widely available, it is summarized in Appendix A. Perkins May 3, 1990 [Page 4] Internet Draft Point-to-Point Protocol 3.1. Frame Format 3.1 Frame Format A summary of the standard PPP frame structure is shown below. The fields are transmitted from left to right. +----------+----------+----------+----------+------------ | Flag | Address | Control | Protocol | Information | 01111110 | 11111111 | 00000011 | 16 bits | * +----------+----------+----------+----------+------------ ---+---------+----------+ | FCS | Flag | | 16 bits | 01111110 | ---+---------+----------+ This figure does not include start/stop bits (for asynchronous links) or any bits or octets inserted for transparency. When asynchronous links are used, all octets are transmitted with one start bit, eight bits of data, and one stop bit. There is no provision in either PPP or ISO 3309:1984/PDAD1 for seven bit asynchronous links. To remain consistent with standard Internet practice, and avoid confusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Significant Bit order, reading from left to right, unless otherwise indicated. Note that this is contrary to standard ISO and CCITT practice which orders bits as transmitted (i.e. network bit order). Keep this in mind when comparing this document with the international standards documents. Flag Sequence The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e). Address Field The Address field is a single octet and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not assign individual station addresses. The All- Stations address should always be recognized and received. The use of other address lengths and values may be defined at a later time, or by prior agreement. Frames with unrecognized Addresses should be reported through the normal network management facility. Perkins May 3, 1990 [Page 5] Internet Draft Point-to-Point Protocol Control Field The Control field is a single octet and contains the binary sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the P/F bit is set to zero. Frames with other Control field values should be silently discarded. Protocol Field The Protocol field is two octets and its value identifies the protocol encapsulated in the Information field of the frame. The most up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC [12]. Initial values are also listed below. Protocol field values in the "cxxx" range identify datagrams as belonging to the Link Control Protocol (LCP) or associated protocols. Values in the "8xxx" range identify datagrams belonging to the family of Network Control Protocols (NCP). Values in the "0xxx" range identify the network protocol of specific datagrams. This Protocol field is defined by PPP and is not a field defined by HDLC. However, the Protocol field is consistent with the ISO 3309 extension mechanism for Address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules should be considered as having an unrecognized Protocol, and should be handled as specified by the LCP. The Protocol field is transmitted and received most significant octet first. Perkins May 3, 1990 [Page 6] Internet Draft Point-to-Point Protocol The Protocol field is initially assigned as follows: Value (in hex)Protocol 0001 to 001freserved (transparency inefficient) 0021Internet Protocol 0023 *OSI Network Layer 0025 *Xerox NS IDP 0027 *DECnet Phase IV 0029 *Appletalk 002b *Novell IPX 002d *Van Jacobson Compressed TCP/IP 1 002f *Van Jacobson Compressed TCP/IP 2 8021Internet Protocol Control Protocol 8023 *OSI Network Layer Control Protocol 8025 *Xerox NS IDP Control Protocol 8027 *DECnet Phase IV Control Protocol 8029 *Appletalk Control Protocol 802b *Novell IPX Control Protocol 802d *Reserved 802f *Reserved c021Link Control Protocol c023 *User/Password Authentication Protocol * Reserved for future use; not described in this document. Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The end of the Information field is found by locating the closing Flag Sequence and allowing two octets for the Frame Check Sequence field. The default maximum length of the Information field is 1500 octets. By prior agreement, consenting PPP implementations may use other values for the maximum Information field length. On transmission, the Information field may be padded with an arbitrary number of octets up to the maximum length. It is the responsibility of each protocol to disambiguate padding octets from real information. Frame Check Sequence (FCS) Field The Frame Check Sequence field is normally 16 bits (two octets). By prior agreement, consenting PPP implementations may use a 32- bit (four-octet) FCS for improved error detection. Perkins May 3, 1990 [Page 7] Internet Draft Point-to-Point Protocol The FCS field is calculated over all bits of the Address, Control, Protocol and Information fields not including any start and stop bits (asynchronous) and any bits (synchronous) or octets (asynchronous) inserted for transparency. This does not include the Flag Sequences or FCS field. The FCS is transmitted with the coefficient of the highest term first. For more information on the specification of the FCS, see ISO 3309 or CCITT X.25. Note: A fast, table-driven implementation of the 16-bit FCS algorithm is shown in Appendix B. This implementation is based on [7], [8], and [9]. Modifications to the Basic Frame Format The Link Control Protocol can negotiate modifications to the standard PPP frame structure. However, modified frames will always be clearly distinguishable from standard frames. Perkins May 3, 1990 [Page 8] Internet Draft Point-to-Point Protocol 4. The PPP Link Control Protocol (LCP) 4. The PPP Link Control Protocol (LCP) The Link Control Protocol (LCP) provides a method of establishing, configuring, maintaining and terminating the point-to-point connection. LCP goes through four distinct phases: Phase 1: Link Establishment and Configuration Negotiation Before any network-layer datagrams (e.g. IP) may be exchanged, LCP must first open the connection through an exchange of Configure packets. This exchange is complete, and the Open state entered, once a Configure-Ack packet (described below) has been both sent and received. Any non-LCP packets received before this exchange is complete are silently discarded. It is important to note that LCP handles configuration only of the link; LCP does not handle configuration of individual network- layer protocols. In particular, all Configuration Parameters which are independent of particular network-layer protocols are configured by LCP. All Configuration Options are assumed to be at default values unless altered by the configuration exchange. Phase 2: Link Quality Determination LCP allows an optional Link Quality Determination phase following transition to the LCP Open state. In this phase, the link is tested to determine if the link quality is sufficient to bring up network-layer protocols. This phase is completely optional. LCP may delay transmission of network-layer protocol information until this phase is completed. The procedure for Link Quality Determination is unspecified and may vary from implementation to implementation, or because of user-configured parameters, but only so long as the procedure doesn't violate other aspects of LCP. One suggested method is to use LCP Echo-Request and Echo-Reply packets. What is important is that this phase may persist for any length of time. Therefore, implementations should avoid fixed timeouts when waiting for their peers to advance to phase 3. Phase 3: Network-Layer Protocol Configuration Negotiation Once LCP has finished the Link Quality Determination phase, network-layer protocols may be separately configured by the appropriate Network Control Protocols (NCP), and may be brought up and taken down at any time. If LCP closes the link, it informs Perkins May 3, 1990 [Page 9] Internet Draft Point-to-Point Protocol the network-layer protocols so that they may take appropriate action. Phase 4: Link Termination LCP may terminate the link at any time. This will usually be done at the request of a human user, but may happen because of a physical event such as the loss of carrier, or the expiration of an idle-period timer. Perkins May 3, 1990 [Page 10] Internet Draft Point-to-Point Protocol 4.1. The LCP Automaton 4.1 The LCP Automaton 4.1.1. Overview 4.1.1 Overview LCP is specified by a number of packet formats and a finite-state automaton. This section presents an overview of the LCP automaton, followed by a representation of it as both a state diagram and a state transition table. There are three classes of LCP packets: 1. Link Establishment packets used to establish and configure a link, (e.g., Configure-Request, Configure-Ack, Configure-Nak and Configure-Reject) 2. Link Termination packets used to terminate a link, (e.g., Terminate-Request and Terminate-Ack) 3. Link Maintenance packets used to manage and debug a link, (e.g., Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply and Discard-Request) The finite-state automaton is defined by events, state transitions and actions. Events include receipt of external commands such as Open and Close, expiration of the Restart timer, and receipt of packets from a LCP peer. Actions include the starting of the Restart timer and transmission of packets. 4.1.2. State Diagram 4.1.2 State Diagram The state diagram which follows describes the sequence of events for reaching agreement on Configuration Options (opening the PPP connection) and for later closing of the connection. The state machine is initially in the Closed state (1). Once the Open state (6) has been reached, both ends of the link have met the requirement of having both sent and received a Configure-Ack packet. In the state diagram, events are shown above horizontal lines. Actions are shown below horizontal lines. Two types of LCP packets - Configure-Naks and Configure-Rejects - are not differentiated in the state diagram. As will be described later, these packets do indeed serve different, though similar, functions. However, at the level of detail of this state diagram, they always cause the same transition. Perkins May 3, 1990 [Page 11] Internet Draft Point-to-Point Protocol Since a more detailed specification of the LCP automaton is given in a state transition table in the following section, implementation should be done by consulting it rather than this state diagram. Perkins May 3, 1990 [Page 12] Internet Draft Point-to-Point Protocol +------------------------------+ | | V | +---2---+ PO +---1---+ RTA +---7---+ | | |<-------------| |<-----------| | | |Listen | |Closed | |Closing| | RCR | | C | | PLD | | | +----| |----->+------>| |<---Any | |<--+ | |scr +-------+ ^ +-------+ State +-------+ | | | | AO | ^ | TO | | | +-----------+ --- | | +---->+ | | | SCR | | str ^ | | C | RCN/TO | | C | | | --- | +-------->+<--------+ | --- | | | | | scr | | | | | +---3---+ V TO +---4---+ +-------+ | | | | |<-----+<------| |<-----------| | | | | | Req- | scr | Ack- | scn | Good | | | | | Sent | RCA | Rcvd | RCR | Req? | | | | | |------------->| |----------->| | | | | +-------+ +-------+ +-------+ | | | | ^ | | | | RCR | +<--------+ | | | | --- | | | TO RCN --- | | | | | | --- +---------+ +-----+ sca | | | | V | scn scr | | scr | V | | | +-------+ +---5---+ | +---6---+ C | | +--->| |------------->| |<--+ | |---+ | | Good | sca | Ack- | | Open | str | | Req? | RCR | Sent | RCA | | | | |<-------------| |----------->| | | +-------+ +-------+ +-------+ | ^ | | | | RCR | | RTR | +---------------------------------------+ +--------+ scr sta Events Actions RCR - Receive-Configure-Request scr - Send Configure-Request RCA - Receive-Configure-Ack sca - Send Configure-Ack RCN - Receive-Configure-Nak or Reject scn - Send Configure-Nak or Reject RTR - Receive-Terminate-Req str - Send Terminate-Req RTA - Receive-Terminate-Ack sta - Sent Terminate-Ack AO - Active-Open PO - Passive-Open C - Close TO - Timeout PLD - Physical-Layer-Down Perkins May 3, 1990 [Page 13] Internet Draft Point-to-Point Protocol 4.1.3. State Transition Table 4.1.3 State Transition Table The complete state transition table follows. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Two actions caused by the same event are represented as action1&action2. | State | 1 2 3 4 5 6 7 Events| Closed Listen Req-Sent Ack-Rcvd Ack-Sent Open Closing ------+------------------------------------------------------------- AO | scr/3 scr/3 3 4 5 6 scr/3 PO | 2 2 2* 4 5 6 sta/3* C | 1 1 1* 1 str/7 str/7 7 TO | 1 2 scr/3 scr/3 scr/3 6 str/7* PLD | 1 1 1 1 1 1 1 RCR+ | sta/1 scr&sca/5 sca/5 sca/6 sca/5 scr&sca/5 7 RCR- | sta/1 scr&scn/3 scn/3 scn/4 scn/3 scr&scn/3 7 RCA | sta/1 sta/2 4 scr/3 6 scr/3 7 RCN | sta/1 sta/2 scr/3 scr/3 scr/5 scr/3 7 RTR | sta/1 sta/2 sta/3 sta/3 sta/3 sta/1 sta/7 RTA | 1 2 3 3 3 1 1 RCJ | 1 2 1 1 1 1 1 RUC | scj/1 scj/2 scj/1 scj/1 scj/1 scj/1 1 scj/7 RER | sta/1 sta/2 3 4 5 ser/6 7 Notes: RCR+ - Receive-Configure-Request (Good) RCR- - Receive-Configure-Request (Bad) RCJ - Receive-Code-Reject RUC - Receive-Unknown-Code RER - Receive-Echo-Request scj - Send-Code-Reject ser - Send-Echo-Reply * - Special attention necessary, see detailed text 4.1.4. Events 4.1.4 Events Transitions and actions in the LCP state machine are caused by events. Some events are caused by commands executed at the local end (e.g. Active-Open, Passive-Open, and Close), others are caused by the receipt of packets from the remote end (e.g. Receive- Configure- Request, Receive-Configure-Ack, Receive-Configure-Nak, Receive- Terminate-Request and Receive-Terminate-Ack), and still others are caused by the expiration of the Restart timer started as the result Perkins May 3, 1990 [Page 14] Internet Draft Point-to-Point Protocol of other events (e.g. Timeout). Following is a list of LCP events. Active-Open (AO) The Active-Open event indicates the local execution of an Active- Open command by the network administrator (human or program). When this event occurs, LCP should immediately attempt to open the connection by exchanging configuration packets with the LCP peer. Passive-Open (PO) The Passive-Open event is similar to the Active-Open event. However, instead of immediately exchanging configuration packets, LCP should wait for the peer to send the first packet. This will only happen after an Active-Open event in the LCP peer. Close (C) The Close event indicates the local execution of a Close command. When this event occurs, LCP should immediately attempt to close the connection. Timeout (TO) The Timeout event indicates the expiration of the LCP Restart timer. The LCP Restart timer is started as the result of other LCP events. The Restart timer is used to time out transmissions of Configure- Request and Terminate-Request packets. Expiration of the Restart timer causes a Timeout event, which triggers the corresponding Configure-Request or Terminate-Request packet to be retransmitted. The Restart timer MUST be configurable, but should default to three (3) seconds. Receive-Configure-Request (RCR) The Receive-Configure-Request event occurs when a Configure- Request packet is received from the LCP peer. The Configure- Request packet indicates the desire to open a LCP connection and may specify Configuration Options. The Configure-Request packet is more fully described in a later section. Receive-Configure-Ack (RCA) The Receive-Configure-Ack event occurs when a valid Configure-Ack packet is received from the LCP peer. The Configure-Ack packet is Perkins May 3, 1990 [Page 15] Internet Draft Point-to-Point Protocol a positive response to a Configure-Request packet. Receive-Configure-Nak (RCN) The Receive-Configure-Nak event occurs when a valid Configure-Nak or Configure-Reject packet is received from the LCP peer. The Configure-Nak and Configure-Reject packets are negative responses to a Configure-Request packet. Receive-Terminate-Request (RTR) The Receive-Terminate-Request event occurs when a Terminate- Request packet is received from the LCP peer. The Terminate- Request packet indicates the desire to close the LCP connection. Receive-Terminate-Ack (RTA) The Receive-Terminate-Ack event occurs when a Terminate-Ack packet is received from the LCP peer. The Terminate-Ack packet is a response to a Terminate-Request packet. Receive-Code-Reject (RCJ) The Receive-Code-Reject event occurs when a Code-Reject packet is received from the LCP peer. The Code-Reject packet communicates an error that immediately closes the connection. Receive-Unknown-Code (RUC) The Receive-Unknown-Code event occurs when an un-interpretable packet is received from the LCP peer. The Code-Reject packet is a response to an unknown packet. Receive-Echo-Request (RER) The Receive-Echo-Request event occurs when a Echo-Request, Echo- Reply, or Discard-Request packet is received from the LCP peer. The Echo-Reply packet is a response to a Echo-Request packet. There is no reply to a Discard-Request. Physical-Layer-Down (PLD) The Physical-Layer-Down event occurs when the Physical Layer indicates that it is down. 4.1.5. Actions 4.1.5 Actions Actions in the LCP state machine are caused by events and typically Perkins May 3, 1990 [Page 16] Internet Draft Point-to-Point Protocol indicate the transmission of packets and/or the starting or stopping of the Restart timer. Following is a list of LCP actions. Send-Configure-Request (scr) The Send-Configure-Request action transmits a Configure-Request packet. This indicates the desire to open a LCP connection with a specified set of Configuration Options. The Restart timer is started after the Configure-Request packet is transmitted, to guard against packet loss. Send-Configure-Ack (sca) The Send-Configure-Ack action transmits a Configure-Ack packet. This acknowledges the receipt of a Configure-Request packet with an acceptable set of Configuration Options. Send-Configure-Nak (scn) The Send-Configure-Nak action transmits a Configure-Nak or Configure-Reject packet, as appropriate. This negative response reports the receipt of a Configure-Request packet with an unacceptable set of Configuration Options. Configure-Nak packets are used to refuse a Configuration Option value, and to suggest a new, acceptable value. Configure-Reject packets are used to refuse all negotiation about a Configuration Option, typically because it is not recognized or implemented. The use of Configure-Nak vs. Configure-Reject is more fully described in the section on LCP Packet Formats. Send-Terminate-Req (str) The Send-Terminate-Request action transmits a Terminate-Request packet. This indicates the desire to close a LCP connection. The Restart timer is started after the Terminate-Request packet is transmitted, to guard against packet loss. Send-Terminate-Ack (sta) The Send-Terminate-Request action transmits a Terminate-Ack packet. This acknowledges the receipt of a Terminate-Request packet or otherwise confirms the belief that a LCP connection is Closed. Send-Code-Reject (scj) The Send-Code-Reject action transmits a Code-Reject packet. This indicates the receipt of an unknown type of packet. This is an unrecoverable error which causes immediate transitions to the Perkins May 3, 1990 [Page 17] Internet Draft Point-to-Point Protocol Closed state on both ends of the link. Send-Echo-Reply (ser) The Send-Echo-Reply action transmits an Echo-Reply packet. This acknowledges the receipt of an Echo-Request packet. 4.1.6. States 4.1.6 States Following is a more detailed description of each LCP state. Closed (1) The initial and final state is the Closed state. In the Closed state the connection is down and there is no attempt to open it; all connection requests from peers are rejected. Physical-Layer- Down events always cause an immediate transition to the Closed state. There are two events which cause a transition out of the Closed state, Active-Open and Passive-Open. Upon an Active-Open event, a Configure-Request is transmitted, the Restart timer is started, and the Request-Sent state is entered. Upon a Passive-Open event, the Listen state is entered immediately. Upon receipt of any packet, with the exception of a Terminate-Ack, a Terminate-Ack is sent. Terminate-Acks are silently discarded to avoid creating a loop. The Restart timer is not running in the Closed state. The Physical Layer connection may be disconnected at any time when in the LCP Closed state. Listen (2) The Listen state is similar to the Closed state in that the connection is down and there is no attempt to open it. However, peer connection requests are no longer rejected. Upon receipt of a Configure-Request, a Configure-Request is immediately transmitted and the Restart timer is started. The received Configuration Options are examined and the proper response is sent. If a Configure-Ack is sent, the Ack-Sent state is entered. Otherwise, if a Configure-Nak or Configure-Reject is sent, the Request-Sent state is entered. In either case, LCP exits its passive state, and begins to actively open the connection. Terminate-Ack packets are sent in response to either Configure-Ack or Configure-Nak packets, Perkins May 3, 1990 [Page 18] Internet Draft Point-to-Point Protocol The Restart timer is not running in the Listen state. Request-Sent (3) In the Request-Sent state an active attempt is made to open the connection. A Configure-Request has been sent and the Restart timer is running, but a Configure-Ack has not yet been received nor has one been sent. Upon receipt of a Configure-Ack, the Ack-Received state is immediately entered. Upon receipt of a Configure-Nak or Configure-Reject, the Configure-Request Configuration Options are adjusted appropriately, a new Configure-Request is transmitted, and the Restart timer is restarted. Similarly, upon the expiration of the Restart timer, a new Configure-Request is transmitted and the Restart timer is restarted. Upon receipt of a Configure-Request, the Configuration Options are examined and if acceptable, a Configure-Ack is sent and the Ack-Sent state is entered. If the Configuration Options are unacceptable, a Configure-Nak or Configure-Reject is sent as appropriate. Since there is an outstanding Configure-Request in the Request- Sent state, special care must be taken to implement the Passive- Open and Close events; otherwise, it is possible for the LCP peer to think the connection is open. Processing of either event should be postponed until there is reasonable assurance that the peer is not open. In particular, the Restart timer should be allowed to expire. Ack-Received (4) In the Ack-Received state, a Configure-Request has been sent and a Configure-Ack has been received. The Restart timer is still running since a Configure-Ack has not yet been transmitted. Upon receipt of a Configure-Request with acceptable Configuration Options, a Configure-Ack is transmitted, the Restart timer is stopped and the Open state is entered. If the Configuration Options are unacceptable, a Configure-Nak or Configure-Reject is sent as appropriate. Upon the expiration of the Restart timer, a new Configure-Request is transmitted, the Restart timer is restarted, and the state machine returns to the Request-Sent state. Ack-Sent (5) In the Ack-Sent state, a Configure-Ack and a Configure-Request have been sent but a Configure-Ack has not yet been received. The Perkins May 3, 1990 [Page 19] Internet Draft Point-to-Point Protocol Restart timer is always running in the Ack-Sent state. Upon receipt of a Configure-Ack, the Restart timer is stopped and the Open state is entered. Upon receipt of a Configure-Nak or Configure-Reject, the Configure-Request Configuration Options are adjusted appropriately, a new Configure-Request is transmitted, and the Restart timer is restarted. Upon the expiration of the Restart timer, a new Configure-Request is transmitted, the Restart timer is restarted, and the state machine returns to the Request- Sent state. Open (6) In the Open state, a connection exists and data may be communicated over the link. The Restart timer is not running in the Open state. In normal operation, only two events cause transitions out of the Open state. Upon receipt of a Close command, a Terminate-Request is transmitted, the Restart timer is started, and the Closing state is entered. Upon receipt of a Terminate-Request, a Terminate-Ack is transmitted and the Closed state is entered. Upon receipt of an Echo-Request, an Echo-Reply is transmitted. Similarly, Echo-Reply and Discard-Request packets are silently discarded or processed as expected. All other events cause immediate transitions out of the Open state and should be handled as if the state machine were in the Listen state. Closing (7) In the Closing state, an active attempt is made to close the connection. A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not yet been received. Upon receipt of a Terminate-Ack, the Closed state is immediately entered. Upon the expiration of the Restart timer, a new Terminate-Request is transmitted and the Restart timer is restarted. After the Restart timer has expired Max-Restart times, this action may be skipped, and the Closed state may be entered. Max-Restart MUST be a configurable parameter. Since there is an outstanding Terminate-Request in the Closing state, special care must be taken to implement the Passive-Open event; otherwise, it is possible for the LCP peer to think the connection is open. Processing of the Passive-Open event should be postponed until there is reasonable assurance that the peer is not open. In particular, the implementation should wait until the state machine would normally transition to the Closed state because of a Receive-Terminate-Ack event or Max-Restart Timeout Perkins May 3, 1990 [Page 20] Internet Draft Point-to-Point Protocol events. 4.2. Loop Avoidance 4.2 Loop Avoidance Note that the protocol makes a reasonable attempt at avoiding Configuration Option negotiation loops. However, the protocol does NOT guarantee that loops will not happen. As with any negotiation, it is possible to configure two PPP implementations with conflicting policies that will never converge. It is also possible to configure policies which do converge, but which take significant time to do so. Implementors should keep this in mind and should implement loop detection mechanisms or higher level timeouts. If a timeout is implemented, it MUST be configurable. 4.3. 4.3 Timers and Counters There is one special timer used by LCP, the Restart timer. The Restart timer is used to time out transmissions of Configure-Request and Terminate-Request packets. Expiration of the Restart timer causes a Timeout event, and the corresponding Configure-Request or Terminate-Request packet retransmission. The Restart timer MUST be configurable, but should default to three (3) seconds. There is one additional restart parameter, Max-Restarts. Max- Restarts indicates the number of packet retransmissions that are required before there is reasonable assurance that the link closed. Max-Restarts MUST also be configurable, but should default to ten (10) retransmissions. Perkins May 3, 1990 [Page 21] Internet Draft Point-to-Point Protocol 4.4. Packet Format 4.4 Packet Format Exactly one Link Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex c021 (Link Control Protocol). A summary of the Link Control Protocol packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code The Code field is one octet and identifies the kind of LCP packet. LCP Codes are assigned as follows: 1 Configure-Request 2 Configure-Ack 3 Configure-Nak 4 Configure-Reject 5 Terminate-Request 6 Terminate-Ack 7 Code-Reject 8 Protocol-Reject 9 Echo-Request 10 Echo-Reply 11 Discard-Request Identifier The Identifier field is one octet and aids in matching requests and replies. Length The Length field is two octets and indicates the length of the LCP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Perkins May 3, 1990 [Page 22] Internet Draft Point-to-Point Protocol Data The Data field is zero or more octets as indicated by the Length field. The format of the Data field is determined by the Code field. Regardless of which Configuration Options are enabled, all LCP packets are always sent in the full, standard form, as if no Configuration Options were enabled. This ensures that LCP Configure-Request packets are always recognizable even when one end of the link mistakenly believes the link to be Open. This document describes Version 1 of the Link Control Protocol. In the interest of simplicity, there is no version field in the LCP packet. If a new version of LCP is necessary in the future, the intention is that a new Data Link Layer Protocol field value should be used to differentiate Version 1 LCP from all other versions. A correctly functioning Version 1 LCP implementation will always respond to unknown Protocols (including other versions) with an easily recognizable Version 1 packet, thus providing a deterministic fallback mechanism for implementations of other versions. Perkins May 3, 1990 [Page 23] Internet Draft Point-to-Point Protocol 4.4.1. Configure-Request 4.4.1 Configure-Request Description A LCP implementation wishing to open a connection MUST transmit a LCP packet with the Code field set to 1 (Configure-Request) and the Options field filled with any desired changes to the default link Configuration Options. Upon reception of a Configure-Request, an appropriate reply MUST be transmitted. A summary of the Configure-Request packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 1 for Configure-Request. Identifier The Identifier field should be changed on each transmission. On reception, the Identifier field should be copied into the Identifier field of the appropriate reply packet. Options The options field is variable in length and contains the list of zero or more Configuration Options that the sender desires to negotiate. All Configuration Options are always negotiated simultaneously. The format of Configuration Options is further described in a later section. Perkins May 3, 1990 [Page 24] Internet Draft Point-to-Point Protocol 4.4.2. Configure-Ack 4.4.2 Configure-Ack Description If every Configuration Option received in a Configure-Request is both recognizable and acceptable, then a LCP implementation should transmit a LCP packet with the Code field set to 2 (Configure- Ack), the Identifier field copied from the received Configure- Request, and the Options field copied from the received Configure-Request. The acknowledged Configuration Options MUST NOT be reordered or modified in any way. On reception of a Configure-Ack, the Identifier field must match that of the last transmitted Configure-Request, or the packet is invalid. Additionally, the Configuration Options in a Configure- Ack must match those of the last transmitted Configure-Request, or the packet is invalid. Invalid packets should be silently discarded. Reception of a valid Configure-Ack indicates that all Configuration Options sent in the last Configure-Request are acceptable. A summary of the Configure-Ack packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 2 for Configure-Ack. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Ack. Options The Options field is variable in length and contains the list of Perkins May 3, 1990 [Page 25] Internet Draft Point-to-Point Protocol zero or more Configuration Options that the sender is acknowledging. All Configuration Options are always acknowledged simultaneously. 4.4.3. Configure-Nak 4.4.3 Configure-Nak Description If every element of the received Configuration Options is recognizable but some are not acceptable, then a LCP implementation should transmit a LCP packet with the Code field set to 3 (Configure-Nak), the Identifier field copied from the received Configure-Request, and the Options field filled with only the unacceptable Configuration Options from the Configure-Request. All acceptable Configuration Options should be filtered out of the Configure-Nak, but otherwise the Configuration Options from the Configure-Request MUST NOT be reordered. Each of the nak'd Configuration Options MUST be modified to a value acceptable to the Configure-Nak sender. Finally, an implementation may be configured to require the negotiation of a specific option. If that option is not listed, then that option may be appended to the list of nak'd Configuration Options in order to request the remote end to list that option in its next Configure-Request packet. The appended option must include a value acceptable to the Configure- Nak sender. On reception of a Configure-Nak, the Identifier field must match that of the last transmitted Configure-Request, or the packet is invalid and should be silently discarded. Reception of a valid Configure-Nak indicates that a new Configure-Request should be sent with the Configuration Options modified as specified in the Configure-Nak. A summary of the Configure-Nak packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Perkins May 3, 1990 [Page 26] Internet Draft Point-to-Point Protocol Code 3 for Configure-Nak. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Nak. Options The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is nak'ing. All Configuration Options are always nak'd simultaneously. Perkins May 3, 1990 [Page 27] Internet Draft Point-to-Point Protocol 4.4.4. Configure-Reject 4.4.4 Configure-Reject Description If some Configuration Options received in a Configure-Request are not recognizable or are not acceptable for negotiation (as configured by a network manager), then a LCP implementation should transmit a LCP packet with the Code field set to 4 (Configure- Reject), the Identifier field copied from the received Configure- Request, and the Options field filled with only the unrecognized Configuration Options from the Configure-Request. All recognizable and negotiable Configuration Options must be filtered out of the Configure-Reject, but otherwise the Configuration Options MUST not be reordered. On reception of a Configure-Reject, the Identifier field must match that of the last transmitted Configure-Request, or the packet is invalid. Additionally, the Configuration Options in a Configure-Reject must be a proper subset of those in the last transmitted Configure-Request, or the packet is invalid. Invalid packets should be silently discarded. Reception of a Configure-Reject indicates that a new Configure- Request should be sent which does not include any of the Configuration Options listed in the Configure-Reject. A summary of the Configure-Reject packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 4 for Configure-Reject. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Reject. Perkins May 3, 1990 [Page 28] Internet Draft Point-to-Point Protocol Options The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is rejecting. All Configuration Options are always rejected simultaneously. Perkins May 3, 1990 [Page 29] Internet Draft Point-to-Point Protocol 4.4.5. Terminate-Request and Terminate-Ack 4.4.5 Terminate-Request and Terminate-Ack Description LCP includes Terminate-Request and Terminate-Ack Codes in order to provide a mechanism for closing a connection. A LCP implementation wishing to close a connection should transmit a LCP packet with the Code field set to 5 (Terminate-Request) and the Data field filled with any desired data. Terminate-Request packets should continue to be sent until Terminate-Ack is received, the Physical Layer indicates that it has gone down, or a sufficiently large number have been transmitted such that the remote end is down with reasonable certainty. Upon reception of a Terminate-Request, a LCP packet MUST be transmitted with the Code field set to 6 (Terminate-Ack), the Identifier field copied from the Terminate-Request packet, and the Data field filled with any desired data. Reception of an unelicited Terminate-Ack indicates that the connection has been closed. A summary of the Terminate-Request and Terminate-Ack packet formats 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 5 for Terminate-Request; 6 for Terminate-Ack. Identifier The Identifier field is one octet and aids in matching requests and replies. Perkins May 3, 1990 [Page 30] Internet Draft Point-to-Point Protocol Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the established maximum Information field length minus four. Perkins May 3, 1990 [Page 31] Internet Draft Point-to-Point Protocol 4.4.6. Code-Reject 4.4.6 Code-Reject Description Reception of a LCP packet with an unknown Code indicates that one of the communicating LCP implementations is faulty or incomplete. This error MUST be reported back to the sender of the unknown Code by transmitting a LCP packet with the Code field set to 7 (Code- Reject), and the inducing packet copied to the Rejected-Packet field. Upon reception of a Code-Reject, a LCP implementation should make an immediate transition to the Closed state, and should report the error, since it is unlikely that the situation can be rectified automatically. A summary of the Code-Reject packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rejected-Packet ... +-+-+-+-+-+-+-+-+ Code 7 for Code-Reject. Identifier The Identifier field is one octet and is for use by the transmitter. Rejected-Packet The Rejected-Packet field contains a copy of the LCP packet which is being rejected. It begins with the rejected Code field; it does not include any PPP Data Link Layer headers. The Rejected- Packet should be truncated to comply with the established maximum Information field length. Perkins May 3, 1990 [Page 32] Internet Draft Point-to-Point Protocol 4.4.7. Protocol-Reject 4.4.7 Protocol-Reject Description Reception of a PPP frame with an unknown Data Link Layer Protocol indicates that the remote end is attempting to use a protocol which is unsupported at the local end. This typically occurs when the remote end attempts to configure a new, but unsupported protocol. If the LCP state machine is in the Open state, then this error MUST be reported back to the sender of the unknown protocol by transmitting a LCP packet with the Code field set to 8 (Protocol-Reject), the Rejected-Protocol field set to the received Protocol, and the Data field filled with any desired data. Upon reception of a Protocol-Reject, a LCP implementation should stop transmitting frames of the indicated protocol. Protocol-Reject packets may only be sent in the LCP Open state. Protocol-Reject packets received in any state other than the LCP Open state should be discarded and no further action should be taken. A summary of the Protocol-Reject packet format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rejected-Protocol | Rejected-Information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 8 for Protocol-Reject. Identifier The Identifier field is one octet and is for use by the transmitter. Rejected-Protocol The Rejected-Protocol field is two octets and contains the Protocol of the Data Link Layer frame which is being rejected. Perkins May 3, 1990 [Page 33] Internet Draft Point-to-Point Protocol Rejected-Information The Rejected-Information field contains a copy from the frame which is being rejected. It begins with the Information field, and does not include any PPP Data Link Layer headers or the FCS. The Rejected-Information field should be truncated to comply with the established maximum Information field length. Perkins May 3, 1990 [Page 34] Internet Draft Point-to-Point Protocol 4.4.8. Echo-Request and Echo-Reply 4.4.8 Echo-Request and Echo-Reply Description LCP includes Echo-Request and Echo-Reply Codes in order to provide a Data Link Layer loopback mechanism for use in exercising both directions of the link. This is useful as an aid in debugging, link quality determination, performance testing, and for numerous other functions. An Echo-Request sender transmits a LCP packet with the Code field set to 9 (Echo-Request) and the Data field filled with any desired data, up to but not exceeding the receiver's established maximum Information field length minus eight. Upon reception of an Echo-Request, a LCP packet MUST be transmitted with the Code field set to 10 (Echo-Reply), the Identifier field copied from the received Echo-Request, and the Data field copied from the Echo-Request, truncating as necessary to avoid exceeding the peer's established maximum Information field length. Echo-Request and Echo-Reply packets may only be sent in the LCP Open state. Echo-Request and Echo-Reply packets received in any state other than the LCP Open state should be discarded and no further action should be taken. A summary of the Echo-Request and Echo-Reply packet formats 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 9 for Echo-Request; 10 for Echo-Reply. Perkins May 3, 1990 [Page 35] Internet Draft Point-to-Point Protocol Identifier The Identifier field is one octet and aids in matching Echo- Requests and Echo-Replies. Magic-Number The Magic-Number field is four octets and aids in detecting loopbacked links. Unless modified by a Configuration Option, the Magic-Number MUST always be transmitted as zero and MUST always be ignored on reception. Further use of the Magic-Number is beyond the scope of this discussion. Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the established maximum Information field length minus eight. Perkins May 3, 1990 [Page 36] Internet Draft Point-to-Point Protocol 4.4.9. Discard-Request 4.4.9 Discard-Request Description LCP includes a Discard-Request Code in order to provide a Data Link Layer data sink mechanism for use in exercising the local to remote direction of the link. This is useful as an aid in debugging, performance testing, and and for numerous other functions. A discard sender transmits a LCP packet with the Code field set to 11 (Discard-Request) and the Data field filled with any desired data, up to but not exceeding the receiver's established maximum Information field length minus eight. A discard receiver MUST simply throw away an Discard-Request that it receives. Discard-Request packets may only be sent in the LCP Open state. A summary of the Discard-Request packet formats 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 11 for Discard-Request. Identifier The Identifier field is one octet and is for use by the Discard- Request transmitter. Magic-Number The Magic-Number field is four octets and aids in detecting loopbacked links. Unless modified by a configuration option, the Magic-Number MUST always be transmitted as zero and MUST always be Perkins May 3, 1990 [Page 37] Internet Draft Point-to-Point Protocol ignored on reception. Further use of the Magic-Number is beyond the scope of this discussion. Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the established maximum Information field length minus four. Perkins May 3, 1990 [Page 38] Internet Draft Point-to-Point Protocol 4.5. Configuration Options 4.5 Configuration Options LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated. Negotiable modifications include such things as the maximum receive unit, async control character mapping, the link authentication method, the link encryption method, etc. The Configuration Options themselves are described in separate documents. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed. The end of the list of Configuration Options is indicated by the end of the LCP packet. Unless otherwise specified, a specific Configuration Options should be listed no more than once in a Configuration Options list. Specific Configuration Options may override this general rule and may be listed more than once. The effect of this is Configuration Option specific and is specified by each such Configuration Option. Also unless otherwise specified, all Configuration Options apply in a half-duplex fashion. When negotiated, they apply to only one direction of the link, typically in the receive direction when interpreted from the point of view of the Configure-Request sender. Perkins May 3, 1990 [Page 39] Internet Draft Point-to-Point Protocol 4.5.1. Format 4.5.1 Format A summary of the Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The Type field is one octet and indicates the type of Configuration Option. The most up-to-date values of the Type field are specified in the most recent "Assigned Numbers" RFC [12]. Length The Length field is one octet and indicates the length of this Configuration Option including the Type, Length and Data fields. If a negotiable Configuration Option is received in a Configure- Request but with an invalid Length, a Configure-Nak should be transmitted which includes the desired Configuration Option with an appropriate Length and Data. Data The Data field is zero or more octets and indicates the value or other information for this Configuration Option. The format and length of the Data field is determined by the Type and Length fields. Perkins May 3, 1990 [Page 40] Internet Draft Point-to-Point Protocol 5. A PPP Network Control Protocol (NCP) for IP 5. A PPP Network Control Protocol (NCP) for IP The IP Control Protocol (IPCP) is responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. IPCP packets may not be exchanged until LCP has reached the Network-Layer Protocol Configuration Negotiation phase. IPCP packets received before this phase is reached should be silently discarded. Likewise, IP datagrams may not be exchanged until IPCP has first opened the connection (reached the Open state). The IP Control Protocol is exactly the same as the Link Control Protocol with the following exceptions: Data Link Layer Protocol Field Exactly one IP Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8021 (IP Control Protocol). 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. Timeouts IPCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types The IPCP has a separate set of Configuration Options. The most up-to-date values of the type field are specified in the most recent "Assigned Numbers" RFC [12]. 5.1. Sending IP Datagrams 5.1 Sending IP Datagrams Perkins May 3, 1990 [Page 41] Internet Draft Point-to-Point Protocol Before any IP packets may be communicated, both the Link Control Protocol and the IP Control Protocol must reach the Open state. Exactly one IP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0021 (Internet Protocol). The maximum length of an IP packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger IP datagrams must be fragmented as necessary. If a system wishes to avoid fragmentation and reassembly, it should use the TCP Maximum Segment Size option [13], or a similar mechanism, to discourage others from sending large datagrams. Perkins May 3, 1990 [Page 42] Internet Draft Point-to-Point Protocol APPENDICES A. Asynchronous HDLC A. Asynchronous HDLC This appendix summarizes the modifications to ISO 3309-1979 proposed in ISO 3309:1984/PDAD1. These modifications allow HDLC to be used with 8-bit asynchronous links. Transmission Considerations Each octet is delimited by a start and a stop element. Flag Sequence The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e). Transparency On asynchronous links, a character stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d) where the bit positions are numbered 87654321 (not 76543210, BEWARE). After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence, Control Escape octet and octet with value less than hexadecimal 0x20 is replaced by a two octet sequence consisting of the Control Escape octet and the original octet with bit 6 complemented (i.e. exclusive-or'd with hexadecimal 0x20). Prior to FCS computation, the receiver examines the entire frame between the two Flag Sequences. Each octet with value less than hexadecimal 0x20 is simply removed (it may have been inserted by intervening data communications equipment). For each Control Escape octet, that octet is also removed, but bit 6 of the following octet is complemented. A Control Escape octet immediately preceding the closing Flag Sequence indicates an invalid frame. Note: The inclusion of all octets less than hexadecimal 0x20 allows all ASCII control characters [10] excluding DEL (Delete) to be transparently communicated through almost all known data communications equipment. A few examples may make this more clear. Packet data is transmitted on the link as follows: Perkins May 3, 1990 [Page 43] Internet Draft Point-to-Point Protocol 0x7e is encoded as 0x7d, 0x5e. 0x7d is encoded as 0x7d, 0x5d. 0x01 is encoded as 0x7d, 0x21. Aborting a Transmission On asynchronous links, frames may be aborted by transmitting a "0" stop bit where a "1" bit is expected (framing error) or by transmitting a Control Escape octet followed immediately by a closing Flag Sequence. Inter-frame Time Fill On asynchronous links, inter-octet and inter-frame time fill should be accomplished by transmitting continuous "1" bits (mark- hold state). Note: On asynchronous links, inter-frame time fill can be viewed as extended inter-octet time fill. Doing so can save one octet for every frame, decreasing delay and increasing bandwidth. This is possible since a Flag Sequence may serve as both a frame close and a frame begin. After having received any frame, an idle receiver will always be in a frame begin state. Robust transmitters should avoid using this trick over- zealously since the price for decreased delay is decreased reliability. Noisy links may cause the receiver to receive garbage characters and interpret them as part of an incoming frame. If the transmitter does not transmit a new opening Flag Sequence before sending the next frame, then that frame will be appended to the noise characters causing an invalid frame (with high reliability). Transmitters should avoid this by transmitting an open Flag Sequence whenever "appreciable time" has elapsed since the prior closing Flag Sequence. It is suggested that implementations will achieve the best results by always sending an opening Flag Sequence if the new frame is not back-to-back with the last. The maximum value for "appreciable time" is likely to be no greater than the typing rate of a slow to average typist, say 1 second. Perkins May 3, 1990 [Page 44] Internet Draft Point-to-Point Protocol B. Fast Frame Check Sequence (FCS) Implementation B. Fast Frame Check Sequence (FCS) Implementation B.1. FCS Computation Method B.1 FCS Computation Method The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. The table is created by the code in section 2. /* * u16 represents an unsigned 16-bit number. Adjust the typedef for * your hardware. */ typedef unsigned short u16; /* * FCS lookup table as calculated by the table generator in section 2. */ static u16 fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, Perkins May 3, 1990 [Page 45] Internet Draft Point-to-Point Protocol 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 }; #define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */ /* * Calculate a new fcs given the current fcs and the new data. */ u16 pppfcs(fcs, cp, len) register u16 fcs; register unsigned char *cp; register int len; { ASSERT(sizeof (u16) == 2); ASSERT(((u16) -1) > 0); while (len--) fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff]; return (fcs); } B.2. Fast FCS table generator B.2 Fast FCS table generator The following code creates the lookup table used to calculate the FCS. /* * Generate a FCS table for the HDLC FCS. * * Drew D. Perkins at Carnegie Mellon University. * * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. */ /* * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408). */ #define P 0x8408 main() { register unsigned int b, v; Perkins May 3, 1990 [Page 46] Internet Draft Point-to-Point Protocol register int i; printf("typedef unsigned short u16;\n"); printf("static u16 fcstab[256] = {"); for (b = 0; ; ) { if (b % 8 == 0) printf("\n"); v = b; for (i = 8; i--; ) v = v & 1 ? (v >> 1) ^ P : v >> 1; printf("0x%04x", v & 0xFFFF); if (++b == 256) break; printf(","); } printf("\n};\n"); } Perkins May 3, 1990 [Page 47] Internet Draft Point-to-Point Protocol REFERENCES References [1] Electronic Industries Association, EIA Standard RS-232-C, "Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange", August, 1969. [2] International Organization For Standardization, ISO Standard 3309-1979, "Data communication - High-level data link control procedures - Frame structure", 1979. [3] International Organization For Standardization, ISO Standard 4335-1979, "Data communication - High-level data link control procedures - Elements of procedures", 1979. [4] International Organization For Standardization, ISO Standard 4335-1979/Addendum 1, "Data communication - High-level data link control procedures - Elements of procedures - Addendum 1", 1979. [5] International Organization For Standardization, Proposed Draft International Standard ISO 3309:1983/PDAD1, "Information processing systems - Data communication - High-level data link control procedures - Frame structure - Addendum 1: Start/stop transmission", 1984. [6] International Telecommunication Union, CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks", CCITT Red Book, Volume VIII, Fascicle VIII.3, Rec. X.25., October, 1984. [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983. [8] Morse, Greg, "Calculating CRC's by Bits and Bytes", Byte, September 1986. [9] LeVan, Jerry, "A Fast CRC", Byte, November, 1987. [10] American National Standards Institute, ANSI X3.4-1977, "American National Standard Code for Information Interchange", 1977. [11] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September, 1981. [12] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 1010 (or Perkins May 3, 1990 [Page 48] Internet Draft Point-to-Point Protocol most recent edition), USC/Information Sciences Institute, May, 1987. [13] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November, 1983. Perkins May 3, 1990 [Page 49] Internet Draft Point-to-Point Protocol CHAIRMAN'S ADDRESS Chairman's Address This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair: Russ Hobby UC Davis Computing Services Davis, CA 95616 Phone: (916) 752-0236 EMail: rdhobby@ucdavis.edu Author's Address Questions about this memo can also be directed to the author: Drew D. Perkins Carnegie Mellon University Networking and Communications Pittsburgh, PA 15213 Phone: (412) 268-8576 EMail: ddp@andrew.cmu.edu Acknowledgments Many people spent significant time helping to develop the Point-to- Point Protocol. The complete list of people is too numerous to list, but the following people deserve special thanks: Ken Adelman (TGV), Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz (cisco systems) and Asher Waldfogel (Wellfleet). Perkins May 3, 1990 [Page 50] Internet Draft Point-to-Point Protocol TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss Perkins May 3, 1990 [Page ii] From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 3 21:15:24 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA03307; Thu, 3 May 90 21:07:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04693; Thu, 3 May 90 20:45:48 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04608; Thu, 3 May 90 20:32:09 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.ucdavis.edu; Thu, 3 May 90 23:32:46 EDT Received: via switchmail; Thu, 3 May 90 23:32:43 -0400 (EDT) Received: from suffern.andrew.cmu.edu via qmail ID ; Thu, 3 May 90 23:32:31 -0400 (EDT) Received: from suffern.andrew.cmu.edu via qmail ID ; Thu, 3 May 90 23:32:14 -0400 (EDT) Received: from BatMail.robin.v2.10.CUILIB.3.45.SNAP.NOT.LINKED.suffern.andrew.cmu.edu.rt.r3 via MS.5.6.suffern.andrew.cmu.edu.rt_r3; Thu, 3 May 90 23:32:02 -0400 (EDT) Message-Id: <8aEDSmW00UodQ3MHIH@andrew.cmu.edu> Date: Thu, 3 May 90 23:32:02 -0400 (EDT) From: Drew Daniel Perkins To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Proposal for PPP frame structure In-Reply-To: <9005021505.AA07951@ucdavis.ucdavis.edu> References: <9005021505.AA07951@ucdavis.ucdavis.edu> Status: O Heather, Discussion of your proposal at the IETF meeting today raised far more questions than answers. No one at the meeting had much knowledge about frame-relay. A few questions in particular puzzled us: 1. Does frame-relay run across the D-channel or a B-channel of your ISDN link? 2. How are virtual circuits established? a. Entirely statically... Call up service provider on phone and add one (we hope not). b. Dynamically by inband communication with special network control LAPD address. c. Dynamically using ISDN D-channel to establish virtual circuit across B/H-channel. 3. How are addresses assigned? a. Statically within "domain". b. Dynamically by smart frame-relay control processor. 4. How can you tell the source of a packet? a. Separate destination address per virtual circuit. 5. Can you suggest a reference for frame-relay? I found some AT&T Tech. Journal articals, but they described things like SNA over frame-relay, not frame-relay itself. Drew From ietf-ppp-request@ucdavis.ucdavis.edu Sat May 5 11:15:03 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA01920; Sat, 5 May 90 11:02:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02564; Sat, 5 May 90 10:30:10 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO5.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02493; Sat, 5 May 90 10:24:37 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Sat, 5 May 90 13:25:17 EDT Received: via switchmail; Sat, 5 May 90 13:25:14 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:22:07 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:22:00 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Sat, 5 May 90 13:21:59 -0400 (EDT) Resent-Message-Id: Resent-Date: Sat, 5 May 90 13:21:59 -0400 (EDT) Resent-From: Drew Daniel Perkins Resent-To: ietf-ppp@ucdavis.ucdavis.edu Return-Path: Date: Fri 4 May 90 00:12:06-PDT From: William "Chops" Westfield Subject: Re: Proposal for PPP frame structure To: ddp+@andrew.cmu.edu In-Reply-To: <8aEDSmW00UodQ3MHIH@andrew.cmu.edu> Message-Id: <12586922820.11.BILLW@MATHOM.CISCO.COM> Status: O I think that since Frame relay is not strictly a Point-to-Point protocol, that it whould fall outside the scope of the PPP RFCs. Perhaps even a separate working group. It would be nice if they use a lot of the same code/etc as PPP, but holding up PPP for something that is a) not clearly with its scope, and b) not widely available, seems quite silly. BillW ------- From ietf-ppp-request@ucdavis.ucdavis.edu Sat May 5 11:45:39 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA02095; Sat, 5 May 90 11:42:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02849; Sat, 5 May 90 11:01:23 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO5.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02783; Sat, 5 May 90 10:51:58 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Sat, 5 May 90 13:51:44 EDT Received: via switchmail; Sat, 5 May 90 13:51:36 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:46:38 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:46:35 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Sat, 5 May 90 13:46:34 -0400 (EDT) Message-Id: Date: Sat, 5 May 90 13:46:34 -0400 (EDT) From: Drew Daniel Perkins To: heather@arch3.att.com Subject: Re: frame relay proposal Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: References: Status: O > Excerpts from mail: 5-May-90 frame relay proposal heather@arch3.att.com (4195) > b. A switched circuit may be established on request > with inband call control procedures (this corresponds > to my reference in #1 above to a "non-ISDN" connection). I don't understand the reference to #1... > Excerpts from mail: 5-May-90 frame relay proposal heather@arch3.att.com (4195) > >3. How are addresses assigned? > > a. Statically within "domain". > > b. Dynamically by smart frame-relay control processor. > Addresses may be assigned statically (PVC operation) or > dynamically on call setup for switched virtual circuits. This didn't answer the question that I was trying to ask (but didn't do a very good job of). What is the algorithm used for picking addresses? What is the scope of an address? > Excerpts from mail: 5-May-90 frame relay proposal heather@arch3.att.com (4195) > >4. How can you tell the source of a packet? > > a. Separate destination address per virtual circuit. > I need more information on this question to answer it properly. > However, the operation of Layer 3 (such as IP) should not change > if a directly connected leased line were replaced with a frame > relay circuit. I'm not worried about IP packets, I'm worried about PPP LCP/IPCP/etc. packets. If I receive a PPP LCP packet, how do I know where it came from? Are the destination addresses unique per virtual circuit? Can I map from the destination address to a unique source address? Drew From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 7 01:00:23 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA05924; Mon, 7 May 90 00:49:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01233; Mon, 7 May 90 00:26:30 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00804; Mon, 7 May 90 00:10:24 -0700 Message-Id: <9005070710.AA00804@ucdavis.ucdavis.edu> Received: from dustbin.cisco.com by wolf.cisco.com with TCP; Sun, 6 May 90 22:39:18 -0700 To: ietf-ppp@ucdavis.ucdavis.edu Cc: heather@arch3.att.com, fowler@cisco.com Subject: Re: frame relay proposal In-Reply-To: Your message of Sat, 05 May 90 13:46:34 -0400. Date: Sun, 06 May 90 22:42:11 MST From: Greg Satz Status: O All, The current PPP specification addresses a different problem then Frame Relay tries to solve, point-to-point asynchronous and synchronous connections. ISDN and Frame Relay are multi-point which I claim falls out of purview of the assigned problem. PPP doesn't have to concern itself with address resolution. Based on my experience with its development, I don't recall any discussion of multiple PPP conversations over a single interface ever being mentioned. This doesn't mean it won't work but it does mean more thought will be necessary and the appropiate things written. I recommend that PPP be left as is for its designated purpose: the interconnection of devices across a point-to-point line. The IETF should immediately address the issue of running PPP over other media such as Frame Relay. Greg Satz cisco From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 7 15:47:19 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA14956; Mon, 7 May 90 15:35:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15173; Mon, 7 May 90 14:46:38 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Vax.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15111; Mon, 7 May 90 14:41:50 -0700 Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA09288; Mon, 7 May 90 17:41:12 EDT Date: Mon, 7 May 90 17:41:12 EDT Message-Id: <9005072141.AA09288@vax.ftp.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: frame relay proposal From: stev@vax.ftp.com Cc: heather@arch3.att.com, fowler@cisco.com Repository: ftp.com Originating-Client: d-cell.ftp.com Status: O hello, campers. allow me to introduce myself, since some of you may not know me. i am the chairman of the WG. here is how i saw the meeting go at pittsburg. 1) there seemed to be no desire to delay the RFC's for something like this. 2) there seemed to be no desire to change the frame characteristics of the current release. a *change* was made, however. we removed the text dealing with discarding addresses not containing the bytes FF. we changed the draft to state that handling of other addresses was beyond the scope of this document. this will hopefully, allow the frame buffer people to write a small RFC defining how diffrent addresses are parsed, and what they mean in terms of processing. 3) it was unfortunate that this was mailed when we were at the meeting, if it had gotten out a week earlier, heather could have possilbly come out to talk to us at the meeting. hopefully, this will clear up any problems we seem to be having. the idea here was to make a minor change that would allow the frame relay people to come back later and just make some adjustments to the stuff to get it to work. at the begining of next week, i will be publishing the writing assignments from the last meeting. i will also be setting up a video confrence sometime in the second half of june, if you have conflicts, please let me know. many thanx to drew, et al, for the initial documents, for fred baker for the bridging RFC, which should be submitted very shortly as a draft, and for dave katz for taking a stab at OSI. i am sure noel will be very happy. stev knowles stev@ftp.com 617-246-0900 IETF-PPP-WG-CHAIR From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 8 10:46:45 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA21684; Tue, 8 May 90 10:42:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27106; Tue, 8 May 90 10:00:07 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from decpa.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27062; Tue, 8 May 90 09:53:08 -0700 Received: by decpa.pa.dec.com; id AA12044; Tue, 8 May 90 09:52:19 -0700 Message-Id: <9005081652.AA12044@decpa.pa.dec.com> Received: from gah.enet; by decpa.enet; Tue, 8 May 90 09:52:36 PDT Date: Tue, 8 May 90 09:52:36 PDT From: "Arthur Harvey, 226-7647, LKG1-2/A19" To: ietf-ppp@ucdavis.ucdavis.edu Subject: OSI Network Layer and DECnet Phase IV over PPP Status: O I work in the Network and Communications Architecure group at Digital. Over the next month, I will be writing sections for both the PPP specification and the PPP Initial Configuration Options document which describe the use of PPP by the OSI Network Layer and Phase IV DECnet. I have draft copies of the PPP specification and the PPP Initial Configuration Options. I would appreciate any suggestions or other information you can offer which would help me complete this. My electronic mail address is harvey@gah.enet.dec.com Regards, -Arthur Harvey From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 07:00:31 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA28961; Wed, 9 May 90 06:52:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10102; Wed, 9 May 90 06:30:19 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Vax.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10005; Wed, 9 May 90 06:23:18 -0700 Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA25506; Wed, 9 May 90 09:22:31 EDT Date: Wed, 9 May 90 09:22:31 EDT Message-Id: <9005091322.AA25506@vax.ftp.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: frame relay proposal From: stev@vax.ftp.com Cc: heather@arch3.att.com Repository: ftp.com Originating-Client: d-cell.ftp.com Status: O i would like to suggest something here. we are going to be having a video meeting sometime in the second half of june. i would *really* like te frame relay people to write up something along the line of the options RFCs for discussions at this meeting. having one or more of them, and people who understand this technology from other companies there would be helpful. i would also like to thank the people who have stepped forward to get some of the options RFCs out of the way, i *really* appreicate the help. from the early returns, it looks like we will have text to review at the video meeting, and, assuming all the bugs can get worked out, we can go through a final review at the UBC IETF meeting, and send them all into the pipe. stev knowles stev@ftp.com 617-246-0900 From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 09:00:35 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA29930; Wed, 9 May 90 08:52:58 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11361; Wed, 9 May 90 08:30:41 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11222; Wed, 9 May 90 08:21:06 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA09135; Wed, 9 May 90 11:26:54 EDT Date: Wed, 9 May 90 11:26:54 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005091526.AA09135@sonny.proteon.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: jas@proteon.com, dkatz@merit.edu, harvey@gah.enet.dec.com In-Reply-To: Dave Katz's message of Thu, 3 May 90 19:54:06 EST <9005040054.AA00375@merit.edu> Subject: OSI network layer over PPP Status: O I quite understand Dave's reasoning for putting the OSI network layer packet directly after the PPP header. Indeed, one can sort out what network layer protocol is coming by looking at the first byte, according to TR 9577. However, not using IEEE 802.2 under these network layers has a serious side effect. The OSI network layer packet begins at an even offset within the packet. On all of the LAN media, due to the 3 byte 802.2 UI header, the network layer packet begins at an odd offset. I suspect that most router hardware implementations have some limitations in the adressing capabilities of their interfaces, and at least some of them cannot do arbitrary byte alignments. Many state of the art LAN interface chips require even addresses for DMA. (Indeed, the TI TMS380 802.5 chipsets are unusual in allowing arbitrary byte alignment, but their microcode does force a performance penalty on odd addresses.) Thus, if we give PPP an even data link layer header length, many vendors will have to move the packet by at least one byte in memory before sending it out on another interface. I would propose that we could consider putting the 802.2 UI header in, or we could just put in a pad byte on the front. (The PPP committee generally has done their best to make the standard imlementable despite hardware limitations in routers.) I realize that the same problem exists in the official ISO stack per ISO 8880, where Point-to-Point lines put ISO 8473 dircetly on ISO 7776, where ISO 7776 is running modulo-8 sequence numbering. Thus, one has a two-byte data-link layer header in that configuration as well. I would also note that supporting CONP over PPP would be a rather strange thing to do. Since PPP does not provide virtual circuit operation, CONP would not be providing the reliability that CONS defines. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 09:45:31 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA00477; Wed, 9 May 90 09:43:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11885; Wed, 9 May 90 09:18:33 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11788; Wed, 9 May 90 09:09:38 -0700 Message-Id: <9005091609.AA11788@ucdavis.ucdavis.edu> Received: from dirt.cisco.com by wolf.cisco.com with TCP; Wed, 9 May 90 09:06:06 -0700 To: ietf-ppp@ucdavis.ucdavis.edu Cc: jas@proteon.com, dkatz@merit.edu, harvey@gah.enet.dec.com Subject: Re: OSI network layer over PPP In-Reply-To: Your message of Wed, 09 May 90 11:26:54 -0400. <9005091526.AA09135@sonny.proteon.com> Date: Wed, 09 May 90 09:03:37 PDT From: Jim Forster Status: O >> I would propose that we could consider putting the 802.2 UI header in, >> or we could just put in a pad byte on the front. (The PPP committee >> generally has done their best to make the standard imlementable >> despite hardware limitations in routers.) I kind of like this idea. I'd rather see just one pad byte than the three byte 802.2 header. Presumably we could negogiate this behavior away for slow-speed links, perhaps as part of some eventual header-compression option, but the extra byte is very little overhead to pay for the benefits of not having to copy the packet on high speed interfaces. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 10:46:56 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA01096; Wed, 9 May 90 10:39:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12643; Wed, 9 May 90 10:17:11 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from BU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12606; Wed, 9 May 90 10:13:17 -0700 Received: by BU.EDU (1.97) Wed, 9 May 90 13:12:42 EDT Received: by xenna.Xylogics.COM (4.12/4.7_jlv1/7/90) id AA08597; Wed, 9 May 90 13:14:22 edt Message-Id: <9005091714.AA08597@xenna.Xylogics.COM> From: John Robert LoVerso Date: Wed, 9 May 1990 13:14:21 EDT In-Reply-To: Jim Forster "Re: OSI network layer over PPP" (May 9, 9:03am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: OSI network layer over PPP Status: O > Presumably we could negogiate this behavior away for slow-speed links, > perhaps as part of some eventual header-compression option, but the Actually, this option exists now, and I'd assume that it will be extended to cover any additional frame header fields that get added. John From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 12:00:47 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA01852; Wed, 9 May 90 11:56:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13846; Wed, 9 May 90 11:31:54 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13619; Wed, 9 May 90 11:20:56 -0700 Received: Wed, 9 May 90 13:20:14 EST by merit.edu (5.59/1.6) Date: Wed, 9 May 90 13:20:14 EST From: Dave Katz Message-Id: <9005091820.AA20633@merit.edu> To: ietf-ppp@ucdavis.ucdavis.edu, jas@proteon.com Subject: Re: OSI network layer over PPP Cc: dkatz@merit.edu, harvey@gah.enet.dec.com Status: O >I would also note that supporting CONP over PPP would be a rather >strange thing to do. Since PPP does not provide virtual circuit >operation, CONP would not be providing the reliability that CONS >defines. In theory, it's possible to run 8208 over non error-corrected links (see 8881 over LLC type 1), but yeah, as a newcomer to PPP I missed the small detail that the LCP doesn't have an option for negotiating LAPB. If someone really wants to run 8208, a LAPB option should probably be added. Serial links are probably too lossy for the 8881 solution to work well, assuming it would work at all. On the one hand this (and the alignment issue) raises a case for putting 802.2 in front of the packets (then LAPB comes for "free"); on the other hand, 802.2 is supposed to be exclusively for LANs (although I think the ISO folks blew it by not providing for non-OSI protocols to share serial links with OSI protocols--this has been partially corrected by assigning a NLPD to IP). But I digress. I'm open to suggestions on where to go with the 8208 and padding issues. I'm partial to retitling the draft to say "connectionless OSI" and dropping references to 8208, and let somebody else worry about this one. As far as padding goes, it seems like the way to handle this is to make the pad octet mandatory, and then allow an option to get rid of it. Is there some reason that the complexity of "compressing" the octet out as an option is desirable (removing it unless the first octet of the packet looks like the pad octet)? From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 13:15:07 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA02539; Wed, 9 May 90 13:10:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14782; Wed, 9 May 90 12:47:10 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14657; Wed, 9 May 90 12:34:36 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA12709; Wed, 9 May 90 15:40:00 EDT Date: Wed, 9 May 90 15:40:00 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005091940.AA12709@sonny.proteon.com> To: katz@merit.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, jas@proteon.com, harvey@gah.enet.dec.com In-Reply-To: Dave Katz's message of Wed, 9 May 90 13:20:14 EST <9005091820.AA20633@merit.edu> Subject: OSI network layer over PPP Status: O I think dropping ISO 8208 probably makes sense. Folks running ISO 8208 are probably CO-purists, and won't be multiplexing with our CL protocols over one wire. Also, I suspect that the ISO 8881 allowance for ISO 8208 over LLC type 1 is mostly a concession, and one will see ISO 8208 over LLC type 2 almost exclusively. (The UK coloured book approach.) I think that the pad byte looks like the better option, since it will avoid the duplication of the UI fields between PPP and LLC. > Is there some reason that the complexity > of "compressing" the octet out as an option is desirable (removing > it unless the first octet of the packet looks like the pad octet)? I don't quite understand what is meant by this. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 9 15:03:37 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA03708; Wed, 9 May 90 14:58:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16298; Wed, 9 May 90 14:32:35 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16148; Wed, 9 May 90 14:27:50 -0700 Received: Wed, 9 May 90 16:27:06 EST by merit.edu (5.59/1.6) Date: Wed, 9 May 90 16:27:06 EST From: Dave Katz Message-Id: <9005092127.AA23450@merit.edu> To: jas@proteon.com Subject: Re: OSI network layer over PPP Cc: harvey@gah.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu Status: O >CL protocols over one wire. Also, I suspect that the ISO 8881 >allowance for ISO 8208 over LLC type 1 is mostly a concession, and one >will see ISO 8208 over LLC type 2 almost exclusively. (The UK >coloured book approach.) I suspect that this will be true. >> Is there some reason that the complexity >> of "compressing" the octet out as an option is desirable (removing >> it unless the first octet of the packet looks like the pad octet)? > >I don't quite understand what is meant by this. I'll try again... There was talk in earlier messages about adding the padding and then "compressing" it back out again as an option. Other compression options seem to be set up in such a way that the receiver effectively does not need to know whether compression is in effect or not; the packets are self-encoding, at the cost of some additional complexity in the receiver. My question is: is there some reason why an OSI NL pad option could not just be negotiated on or off in the NCP and the receiver be required to maintain the state of the option in order to decode the packet? The alternative is presumably to pick a value for the padding that is unlikely to collide with the first part of the packet, and always include the padding when it does collide. Put another way, is the self-encoding nature of the header-compression options driven by anything besides the requirement that LCP packets be uncompressed even though everything else may be compressed? On a slightly different note, should padding be an option specific to OSI NL, or should it be a general LCP option? Should the amount of padding be negotiable? Some machines may want 32-bit alignment, f'rinstance. From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 14 10:50:08 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA01147; Mon, 14 May 90 10:43:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00666; Mon, 14 May 90 10:19:09 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00300; Mon, 14 May 90 10:06:22 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA06016; Mon, 14 May 90 13:05:46 -0400 Message-Id: <9005141705.AA06016@uunet.uu.net> Date: Mon, 14 May 90 09:40:28 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: ietf-ppp@uunet.UU.NET Subject: OSI network layer over PPP Status: O There may be a simpler approach than putting in a pad byte. Coming back to our discussion of ISO 3309 addressing, if the address is lenghthened by prepending a zero onto it, the value of the address is not altered, the logical frame structure is not changed, and 'evenness' can be preserved. It does require those putting PPP into microcode to handle this (or the equivaleent - prepend the zero onto the PPP packet type field), but it may simplify a whole lot following. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 14 13:15:37 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA02984; Mon, 14 May 90 13:03:04 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03112; Mon, 14 May 90 12:33:37 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02801; Mon, 14 May 90 12:18:24 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA22630; Mon, 14 May 90 15:24:06 EDT Date: Mon, 14 May 90 15:24:06 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005141924.AA22630@sonny.proteon.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: VitaM6!baker@uunet.uu.net (Fred Baker) In-Reply-To: Fred Baker's message of Mon, 14 May 90 09:40:28 PDT <9005141705.AA06016@uunet.uu.net> Subject: OSI network layer over PPP (pad byte) Status: O I would think that using two different address lengths in the MAC layer would not be "convenient". Chips that understand that byte might have to be programmed (initialized) differently to send one or two bytes, and there could well be similar problems on the receive side. I don't think any of the chips I presently use have this problem (it's just data to them), but I certainly don't want to trust them (the chip designers) not to screw us. The goal is so that the microcode, etc., won't have to peek ahead and know what type of packet it's dealing with before doing the "DMA" transfer for the packet. (Assuming a bus structure of some sort.) Remember the Alamo! Remember the Z8530! From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 14 18:01:26 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA00263; Mon, 14 May 90 17:50:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07283; Mon, 14 May 90 17:31:08 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07116; Mon, 14 May 90 17:23:16 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA03113; Mon, 14 May 90 20:22:39 -0400 Message-Id: <9005150022.AA03113@uunet.uu.net> Date: Mon, 14 May 90 17:15:19 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: ietf-ppp@uunet.UU.NET Subject: OSI network layer over PPP (pad byte) Status: O John: I'm confused, but that's normal. If I understand your message, you're talking about variable length MAC addresses, which chips must needs set to some precise length or they get all hosed up. However, I'm refering to either the PPP station address (hex FF) or the protocol type field (0x0021 == 0x21 for IP, if memory serves). My suggestion this morning was, in essence, if using the number 0xNN will put the remainder of the message on an ODD boundary, and Administrative Control #27 is set to TRUE, then insert 0x00NN instead. This is: (1) required to be understood by the receiver anyway, (2) legal (3) effective (4) no change to existing specifications Am I tilting at windmills? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Sat May 5 11:30:38 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA02041; Sat, 5 May 90 11:26:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02775; Sat, 5 May 90 10:50:36 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO5.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02715; Sat, 5 May 90 10:44:15 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Sat, 5 May 90 13:44:28 EDT Received: via switchmail; Sat, 5 May 90 13:44:21 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:40:56 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Sat, 5 May 90 13:40:53 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Sat, 5 May 90 13:40:52 -0400 (EDT) Resent-Message-Id: Resent-Date: Sat, 5 May 90 13:40:52 -0400 (EDT) Resent-From: Drew Daniel Perkins Resent-To: ietf-ppp@ucdavis.ucdavis.edu Return-Path: Message-Id: From: heather@arch3.att.com Date: Sat, 5 May 90 12:39 EDT Original-From: arch3!heather (Heather C Dee +1 201 949 5303) To: ddp+@andrew.cmu.edu Subject: frame relay proposal Status: O Drew, Thank you for the quick response to the frame relay proposal. Let me briefly answer your questions from an architectural point of view: >1. Does frame-relay run across the D-channel or a B-channel of your > ISDN link? The frame-relay service may run across the B- or D-channel of an ISDN connection, as well as over a non-ISDN connection (non-channelized). ********************************************************************* >2. How are virtual circuits established? > a. Entirely statically... Call up service provider on phone > and add one (we hope not). > b. Dynamically by inband communication with special network > control LAPD address. > c. Dynamically using ISDN D-channel to establish virtual > circuit across B/H-channel. Frame relay allows the establishment of both Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). Choice of circuit establishment method is up to the user. a. A PVC is entirely static, as you described (call the service provider to add one - but this has advantages over calling to add a leased line). b. A switched circuit may be established on request with inband call control procedures (this corresponds to my reference in #1 above to a "non-ISDN" connection). c. A switched circuit may also be established across a B/H-channel on request using the IDSN D-channel call control procedures. ********************************************************************* >3. How are addresses assigned? > a. Statically within "domain". > b. Dynamically by smart frame-relay control processor. Addresses may be assigned statically (PVC operation) or dynamically on call setup for switched virtual circuits. ********************************************************************* >4. How can you tell the source of a packet? > a. Separate destination address per virtual circuit. I need more information on this question to answer it properly. However, the operation of Layer 3 (such as IP) should not change if a directly connected leased line were replaced with a frame relay circuit. ********************************************************************* >5. Can you suggest a reference for frame-relay? I found some AT&T > Tech. Journal articals, but they described things like SNA over > frame-relay, not frame-relay itself. These ANSI documents provide a technical description of frame relay service and protocol: ANSI T1.6fr "Digital Signaling Specification No. 1 (DSS1) - Signalling Specification for Frame Relay" ANSI T1.606 :Frame Relaying Bearer Service - Architectural Framework and Service Description" "DSS1 Core Aspects of Frame Protocol for use with Frame Relay Bearer Service" (recently submitted by T1S1.2 to be ballotted) For a market view of frame relay, see "Plugging into Frame Relay for Speed and Flexibility" by Sue J. Lowe in the April 1990 issue of Data Communications. DEC and Vitalink have recently announced support for frame relay in their routers, and Lowe's article points to other vendor support in the switch and front-end processor area, too. Cisco Systems is planning to add a frame relay interface to its routers in the third quarter, according to a news article in Communications Week, April 30, 1990. Growing vendor support for frame relay points to its importance in wide area networking for connectionless service. Thus, we feel it is important to pursue the merging of the PPP and frame relay framing structures as quickly as possible to benefit both users and vendors. I understand the urgency of getting PPP to Draft Standard status, and we do not want to hold up the process. However, we would like to discuss the proposal further in whatever time we do have. I am new to the PPP group, and need guidance on the proper channels to use. We can prepare additional submissions to further answer questions about frame relay, as well as discuss issues pertaining to PPP. Please let me know what I should do next, as I would like to have the proposal considered for the current draft of PPP and I know time is critical. Thanks. Heather Subject: Frame Relay proposal From bkc@omnigate.clarkson.edu Sun May 20 13:45:03 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA18755; Sun, 20 May 90 13:32:59 -0700 Received: from omnigate.clarkson.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18063; Sun, 20 May 90 13:27:39 -0700 Message-Id: <9005202027.AA18063@ucdavis.ucdavis.edu> Date: Sun, 20 May 90 16:25:38 EDT From: Brad Clements To: Drew Daniel Perkins Cc: Russ Hobby , karn@thumper.bellcore.com, nelson@image.soe.clarkson.edu, bkc@omnigate.clarkson.edu, ron@manta.nosc.mil, mrm@sceard.com, telebit!cec@uunet.uu.net, ietf-ppp@ucdavis.ucdavis.edu Subject: Beta version of PPP for Sun OS now available Status: O For those interested in a Sun OS (streams) PPP version of this package, it is now available via anonymous ftp from omnigate.clarkson.edu:/pub/sun/ppp.tar.Z I'm calling this a 'beta' release, like to see some other people try it out before I make a general announcement. This one does VJ compression, and seems to work with the ucdavis version of ka9q. Please let me know if you pick this up and try it out.. I'd like to test it against a stock BSD version, but I don't have a system set up here for that. | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Network Engineer Clarkson University (315)268-2292 Ps. Those who need a shar through the mail, drop me a line and I'll mail it to you. From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 21 08:00:37 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA22193; Mon, 21 May 90 07:59:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26168; Mon, 21 May 90 07:30:19 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from decpa.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26108; Mon, 21 May 90 07:29:22 -0700 Received: by decpa.pa.dec.com; id AA09514; Mon, 21 May 90 07:28:38 -0700 Message-Id: <9005211428.AA09514@decpa.pa.dec.com> Received: from gah.enet; by decwrl.enet; Mon, 21 May 90 07:28:39 PDT Date: Mon, 21 May 90 07:28:39 PDT From: "Arthur Harvey, 226-7647, LKG1-2/A19" To: ietf-ppp@ucdavis.ucdavis.edu Subject: Questions on PPP and Dave Katz's proposal for OSI NL over PPP. Status: O Hello, I've just finished reading (and thinking some about) the PPP spec and Dave Katz's proposal for OSI-NL over PPP. Being a PPP neophyte, I have a few questions which are included below. If this is the wrong place for these questions, then I apologize and ask for a redirect message. Here goes. 1. Will network management parameters and their effects on the operation of PPP be given in a separate document? 2. Is there any plan to include a PPP user (user being the network layer in this context) interface? For example, it isn't clear to me what input the PPP users might have over option negotiations. Another is how LCP echo requests and replies are initiated and how the reply data is examined. Are PPP users allowed to do this? 3. Should anything be said about buffer management and other resource sharing? Given that the link is multiplexed among independent PPP users, some guidelines on these issues might be helpful. For example, if a PPP entity has any internal buffering, it must make decisions on how to partition this among PPP users and what policy it has for dropping packets when the remote PPP sends frames faster than the local PPP users receive them. If a PPP user is malfunctioning, it may be necessary to drop his frames so that the necessary management protocol frames can be received to repair (or stop) the malfunctioning PPP user. 4. Any plans for congestion control? Providing a congestion indication to PPP users (this is also related to the interface and buffer management questions) and/or communicating congestion status to the peer PPP entity are sometimes useful to avoid excessive data loss under heavy loads. 5. What techniques were used to verify the LCP protocol correctness? LCP is reasonably complex. Has anyone examined the complete state machine that includes both ends of the link? 6. Are the NCP protocols part of the data link, the Network layer or network management (an interface definition might help clarify this.)? NCPs appear to negotiate Network Layer parameters. Isn't that a function of either the Network Layer protocols or network management protocols? It may sound like nit-picking, but these NCPs appear to add overhead to the data link which may not always be needed. Given that either the Network Layer or network management must be involved in the negotiation, why not let these entities handle the entire negotiation protocol? The difficulty often encountered is that the lower layer negotiation service is not used because it doesn't efficiently provide the exact procedures needed by the higher layer. 7. In Dave Katz's proposal for the OSI NL over PPP, the OSI NL does not use the NCP to negotiate any parameters. In OSI, configuring, enabling and disabling of a protocol are management functions that are either internal to the protocol operation or external management operations. For example, enabling and disabling and setting parameters of the NL takes place through network management. Exchange of configuration information (e.g. addresses) between NL entities is achieved by "Hello" messages. The NCP handshake mechanism adds delay to starting normal operation of the OSI NL and does not allow parameters to be renegotiated without halting and restarting delivery of other packets. Perhaps the OSI NL does not need this NCP and the OSI NL should begin sending datagrams as soon as the data link has reached the "Open" state. In other words, why not make the NCP for the OSI-NL be null? Thanks, -Arthur From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 22 08:31:10 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA01886; Tue, 22 May 90 08:27:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06124; Tue, 22 May 90 08:00:20 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Vax.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06059; Tue, 22 May 90 07:52:52 -0700 Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA03263; Tue, 22 May 90 10:51:39 EDT Date: Tue, 22 May 90 10:51:39 EDT Message-Id: <9005221451.AA03263@vax.ftp.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: meeting date and writing assignments . . . . From: stev@vax.ftp.com Cc: heather@arch3.att.com Repository: ftp.com Originating-Client: d-cell.ftp.com Status: O hello, campers, i have gotten the form for the video confrence rooms, and have tenatively scheduled a date of monday, 18 june. unless there are serious problems, i would like to go with that. there are four centers for access to the video confrence, Boston(BBN), Washington DC (DARPA), LA area (ISI), and Palo Alto (stanford). if you are interested in attending, an i encourage all of you to attend, please let me know where you will be going by the end of the week, so i can let them know. here are the writing assingments people have volunteered for so far: Dave Katz katz@merit.edu ISO Heather (?) heather@arch3.att.com Frame Relay Art Harvey harvey@gah.enet.dec.com ISO, DECNet IV Steve Senum sjs@eros.network.com Appletalk, DECNet IV Larry Backman backman@interlan.interlan.com IPX(Novell) Frank Kastenholtz kasten@interlan.interlan.com MIB (SNMP variables) Frank Slaughter(?) (?) Appletalk Stev Knowles stev@ftp.com MIB (SNMP variables) some people, like frank slaughter from shiva, i do not have an email address for. hopefully, he is on the list. if you know the address, please let me know(drew?). some people have done a alot of work already, and that is greatly appreciated. i dont think anyone i waiting on something form anyone else. fred, could you send me the MIB stuff you wanted to make sure would be included. thanx campers, i appreciate the effort. From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 22 19:15:16 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA07678; Tue, 22 May 90 19:10:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14111; Tue, 22 May 90 18:45:14 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay.cs.net by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14050; Tue, 22 May 90 18:35:48 -0700 Received: from relay2.cs.net by RELAY.CS.NET id aa01477; 22 May 90 21:35 EDT Received: from [192.31.242.27] by RELAY.CS.NET id aa04201; 22 May 90 21:24 EDT Received: by interlan.Interlan.Com (5.51/5.17) id AA27005; Tue, 22 May 90 15:52:57 EDT Date: Tue, 22 May 90 15:52:57 EDT From: Larry Backman Message-Id: <9005221952.AA27005@interlan.Interlan.Com> To: ietf-ppp@UCDAVIS.ucdavis.edu Subject: Re: meeting date and writing assignments . . . . Status: O Stev: I just read the PPP RFC on a plane last nite. I see some real problems with IPX... First; IPX over PPP is a misnomer; what people realy want is Netware Core prot Protocol support; IPX is the datagram protocol; NCP is the filing protocol, and guess what....there's nothing in between the two! It gets worse; NCP was designed in 1981 to run over unreliable but fast (at the time) links. As such it used an ACK/NAK protocol (NCP) on top of datagrams (IPX). To ensure reliability timeout/retransmission logic is built into the client's and keepalive logic is built into the server. This approach is all well and good on an Ethernet or Token Ring; it fails miserably over slower asynch. lines. No to belabour the point, but at one sad interval in Interlan's history we were developing remote MAC bridges. To test the things we removed an Ethernet-Ethernet bridge and replaced it with two remote bridges hooked back to back (speed was 1.544 Meg). As expected, the 1.5 Meg hookup reduced performance, but by and large things seemed to work TCP & OSI wise. Netware on the other hand choked big-time. Once NCP request/responses got stuck in the bridge queue's clients would time out and start retransmitting. AS more clients were connected, more NCP requests timed out, and more retransmissions occurred. Brisge meltdown occurred shortly thereafter. There are ways around this of course; there are vendor's who make IPX bridges which solve the problem in numerous way's. Most of these solutions do involve some sort of protocol knowledge and means of keeping the client happy while the NCP request/response makes its way through the slower link. And then there is Netware routing...... File servers advertise themselves via a broadcast protocol called SAP, Service Advertising Protocol. In addition Netware servers use RIP, of XNS and old TCP fame to tell each other about which how to get to servers. All Netware addresses are made up of a combination of a network number and node number. Each server keeps a routing table of a server's node number and what network it is on. All network numbers are considered to be unique through a Netware internet. Now consider a Novell inetrnet in Boston with 10 servers, S1..S10, and 3 networks N1..N3. WE use PPP to hook up this network to another one in New York. The NY network has 5 servers S1..S5, and only a single network, N1. Unfortunately, Boston's N1 and New York's N1 have the same network address, and Bostons S2 has the same name as New York's S3. Can you guess what Netware does at this point? The above scenerio is not uncommon; Novell installation manuals lead rookie Netware types down the golden path involving a server name FS1 and a network number of 1. As with NCP; there are ways around the problem....They involve some serious software development. Which leads me to the real question... At what level is IPX over PPP considered; to provide Netware internetwork connectivity? Connectivity for a single client? Does it make sense to deal with the above 2 issues in such a spec. or instead to document them as caveat's and ignore the problem? BTW, if you can solve the above 2 problems, wait, I got another one..... Larry From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 23 00:00:20 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA08965; Tue, 22 May 90 23:53:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16771; Tue, 22 May 90 23:30:23 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mathom.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16714; Tue, 22 May 90 23:29:41 -0700 Date: Tue 22 May 90 23:28:50-PDT From: William "Chops" Westfield Subject: Novell PPP To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9005221952.AA27005@interlan.Interlan.Com> Message-Id: <12591895680.12.BILLW@mathom.cisco.com> Status: O PPP is a link layer protocol. By allowing IPX over PPP, you provide connectivity between novell networks. That Novell protocols may not be well designed for a large network with slow links is irrelevant to the link level - by supporting IPX, any improvements to NCP, SAP, RIP, and so on will automagically work (as long as they continue to use IPX packet format.) Don't forget that a significant use of PPP is over high speed synchronous serial lines. cisco, proteon, wellfleet, and presumably others all route novell, and by supplying a PPP spec, they can talk novell to each other. If the lines have to be T1 to get acceptable performance out of it, well, thats no worse than bridging LAT over WANs, and it is certainly outside the scope of the PPP group (or even the IETF) to do much about. The naming and addressing issue you raise are true of any networking protocols, and are not a technical issue at all. Exactly the same problems would happen with IP, except that IP network number are handed out by a central authority (actually, the problem has happened anyway). Bill Westfield cisco Systems. PS: Isn't Novell supposed to convert to ISO protocols in N years anyway? ------- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 23 05:45:20 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA10135; Wed, 23 May 90 05:30:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19309; Wed, 23 May 90 04:45:12 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inria.inria.fr by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19266; Wed, 23 May 90 04:35:01 -0700 Received: from Gipsi.Gipsi.FR by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA15321; Wed, 23 May 90 13:33:36 +0200 (MET) Received: by Gipsi.Gipsi.Fr (4.12/4.8) id AA17169; Wed, 23 May 90 13:33:04 -0100 (MET) Date: Wed, 23 May 90 13:33:04 -0100 From: Philippe Prindeville Message-Id: <9005231233.AA17169@Gipsi.Gipsi.Fr> X-Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74 To: BILLW@mathom.cisco.com Subject: Re: Novell PPP Cc: ietf-ppp@ucdavis.ucdavis.edu Status: O But Larry makes the point that the retransmission strategy doesn't work with T1 lines. I am assuming here that when the client requests the route (via the getLocalTarget call that does a RIP request packet), the metric (which is expressed as a vector: hops and some pseudo- linear delay [ms?]), that the delay is not being used by the code to figure out the retransmission time *OR* that the delay was not being sufficiently incremented to reflect the delays incurred by T1 propa- gation times (actually, if it was a bridge, there would be no RIPping anyway -- so perhaps this problem is specific to bridges but not to routers that compute the delay correctly?). -Philip From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 23 08:00:13 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA10943; Wed, 23 May 90 07:55:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20793; Wed, 23 May 90 07:32:08 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20613; Wed, 23 May 90 07:23:05 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA26782; Wed, 23 May 90 10:28:43 EDT Date: Wed, 23 May 90 10:28:43 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005231428.AA26782@sonny.proteon.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: Larry Backman In-Reply-To: Larry Backman's message of Tue, 22 May 90 15:52:57 EDT <9005221952.AA27005@interlan.Interlan.Com> Subject: IPX over PPP Status: O Yes, I can fully agree that IPX/NCP would gag horribly over a bridge, especially one that had a long delay. This is because it (NCP) has a lockstep protocol (think of TFTP and you're not far off), and non- adaptive timeouts. However, IPX over PPP would be for routing, not bridging. This would work better than bridging. The reason is that Novell's IPX adaptation of RIP has a extra field in the routing entries, which is delay. It gets added up by RIP just like the hop count, and is propogated in the same way. Slower lines have higher delays. The NCP in the end nodes looks at the delay to the network it is talking to, and uses this as the timer to schedule its retransmissions on. Thus, a router over a PPP line would cause the end nodes to get the correct delay number, while nodes using a bridge would think that the delay was just two Ethernets. The unit of the delay is the number of IBM PC clock ticks that it would take to send a 576 byte packet over the network in question. (Strange unit, eh?) The minimum delay is 1, which is what all the LANs use. I have run IPX routed over 56 KB lines. I can't claim that it's speedy, but it does work. You surely wouldn't want to load executables over it, but you surely could do file access. On a T1 line, things worked fine. I don't think that the PPP committee needs to worry about the naivete of the average NetWare user. They are not the only naive people out there. I have seen customers try and use the same XNS network number on both sides of a router. Ignorance is universal, and does not discriminate among protocols. A NetWare router will be able to detect duplicate service names, and be able to log an error, because it is seeing the service constantly "move". You can't detect duplicate networks, however. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 23 10:45:45 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA12456; Wed, 23 May 90 10:42:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22682; Wed, 23 May 90 10:17:10 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Vax.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22459; Wed, 23 May 90 10:04:40 -0700 Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA15179; Wed, 23 May 90 13:03:27 EDT Date: Wed, 23 May 90 13:03:27 EDT Message-Id: <9005231703.AA15179@vax.ftp.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: meeting date and writing assignments . . . . From: stev@vax.ftp.com Repository: ftp.com Originating-Client: d-cell.ftp.com Status: O i must say that i agree with bill westfield. the idea here is to let vendors ship novell packets across ppp connections, all the same way, to allow vendors to interoperate. while i realize that this may not be advisable for bridges, it is common for routers. certainly the spec should mention this, and briefly explain why. so, i suppose it should cover the stuff for necessary for routers then . . . . . *REMEMBER* to mail to me and let me know if you are attending the video confrence on 18JUN. the require access lists for attendies. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 23 22:30:11 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA17337; Wed, 23 May 90 22:28:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02182; Wed, 23 May 90 21:48:31 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay.cs.net by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02023; Wed, 23 May 90 21:41:37 -0700 Received: from relay2.cs.net by RELAY.CS.NET id al19076; 23 May 90 16:45 EDT Received: from [130.204.0.1] by RELAY.CS.NET id aa18712; 23 May 90 16:38 EDT Received: by interlan.Interlan.Com (5.51/5.17) id AA08421; Wed, 23 May 90 16:42:13 EDT Date: Wed, 23 May 90 16:42:13 EDT From: Larry Backman Message-Id: <9005232042.AA08421@interlan.Interlan.Com> To: ietf-ppp@UCDAVIS.ucdavis.edu Subject: Re: Novell PPP Status: O Novell is converting to ISO at the same time they deliver on promised functionality in the promised timeframe..... Couple of issues re Netware. As John pointed out their non-adaptive timeouts are the crux of the fast LAN/slow PPP delay issue. Adaptive backoff and Netware...hah. I agree that Netware's problems are outside of the scope of this working group; however, they still have to be mentioned as a problem. the nastiness of Netware over 56KB or T1 is that it seems to work fine right up to the point when it croaks, badly! That timeframe was typically about 9:30 or 10:00 in the morning at Interlan when the world arrived and started doing work. Analysis of the bridge bottlenecks showed that data flow was OK for the 1st couple of user's trying to use Netware across T1; however when 4 or 5 starting doing heavy work; the bridge queues backed up, Netware retransmissions occurred, and things wedged. As to routing, that's clearly an Appendix issue, however its something to be addressed. The lovely message ROUTER CONFIGURATION ERROR!!!ROUTER 123456 CLAIMS LAN A IS 0002 sends fear through the heart of your average Netware supervisor. I'm by no means proposing to write an RFC which designs a mechanism for bridging (as they call it) Netware LAN's via PPP, however, I do believe a RFC should at least address the pitfalls. If I get the consensus correctly, Netware/PPP is designed to support Netware internet bridging as opposed to a single client dialing up to a server? Larry BTW; I assume Netware's non 802.3 compliance is not an issue as their entire packet is encapsulated within PPP? From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 24 00:15:05 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA19178; Thu, 24 May 90 00:08:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04837; Wed, 23 May 90 23:45:27 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mathom.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04808; Wed, 23 May 90 23:40:34 -0700 Date: Wed 23 May 90 23:39:55-PDT From: William "Chops" Westfield Subject: Re: Novell PPP To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9005232042.AA08421@interlan.Interlan.Com> Message-Id: <12592159843.11.BILLW@mathom.cisco.com> Status: O If I get the consensus correctly, Netware/PPP is designed to support Netware internet bridging as opposed to a single client dialing up to a server? Uh, netware/ppp is designed to support netware internet ROUTING, either between routers, or between a node and a router (which may not work, or maybe it will...) Do not be confused by the fact that Novell calls their routers "bridges". There is a separate PPP spec to cover bridging, which is not specific to any particular network protocol. Bill Westfield cisco Systems. ------- From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 24 11:30:29 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA22948; Thu, 24 May 90 11:25:18 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11549; Thu, 24 May 90 11:01:53 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11454; Thu, 24 May 90 10:52:22 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA16344; Thu, 24 May 90 13:57:57 EDT Date: Thu, 24 May 90 13:57:57 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005241757.AA16344@sonny.proteon.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: Larry Backman In-Reply-To: Larry Backman's message of Wed, 23 May 90 16:42:13 EDT <9005232042.AA08421@interlan.Interlan.Com> Subject: Novell PPP Status: O The 802.3 (without 802.2) mis-encapsulation is a non-issue for PPP. After the PP header, the next thing will be the IP header, starting with the checksum (0xffff). We're routing, and the data link code will long since have stripped either the 802.3 or Ethernet 8137 header off. I will agree that I only had one workstation/server session across the sync line, so that there was no additional delay due to congestion. If you make the delay number for RIP configurable, rather than compute it from the line's baud rate, then you can account for congestion. (Tuning transport protocols at the router. How lovely!) PS. Novell converting the DOS workstation shell to CNLP/TP4/FTAM is about as likely as the FCC announcing that the NTSC TV standard will be abandoned 12/31/90, to be replaced with 20 channels of HDTV in the current UHF band. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 30 06:31:31 1990 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.03) id AA27964; Wed, 30 May 90 06:24:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18063; Wed, 30 May 90 06:00:09 -0700 Reply-To: ietf-ppp@ucdavis.ucdavis.edu Sender: ietf-ppp-request@ucdavis.ucdavis.edu Errors-To: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Vax.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18050; Wed, 30 May 90 05:57:59 -0700 Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA11203; Wed, 30 May 90 08:56:55 EDT Date: Wed, 30 May 90 08:56:55 EDT Message-Id: <9005301256.AA11203@vax.ftp.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: video meeting From: stev@vax.ftp.com Repository: ftp.com Originating-Client: d-cell.ftp.com Status: O i have reserved the room for jun 18, that is a monday. ***** if you dont let me know you are attend soon, you *cant*, the sites *require* access lists. let me know *now*, you wont forget. if there is nothing written for the meetings, there will be nothing to finish up at the last meeting in BC. ***** i know you folks are busy at work, like frank, john, and i are on the MIB spec:). your help *is* appreciated . . . . . . . .