Point-to-Point Protocol
Table of Contents:
The
Option Negotiation Automaton
Link
Control Protocol (LCP) Packet Formats
Description
of some LCP packets
Link
Control Protocol (LCP) Configuration Options
Description
of some Configuration Options
Introduction
PPP
(Point-to-Point Protocol) is a protocol for communication over point-to-point links,
typically between a personal computer and a server which are connected by a
phone line. These links provide full-duplex simultaneous bi-directional
operation, and are assumed to deliver packets in order. A generic
point-to-point communications configuration consists of two endpoints connected
by a communications link. An endpoint system could be a computer or terminal,
either in an isolated location or physically connected to a network. The term
communications link refers to the hardware and software connecting these
endpoint systems. Basic Point-to-Point Link illustrates these concepts:
Another use
PPP is to connect two separate networks through a point-to-point link, with one
system on each network serving as an endpoint. These endpoints communicate
through modems and phone lines, essentially in the same fashion as shown in
Basic Point-to-Point Link. But in this setup, the endpoints, modems, and PPP
software become routers for their physical networks. Using this type of
configuration scheme, you can create an internetwork with wide geographic
reach.
According to
the Open Systems Interconnection (OSI) reference model, PPP provides data-link
layer (layer 2) service.
PPP uses
the Internet protocol (IP) (and is designed to handle others). It is sometimes
considered a member of the TCP/IP suite of protocols.
PPP is a
full-duplex, bit-oriented protocol that can run over synchronous or
asynchronous links. PPP uses a variant of High Speed Data Link Control (HDLC)
as the basis for encapsulation. Links may be dedicated or circuit-switched, and
PPP can work over copper, fiber optic, microwave, or satellite leased lines.
PPP provides data error detection while higher layer protocols are responsible
for error recovery.
PPP is
usually preferred over the earlier de facto standard Serial Line Internet
Protocol (SLIP) because it can handle synchronous as well as asynchronous
communication. PPP can share a line with other users and it has error detection
that SLIP lacks. Where a choice is possible, PPP should be preferred.
PPP is a
recommended standard of the Internet Advisory Board (IAB) and is represented by
a number of RFCs (Request for Comments) produced by the Point-to-Point Protocol
Working Group.
PPP Components
PPP has three main components: 1. Encapsulation scheme - a method for encapsulating multi-protocol datagrams to a frame. 2. Link Control Protocol (LCP) - a protocol for establishing, configurating and testing the data-link connection. 3. Network Control Protocols (NCPs) - a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
Encapsulation
The PPP encapsulation provides for multiplexing of
different network-layer protocols simultaneously over the same link. Standard
encapsulation schemes exist for the transmission of datagrams over most Local
Area Networks (LANs) such as Ethernet, Token Ring, ARCnet, and FDDI. In the
past, the only Wide Area Network (WAN) encapsulation scheme that provided a
standard for the transmission of datagrams was X.25. The introduction of new
WAN schemes such as Frame Relay expanded the variety of encapsulation schemes
available. However, the majority of LAN-to-LAN traffic is still carried over
dedicated leased lines.
The introduction of PPP allows these existing
proprietary leased lines the opportunity to convert to a new encapsulation
scheme that gives the user the true interoperability that traditionally could
only be found on LANs. The encapsulation requires framing to indicate the beginning
and end of the encapsulation.
PPP frames' format :
|
Protocol |
Information |
Padding |
|
2 Bytes |
variable |
* |
|
PROTOCOL |
Its value identifies the datagram encapsulated in the
INFORMATION field of the packet ( for example a value of 0x0021 means the
INFORMATION field is an IP datagram, a value of 0xc021 means the INFORMATION
field is link control data and so on).This field is one or two bytes. |
|
INFORMATION |
This field contains the datagram for the protocol
specified in the PROTOCOL field. This field is zero or more bytes. |
|
PADDING |
On transmission the INFORMATION field may be padded
with any number of bytes up to 1500 bytes. |
Link Control Protocol
The second component of PPP is the Link Control
Protocol (LCP), which operates at the data link layer to manage communication
functions. LCP establishes the link between two PPP peers and negotiates
configuration options. Some phases are necessary to establish communications
(such as link establishment phase, link termination phase) and some are
optional and completely dependent on the PPP implementations at both ends of
the link.
The LCP management functions do the following:
·
Determine encapsulation format
options
·
Negotiate optimal packet size by
implementing the MRU (Maximum Receive Unit) process. MRU defines the optimal
packet size for both ends of the serial link which increases the transmission
efficiency of the link
·
Negotiate Magic Number, which
identifies each peer so loopback conditions can be recognized and corrected.
·
Terminate the link
·
Authenticate the identity of the
peer on the link (optional)
·
Negotiate PPP Multilink
·
Data Compression (optional)
·
Link quality monitoring (optional)
First, each end of PPP must send the LCP (Link
Control Protocol) packet to establish communications over a point-to-point
link. After the link has been established, PPP sends NCP (Network Control
Protocol) to configure the network-layer protocols.
Phases
In the process of configuring, maintaining and terminating the point-to-point link, the PPP link goes through several distinct phases, which are specified in the following simplified state diagram:
·
Link Dead - Link
necessarily begins and ends with this phase. At this phase the physical-layer
is not ready. If there's an event which indicates that the physical-layer is
ready to be used, PPP proceeds to the next phase.
·
Link Establishment Phase - During
this phase each end of the PPP link must send LCP packets to configure and test
the data link.
·
Authentication Phase - This
phase is optional. Only Link Control Protocol, Authentication Protocol and
quality monitoring packets are allowed during this phase. Authentication takes
place after link establishment and before Network-Layer Protocol Phase. If Authentication
fails, the authenticator should proceed instead to the Link Termination Phase
·
Network-Layer Protocol Phase - During
this phase each network-layer protocol must be configured by the appropriate
Network Control Protocol (NCP) through an exchange of NCP packets.
·
Link Termination Phase - PPP can
terminate the link at any time. In order to close the link, LCP is used to
terminate the link through an exchange of Terminate packets. Following the exchange
of Terminate packets, the implementation can signal the physical-layer to
disconnect.
Network Control Protocols
The last key component of PPP is the Network Control Protocols
(NCPs). NCPs are a series of independently-defined protocols that encapsulate
network layer protocols such as TCP/IP, DECnet, AppleTalk, IPX, XNS, and OSI.
Each NCP has individual requirements for addressing and advertising
connectivity for its network layer protocol. Each NCP is defined in a separate
RFC. Future protocols can be supported by defining new NCPs.
The Option Negotiation Automaton
The finite-state automaton is defined by events,
actions and state transitions. Events include reception of external
commands such as Open and Close, expiration of the Restart timer, and reception
of packets from a peer. Actions include the starting of the Restart timer
and transmission of packets to the peer.
States
Following is description of each automaton state.
|
State |
Description |
|
Initial |
Lower layer is unavailable (Down), and no Open
has occurred. The Restart timer is not running in the this state |
|
Starting |
The Starting state is the Open counterpart to the
Initial state. The lower layer is still unavailable (Down). The
Restart timer isn't running in the Starting state. When the lower layer
becomes available (Up), a Configure-Request is sent. |
|
Closed |
The link is available (Up), but no Open has
occurred. The Restart timer is not running in the Closed state. Upon
reception of Configure-Request packets, a Terminate-Ack is sent.
Terminate-Acks are silently discarded to avoid creating a loop. |
|
Stopped |
The Stopped state is the Open counterpart to the
Closed state. It is entered when the automaton is waiting for a
Down event after the This-Layer-Finished action, or after sending a
Terminate-Ack. The Restart timer is not running in the Stopped state. |
|
Closing |
An attempt is made to terminate
the connection. A Terminate-Request has been sent and the
Restart timer is running, but a Terminate-Ack has not yet been received.
|
|
Stopping |
The Stopping state is the Open counterpart to the
Closing state. A Terminate-Request has been sent and the Restart timer
is running, but a Terminate-Ack has not yet been received. |
|
Request-Sent |
In the Request-Sent state an attempt is made to
configure the connection. A Configure-Request has been sent and
the Restart timer is running, but a Configure-Ack has not yet been received
nor has one been sent. |
|
Ack-Received |
In the Ack-Received state, a Configure-Request has
been sent and a Configure-Ack has been received. The Restart timer
is still running, since a Configure-Ack has not yet been sent. |
|
Ack-Sent |
In the Ack-Sent state, a Configure-Request and a
Configure-Ack have both been sent, but a Configure-Ack has not yet been
received. The Restart timer is running, since a Configure-Ack hasn't
yet been received. |
|
Opened |
In the Opened state, a Configure-Ack has been both
sent and received. The Restart timer is not running. |
Events
Transitions and actions in the automaton are caused by
events.
|
Event |
Description |
|
Up |
This event occurs when a lower layer indicates that it
is ready to carry packets. |
|
Down |
This event occurs when a lower layer indicates that
it is no longer ready to carry packets. |
|
Open |
This event indicates that the link is
administratively available for traffic; that is, the network administrator
(human or program) has indicated that the link is allowed to be Opened.
When this event occurs, and the link is not in the Opened state, the
automaton attempts to send configuration packets to the peer. |
|
Close |
This event indicates that the link is not available
for traffic; that is, the network administrator (human or program)
has indicated that the link is not allowed to be Opened. When
this event occurs, and the link is not in the Closed state,
the automaton attempts to terminate the connection. Further
attempts to re-configure the link are denied until a new Open event occurs. |
|
Timeout (TO+,TO-) |
This event indicates the expiration of the Restart
timer. The Restart timer is used to time responses to
Configure-Request and Terminate-Request packets. The TO+ event
indicates that the Restart counter continues to be greater than zero,
which triggers the corresponding Configure - Request or
Terminate-Request packet to be retransmitted. The TO- event indicates that
the Restart counter is not greater than zero, and no more packets need
to be retransmitted. |
|
Receive-Configure-Request (RCR+,RCR-) |
This event occurs when a Configure-Request packet is
received from the peer. The Configure-Request packet indicates the
desire to open a connection and may specify Configuration Options.
The Configure-Request packet is more fully described in a later
section. The RCR+ event indicates that the Configure-Request
was acceptable, and triggers the transmission of a corresponding Configure-Ack.
The RCR- event indicates that the Configure-Request was unacceptable,
and triggers the transmission of a corresponding Configure-Nak or
Configure-Reject. |
|
Receive-Configure-Ack (RCA) |
This event occurs when a valid Configure-Ack packet is
received from the peer. The Configure-Ack packet is a positive
response to a Configure-Request packet. An out of sequence or
otherwise invalid packet is silently discarded. |
|
Receive-Configure-Nak/Rej |
This event occurs when a valid Configure-Nak
or Configure-Reject packet is received from the peer. |
|
Receive-Terminate-Request |
This event occurs when a Terminate-Request packet
is received. |
|
Receive-Terminate-Ack |
This event occurs when a Terminate-Ack packet is
received from the peer. |
|
Receive-Unknown-Code |
This event occurs when an un-interpretable
packet is received from the peer. A Code-Reject packet is sent in
response. |
Actions in the automaton are caused by events and typically
indicate the transmission of packets and/or the starting or stopping of
the Restart timer.
|
Action |
Description |
|
Illegal-Event(-) |
This indicates an event that cannot occur in a
properly implemented automaton. |
|
This-Layer-Up (tlu) |
This action indicates to the upper layers that the
automaton is entering the Opened state. |
|
This-Layer-Down (tld) |
This action indicates to the upper layers that the
automaton is leaving the Opened state. |
|
This-Layer-Started (tls) |
This action indicates to the lower layers that the
automaton is entering the Starting state, and the lower layer is needed
for the link. The lower layer should respond with an Up event when the
lower layer is available. |
|
This-Layer-Finished (tlf) |
This action indicates to the lower layers that the
automaton is entering the Initial, Closed or Stopped states, and the
lower layer is no longer needed for the link. The lower layer
should respond with a Down event when the lower layer has terminated. |
|
Initialize-Restart-Count (irc) |
This action sets the Restart counter to the
appropriate value (Max-Terminate or Max-Configure). The counter
is decremented for each transmission, including the first. |
|
Zero-Restart-Count (zrc) |
This action sets the Restart counter to zero. |
|
Send-Configure-Request (scr) |
A Configure-Request packet is transmitted.
This indicates the desire to open a connection with a specified set of
Configuration Options. The Restart timer is started when the Configure-Request packet
is transmitted, to guard against packet loss. The Restart counter
is decremented each time a Configure-Request is sent. |
|
Send-Configure-Ack (sca) |
A Configure-Ack packet is transmitted. This
acknowledges the reception of a Configure-Request packet with an
acceptable set of Configuration Options. |
|
Send-Configure-Nak (scn) |
A Configure-Nak or Configure-Reject packet is
transmitted, as appropriate. This negative response reports the
reception of a Configure-Request packet with an unacceptable set of
Configuration Options. |
|
Send-Terminate-Request (str) |
A Terminate-Request packet is transmitted.
This indicates the desire to close a connection. The Restart timer
is started when the Terminate-Request packet is transmitted, to guard
against packet loss. The Restart counter is decremented each time
a Terminate-Request is sent. |
|
Send-Terminate-Ack (sta) |
A Terminate-Ack packet is transmitted. This
acknowledges the reception of a Terminate-Request packet or otherwise serves
to synchronize the automatons. |
|
Send-Code-Reject (scj) |
A Code-Reject packet is transmitted. This
indicates the reception of an unknown type of packet. |
|
Send-Echo-Reply (ser) |
An Echo-Reply packet is transmitted. This
acknowledges the reception of an Echo-Request packet. |
Counters and Timers
Restart Timer is used to time transmissions of
Configure-Request and Terminate-Request packets. Expiration of the Restart
Timer causes a Timeout event, and retransmission of the packets. The Restart
Timer must be configurable, but should default to 3 second.
Max-Terminate is one required restart counter for
Terminate-Requests. Max-Terminate indicates the number of Terminate-Request
packets sent without receiving a Terminate-Ack before assuming that the peer is
unable to respond. Max-Terminate must be configurable, but should default
to 2 transmissions.
Max-Configure is a similar counter for
Configure-Requests.
Link Control Protocol (LCP) Packet
Formats
There are three classes of LCP packets
·
Link Configuration packets used to
establish and configure a link (Configure-Request, Configure-Ack, Configure-Nak
and Configure-Reject).
·
Link Termination packets used to
terminate a link (Terminate- Request and Terminate-Ack).
·
Link Maintenance packets used to
manage and debug a link (Code-Reject, Protocol-Reject,
Echo-Request, Echo-Reply, and Discard-Request).
A summary of the Link Control Protocol packet format
is shown below.
+------------------------------------------------------------+
| Code | Identifier | Length | Data ...
+------------------------------------------------------------+
Code Field
The Code field is one octet, and identifies the kind
of LCP packet. When a packet is received with an unknown Code field, a
Code-Reject packet is transmitted.
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
Identifier Field
The Identifier field is one octet, and aids in
matching requests and replies. When a packet is received with an invalid
Identifier field, the packet is silently discarded without affecting the
automaton.
Length Field
The Length field is two octets, and indicates the
length of the LCP packet, including the Code, Identifier, Length and
Data fields. The Length MUST NOT exceed the MRU of the link.
Data field
The Data field is zero or more octets, as indicated by
the Length field. The format of the Data field is determined by the Code
field.
Description of LCP packets
Configure-Request
An implementation wishing to open a connection must transmit a
Configure-Request. The Options field is filled with any desired changes to
the link defaults. Configuration Options should not be included with
default values. Upon reception of a Configure-Request, an appropriate reply
must be transmitted. The packet has code, identifier, length, options fields.
Configure-Ack
If every Configuration Option received in a Configure-Request is recognizable
and all values are acceptable, then the implementation must transmit a
Configure-Ack. The acknowledged Configuration Options must not be reordered or
modified in any way. The packet has code, identifier, length, options fields.
Configure-Nak
If every instance of the received Configuration Options is recognizable, but
some values are not acceptable, then the implementation must transmit a
Configure-Nak. The Options field is filled with only the unacceptable
Configuration Options from the Configure-Request. All acceptable
Configuration Options are filtered out of the Configure-Nak, but otherwise the
Configuration Options from the Configure-Request must not be reordered.
Configure-Reject
If some Configuration Options received in a Configure-Request are not
recognizable or are not acceptable for negotiation (as configured by a network
administrator), then the implementation must transmit a Configure-Reject.
Terminate-Request and Terminate-Ack
LCP includes Terminate-Request and Terminate-Ack Codes in order to provide a
mechanism for closing a connection.
Discard-Request
LCP includes a Discard-Request Code in order to provide a Data Link Layer sink
mechanism for use in exercising the local to remote direction of the
link. This is useful as an aid in debugging, performance testing, and for
numerous other functions. Discard-Request packets must only be sent in the LCP
Opened state. On reception, the receiver must silently discard any Discard- Request
that it receives.
Link Control Protocol (LCP) Configuration Options
LCP Configuration Options allow negotiation of
modifications to the default characteristics of a point-to-point link. If
a Configuration Option is not included in a Configure-Request packet, the
default value for that Configuration Option is assumed. The end of the
list of Configuration Options is indicated by the Length field of the LCP
packet. A summary of the Configuration Option format is shown below.
+------------------------------------------------------------+
| TYPE | LENGTH | DATA...
+------------------------------------------------------------+
Type Field
The Type field is one octet, and indicates the
type of Configuration Option.
0 RESERVED
1 Maximum-Receive-Unit
3 Authentication-Protocol
4 Quality-Protocol
5 Magic-Number
7 Protocol-Field-Compression
8 Address-and-Control-Field-Compression
Length Field
The Length field is one octet, and indicates the
length of this Configuration Option including the Type, Length and Data fields.
Data Field
The Data field is zero or more octets, and contains information
specific to the Configuration Option. The format and length of the Data
field is determined by the Type and Length fields.
Configuration Options
Description
Maximum-Receive-Unit (MRU)
This Configuration Option may be sent to inform the
peer that the implementation can receive larger packets, or to request that the
peer send smaller packets. The default value is 1500 octets. If smaller packets
are requested, an implementation must still be able to receive the full 1500
octet information field in case link synchronization is lost.
Quality-Protocol
Sometimes we want to determine when and how often the
link is dropping data. This process is called link quality monitoring. The
implementation sends the Configure-Request and indicates that it expects to
receive monitoring information. An implementation receiving a Configure-Ack
should expect the peer to send the acknowledged protocol.
+----------------------------------------------------------------------+
|Type | Length | Quality-Protocol | Data ...
+----------------------------------------------------------------------+
The Quality-Protocol field is two octets, and
indicates the link quality monitoring protocol desired. Values of the
Quality-Protocol field are specified in the most recent "Assigned
Numbers" RFC [2].
Magic-Number
This is a method to detect looped-back links. Before
this Option is requested, an implementation must choose its Magic-Number.
This number is chosen in the random manner in order to guarantee with very high
probability that an implementation will arrive at a unique number.
When a Configure-Request is received with a Magic-Number Configuration Option,
the received Magic-Number is compared with the Magic-Number of the last
Configure-Request sent to the peer. If the two Magic-Numbers are different,
then the link is not looped-back, and the Magic-Number should be acknowledged,
else it is possible that the link is looped-back. To determine this, a
Configure-Nak must be sent specifying a different Magic-Number value. A new
Configure-Request should not be sent to the peer until normal processing
would cause it to be sent (that is, until a Configure-Nak is received or
the Restart timer runs out).
Protocol-Field-Compression (PFC)
This is a method to negotiate the compression of the
PPP Protocol field. PPP Protocol field numbers are chosen such that some values
may be compressed into a single octet form which is clearly distinguishable
from the two octet form. This Configuration Option is sent to inform
the peer that the implementation can receive such single octet Protocol fields.
When a Protocol field is compressed, the Data Link Layer FCS field is
calculated on the compressed frame, not the original uncompressed frame.
Address-and-Control-Field-Compression
(ACFC)
This Configuration Option provides a method to
negotiate the compression of the Data Link Layer Address and Control field. If
a compressed frame is received when Address-and-Control-Field-Compression has
not been negotiated, the implementation may silently discard the
frame. When the Address and Control fields are compressed, the Data Link
Layer FCS field is calculated on the compressed frame, not the original
uncompressed frame.
+-----------------------------+
| Type | Length |
+-----------------------------+
References
RFC 1661 - The
Point-to-Point Protocol (PPP)
TCP/IP Illustrated, volume1 by W. Richard Stevens.