Data Network Resource
       Earn on the Web

Point to Point Protocol (PPP)


PPP is based on the High-Level Data link Control (HDLC) protocol and provides a standard for sending data over DTE and DCE interfaces such as V.35, T1, E1, HSSI, EIA-232-D, EIA-449. It replaces Serial Line Internet Protocol (SLIP) which uses a variation of TCP/IP and is not as complicated. PPP allows multiple protocols per line, error detection, header compression, compression and multilinks. PPP has two components:
  • Link Control Protocol (LCP): LCP (RFC 1570 describes LCP extensions) opens, configures and terminates the link. Additionally, Link Quality Monitoring (LQM) can be configured along with Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP).
  • Network Control Protocol (NCP): NCP opens, configures and terminates network layer protocol communication e.g. IP, IPX, AppleTalk and DECnet.
Both LCP and NCP operate at Layer 2. There is an extension to PPP to cater for multiple links and this is called Multilink PPP (MPPP) and uses Multilink Protocol (MLP) to link the LCP and NCP layers.

RFC 1661 describes PPP in general.

Frame Format

The PPP frame format is detailed below:

PPP header

There are five phases for a PPP link:
  • Dead:
  • Establish: Initialises LCP and when Configure ACK is received we move to...
  • Authenticate: Optional use of PAP or CHAP.
  • Network: Supported Network Layer protocols are brought up and data transfer starts.
  • Terminate:
Piggyback routing can be used, where routing information is cached and only sent when the link is up.

In the LCP packet (contained within the Information field of the PPP packet), the Code field will identify the packet as a Configure Request (1), Configure Ack (2), Configure Nak (3) meaning unacceptable and Configure Reject (4).

There is an NCP code for each protocol, and these are identified in the protocol field of the NCP packet as shown below:

Code Protocol
8021 IP
8029 AT
8025 XNS, Vines
8027 DECnet
8031 Bridge
8023 OSI

RFC 1662 describes the HDLC-like framing and RFC 1549 describes PPP in HDLC framing.


Password Authentication Protocol (PAP)

At the LCP phase, when a PPP connection is requested by the client and PAP is being used, the access server tells the client to use PAP. The client then sends a username and a password, both of which are in clear text within the PPP packet. The server then decides whether to accept or reject the connection. This is One-way PAP between a client and a server. If two routers are talking to each other then Two-way PAP is used where each router sends its username and password, and each router authenticates each other.

Challenge Handshake Protocol (CHAP)

CHAP is more commonly used rather than PAP, since it encrypts the password as well as the data.


Each end of the link share the same CHAP secret and each end is given its own local name.
  • A caller A dials in to an access server B.
  • The Access server sends across the link an initial Type 1 authentication packet called a Challenge. This Challenge packet contains a randomly generated number, an ID sequence number to identify the challenge and the authentication name of the challenger.
  • The caller takes the authentication name and looks up the CHAP secret associated with that name.
  • The caller feeds the CHAP secret, the ID sequence number and the randomly generated number into the Message Digest 5 (MD5) hashing algorithm.
  • The resultant hashed value is sent back to the Challenger (the Access server) in a CHAP Response packet (Type 2) which contains the hash, the authentication name of the caller and the ID (Sequence Number) copied from the Challenge packet.
  • On receipt of the Type 2 Response packet, the Challenger uses the ID to find the original Challenge packet.
  • The caller username (A) is used to look up the CHAP secret from a local database, a RADIUS or a TACACS+ server.
  • The ID, the original Challenge random value and the CHAP secret are fed into the MD5 hash generator.
  • The resultant hashed value is then compared with the value sent in the Response packet.
  • If they are the same, then CHAP authentication has been successful and Type 3 packets are sent to the caller containing the ID. This means that the authenticated link is 'legal'.
  • On CHAP authentication failure, a Type 4 packet is sent to the caller containing the original ID, this indicates that the authentication is incorrect.
Hashing is different from encryption as it is not reversible, like a grinder! In Nortel Networks routers Code C223 indicates a CHAP operation.

RFC 1994 describes CHAP in detail whereas RFC 1334 describes Authentication Protocols.

PPP Callback

Callback is useful for minimising costs and security. The processes that occur are as follows:
  1. Initiation of call by client. The client requests callback as one of the options during the LCP negotiation phase (The Callback Option Message Field defined in RFC 1570).
  2. Callback request is acknowledgement by server and it checks its configuration to see if it is allowed.
  3. User authentication occurs and the client username is used in the dialer map to identify the dial string to be used in the return call.
  4. If authentication is successful but there is no callback option then the call continues and the client pays for the call, otherwise the call is disconnected by server.
  5. Client called by the server using the dial string.
  6. Authentication occurs again.
  7. The connection continues.
Ideally, for maximum security the call back should occur on a different modem at the server end from the line used by the incoming call. When using ISDN callback uses the D-channel which incurs no charge at all, whereas callback using modems will always incur a small charge whilst the authentication process occurs.

