Table of Contents Example

5.9 Point-to-Point Protocol (PPP)

PPP is a network-specific standard protocol with STD number 51. Its status is elective. It is described in RFC 1661 and RFC 1662.

There are a large number of proposed standard protocols which specify the operation of PPP over different kinds of point-to-point link. Each has a status of elective. The reader is advised to consult STD 1 - Internet Official Protocol Standards for a list of PPP-related RFCs which are on the Standards Track.

Point-to-Point circuits in the form of asynchronous and synchronous lines have long been the mainstay for data communications. In the TCP/IP world, the de facto standard SLIP protocol has served admirably in this area, and is still in widespread use for dial-up TCP/IP connections. However, SLIP has a number of drawbacks:

• SLIP defines only the encapsulation protocol, not any form of handshaking or link control. Links are manually connected and configured, including the specification of the IP address.
• SLIP is only defined for asynchronous links.
• SLIP cannot support multiple protocols across a single link; all packets must be IP datagrams.
• SLIP does no form of frame error detection which forces re-transmission by higher level protocols in the case of errors on noisy lines.
• SLIP provides no mechanism for compressing frequently used IP header fields. Many applications over slow serial links tend to be single-user interactive TCP traffic such as TELNET. This frequently involves small packet sizes and therefore a relatively large overhead in TCP and IP headers which do not change much between datagrams, but which can have a noticeably detrimental effect on interactive response times.

  However, many SLIP implementations now use Van Jacobsen Header Compression. This is used to reduce the size of the combined IP and TCP headers from 40 bytes to 8 bytes by recording the states of a set of TCP connections at each end of the link and replacing the full headers with encoded updates for the normal case where many of the fields are unchanged or are incremented by small amounts between successive IP datagrams for a session. This compression is described in RFC 1144.

PPP has three main components:

1. A method for encapsulating datagrams over serial links.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network-layer protocols.

Before a link is considered to be ready for use by network-layer protocols, a specific sequence of events must happen. The LCP provides a method of establishing, configuring, maintaining and terminating the connection. LCP goes through the following phases:

1. Link establishment and configuration negotiation:

   In this phase, link control packets are exchanged and link configuration options are negotiated. Once options are agreed upon, the link is open, but not necessarily ready for network-layer protocols to be started.

2. Link quality determination:

   This phase is optional. PPP does not specify the policy for determining quality, but does provide low-level tools, such as echo request and reply.

3. Authentication:

   This phase is optional. Each end of the link authenticates itself with the remote end using authentication methods agreed to during phase 1.

4. Network-layer protocol configuration negotiation:

   Once LCP has finished the previous phase, network-layer protocols may be separately configured by the appropriate NCP.

5. 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.

The IP Control Protocol (IPCP) is the NCP for IP and is responsible for configuring, enabling and disabling the IP protocol on both ends of the point-to-point link. The IPCP options negotiation sequence is the same as for LCP, thus allowing the possibility of reusing the code.

One important option used with IPCP is Van Jacobsen Header Compression which is used to reduce the size of the combined IP and TCP headers from 40 bytes to approximately 4 by recording the states of a set of TCP connections at each end of the link and replacing the full headers with encoded updates for the normal case where many of the fields are unchanged or are incremented by small amounts between successive IP datagrams for a session. This compression is described in RFC 1144.

Table of Contents TCP/IP and X.25