PPP has been standardized through the IETF
process, so an excellent history of the evolution of the protocol has
been captured through the RFC series. Open development has also made
a number of good references readily available. I particularly
recommend PPP Design, Implementation, and
Debugging, by James Carlson.
Documents listed in this section are of interest because they offer insight into the way the protocol evolved and the challenges facing protocol designers at the time. None of the RFCs in this section describe present standards, nor should they be used to guide any implementation efforts.
- RFC 1144
“Compressing TCP/IP Headers for Low-Speed Serial Links”
This RFC is unusual in that it is available in both ASCII text and PostScript, with the latter format having more detailed and prettier diagrams. In 1990, state of the art modems were far slower than they are today, and time-shared computing was a necessity for researchers needing even moderate power. One of SLIP’s many problems is that it transmitted full headers for both TCP and IP. Interactive connections frequently send packets with 1 or 2 bytes of data. LAN media can easily handle packets with 40-plus header bytes for 1 data byte, but a 2,400-baud modem makes the procedure excruciating. Van Jacobson, the networking wizard responsible for writing
tcpdumpand for helping us to understand the behavior of TCP/IP in many other contexts, developed a procedure for compressing the TCP and IP headers down to only a handful of bits. Not surprisingly, the procedure is known as Van Jacobson header compression, or simply Van Jacobson compression. When used with SLIP, it is called Compressed SLIP, or CSLIP.Van Jacobson’s work on SLIP compression was funded in part by federal research dollars. As he said in a Usenet post in 1988, “Research to make slow things go fast sometimes makes fast things go faster.” That post is archived at http://wwwhost.ots.utexas.edu/ethernet/enet-misc/load/vanj-enet-posting.html.
- RFC 1547
“Requirements for an Internet Standard Point-to-Point Protocol”
Before PPP was specified, a set of design requirements was drawn up. These requirements from 1989 were initially published in RFC 1547 in 1993 for completeness. RFC 1547 concludes with a discussion of the various serial-line protocols available at the time and their weaknesses.
Several RFCs define the PPP suite. The list in this appendix is complete for common features as of this writing, but more features may be added to PPP in the future. Up-to-date listings of all the officially assigned PPP protocol numbers may be retrieved from the IANA web site at http://www.iana.org/assignments/ppp-numbers.
- RFC 1662
“PPP in HDLC-like Framing”
This RFC specifies the link layer framing for PPP. Adaptations laid out in this document allow PPP to run across nearly any serial link. This RFC borrows some of the common HDLC header components, as well as the standard HDLC stuffing procedure for bit-synchronous links. It also defines the octet-stuffed interface used on asynchronous links and discusses the use of PPP across asynchronous-to-synchronous converters.
- ISO/IEC 7776
“Information technology—Telecommunications and information exchange between systems—High-level data link control procedures—Description of the X.25 LAPB-compatible DTE data link procedures”
LAPB is the link layer for ISDN. Unlike many other link layers developed by the networking industry, LAPB is reliable. Damaged or lost frames are automatically retransmitted. When PPP is used with reliable transmission, the PPP layer rides on LAPB rather than the standard modified HDLC layer.
Network Control Protocols have been defined for most common network protocols. Table F-2 lists the standardized PPP NCPs at the time this book was written.
All NCPs have similar structure. They each inherit the option-negotiation state engine from RFC 1661 and negotiate options in a similar fashion to LCP. Each NCP standard defines the PPP protocol number for encapsulating the higher-layer protocol, the PPP protocol number for its related NCP, and the options used by that NCP to bring up the network layer in question.
MP is specified in one RFC, and not a particularly long one at that. RFC 1717 was the predecessor to the current specification, RFC 1990:
- RFC 1990
“The PPP Multilink Protocol (MP)”
This standard defines MP. It includes information on MP encapsulation, fragmentation, reassembly, and detecting fragment loss and negotiating MP with LCP.
Several extensions to RFC 1990 may be used for Multi-Chassis MP. Nortel’s method has been specified in an informational RFC. Two of the layer-two protocols used are also specified, though only L2TP was an open, publicly developed standard:
- RFC 2701
“Nortel Networks Multilink Multinode PPP Bundle Discovery Protocol”
This is Nortel’s MMP specification. It is discussed in detail in Appendix B.
Other protocols I did not cover were the Ascend (Lucent) Stacks and Cisco’s Stack Group Bidding Protocol (SGBP). Neither is publicly documented.
Two informational RFCs describe additional approaches to using multiple links. MP+ is specific to Ascend/Lucent. BAP and BACP form the basis of the call-steering approach described in Appendix B:
- RFC 1570
“PPP LCP Extensions”
This RFC specified the first set of extensions to LCP. It describes two new LCP codes for the Identification and Time-Remaining frames. It also defines several new LCP options for alternative frame check sequences, the Self-Describing-Padding option, the use of the Callback option for shifting dial-up costs, and the seldom used Compound-Frames option for encapsulating multiple PPP frames in a single link layer frame.
- RFC 1968
“The PPP Encryption Control Protocol (ECP)”
PPP can also be used to encrypt packets before transmitting them across the link. ECP is used only after the packets are compressed with CCP. The PPP reliable delivery option is often used to ensure sequential loss-free delivery because retransmission requires key resynchronization.