EE6364

Point-to-Point Protocol (PPP)

-

Functions performed by PPP

PPP components
PPP operation
PPP protocol format
PAP and CHAP
Multilink PPP
Packet over SONET (POS)

DCCW

PPP-1

EE6364

Functions performed by PPP

PPP is widely used, especially in the analog modem access to the ISP, where
one end is the PC and the other end is the ISP router. The functions performed
are:

The Point-to-Point Protocol (PPP) was designed to transport multi-protocol

packets between two peers connected by simple links.
These links provide full-duplex simultaneous bi-directional operation.

Components of PPP
PPP consists of the following three main components:
A method 1 for encapsulating multi-protocol datagrams. PPP supports either
asynchronous link with 8 bits of data and no parity, or with bit-oriented
synchronous links.
A Link Control Protocol (LCP) for establishing, configuring, and testing the
data-link connection. This allows the two ends to negotiate various link layer
options.
A family of Network Control Protocols (NCPs) 2 for establishing and
configuring different network-layer protocols. This allows the two ends to
negotiate various network layer options.

1. W. Simpson, The Point-to-Point Protocol (PPP), RFC1661, July 1994.

W. Simpson, PPP in HDLC-like Framing, RFC1662, July 1994.
2. G, McGregor, The PPP Internet Protocol Control Protocol (IPCP), RFC1332, May, 1992.

DCCW

PPP-2

EE6364

PPP operation
The operation of PPP is as follows.
Before the two ends can start sending data packets, each end of the PPP link
must first send LCP packets to configure and test the data link. Once the link
has been established, the peer may be authenticated. Then, PPP must send
NCP packets to choose and configure one or more network-layer protocols.
Once each of the chosen network-layer protocols has been configured,
datagrams from each network-layer protocol can be sent over the link.
The link will remain configured for communications until explicit LCP or NCP
packets close the link down, or until some external event occurs (for example, an
inactivity timer expires or network administrator intervention).
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:

Dead

Up

Opened
Establish

Fail

Terminate

Authenticate

Success

Fail

Closing
Network

The link begins with Link-Dead state. When the physical layer is ready for
communication (e.g., two analog modems are connected to each other), PPP will
proceed to the Link Establishment state. The LCP is used to establish the
connection through an exchange of Configure packets. When this is completed, it
enters the LCP OPENED state. Once the OPENED state is reached, the two
peers may Authenticate the other. If authentication is successful, each network
layer protocol must be configured separately by the appropriate NCP.
When these are done, the two ends can begin sending packets. PPP can
terminate the link any time. Either LCP or NCP can be used to close the link.

DCCW

PPP-3

EE6364

The sequence of the PPP operation is illustrated in the following:

Router

User
HEWLETT
Vectra
Office
PACKARD

Configure-Request (LCP)
Configure-ACK (LCP)
Configure-Request IP (NCP)
Configure-ACK IP (NCP)
IP Data Packets
Terminate-Request (LCP)
Terminate-ACK (LCP)

PPP Protocol Format

The PPP framing format is as follows:
Flag
0x7E

Addr
0xFF

Control
0x03

bytes

Information

Protocol
2

Protocol
0xC021
bytes

DCCW

2 or 4

Up to 1500 (default)

Protocol
0x0021

IP datagram (IP header + data)

Code

ID

Protocol
0x8021

Code

ID

Length
2

Length

Flag
0x7E

FCS

Data (options)

Data packet format

LCP format

variable

Data (options)

NCP format

PPP-4

EE6364

Each PPP frame begins and ends with flag (0X7E) bytes. The beginning flag is
followed by an address byte and a control byte. Byte stuffing procedure is used
when any byte other than the flags is 0x7E. The Control Escape octet is defined
as binary 01111101 (hexadecimal 0x7d). The byte stuffing process is as follows:
After FCS computation, the transmitter examines the entire frame between the
two Flag Sequences. Each Flag Sequence and Control Escape octet is replaced
by a two-octet sequence consisting of the Control Escape octet (binary
01111101) followed by the original octet exclusive-or'd with hexadecimal 0x20.
The value of the address field is 0XFF to indicate a broadcast address, and the
value of the control filed is 0X03 to indicate it is an un-numbered frame and has
no flow control. The protocol field indicates the network protocol used for data
transfer, or LCP or NCP. The above figure indicates the network protocol used
for data transfer is IP (0x0021). Examples of other PPP protocol field values are:
Protocol Type
Network Layer Protocols

