Requirements for an Internet Standard Point-to-Point Protocol
RFC 1547
Document | Type | RFC - Informational (December 1993) | |
---|---|---|---|
Author | Drew D. Perkins | ||
Last updated | 2013-03-02 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 1547
RFC 1547 Point-to-Point Protocol Requirements December 1993 3.2 Flow Control Flow control (such as XON/XOFF) is not required. Any implementation of the ISPPP is expected to be capable of receiving packets at the full rate possible for the particular data link and physical layers used in the implementation. If higher layers cannot receive packets at the full rate possible, it is up to those layers to discard packets or invoke flow control procedures. As discussed above, end- to-end flow control is the responsibility of the transport layer. Including flow control within a point-to-point protocol often causes violation of the simplicity requirement. 3.3 Sequencing Sequencing of packets is not required. The ISPPP need provide no more service than the IP protocol, an unreliable datagram service which is free to reorder packets. In fact, it is specifically allowed to reorder packets based upon some type-of-service criteria implemented in higher-level protocols. 3.4 Backward Compatibility There is no requirement for the ISPPP to provide backward compatibility with any other point-to-point protocol. First, there are no official Internet Standards with which backward compatibility must be maintained. Second, attempting to maintain backward compatibility may lead to needless restrictions on the new protocol. However, there is no need for the designers of the ISPPP to go out of their way to inhibit backward compatibility. 3.5 Multi-Point Links There is no requirement for supporting multi-point links. Many features which are required are only valid between two peers. These links are sufficiently rare that the benefits of supporting them are outweighed by the added complexity their support would introduce into the ISPPP. Historical Note: The original rationale also stated: "Furthermore, it is unlikely that many new types of multi-point links will be introduced in the foreseeable future." Since this was written, considerable effort has been expended in new multi-point links, including Switched Multimegabit Data Service, Frame Relay, and Asynchronous Transfer Mode. However, it is clear that these are considerably more complex than ISPPP. Perkins [Page 13] RFC 1547 Point-to-Point Protocol Requirements December 1993 3.6 Half-Duplex or Simplex Links Support for half-duplex or simplex links is not required. These types of links are not in common use in the current Internet. Half- duplex links require some method of turning the line around. The ISPPP need not have an explicit mechanism for handling line turn- around. Such support might possibly be added in the future via the required extension mechanism. 3.7 7-bit Asynchronous RS-232 Links The use of asynchronous RS-232 need not support 7-bit links. 8-bit links are predominant in the Internet environment and supporting 7- bit links introduces unnecessary complexity. 4. Prior Work On PPP Protocols This section reviews a number of existing point-to-point and data link layer protocols and points out which of our requirements are not satisfied. 4.1 Internet Protocols 4.1.1 RFC 891 - DCN Local-Network Protocols, Appendix A In Appendix A of RFC 891, "DCN Local-Network Protocols" [4], D.L. Mills describes the data link layer packet formats used by the Fuzzball system for asynchronous, character-oriented synchronous, DDCMP, HDLC, ARPANET 1822, X.25 LAPB and ethernet links. These protocols meet the stated requirements for simplicity, transparency, packet framing and efficiency, but fall short of many of the others. Most of these protocols assume the use of the IP protocol, and do not include any type of protocol demultiplexing field. No error detection mechanism is provided except when necessary to comply with another standard such as ethernet. RFC 891 does not mention the MTU used for any of these links. Other requirements such as loopback detection and misconfiguration detection are not discussed. Finally, no option negotiation scheme is defined; without a protocol demultiplexing field it would be difficult or impossible to include one. 4.1.2 RFC 914 - Thinwire Protocols RFC 914, "Thinwire Protocols" [5], discusses the use of low speed links in the Internet. This document places its main emphasis on decreasing round-trip delay and increasing link efficiency with the help of header compression (vs. data compression) techniques. Three "Thinwire" protocols are discussed, Thinwire I, Thinwire II and Perkins [Page 14] RFC 1547 Point-to-Point Protocol Requirements December 1993 Thinwire III. The latter two protocols require the use of a reliable data link layer protocol; one such protocol, "SLIP" (not to be confused with Rick Adams' SLIP), is proposed in Appendix D of the RFC. As proposed, "SLIP" does not meet many of the stated requirements. Although not terribly complex, as a reliable, error detecting and correcting protocol, it is not "simple". The 32 octet packet size makes it inefficient for large or uncompressed packets, requiring complex fragmentation and reassembly. The use of other than asynchronous links is not mentioned. The entire reliable link layer would be redundant over LAPB links. There is no mechanism for option negotiation or future extensibility. 4.1.3 RFC 916 - Reliable Asynchronous Transfer Protocol RFC 916 [6] presents RATP, the Reliable Asynchronous Transfer Protocol. RATP provides error detection and correction, sequencing and flow control across a point-to-point connection. It is directed towards full duplex RS-232 links although it is useful for other point-to-point links. Although the author claims that RATP is not as complex as some other protocols, it is far from simple. RATP solves many of the problems which we have labeled non-requirements and fails to solve many of our stated requirements. Specifically, RATP does not support option negotiation and has no mechanism for future extensibility. Since RFC 916 was published, no consensus has emerged advocating RATP. For these reasons RATP is not recommended as the ISPPP. 4.1.4 RFC 935 - Reliable Link Layer Protocols RFC 935 [7] is a rebuttal to the protocols proposed in RFCs 914 and 916. J. Robinson discusses existing and widely-used national and international standards which meet the needs addressed by the two prior RFCs. The standards reviewed include character-oriented asynchronous and synchronous (bisynch) protocols and bit-oriented synchronous protocols. RFC 935 does not present any higher level issues such as option negotiation or extensibility. 4.1.5 RFC 1009 - Requirements for Internet Gateways Section 3 of RFC 1009, "Constituent Network Interfaces" [8], briefly discusses requirements for transmission of IP datagrams over a number of types of point-to-point links including X.25 LAPB, HDLC framed synchronous links, Xerox Synchronous Point-to-Point synchronous lines and the MIT Serial Line Framing Protocol for asynchronous lines. RFC 1009 merely mentions these as reasonable candidates and does not go into depth on any of them. All are discussed further in this document. Perkins [Page 15] RFC 1547 Point-to-Point Protocol Requirements December 1993 4.1.6 RFC 1055 - Serial Line IP Rick Adams' Serial Line IP (SLIP) protocol [9] has become something of a de facto standard due to the popularity of the 4.2 and 4.3BSD UNIX operating systems. SLIP is easily added to 4.2 systems and is included with 4.3. Many other TCP/IP implementation have added SLIP implementations in order to be compatible. Yet SLIP is not a real standard; the protocol was only recently published in RFC form. Before RFC 1055 it was specified in the SLIP source code. SLIP does not meet most of the requirements set forth above. SLIP certainly meets the requirement for simplicity, and also meets the requirements for transparency and bandwidth efficiency. But SLIP only provides for sending IP packets over asynchronous serial lines. Since it provides no higher level protocol field for demultiplexing, SLIP cannot support multiple concurrent higher level protocols. Providing only a framing protocol, SLIP would be entirely redundant when used with a LAPB synchronous link. SLIP includes absolutely no mechanism for error detection, not even parity. Again due to its lack of a protocol type field, SLIP does not support any type of option negotiation or extensibility. 4.2 International Protocols 4.2.1 ISO 3309 - HDLC Frame Structure ISO 3309 [10], the HDLC frame structure, is a simple data link layer protocol which provides framing of packets transmitted over bit- oriented synchronous links. Special flag sequences mark the beginning and end of frames and bit stuffing allows data containing flag characters to be transmitted. A 16-bit Frame Check Sequence provides error detection. By itself, the HDLC frame structure does not meet most of the requirements. HDLC does not provide protocol multiplexing, standard MTUs, fault detection or option negotiation. There is no mechanism for future extensibility. Given the HDLC frame structure's wide acceptance and simplicity, it may be an ideal building block for the ISPPP. 4.2.2 ISO 6256 - HDLC Balanced Class of Procedures ISO 6256, the HDLC Balanced Class of Procedures, specifies a data link layer protocol which provides error correction, sequencing and flow control. ISO 6256 builds on ISO 3309 and ISO 4335, HDLC Elements of Procedures. As far as meeting our requirements is concerned, ISO 6256 does not Perkins [Page 16] RFC 1547 Point-to-Point Protocol Requirements December 1993 provide any more utility than does ISO 3309. The capabilities that are provided are all considered unnecessary and overly complex. 4.2.3 CCITT X.25 and X.25 LAPB CCITT recommendation X.25 [11] describes a network layer protocol providing error-free, sequenced, flow controlled virtual circuits. X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 and 6256. Neither X.25 LAPB or full LAPB meet any more of our requirements than the ISO protocols. 4.2.4 CCITT I.441 LAPD CCITT I.441 LAPD [12] defines the Link Access Procedure on the ISDN D-Channel. The data link layer of LAPD is very similar to that of LAPB and fails to meet the same requirements. 4.3 Other Protocols 4.3.1 Cisco Systems point-to-point protocols The Cisco Systems gateway supports both asynchronous links using SLIP and synchronous links using either simple HDLC framing, X.25 LAPB or full X.25. The HDLC framing procedure includes a four byte header. The first octet (address) is either 0x0F (unicast intent) or 0x8F (multicast intent). The second octet (control byte) is left zero and is not checked on reception. The third and fourth octets contain a standard 16 bit Ethernet protocol type code. A "keepalive" or "beaconing" protocol is used to ensure the two-way connectivity of the serial line. Each end of the link periodically sends two 32 bit sequence numbers to the other side. One sequence number is the local side's sequence number, the other is the sequence number received from the other side. Hearing the local sequence number from the other side indicates that the link is working in both directions. The keepalive protocol is extensible. One extension is used to default IP addresses on serial lines of systems without non-volatile memory. A request for address is sent to the remote side. The remote side responds with its own IP address and a subnet mask. When the querying side receives the reply, it checks if the host portion of the remote address is either 1 or 2. If so, the opposite address is chosen for the local address. If not, the protocol cannot be used and we must rely on other address resolution means. This protocol assumes that each serial link uses one subnet or network number. LAPB assuming IP is another possible encapsulation. A multi-protocol Perkins [Page 17] RFC 1547 Point-to-Point Protocol Requirements December 1993 extension of LAPB (multi-LAPB) includes a 16 bit Ethernet type code after the address and control bytes and in front of the actual protocol data. DDN X.25 and Commercial X.25 encapsulations are also supported. Multiple protocols are supported by making protocol dependent CALL REQUEST's. 4.3.2 MIT PC/IP framing protocol The MIT PC/IP framing protocol [13] provides a mechanism for the transmission of IP datagrams over asynchronous links. The low-level protocol (LLP) sublayer provides encapsulation while the local net protocol provides multiplexing of IP datagrams and IP address request packets. The protocol only allows host-to-gateway connections. Host-to-gateway flow control is provided by requiring the host to transmit request packets to the gateway until an acknowledgment is received. Rudimentary IP address negotiation requires the host to ascertain its IP address from the gateway. The protocol does not implement error detection, connection status determination, fault detection or option negotiation. Only asynchronous links are supported. 4.3.3 Proteon p4200 point-to-point protocol The Proteon p4200 multi-protocol router supports transmission of packets over bit-oriented synchronous links with a wide range of speeds (zero to 2 Mb/sec). The p4200 point-to-point protocol encapsulates packets inside HDLC frames but does not use the HDLC address or control fields; these two octets are instead used for a 16-bit type field. The p4200 does use the HDLC frame check sequence trailer. Protocol type numbers are ad hoc and do not correspond to any existing standard. A simple liveness protocol detects dead connections. Although the Proteon protocol does meet many of our requirements, it does not meet our requirements for option negotiation. 4.3.4 Ungermann Bass point-to-point protocol The Ungermann Bass router supports synchronous links using simple HDLC framing. Neither the HDLC address or control field are used, IP datagrams are placed immediately after the HDLC flag. The U-B protocol does not meet any of our requirements for fault detection or option negotiation. No mechanism for future extensibility is currently defined. Perkins [Page 18] RFC 1547 Point-to-Point Protocol Requirements December 1993 4.3.5 Wellfleet point-to-point protocol The Wellfleet router supports synchronous links using simple HDLC framing. The HDLC framing procedure uses the HDLC address and places the Unnumbered Information (UI) command in all frames. A simple header following the UI command provides a two octet type field using the same values as Ethernet. The Wellfleet protocol does not meet any of our requirements for fault detection or option negotiation. No mechanism for future extensibility is currently defined, although one could be added. 4.3.6 XNS Synchronous Point-to-Point Protocol The Xerox Network Systems Synchronous Point-to-Point protocol (XNS PPP) [14] was designed to address most of the same issues that an ISPPP must address. In particular, it addresses the issues of simplicity, transparency, efficiency, packet framing, protocol multiplexing, error detection, standard MTUs, symmetry, switched and non-switched media, connection status, network address negotiation and future extensibility. However, the XNS SPPP does not meet our requirements for multiple data link layer protocols, fault detection and data compression negotiation. Although protocol multiplexing is provided, the packet type field has only 8 bits which is too few. Perkins [Page 19] RFC 1547 Point-to-Point Protocol Requirements December 1993 References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [2] Postel, J., "User Datagram Protocol", STD 6, RFC768, USC/Information Sciences Institute, August 1980. [3] Electronic Industries Association, EIA Standard RS-232-C, "Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange", August 1969. [4] Mills, D. L., "DCN Local-Network Protocols", STD 44, RFC 891, University of Delaware, December 1983. [5] Farber, David J., Delp, Gary S., and Conte, Thomas M., "A Thinwire Protocol for Connecting Personal Computers to the Internet", RFC 914, University of Delaware, September 1984. [6] Finn, G., "Reliable Asynchronous Transfer Protocol (RATP)", RFC 916, USC/Information Sciences Institute, October 1984. [7] Robinson, J., "Reliable Link Layer Protocols", RFC 935, BBN, January 1985. [8] Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC1009, USC/Information Sciences Institute, June 1987. [9] Romkey, J., "A Nonstandard for the Transmission of IP Datagrams Over Serial Lines: SLIP", STD 47, RFC 1055, June 1988. STD 4, RFC 1009, June 1987. [10] ISO International Standard (IS) 3309, "Data Communications - High-level Data Link Control Procedures - Frame Structure", 1979. [11] 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", Vol. VIII, Fascicle VIII.2, Rec. X.25. [12] CCITT Recommendation Q.921 "ISDN User-Network Interface Data Link Layer Specification". Perkins [Page 20] RFC 1547 Point-to-Point Protocol Requirements December 1993 [13] Romkey, J.L., "PC/IP Programmer's Manual", Massachussetts Institute of Technology Laboratory for Computer Science, January 1986. [14] Xerox Corporation, "Synchronous Point-to-Point Protocol", Xerox System Integration Standard, Stamford, Connecticut, XSIS 158412, December 1984. [15] "Digital Data Communications Message Protocol", Digital Equipment Corporation. Security Consideration Security issues are not discussed in this memo. Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Author's Address Questions about this memo can also be directed to: Drew Perkins 4015 Holiday Park Drive Murrysville, PA 15668 EMail: perkins+@cmu.edu Editor's Address Typographic revision and historical notes by: William Allen Simpson 1384 Fontaine Madison Heights, Michigan 48071 EMail: Bill.Simpson@um.cc.umich.edu Perkins [Page 21]