Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

The fragments used in MP are similar in concept to IP fragments, but of course these are

different protocols running at different layers. To PPP or MP, an IP fragment is just an IP

datagram like any other.

The fragmenting of data in MP introduces a number of complexities that the protocol must

handle. For example, since fragments are being sent roughly concurrently, we need to

identify them with a sequence number to facilitate reassembly. We also need some control

information to identify the first and last fragments. A special frame format is used for MP

fragments to carry this extra information, which I describe in the section on PPP frame

formats. That topic also contains more information about how fragmenting is accomplished,

as well as an illustration that demonstrates how it works.

Related Information: I also recommend reading the next topic, which describes

two protocols defined after MP to better control how it works: BAP and BACP.

PPP Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control

Protocol (BACP)

The PPP Multilink Protocol (MP) described in the previous topic allows multiple links

between a pair of devices, whether physical or in the form of virtual channels, to be

combined into a “fat pipe” (high-capacity channel). This offers tremendous advantages to

many PPP users, as it lets them make optimal use of all their bandwidth, especially for

applications such as Internet connectivity. It's no surprise, then, that MP has become one of

the most popular features of PPP.

The original standard defining MP basically assumed that multiple links would be combined

into a single bundle. For example, if you had two modem links they would both be

connected and then combined, or two B channels in an ISDN link would be combined. After

MP was set up the bundle would be available for either device to use in its entirety.

There's one drawback to this system: the “fat pipe” is always enabled, and in many cases, it

is expensive to have this set up all the time. It often costs more to connect two or more layer

one links than a single one, and it's not always needed. For example, some ISDN services

charge per minute for calls on either of the B channels. In the case of modem dialup there

are per-minute charges in some parts of the world. Even where regular phone calls are

“free”, there is a cost in the form of tying up a phone line. Consider that in many applica-

tions, the amount of bandwidth needed varies over time.

It would be better if we could set up MP so that it could dynamically add links to the bundle

when needed, such as when we decided to download some large files, and then automati-

cally drop them when no longer required. This enhancement to the basic MP package was

provided in the form of a pair of new protocols described in RFC 2125:

☯ Bandwidth Allocation Protocol (BAP): Describes a mechanism where either device

communicating over an MP bundle of layer one links may request that a link be added

to the bundle or removed from it.

☯ Bandwidth Allocation Control Protocol (BACP): Allows devices to configure how

they want to use BAP.

Key Concept: BAP and BACP are used to provide dynamic control over how the

PPP Multilink Protocol functions.

BACP Operation: Configuring the Use of BAP

Let's start with BACP, since it is the protocol used for initial setup of the feature. BACP is

very similar in general concept to all those other PPP protocols with “Control” in their

names, such as LCP, the NCP family, CCP and ECP, but is actually even simpler. It is used

only during link configuration to set up BAP. This is done using Configure-Request,

Configure-Ack, Configure-Nak and Configure-Reject messages just as described in the

LCP topic. The only configuration option that is negotiated in BACP is one called Favored-

Peer, which is used to ensure that the two devices on the link don't get “stuck” if each tries

to send the same request at the same time.

If both devices support BAP then the BACP negotiation will succeed and BAP will be

activated.

BAP Operation: Adding and Removing Links

BAP defines a special set of messages that can be sent between devices to add or drop

links to/from the current PPP bundle. What's particularly interesting about BAP is that it

includes the tools necessary to have a device actually initiate different types of physical

layer connections (such as dialing a modem for bundled analog links or enabling an extra

ISDN channel) when more bandwidth is required, and then shut them down when no longer

needed.

A brief description of the BAP message types:

☯ Call-Request and Call-Response: When one device on the link wants to add a link to

the bundle and initiate the new physical layer link itself, it sends a Call-Request frame

to tell the other device, which replies with a Call-Response.

☯ Callback-Request and Callback-Response: These are just like the two message

types above, but used when a device wants its peer (the other device on the link) to

initiate the call to add a new link. So, if device A says “I need more bandwidth but I

want you to call me, instead of me calling you”, it sends device B a Callback-Request.

☯ Call-Status-Indication and Call-Status-Response: After a device attempts to add a

new link to the bundle (after sending a Call-Request or receiving a Callback-Request)

it reports the status of the new link using the Call-Status-Indication frame. The other

device then replies with a Call-Status-Response.