Network Control Protocols

Link Control Protocol

Assigned
Value
0x0021
0x0023
0x002B
0x003D
0x003F
0x0041
0x004D
0x0057
0x8021
0x8023
0x802B
0x803D
0x803F
0x8041
0x804D
0x8057
0xC021
0xC023
0xC025
0xC02B
0xC02D
0xC223

Protocol
IP V4
OSI network layer protocol
Novell IPX
PPP Multilink Protocol (RFC1990)
NetBIOS
Cisco system
IBM SNA
IP v6
IPv4 control protocol
OSI network layer control protocol
IPX control protocol
Multilink control protocol (RFC1990)
NetBIOS framing control protocol
Cisco system control protocol
IBM SNA control protocol (RFC2043)
IPv6 control protocol
Link control protocol
Password Authentication Protocol
Link quality report
Bandwidth control protocol (RFC2125)
Bandwidth allocation protocol
(RFC2125)
Challenge Handshake Authentication
Protocol

The information field contains the upper layer data and possibly padding. The
FCS field can be CRC16 or CRC32. The length of the FCS can be negotiated
using LCP.

DCCW

PPP-5

EE6364

For LCP and NCP frames, the value in the code field identifies the kind of packet.
The possible values for the code field are
Value
Packet
For both LCP and NCP:
1
Configure-Request
2
Configure-Ack
3
Configure-Nak
4
Configure-Reject
5
Terminate-Request
6
Terminate-Ack
7
Code-Reject
For LCP only:
8
Protocol-Reject
9
Echo-Request
10
Echo-Reply
11
Discard-Request

Functions
Start connection, define and negotiate configuration
Acknowledge Configure-Request received
Negative response to Configure-Request received
Configuration options not recognizable
Close a connection
Acknowledge the reception of Terminate-Request
Unknown code received
Unknown protocol field value received
Loopback for link quality determination
Reply to Echo-Request
Receiver discards the request received

The identifier (ID) field is used to aid in matching requests and replies. When a
packet is received with an invalid identifier, the packet is discarded.
The length field indicates the length of the LCP or NCP packet, including the
code, identifier, length, and the data fields.
The data field in the LCP and NCP packets contains the configuration options.
The format for each option is:

bytes

Type

Length

Data

variable

Type indicates the type of configuration option. Examples of types of options for
LCP are: maximum receive unit (MRU), authentication protocol, quality protocol,
magic number, protocol field compression. Examples of types of options for NCP
are: IP compression protocol, IP address.
Length indicates the length of this option. It includes the type, the length and the
data fields.
The data field contains the data specific to the configuration option.

DCCW

PPP-6

EE6364

Password Authentication Protocol (PAP)

PAP, part of PPP, is a simple authentication protocol. The value in the protocol
field for PAP is 0xC023. PAP involves a two steps process, as following:
1. The user sends an authentication request, which include the username and
password to the server;
2. The server checks the username and the password, and accepts or rejects
the request.

Authentication Request: User Name & Password

User/
Client

Server

Ack or Nak

Three types of packets are used in PAP. They are:

Bytes

DCCW

ID

Length

Message
Length

Message

ID

Length

Message
Length

Message

Nak

Code
3

Variable
Username

Code
2

Protocol
0xC023

Length

Ack

Addr Control
0xFF 0x03

Username
Length

ID

Flag
0x7E
Bytes

Code
Authentication Request
1

Information

1
Password
Length

Variable
Password

FCS
2 or 4

Flag
0x7E
1

PPP-7

EE6364

Challenge Handshake Authentication Protocol (CHAP)

PPP supports a more secure authentication protocol, called challenge
handshake authentication protocol (CHAP). The value of the protocol field is
0xC223.
CHAP involves three steps as follows:

Challenge
User/
Client

Response

Server

Success or Failure

