EE6364

DCCW PPP-1

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)

EE6364

DCCW PPP-2

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.

EE6364

DCCW PPP-3

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:

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.

DeadDead EstablishEstablish AuthenticateAuthenticate

NetworkNetworkTerminateTerminate

Up Opened Success

FailFail

Closing

EE6364

DCCW PPP-4

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

PPP Protocol Format The PPP framing format is as follows:

VectraOfficeHEWLETTPACKARDVectraOfficeHEWLETTPACKARD

User Router

Configure-Request (LCP)

Configure-ACK (LCP)

Configure-Request IP (NCP)

Configure-ACK IP (NCP)

IP Data Packets

Terminate-Request (LCP)

Terminate-ACK (LCP)

Flag0x7E

Addr0xFF

Control0x03 Protocol

bytes 1 1 1 2

InformationFlag0x7EFCS

2 or 4 1

Protocol0x0021 IP datagram (IP header + data)

Protocol0xC021

Protocol0x8021

Code ID Length Data (options)

Code ID Length Data (options)

LCP format

NCP format

Data packet format

Up to 1500 (default)

bytes 2 1 1 2 variable

EE6364

DCCW PPP-5

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 Assigned Value

Protocol

Network Layer Protocols 0x0021 IP V4 0x0023 OSI network layer protocol 0x002B Novell IPX 0x003D PPP Multilink Protocol (RFC1990) 0x003F NetBIOS 0x0041 Cisco system 0x004D IBM SNA 0x0057 IP v6 Network Control Protocols 0x8021 IPv4 control protocol 0x8023 OSI network layer control protocol 0x802B IPX control protocol 0x803D Multilink control protocol (RFC1990) 0x803F NetBIOS framing control protocol 0x8041 Cisco system control protocol 0x804D IBM SNA control protocol (RFC2043) 0x8057 IPv6 control protocol Link Control Protocol 0xC021 Link control protocol 0xC023 Password Authentication Protocol 0xC025 Link quality report 0xC02B Bandwidth control protocol (RFC2125) 0xC02D Bandwidth allocation protocol

(RFC2125) 0xC223 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.

EE6364

DCCW PPP-6

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 Functions For both LCP and NCP: 1 Configure-Request Start connection, define and negotiate configuration 2 Configure-Ack Acknowledge Configure-Request received 3 Configure-Nak Negative response to Configure-Request received 4 Configure-Reject Configuration options not recognizable 5 Terminate-Request Close a connection 6 Terminate-Ack Acknowledge the reception of Terminate-Request 7 Code-Reject Unknown code received For LCP only: 8 Protocol-Reject Unknown protocol field value received 9 Echo-Request Loopback for link quality determination 10 Echo-Reply Reply to Echo-Request 11 Discard-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:

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.

Type Length Data

bytes 1 1 variable

EE6364

DCCW PPP-7

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. Three types of packets are used in PAP. They are:

User/Client Server

Authentication Request: User Name & Password

Ack or Nak

Code1

ID Length UsernameLength

Username PasswordLength Password

Bytes 1 1 2 1 Variable 1 Variable

Authentication Request

Code2

ID Length MessageLength MessageAck

Code3

ID Length MessageLength

MessageNak

Flag0x7E

Addr0xFF

Control0x03

Protocol0xC023

Bytes 1 1 1 2

Information Flag0x7EFCS

2 or 4 1

EE6364

DCCW PPP-8

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: 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:

User/Client Server

Challenge

Response

Success or Failure

Code2

ID Length ResponseLength

ResponseValue

Username

Bytes 1 1 2 1 Variable Variable

Response

Code3

ID Length MessageSuccess

Code4

ID LengthFailure

Flag0x7E

Addr0xFF

Control0x03

Protocol0xC223

Bytes 1 1 1 2

Information Flag0x7EFCS

2 or 4 1

Code1

ID Length ChallengeLength

ChallengeValue

UsernameChallenge

Message

EE6364

DCCW PPP-9

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. 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: 3 K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, “The PPP Multilink Protocol (MP),”

RFC 1990, August 1996.

End Point

End Point

B it 0 7 8 15

A ddress 0xff C ontrol 0x03

Protocol ID (0x003d)

B E 0 0 0 0 0 0 Sequence N um ber

Sequence N um ber

Fragm ented D ata

Long Sequence N um ber Form at

EE6364

DCCW PPP-10

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.

Bit 0 7 8 15

Address 0xff Control 0x03

Protocol ID (0x003d)

B E 0 0 Sequence Num ber

Fragm ented D ata

Short Sequence Num ber Form at

EE6364

DCCW PPP-11

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.