Table of Contents
PPP (Point-to-Point Protocol) is a protocol for communication between two computers using a serial interface, typically a personal computer connected by phone line to a server. 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. Relative to the Open Systems Interconnection (OSI) reference model, PPP provides layer 2 (data-link layer) service.
PPP enables to connect computers and networks at separate physical locations by using modems and telephone lines. With PPP, users with computers at home or in remote offices can connect to site's network. You can also use the combination of PPP software, a modem, and telephone lines as a router connecting networks in different places. PPP offers strategies for configuring these machines and networks. 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. A list of the pertinent RFCs follows.
RFC 1220 - PPP Extensions for Bridging
RFC 1332 - PPP Internet Protocol Control Protocol (IPCP)
RFC 1333 - PPP Link Quality Monitoring
RFC 1334 - PPP Authentication Protocols (PAP and CHAP)
RFC 1376 - PPP DECnet Phase IV Control Protocol (DNCP)
RFC 1378 - PPP AppleTalk Control Protocol (ATCP)
RFC 1471 - Managed Objects for the LCP of the PPP
RFC 1472 - Managed Objects for the Security Protocols
of the PPP
RFC 1473 - Managed Objects for the IPCP of the PPP
RFC 1474 - Managed Objects for the BCP of the PPP
RFC 1549 - PPP in HDLC framing
RFC 1552 - PPP Internetwork Packet Exchange Control Protocol
(IPXCP)
RFC 1570 - PPP LCP Extensions
RFC 1618 - PPP over ISDN
RFC 1661 - PPP obsoletes RFC 1171, 1172, 1548 and RFC
1331
RFC 1717 - PPP Multilink Protocol (MP)
RFC 1717 - Multilink
RFC 1934 - Multilink Plus
RFC 1962 - Control Compression Protocol (CCP)
Point-to-Point Communications Links
The most common use of PPP is to set up a point-to-point
communications link. 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. In a generic configuration, 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.
The three main components of PPP are the encapsulation scheme, the Link Control Protocol, and the Network Control Protocols. These components are responsible for creating the frame, controlling the link, and managing the network layer protocol respectively.
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 fraiming to indicate
the beginning and end of the encapsulation. This figure shows the format
of PPP frames:
PROTOCOL field : 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).Thisx field is one or
two bytes. INFORMATION FIELD : this field contains the datagram for the
protocol specified in the PROTOCOL field.This field is zero or more bytes.
PADDING FIELD : on transmission the INFORMATION field may be padded with
any number of bytes up to 1500 bytes.
The second component of PPP is the Link Control Protocol (LCP), which operates at the data link layer to manage communication functions. In addition to providing procedures for establishing, configuring, testing, and terminating data link connections, LCP also negotiates other non-default LCP options such as Maximum Receive Unit (MRU) and Magic Number. MRU defines the optimal packet size for both ends of the serial link which increases the transmission efficiency of the link. Magic Number identifies each peer so loopback conditions can be recognized and corrected. LCP, using a phase process, 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:
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 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.
Following is description of each automaton state.
Initial - the 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 is not 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 has not yet been
received.
Opened
In the Opened state, a Configure-Ack has been both sent
and received. The Restart timer is not running.
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. Futher 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.
There are also the next events: 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.
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.
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.
+------------------------------------------------------------+
| Code | Identifier | Length | Data ...
+------------------------------------------------------------+
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
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.
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.
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.
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.
+----------------------------------------------------------------------+
|Code |Identifier |Length |Magic Number | Data...
+----------------------------------------------------------------------+
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...
+------------------------------------------------------------+
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
The Length field is one octet, and indicates the length of this Configuration Option including the Type, Length and Data fields. 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.
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
|
+-----------------------------+
RFC
1661 The Point-to-Point Protocol (PPP)
Point-to-Point Protocol
TCP/IP Illustrated, volume1 by W. Richard Stevens.
http://www.cisco.com/cc/td/doc