☯ Link-Drop-Query-Request and Link-Drop-Query-Response: These messages are

used by one device to request that a link be dropped and the other to respond to that

request.

I should also point out that the decision of when to add or remove links is not made by these

protocols. It is left up to the particular implementation.

PPP Protocol Frame Formats

The PPP protocol suite includes a number of different protocols used to send both data and

control information in different ways. Each of these packages information into messages

called frames, each of which follows a particular frame format. PPP starts with a general

frame format that encompasses all frames sent on the link, and then includes more specific

formats for different purposes. Understanding these formats not only makes diagnosing

PPP issues easier, it also helps make more clear how the key PPP protocols function.

In this section I illustrate the most common frame formats used for sending both data and

control information over PPP. I begin with an explanation of the overall format used for all

PPP frames. I also describe the general format used for the various control protocols and

the option format that most of them use. (One of the nice things about PPP is that so many

of the protocols use control frames with a common format.)

I then specifically list the frames used for the Link Control Protocol (LCP) and the authenti-

cation protocols (PAP and CHAP). I also describe the special format used by the PPP

Multilink Protocol (MP) to transport fragments of data over bundled links.

Note: Due to the sheer number of different protocols in PPP (dozens) and the fact

that many have their own unique options, I cannot describe all the specific frame

formats and option formats for every protocol in detail here. Please refer to the

appropriate RFCs (shown in the topic on PPP standards) if you need more detail than

provided in this section.

PPP General Frame Format

All messages sent using PPP can be considered either data or control information. The

word “data” describes the higher-layer datagrams we are trying to transport here at layer

two; this is what our “customers” are giving us to send. Control information is used to

manage the operation of the various protocols within PPP itself. Even though different

protocols in the PPP suite use many types of frames, at the highest level they all fit into a

single, general frame format.

In the overview of PPP I mentioned that the basic operation of the suite is based on the ISO

High-Level Data Link Control (HDLC) protocol. This becomes very apparent when we look

at the structure of PPP frames overall—they use the same basic format as HDLC, even to

the point of including certain fields that aren't strictly necessary for PPP itself. The only

major change is the addition of a new field to specify the protocol of the encapsulated data.

The general structure of PPP frames is defined in RFC 1662, a “companion” to the main

PPP standard RFC 1661.

The general frame format for PPP, showing how the HDLC framing is applied to PPP, is

described in Table 33 and illustrated in Figure 32.

Figure 33 shows one common application of the PPP general frame format: carrying

data.The value 0x0021 in the Protocol field marks this as an IPv4 datagram. This sample

has one byte of Padding and a 2-byte FCS as well. (Obviously real IP datagrams are longer

than the 23 bytes shown here! These bytes are arbitrary and don’t represent a real

datagram.) See Figure 43 for an illustration of how this same data frame is formatted and

then fragmented for transmission over multiple links using the PPP Multilink Protocol.

Protocol Field Ranges

The Protocol field is the main “frame type” indicator for the device receiving the frame. For

data frames this is normally the network-layer protocol that created the datagram, and for

control frames, the PPP protocol that created the control message. In the case of protocols

Table 33: PPP General Frame Format

Field Name

Size

(bytes)

Description

Flag 1

Flag: Indicates the start of a PPP frame. Always has the value “01111110”

binary (0x7E hexadecimal, or 126 decimal).

Address 1

Address: In HDLC this is the address of the destination of the frame. But

in PPP we are dealing with a direct link between two devices, so this field

has no real meaning. It is thus always set to “11111111” (0xFF or 255

decimal), which is equivalent to a broadcast (it means “all stations”).

Control 1

Control: This field is used in HDLC for various control purposes, but in

PPP it is set to “00000011” (3 decimal).

Protocol 2

Protocol: Identifies the protocol of the datagram encapsulated in the Infor-

mation field of the frame. See below for more information on the Protocol

field.

Information Variable

Information: Zero or more bytes of payload that contains either data or

control information, depending on the frame type. For regular PPP data

frames the network-layer datagram is encapsulated here. For control

frames, the control information fields are placed here instead.

Padding Variable

Padding: In some cases, additional dummy bytes may be added to pad

out the size of the PPP frame.

FCS 2 (or 4)

Frame Check Sequence (FCS): A checksum computed over the frame to