1. The server sends a challenge packet to the user. The packet includes a
challenge value.
2. The user applies a predefined function that involves the challenge value, and
the password and generates a result. The user then sends the result back to
the server.
3. The server checks the results received by applying the predefined function on
the challenge value and the password. The server then responds with a
success or failure.
Four types of packets are used in CHAP. Their formats are:
Bytes

Flag
0x7E
Bytes

DCCW

Challenge Code
1

ID

Length

Challenge
Length

Response

Code
2

ID

Length

Response
Length

Success

Code
3

ID

Length

Failure

Code
4

ID

Length

Addr Control
0xFF 0x03
1

Protocol
0xC223
2

Variable

Variable

Challenge
Value

Username

Response
Value

Username

Message

Message

Information

FCS
2 or 4

Flag
0x7E
1

PPP-8

EE6364

Multi-Link PPP (MLPPP)3

PPP is a point-to-point protocol over a single physical link. If the physical link
speed is slow, the throughput would be slow. To increase the bandwidth between
the two end points, a higher speed link or multiple lower speed links can be used.
Sometimes, a higher speed link is not cost effective. When multiple lower speed
links are used, these links must be coordinated and their bandwidth can be
aggregated. The purpose of the multilink operation is to coordinate multiple
independent links between a pair of the end points, and to provide a virtual link
with greater bandwidth than any of the constituent links.

End
Point

End
Point

Multilink PPP is based on an LCP option negotiation that permits an end point to
indicate to its PPP peer that it is capable of combining multiple physical links into
a "bundle". Multilink is negotiated during the initial LCP option negotiation. A PPP
end point indicates to its peer that it is willing to do multilink by sending the
multilink option as part of the initial LCP option negotiation.
Before transmission, the transmitting end point fragments the upper layer data
and encapsulated in one of the formats shown below:
B it 0

A ddress 0x ff

15

C ontrol 0x 03

P rotocol ID (0x 003d)

B E 0 0 0 0 0 0

S equen ce N um b er

S equen ce N um b er

Fragm ented D ata

L on g S equ en ce N um b er Form at
3 K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, The PPP Multilink Protocol (MP),
RFC 1990, August 1996.

DCCW

PPP-9

EE6364

B it 0

A ddress 0xff

15

C ontrol 0x03

Protocol ID (0x003d)
B E 0 0

Sequence N um ber

Fragm ented D ata

Short Sequence N um ber Form at

The B (beginning fragment) bit is a one bit field set to 1 on the first fragment
derived from a PPP packet and set to 0 for all other fragments from the same
PPP packet. The E (ending fragment) bit is a one bit field set to 1 on the last
fragment and set to 0 for all other fragments.
The format used is negotiated during the LCP negotiation. The fragmented data
are then transmitted simultaneously over the multilinks.
The receiving end point receives the fragmented data from multiple links. It then
reassembles the data based on the sequence numbers.

DCCW

PPP-10

EE6364

Packet over SONET4

The initial deployment of PPP (RFC 1661) has been over lease lines or POTS
modems. Since this protocol has been widely deployed, many other physical
layers have been defined and used. One physical layer that has been specified is
SONET or Synchronous Digital Hierarchy (SDH). It is called packet over
SONET/SDH, or POS. RFC 1619 defines PPP over SONET OC3. It has been
expanded to include higher speed (e.g., OC12c, OC48, etc.) and updated by
RFC 2615.
In POS, the IP packet is first encapsulated by PPP format. The octet stream of
the PPP frame is then mapped into the SONET SPE, with the octet boundaries
aligned with the SONET SPE octet boundaries. Scrambling of payload is
performed during insertion of the PPP frame into the SONET SPE to provide
adequate transparency. For backwards compatibility with RFC 1619 (OC-3 only),
the scrambler MAY have an on/off capability where the scrambler is bypassed
entirely when it is in the off mode. If this capability is provided, the default MUST
be set to scrambling enabled. The C2 byte in the SONET payload overhead
indicates whether scrambling is used or not. For PPP over SONET/SDH, the
entire SONET/SDH payload is scrambled.
When OC3 is used, the FCS may be CRC16. Other speeds use CRC32 (four
bytes).

4 W. Simpson, PPP over SONET/SDH, RFC 1619, May 1994.

A Malis and W. Simpson, PPP over SONET/SDH, RFC 2615, June 1999.

DCCW

PPP-11