Link Quality Monitoring (LQM)

This may only be implemented on standard synchronous links. Link quality is based on the percentage of successfully transmitted or received frames within a reported period. These Link Quality Reports (LQR) have counters which determine inbound and outbound link quality. Echo Requests are also periodically sent, if, after a certain number of echo requests, there have been no echo replies, then the NCPs are terminated.

RFC 1333 describes Link Quality Monitoring.


Software compression can come in the form of utilities such as Wellfleet Compression Protocol (WCP) (as used in Nortel Networks routers) and is best used on slow links (128Kb/s or less). The Lempel-Ziv (LZS) (RFC 1974) algorithm provides fast data compression and decompression. This is used by STAC compression and you will find it used on PPP, ISDN and Frame Relay. In addition, PKZIP uses the deflate algorithm so you obtain no benefit from sending ZIP files down an already compressed link, in fact there will a slight increase in packet size. The algorithm works by by first searching for redundant data strings, then replacing these with tokens. A dictionary of these tokens is built up at each end of the link.

Although all layer 3 data (IPCP and IPXCP) is subject to compression, Layer 2 LCP and NCP traffic is exempt. WCP compression can only occur between two Nortel routers as the WCP puts a protocol value in the protocol field that is proprietory to Nortel Networks.

A history buffer works at both ends to match strings of data being sent and received, so if a match in the transmission end buffer is found, then the offset and length of the data is sent instead of the actual data itself. The receiving end appropriately places the matched data into the incoming message and so this minimises data transmission.

Nortel have two compression modes available:
  • Continuous Packet Compression: The history buffer spans multiple packets, which means more memory is used up, but produces greater compression ratio.
  • Packet-by-Packet Compression: The history buffer is reset with each packet, which means less memory is used but the compression ratio is not as great.
Cisco, on the other hand use their own two forms of compression:
  • Stacker - which examines the data and only sends each data type once and sends information indicating to the other end where each type occurs within the data stream. The other end reassembles the data into the various data types from the data stream. Stacker tends to be more CPU intensive and less memory intensive.
  • Predictor - examines the data to see if it is already compressed and sends it. It does not waste time compressing data that is already compressed. Predictor tends to be more memory intensive and less CPU intensive.
Compressing data that is already compressed adds a little overhead to the frames so in fact the data exapnds slightly purely due to the header. In addition, applying compression unnecessarily adds CPU processing which is not required.

Multilink PPP Interleaving

LCP has a number of options, one of which is multilink with interleaving. For multilink PPP to work, PPP packets can be fragmented and marked with sequence numbers so that large packets can be split across a number of PPP links. This is built in to the PPP specifications in RFC 1717 and happens to be useful for real time data traffic such as voice even if you are using PPP as the transport across just one link.

A large data frame is split up into smaller fragments, each one having a small header with its own sequence number. Small Real time data packets are not fragmented and remain as 'naked' PPP. The receptor of these fragmented packets needs to utilise a queue that can hold the fragments long enough to be able to re-order them and reform the large data frame. A separate queue is set aside for the sensitive real time data packets. This queue can be dealt with more quickly than the others.

Multilink PPP (MPPP or MP)

MPPP provides load balancing over a number of interfaces of varying sorts, synchronous, asychronous and ISDN.

Multilink PPP uses Bandwidth Allocation Protocol (BAP & BACP) (RFC 2125) to dynamically change the number of bearer channels (of various sorts if you want) being used for a connection depending on the current demand requirement. These separate channels are treated as one logical channel, or bundle, and upper layer PDUs are segmented and reassembled.

The PPP frame has an 4 byte sequencing header for PPP multilink which is used when datagrams are split and sequenced to travel across the multiple links. During LCP negotiation a peer that is wanting to multilink, sends a Maximum Received Reconstructed Unit (MRRU) during LCP negotiation, that defines the size of the pipe or bundle. The username is used to determine which bundle to add a particular link to.

Multichassis Multilink PPP is an extension of Multilink PPP where the various bearer channels can come from a number of separate devices rather than just one.

RFC 1717 describes PPP Multilink Protocol and has more recently been superceded by RFC 1990

The following RFCs provide more detail on PPP:
  • RFC 1332 describes IP over PPP (IPCP).
  • RFC 1877 describes IPCP Extensions for DNS and NetBIOS.
  • RFC 1378 describes AppleTalk ATCP.
  • RFC 1552 describes IPXCP.
  • RFC 1220 describes Bridging on PPP.
  • RFC 1638 describes Bridging Control Protocol (BCP).
  • RFC 1762 describes DECnet IV (DNCP).
  • RFC 1763 describes Banyan Vines (BNCP).
  • RFC 1764 describes XNS (XNSCP).
  • RFC 1492 describes Access Control Protocol or TACACS.

Valid HTML 4.01 Transitional

Earn on the Web    

All rights reserved. All trademarks, logos, and copyrights are property of their respective owners.