Point-to-Point Protocol (PPP)

When industry experts began to design the PPP standard, they had a much better idea of what features would be useful for the emerging Internet. They also knew that modems and phone lines were getting faster and could support a greater amount of protocol overhead. PPP was an effort to address some of the shortcomings of SLIP.

The designers of PPP also wanted PPP to be capable of dynamically negotiating configuration settings at the beginning of a connection and to be capable of managing the link between the communicating computers throughout the session.

How PPP Works

PPP is really a collection of protocols that interact to supply a full complement of modem-based networking features. The design of PPP evolved through a series of RFCs. The current PPP standard is RFC 1661; subsequent documents have clarified and extended PPP components. RFC 1661 divides the components of PPP into three general categories:

  • A method for encapsulating multiprotocol datagrams. SLIP and PPP both accept datagrams and prepare them for the Internet. But PPP, unlike SLIP, must be prepared to accept datagrams from more than one protocol system.

  • A Link Control Protocol (LCP) for establishing, configuring, and testing the connection. PPP negotiates configuration settings and thus eliminates compatibility problems encountered with SLIP connections.

  • A family of Network Control Protocols (NCPs) supporting upper-layer protocol systems. PPP can include separate sublayers that provide separate interfaces to TCP/IP and to alternative suites, such as IPX/SPX.

The following sections discuss these components of PPP.

PPP Data

The primary purpose of PPP (and also SLIP) is to forward datagrams. One challenge of PPP is that it must be capable of forwarding more than one type of datagram. In other words, the datagram could be an IP datagram, or it could be some OSI network-layer datagram.

By the Way

The PPP RFCs use the term packet to describe a bundle of data transmitted in a PPP frame. A packet can consist of an IP (or other upper-layer protocol) datagram, or it can consist of data formatted for one of the other protocols operating through PPP. The word "packet" is an often-imprecise term used throughout the networking industry for a package of data transmitted across the network; for the most part, this book has attempted to use a more precise term, such as "datagram." Not all PPP data packages, however, are datagrams, so in keeping with the RFCs, this hour uses the term packet for data transmitted through PPP.


PPP must also forward data with information relating to its own protocols: the protocols that establish and manage the modem connection. Communicating devices exchange several types of messages and requests over the course of a PPP connection. The communicating computers must exchange LCP packets, used to establish, manage, and close the connection; authentication packets, which support PPP's optional authentication protocols; and NCP packets, which interface PPP with various protocol suites. The LCP data exchanged at the beginning of the connection configures the connection parameters that are common to all protocols. NCP protocols then configure suite-specific parameters relating to the individual protocol suites supported by the PPP connection.

The data format for a PPP frame is shown in Figure 8.5. The fields are as follows:

  • Protocol A one- or two-byte field providing an identification number for the protocol type of the enclosed packet. Possible types include an LCP packet, an NCP packet, an IP packet, or an OSI Network layer protocol packet. ICANN maintains a list of standard identification numbers for the various protocol types.

  • Enclosed data (zero or more bytes) The control packet or upper-layer datagram being transmitted with the frame.

  • Padding (optional and variable length) Additional bytes as required by the protocol designated in the protocol field. Each protocol is responsible for determining how it will distinguish padding from the enclosed datagram.

Figure 8.5. The PPP data format.

graphics/08fig05.gif

By the Way

If the enclosed data is a datagram of some other protocol suite, it isn't related to TCP/IP, and you won't find it discussed in this book.


PPP Connections

The life cycle of a PPP connection is as follows:

  1. The connection is established using the LCP negotiation process, as described later in this hour.

  2. If the negotiation process in step 1 specifies a configuration option for authentication, the communicating computers enter an authentication phase. RFC 1661 offers the authentication options Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Additional authentication protocols are also supported.

  3. PPP uses NCP packets to specify protocol-specific configuration information for each supported protocol suite (for example, TCP/IP or IPX/SPX).

  4. PPP transmits datagrams received from upper-layer protocols. If the negotiation phase in step 1 includes a configuration option for link quality monitoring, then monitoring protocols will transmit monitoring information. NCP might transmit information regarding specific protocols.

  5. PPP closes the connection through the exchange of LCP termination packets.

Link Control Protocol (LCP)

Much of PPP's power and versatility comes from the LCP functions that establish, manage, and terminate connections. RFC 1661 identifies three types of LCP packets:

  • Link configuration packets

  • Link termination packets

  • Link maintenance packets

Many PPP features that aren't available with SLIP are a result of LCP. Figure 8.6 describes how LCP configuration packets enable the communicating computers to establish a connection. In Figure 8.6, Computer A sends an LCP Configure-Request packet to Computer B. The Configure-Request packet includes a proposal for any connection parameters Computer A would like to negotiate for the connection. These parameters include the Maximum Receive Unit (MRU), the maximum length for the data enclosed in a PPP frame; the authentication protocol; and the quality control protocol, which defines how the connection monitors for reliable delivery, compression protocol settings, and other configuration choices.

Figure 8.6. An LCP connection configuration.

graphics/08fig06.gif

If Computer B accepts all configuration options submitted in the Configure-Request packet, Computer B responds with a Configure-AcK packet (AcK stands for acknowledge). If all configuration options transmitted with the Configure-Request packet are recognizable but some are not acceptable to Computer B, then Computer B responds with a Configure-NaK packet (NaK stands for not acknowledged) and returns a list of unacceptable parameters with alternative values. Computer A then responds to the Configure-NaK with a new configuration request using adjusted values. This process continues until all values are accepted.

If the Configure-Request packet includes unrecognizable options, Computer B returns a Configure-Reject packet, which lists any unacceptable options.

Figure 8.7 shows the format for an LCP packet. Several other types of LCP packets assist with overseeing the modem connection. The Code field in Figure 8.7 identifies the LCP packet type. The Identifier field identifies the packet and helps to match up requests with acknowledgments. The Length field is the length of the packet. The data transmitted with the packet depends on the type of packet. A list of LCP packet type codes is shown in Table 8.1.

Figure 8.7. LCP packet format.

graphics/08fig07.gif

Table 8.1. LCP Packet Type Codes

Code

Description

1

Configure-Request

2

Configure-AcK

3

Configure-NaK

4

Configure-Reject

5

Terminate-Request

6

Terminate-AcK

7

Code-Reject

8

Protocol-Reject

9

Echo-Request

10

Echo-Reply

11

Discard-Request

As mentioned earlier, LCP tends to maintenance and termination tasks as well as configuration tasks. The Terminate-Request and Terminate-AcK packets are used to request and acknowledge termination of the connection. Code-Reject and Protocol-Reject reject requests for an unknown code or protocol. Echo-Request, Echo-Reply, and Discard-Request provide maintenance, quality assurance, and troubleshooting capabilities.



Sams Teach Yourself TCP/IP in 24 Hours
Sams Teach Yourself TCP/IP in 24 Hours (4th Edition)
ISBN: 0672329964
EAN: 2147483647
Year: 2003
Pages: 259
Authors: Joe Casad

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net