PPP

PPP is defined in RFC 1661 and replaces the Serial Line Internet Protocol (SLIP) because of its deficiencies. SLIP only supports the IP protocol, and does not allow authentication and dynamic assignment of routed protocols. Unlike SLIP, PPP provides a standard method for transporting multiprotocol datagrams over point-to-point links. PPP is composed of three main components :

• A method for encapsulating multiprotocol datagrams

• A link control protocol (LCP) for establishing, configuring, and testing the data-link connection

• A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols ^[1]

The PPP protocol falls under the definitions of the second, or data link layer, of the Open System Interconnection (OSI) model. The format of the PPP frame is shown in Figure 5-2.

Figure 5-2. The Format of the PPP Frame

The descriptions of the fields in Figure 5-2 are as follows :

• Flag Similar to the one for high-level data link control (HDLC), the Flag indicates the beginning and the end of the PPP frame. Its value is 01111110.

• Address Because PPP is used for a point-to-point connection, the Address field uses the broadcast address of HDLC, 11111111, to avoid the data-link address in the protocol.

• Control The Control field uses the format of the U-frame in HDLC. The value is 11000000 to show that the frame does not contain any sequence numbers , and that there is no flow and error control.

• Protocol This field defines what is being carried in the Data field. Some valid values of the Protocol field include the following:

  - c021 LCP
  
  

  - c023 PAP
  
  

  - c025 Link Quality Report
  
  

  - c223 CHAP
  
  

• Data field The user data or NCP packets are carried by the Data field, sometimes called the Payload field.

• FCS The Frame Check Sequence (FCS) field is the same as in HDLC. It contains a 2- or 4-byte cyclic redundancy check (CRC).

During the process of establishing the protocol, the PPP link goes through several distinct phases, which are specified as follows:

• Link Dead (physical layer not ready)

• Link Establishment phase

• Authentication phase

• Network-Layer Protocol phase

• Link Termination phase

The following sections summarize these phases.

Link Dead (Physical Layer Not Ready)

The link necessarily begins and ends with this phase. When an external event, such as a Carrier Detect (CD) Up event, indicates that the physical layer is ready to be used, PPP proceeds to the Link Establishment phase. During this phase, the LCP automation (described later) is in the initial or starting state.

Link Establishment Phase

LCP establishes the connection through an exchange of configure packets. As soon as the Protocol field contains c021h, the phase is changed to link establishment. After a Configure-Ack packet is both sent and received, the exchange is complete and the LCP Opened state begins. The LCP codes are 1-byte long and are listed in Table 5-2.

Table 5-2. LCP Codes, Packet Types, and Descriptions

Code (Hex)	Packet Type	Description
01	Configure-Request	List of proposed link configuration options
02	Configure-Ack	Acknowledge the proposed configuration options
03	Configure-Nak	Does not acknowledge the proposed configuration options
04	Configure-Rej	Unknown configuration optionReject
05	Terminate-Request	Request to terminate the phase
06	Terminate-Ack	Acknowledges the termination request
07	Code-Rej	Unknown codeReject
08	Protocol-Rej	Unknown protocolReject
09	Echo-Request	Checks if the other end is Up
0A	Echo-Replay	Response to Echo-Request
0B	Discard-Request	Discard the request

Any non-LCP packets received during the Link Establishment phase must be silently discarded.

Authentication Phase

By default, authentication is not mandatory unless the protocol number used is c023 (PAP) or c223 (CHAP). The authentication negotiation occurs during the Link Establishment phase, where only LCP, authentication protocol, and link quality monitoring packets (protocol type c025Link Quality Report) are allowed. All other packets received during this phase are discarded.

In PAP, one side supplies both a username and password in clear-text to the peer that is authenticating it. In CHAP, one peer challenges the other peer, and the latter one must be able to respond with the correct answer to the challenge before passing authentication. The password in CHAP creates the answer to the challenge and is never transmitted across the wire, which makes it inherently more secure. Also, there is MS-CHAP, which is similar to CHAP with the only exception being that MS-CHAP uses Microsoft's version of the protocol.

Network Layer Protocol Phase

After the link is established and optional facilities are negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols (such as IP, Internetwork Packet Exchange [IPX], or AppleTalk). After it is configured, datagrams from each network layer protocol can be sent over the link. The link remains configured for communications until explicit LCP or NCP packets close the link down. Each NCP can be opened and closed at any time. After an NCP reaches the Opened state, PPP carries the corresponding network-layer protocol packets. One example for NCP is the IP Control Protocol (IPCP). Its format is shown in Figure 5-3. The value of the Protocol field for a PPP packet is 8021h. ^[2]

Figure 5-3. The Format of an IPCP Frame

Because every NCP negotiates its own phases, reaching levels of Open and Close, Code values are defined in the Code field to facilitate the process. The Code field is 1-byte and the valid values are identified in Table 5-3.

Table 5-3. Code Values of an IPCP Protocol

Code (Hex)	Packet Type	Description
01	Configure-Request	List of proposed link configuration options
02	Configure-Ack	Acknowledge the proposed configuration options
03	Configure-Nak	Does not acknowledge the proposed configuration options
04	Configure-Rej	Unknown configuration optionReject
05	Terminate-Request	Request to terminate the phase
06	Terminate-Ack	Acknowledges the termination request
07	Code-Rej	Unknown codeReject

Link Termination Phase

PPP can terminate the link at any time. Possible reasons include loss of carrier, authentication failure, link quality failure, expiration of an idle-period timer, and the administrative closing of the link. LCP closes the link through an exchange of terminate packets (see LCP packets 05h and 06h). While the link is closing, PPP informs the network-layer protocols so that they can take appropriate action.

PPP Troubleshooting Considerations

For practical purposes, engineers often consider PPP as a four-phase protocol, ignoring the very first phase (Link Dead). This does not make a difference for troubleshooting purposes. ^[3]

NOTE

PPP over different technologies, such as dial, ISDN, and Frame Relay, poses different requirements to ensure inter-operability with the PPP protocol. For additional information, see RFC 1618 or Parts III and IV, "Frame Relay," of this book.

One of the most resource- intensive procedures in PPP negotiation occurs during the LCP negotiation. Previously, Cisco IOS created a statically configurable number of processes to authenticate calls. Each of these processes handles a single call, but in some situations, the limited number of processes cannot keep up with the incoming call rate, resulting in some calls timing out (the empiric numbers were showing about 1300 users per NAS). The AAA-PPP-VPDN Non-Blocking feature, introduced in IOS release 12.2(4)T, changed the software architecture such that the number of processes does not limit the rate of call handling. Async HDLC framing (the frame type defined in RFC 1662) engine for the R1.1 release is compatible with the 7200 platform and ensures that each Packet Data Serving Node (PDSN) can handle 8000 active PPP sessions on the 7200 platform.