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.

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.

PPP Connections

The life cycle of a PPP connection is as follows:

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.

Набор онлайн поисковых сервисов
Сегодня веб стал неплохим источником доходов как для создателей сайтов так и для бизнесменов. Многие творят или заказывают сайты для того чтобы подзаработать в интернете. Но даже если у вашего ресурса замечательный дизайн и он наполнен полезной информацией для людей, он может быть почти незаметен поисковыми роботами в следствие чего иметь небольшую посещаемость. Для того чтобы поменять эту ситуацию вам необходимо использовать поисковую оптимизацию.

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.

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.