provide basic protection against errors in transmission. This is a CRC code

similar to the one used for other layer two protocol error protection

schemes such as the one used in Ethernet. It can be either 16 bits or 32

bits in size (default is 16 bits).

The FCS is calculated over the Address, Control, Protocol, Information and

Padding fields.

Flag 1

Flag: Indicates the end of a PPP frame. Always has the value “01111110”

binary (0x7E hexadecimal, or 126 decimal).

Figure 32: PPP General Frame Format

All PPP frames are built upon the general format shown above. The first three bytes are fixed in value,

followed by a two-byte Protocol field that indicates the frame type. The variable-length Information field is

formatted in a variety of ways, depending on the PPP frame type. Padding may be applied to the frame, which

concludes with an FCS field of either 2 or 4 bytes (2 bytes shown here) and a trailing Flag value of 0x7E. See

Figure 33 for an example of how this format is applied.

Figure 33: Sample PPP Data Frame

This sample PPP data frame has a value of 0x0021 in the Protocol field, indicating it is an IP datagram

(though the actual data is made up and not a real IP message.)

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Information

Flag = 7E Address = FF Control = 03

Protocol

(byte 1) = 00

Protocol

(byte 2) = 21

2A 00 1D

47 9F BC 19

88 18 E5 01

73 A3 69 AF

1B 90 54 BA

00 7C D1 AA

Padding = 00 Frame Check Sequence = ???? Flag = 7E

4 8 12 16 20 24 28 320

that modify data such as when compression (CCP) or encryption (ECP) are used, this field

identifies the data as being either compressed or encrypted, and the original Protocol value

is extracted after the Information field is decompressed/decrypted.

There are dozens of network-layer protocols and PPP control protocols, and a correspond-

ingly large number of Protocol values The main PPP standard defines four ranges for

organizing these values, as shown in Table 34.

The standard also specifies that the Protocol value must be assigned so that the first octet

is even, and the second octet is odd. So, for example, 0x0021 is a valid value but 0x0121

and 0x0120 are not. (The reason for this will become apparent shortly). There are also

certain blocks that are reserved and not used.

Table 34: PPP Protocol Field Ranges

Protocol Field

Range

(hexadecimal)

Description

0000 - 3FFF

Encapsulated network layer datagrams that have an associated Network Control

Protocol (NCP). In this case, control frames from the corresponding NCP use a

Protocol field value that is computed by adding “8” to the first octet of the network

layer Protocol value. For example, for IP the Protocol value is 0021, and control

frames from the IP Control Protocol (IPCP) use Protocol value 8021.

This range also includes several values used for specially-processed encapsulated

datagrams, such as when compression or encryption are employed.

4000 - 7FFF

Encapsulated datagrams from “low-volume” protocols. These are protocols that do

not have an associated NCP.

8000 - BFFF

Network Control Protocol (NCP) control frames that correspond to the network

layer Protocol values in the 0000-3FFF range.

C000 - FFFF

Control frames used by LCP and LCP support protocols such as PAP and CHAP.

Some miscellaneous protocol values are included here as well.

Protocol Field Values

The full list of PPP Protocol values is maintained by the Internet Assigned Numbers

Authority (IANA) along with all the other different reserved numbers for Internet standards.

Table 35 shows some of the more common values:

Table 35: Common Protocols Carried In PPP Frames and Protocol Field Values (Page

1 of 2)

Protocol Type

Protocol

Field

Value

(hex)

Protocol

Encapsulated

Network Layer

Datagrams

0021 Internet Protocol version 4 (IPv4)

0023 OSI Network Layer

0029 Appletalk

002B Novell Internetworking Packet Exchange (IPX)

003D PPP Multilink Protocol (MP) Fragment

003F NetBIOS Frames (NBF/NetBEUI)

004D IBM Systems Network Architecture (SNA)

0053 Encrypted Data (using ECP and a PPP encryption algorithm)

0055 Individual-Link Encrypted Data under PPP Multilink

0057 Internet Protocol version 6 (IPv6)

00FB Individual-Link Compressed Data under PPP Multilink

00FD Compressed Data (using CCP and a PPP compression algorithm)

Low-Volume

Encapsulated

Protocols

4003 CDPD Mobile Network Registration Protocol

4025 Fibre Channel

Network Control

Protocol (NCP)

Control Frames

