PPP Frame
Format
The NetWare Link/PPP implementation of the PPP specification uses encapsulation methods supporting bit-synchronous and character-asynchronous serial communications links. The links must be full-duplex and can be either dedicated or switched.
PPP uses a variant of HDLC that provides a basic level of transport services for the delivery of data packets. The protocol is characterized by a low-overhead, high-throughput orientation. Error detection is included using the ITU CRC-16 FCS for error detection, but not error recovery, and is compatible with most hardware.
At the Physical layer, PPP works over any asynchronous or synchronous, dedicated or dial-up, full-duplex bit-serial circuit. NetWare Link/PPP supports the use of both types of links and operates across most modems and DTE/DCE interfaces (for example, EIA RS-232, EIA RS-422, EIA RS-423, X.21, and ITU V.35).
Figure 5-5 shows the NetWare Link/PPP frame format. The figure does not include start/stop bits for asynchronous links or any bits/octets for transparency.
Figure 5-5.
PPP Frame
Format
Table 5-6 explains each field of the frame format.
Field |
Description |
|---|---|
Flag |
Single octet indicating the beginning or end of a frame. Used as a frame separator, only one Flag field is required between two frames; two consecutive Flag fields constitute an empty frame, which is ignored. |
Address |
Single octet containing the binary sequence 11111111, the All-Stations address. NetWare Link/PPP does not assign individual station addresses; the use of other address lengths and values might be defined at a later time. Frames with unrecognized addresses are discarded. |
Control |
Single octet containing the Unnumbered Information (UI) command with the p/f bit set to zero. Frames with the Control field containing any other values are discarded. |
Protocol ID |
Two octets specific to PPP identifying the protocol encapsulated in the Information field of the frame. Values in the 0xxx to 3xxx range identify Network-layer protocols; values in the 4xxx to 7xxx range are used for those protocols with low-volume traffic and no associated NCP; values in the 8xxx to Bxxx range identify the associated NCP; values in the cxxx to fxxx range identify the Link Control Protocol (LCP). |
Information |
Zero or more octets containing a datagram from the protocol identified in the Protocol field. The default maximum size is 1,500 octets; however, through negotiation, other values for the maximum Data field length can be used. |
FCS |
Sixteen bits containing the remainder from a cyclic redundancy check (CRC) to detect bit errors. |
For PPP to be versatile and flexible enough to support a wide variety of environments, the LCP is provided. It performs the following functions:
All LCP packets have the same general format, as shown in Figure 5-6.
Figure 5-6.
LCP Packet
Format
Table 5-7 provides a description of each LCP packet field.
Field |
Description |
|---|---|
Code |
One-octet field identifying the type of packet (Configure-Request, Echo-Request, and so on), as shown in the Packet and Code Type column of Table 5-8. |
Identifier |
One-octet field consisting of an incremented number, starting with zero, used to associate requests and replies. Any packet sent in response to a request must contain the same Identifier value as the request. |
Length |
Two-octet field indicating the length of the entire LCP packet. Any additional information (data or configuration options) follows the Length field. |
Data |
Zero or more octets (indicated by the Length field) used for data or configuration options. The actual format of the Data field is set by the Code field value. |
LCP packets are classified into three types, according to their function:
Each LCP packet is described in Table 5-8.
Packet Type |
Packet and Code Type |
Description |
|---|---|---|
Link-Configuration |
Configure-Request (1) |
Sent by a peer attempting to open an LCP connection. Configuration options, such as maximum packet size, asynchronous control characters, type of authentication protocol, and compression type, can also be included in the Options field following the Length field. |
|
Configure-ACK (2) |
Sent when all Configuration options received in a Configure-Request are accepted; indicates successful LCP negotiation. |
|
Configure-NAK (3) |
Sent when all Configuration options received in a Configure-Request are recognized, but the values are not accepted by the receiver. The packet includes only the unaccepted options from the original request, along with values that are acceptable to the receiver. The sending peer can elect to send a new Configure-Request with new Configuration options, or the two sides can negotiate the value for a specific option. |
|
Configure-Reject (4) |
Sent when one or more Configuration options received in a Configure-Request are not recognizable because they are not supported by the receiving side or are not acceptable for negotiation. The packet includes the unacceptable options in the Options field. The sending side can send a new Configure-Request that does not contain the unacceptable options listed. |
Link-Termination |
Terminate-Request (5) |
Sent by the peer wanting to close an LCP connection and, therefore, a PPP link. Any data can be exchanged in the Data field of this packet. |
|
Terminate-ACK (6) |
Sent by the remote peer acknowledging the LCP Terminate-Request. Any data can be exchanged in the Data field of this packet. |
Link-Maintenance |
Code-Reject (7) |
Sent when a peer receives a packet with an unknown or unsupported Code value. A copy of the rejected LCP packet is carried in the Data field. |
|
Protocol-Reject (8) |
Sent when a peer receives a frame with an unknown or unsupported Protocol value, which could be the result of the sending peer attempting to use a protocol not supported by this peer. A copy of the rejected frame's Protocol and Information fields are carried in the Data field. |
|
Echo-Request (9)/ Echo-Reply (10) |
Sent to see whether the other end of a connection is still there. Used as a means to provide a loopback mechanism for debugging, performance testing, link-quality determination, and other functions. |
|
Discard-Request (11) |
Sent to exercise the local-to-remote direction of the data link to aid in debugging, performance testing, and other functions. |
The LCP configuration options allow modifications to the standard characteristics of a PPP link. If a configuration option value is not included in the Configure-Request packet, the default value for that option is used.
Typically, all configuration options work in half-duplex. When negotiated, they apply to only one direction of the link, typically in the receive direction from the point of view of the Configure-Request sender (in other words, the option values the Configure-Request sender proposes for the receiver).
The configuration option format of the LCP packet consists of the following fields, with NetWare Link/PPP default values:
The following section describes each configuration option in more detail.
Sent to inform the peer of the maximum size frame that can be received. If smaller frames are requested, 1,500 octet frames must still be able to be received in case link synchronization is lost. Following is the format for this option:
Type |
Length |
Maximum Receive Unit |
Default |
1 |
4 |
Two-octet field indicating new maximum receive unit. This field covers only the Data-Link layer Information field and does not include header, padding, or FCS. |
1,500 |
Provides negotiation for the use of control character mapping on asynchronous links. Until this option is negotiated, NetWare Link/PPP maps all control characters into an appropriate two-character sequence. It is rarely necessary to map all control characters. This option can be used to inform the peer which control characters must remain mapped and which control characters need not remain mapped when the peer sends them. Until this option is negotiated in the LCP phase, all characters under 0x20 are mapped.
The map is encoded so that each numbered bit corresponds to the ASCII control character of the same value. If the bit is cleared to zero, that ASCII control character need not be mapped. If the bit is set to one, the ASCII control character must remain mapped. Following is the format for this option:
Type |
Length |
ACCM |
Default |
2 |
6 |
Four-octet field indicating the new ACCM |
0x000A0000 |
Provides a method to negotiate the use of a specific authentication protocol. This requires a peer to authenticate itself before allowing any data packets to be exchanged. Authentication can be either full-duplex or half-duplex, and different authentication protocols can be used in each direction, depending on the protocols negotiated. Following is the format for this option:
Type |
Length |
Authentication Protocol |
Default |
3 |
4 or less |
Two-octet field indicating the protocol to be used. Values for this field are the same as the PPP Data-Link layer Protocol field for the same authentication protocol. Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) are the protocols available. The Data field is zero or more octets that can contain additional data, determined by the particular protocol. |
None |
Provides a method to detect loopback links and other Data-Link layer anomalies. If used (negotiated only if the Echo Requests parameter is enabled), when a Configure-Request is received with a magic number, the received magic number is compared with the magic number of the last Configure-Request sent to the peer. If the two are different, then the link is not looped back and the magic number is acknowledged. If the two are equal, it is possible that the link is looped back and that the Configure-Request is actually the one last sent. Following is the format for this option:
Type |
Length |
Magic Number |
Default |
5 |
6 |
Four-octet field indicating a number that is unique to one end of the link. Must have Echo Requests parameter enabled. |
None |
Provides a method to negotiate the compression of the Data-Link layer Protocol field. With low-speed links, you can conserve bandwidth by using the protocol field compression option so that you send as little redundant data as possible. If successfully negotiated, the option can compress the Protocol field to one octet instead of two. However, the Protocol field is never compressed when any LCP packet is sent. Following is the format for this option:
Type |
Length |
Protocol Field Compression |
Default |
7 |
2 |
Two-octet field indicating that protocol field compression can be used |
None |
Provides a method to negotiate the compression of the Data-Link layer Address and Control fields. This option is sent to inform the peer that it can receive compressed Address and Control fields.
On reception, the Address and Control fields are decompressed. If a compressed frame is received when Address and Control field compression has not been negotiated, the frames might be discarded. Following is the format for this option:
Type |
Length |
Protocol Field Compression |
Default |
8 |
2 |
Two-octet field indicating that Address and Control field compression can be used |
None |
The Network Control Protocol (NCP) provides procedures for establishing, configuring, and terminating various network protocols, such as IPX, IP, and AppleTalk. Basic protocol elements are common to all NCPs; however, the configurable parameters of each NCP are specific to the network protocol.
NCP includes a complete set of Network-layer interfaces for negotiating protocols simultaneously over a single link.
Each Network-layer protocol has its own NCP. Each protocol can establish and terminate connections at any appropriate time during the Network-layer protocol phase. The finite state machine used for each NCP is the same as the LCP state machine; however, different NCP options exist for each Network-layer protocol. Each NCP packet has the same format as LCP packets, with specific codes or information specific to each Network-layer protocol. The Network-layer protocol phase is complete when the NCP configuration is negotiated successfully. Completion of this phase allows Network-layer data transfer.
For example, TCP/IP has an NCP called Internet Protocol Control Protocol (IPCP). The Information field of PPP frames carries the IPCP packets. The sending peer initiates an IP connection by sending an IPCP Configure-Request packet, which might include such IP-specific options as the local IP address and an indication that the sending peer wants to use IP header compression. The destination peer either agrees with all options (Configure-ACK), disagrees with some options (Configure-NAK), or does not support some options (Configure-Reject).
When the IPCP connection is established successfully, the two peers can exchange IP datagrams. The Information field of the frame carries the IP datagrams, and the Protocol field contains the IP value of 0021. Once IP data exchange has concluded, the peers can close the IPCP connection by exchanging IPCP Terminate packets.
HDLC framing operates over both bit-synchronous and character- asynchronous data links. Synchronous HDLC performs bit stuffing to ensure that the unique flag sequence never occurs in the frame data, whereas asynchronous HDLC uses character stuffing to ensure that the frame delineation flags remain unique.
Both the Synchronous/+ Adapter and the NW2000 serial interface boards support bit-synchronous and character-asynchronous HDLC framing. Additional support is provided for asynchronous HDLC framing using available NetWare Async I/O (AIO) services. NetWare AIO services allow any AIO-compliant hardware interface to be used to provide asynchronous HDLC framing for NetWare Link/PPP by using the WAN Hardware Specific ModuleTM Asynchronous Input/Output (WHSMAIO) driver. Support for connections over ISDN lines is provided by the CAPI Manager and the WHSMCAPI driver.