Layer 2 Vpn Architectures [Electronic resources]

Introducing PPP Encapsulation

In 1993, the Internet Engineering Task Force (IETF) defined the requirements for a serial line data encapsulation protocol in RFC 1547. The protocol that eventually grew out of this RFC was PPP. Following are some of the more important goals that RFC 1547 outlined:

Protocol multiplexing PPP was required to support multiple higher level protocols. This, in turn, required PPP to support a Protocol field to allow for multiplexing several network layer protocols over the same point-to-point link.

Error detection PPP must be able to detect errors in the encapsulated frames.

Network layer address negotiation PPP must support dynamic learning and negotiation of network layer addresses.

Transparency PPP cannot restrict the network layer protocols to avoid certain characters or bit patterns. Instead, PPP must be fully transparent to higher layer protocols. Furthermore, PPP must handle any character or bit pattern restrictions through means such as bit or escaping.

The finalized RFC also described features that PPP explicitly did not require, such as these:

Error correction PPP is not expected to perform error correction, only error detection. Instead, the error correction responsibility is left to upper transport layer protocols.

Flow control PPP is not required to support a flow control mechanism; instead, it is expected to receive packets at the full rate possible depending on the physical layer protocol. The transport layer is left with the responsibility of end-to-end flow control.

Sequencing Although some network layer protocols require sequenced frame delivery, PPP is not required to deliver frames in the same order that these frames were sent.

To meet these requirements, PPP's implementation is primarily composed of four components:

Encapsulation method This is an encapsulation method (RFC 1662) based on HDLC for datagram transmission over point-to-point links.

Link Control Protocol (LCP) LCP allows for establishment of link connectivity and dynamic configuration and testing of the data link connection. RFC 1661 refers to this phase as the Link Establishment phase.

Authentication phase[optional] The Authentication phase is an optional step whereby the peer is authenticated via some mechanism such as Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP).

Network Control Protocol (NCP) An NCP is defined for each upper layer network protocol to allow for dynamic negotiation of its properties. Internet Protocol Control Protocol (IPCP) as defined in RFC 1332 is an example of an NCP for IP and negotiates parameters such as IP address assignment. A host of other NCPs exist for alternate Layer 3 protocols such as IPXCP (IPX) and ATCP (AppleTalk). RFC 1661 refers to this phase as the Network Protocol Phase.

You can find the IETF standards for PPP encapsulation in RFC 1661, "Point-to-Point Protocol (PPP)," and RFC 1662, "PPP in HDLC-Like Framing." Subsequent RFCs were defined to augment PPP's capabilities. RFC 1570 defines additional extensions to the LCP mechanism, and RFC 1990 defines Multilink PPP (MLPPP), which provides a means for link aggregation.

Note

This discussion primarily examines the basic format of PPP data encapsulation as defined in RFCs 1661 and 1662. This discussion does not delve into the negotiation aspects of LCP and the various NCPs because the pseudowire emulation protocols do not interact with PPP at that level.

Figure 5-5 shows the typical PPP frame structure.

Each component of the PPP frame is described as follows:

Flag The beginning and end of every PPP frame must contain a 1-byte Flag Sequence field to delimit the frame. The flag value is 01111110 (0x7e). Like HDLC, PPP uses bit stuffing on synchronous links to fulfill the requirement for network layer transparency.

Note

Similar to HDLC, PPP utilizes byte stuffing on asynchronous links.

Address The Address field is set to an All Stations address of 0xff.

Control The Control field is a single byte that is set to 0x03.

Note

When you perform Address and Control Field Compression (ACFC), the Address and Control fields are omitted. Furthermore, the Protocol field is reduced to a single octet when performing Protocol Field Compression (PFC). Both ACFC and PFC are negotiated in the Link Establishment phase. You can obtain additional details on this in RFC 1661.

Protocol The Protocol field is a 2-octet field which identifies the encapsulated protocol. Internet Assigned Numbers Authority (IANA) administers the assigned PPP protocol numbers. You can find the numbers at http://www.iana.org/assignments/ppp-numbers. Note that the IANA-assigned PPP protocol values do not match Cisco-assigned protocol values used in HDLC.

Information The Information field is a variable-length field that contains upper layer protocol data.

FCS The FCS is a 2-octet CRC calculated over the Address, Control, Protocol, Information, and Padding fields. If negotiated, PPP also supports a 4-octet FCS field.