8021 PPP Internet Protocol Control Protocol

8023 PPP OSI Network Layer Control Protocol

8029 PPP Appletalk Control Protocol

802B PPP IPX Control Protocol

803F PPP NetBIOS Frames Control Protocol

804D PPP SNA Control Protocol

8057 PPP IPv6 Control Protocol

PPP Field Compression

PPP uses the HDLC basic framing structure, which includes two fields that are needed in

HDLC but not in PPP due to how the latter operates: the Address and Control fields. Why

bother sending two bytes that have the same value for every frame and aren't used for

anything? Originally they were maintained for compatibility, but this reduces efficiency.

To avoid wasting two bytes in every frame, it is possible during initial link setup using LCP

for the two devices on the link to negotiate a feature called Address and Control Field

Compression (ACFC) using the LCP option by that same name. When enabled, this feature

simply causes these two fields not to be sent for most PPP frames (but not LCP control

frames.) In fact, the feature would be better named “Address and Control Field

Suppression” because the fields are just suppressed: compressed down to nothing.

Now, even when devices agree to use field compression, they must still be capable of

receiving both “compressed” and “uncompressed” frames. They differentiate one from the

other by looking at the first two bytes after the initial Flag field. If they contain the value

0xFF03, they must be the Address and Control fields; otherwise, those fields were

suppressed. (The value 0xFF03 is not a valid Protocol field value, so there is no chance of

ambiguity.)

Similarly, it is also possible for the two devices on the link to negotiate compression of the

Protocol field, so it takes only one byte instead of two. This is done generally by dropping

the first byte if it is zero, a process called Protocol Field Compression (PFC). Recall that the

first byte must be even and the second odd. Thus, a receiving device examines the

evenness of the first byte of the Protocol field in each frame. If it is odd, this means that a

leading byte of zeroes in the Protocol field has been suppressed, because the first byte of a

full two-byte Protocol value must be even.

LCP and Other

Control Frames

C021 PPP Link Control Protocol (LCP)

C023 PPP Password Authentication Protocol (PAP)

C025 PPP Link Quality Report (LQR)

C02B PPP Bandwidth Allocation Control Protocol (BACP)

C02D PPP Bandwidth Allocation Protocol (BAP)

C223 PPP Challenge Handshake Authentication Protocol (CHAP)

Table 35: Common Protocols Carried In PPP Frames and Protocol Field Values (Page

2 of 2)

Protocol Type

Protocol

Field

Value

(hex)

Protocol

Note: This “field compression” (really suppression) has nothing to do with data

compression using PPP's Compression Control Protocol (CCP) and compression

algorithms.

PPP General Control Protocol Frame Format and Option Format

A general frame format is used for all of the many frame types defined in the PPP protocol

suite. Within that format, the Information field carries either encapsulated layer-three user

data, or encapsulated control messages. These control messages contain specific infor-

mation that is used to configure, manage and discontinue PPP links, and to implement the

various features that comprise PPP.

As we saw in previous sections, there are many different PPP control protocols, which

usually can be distinguished by the word “Control” appearing their names. These include

the main PPP Link Control Protocol (LCP), a family of Network Control Protocols (NCPs)

such as IPCP, IPXCP and so forth, and also control protocols for implementing features,

such as CCP and ECP. The authentication protocols PAP and CHAP lack “Control” in the

name but also fall into this category.

The control protocols each use control messages in a slightly different way, but there is also

a great deal of commonality between the messages in many of them. This is because, as I

explained in the topics describing the PPP protocols, most of the control protocols such as

the NCP family, CCP and ECP are implemented as “subsets” of the functionality of the Link

Control Protocol. They perform many of the same functions, so the PPP designers wisely

“adapted” the LCP messaging system for these other control protocols.

This all means that control protocol frames have themselves a common format that fits

within the overall general frame format in PPP. Even protocols like PAP and CHAP that

aren't based on LCP use this general control frame format, which is described in Table 36.

Table 36: PPP Control Message Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Code (Type) 1

Code: A single byte value that indicates what type of control message is in

this control frame. It is sometimes instead called “Type” in certain PPP

standards.

Identifier 1

Identifier: This is a label field, used to match up requests with replies.

When a request is sent a new Identifier is generated. When a reply is

created, the value from the Identifier field in the request that prompted the

reply is used for the reply's Identifier field.