Charles M. Kozierok The TCP-IP Guide

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

PPP Multilink Protocol (MP) Frame Format

Some devices are connected not by a single physical layer link but by two or more. These

may be either multiple physical connections such as two connected pairs of modems, or

multiplexed virtual layer one connections like ISDN B channels. In either case, the PPP

Figure 39: PPP CHAP Challenge and Response Frame Format

Figure 40: PPP CHAP Success and Failure Frame Format

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Code (Type) Identifier

Length

(first byte)

Length

(second byte)

Value-Size

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Value

Name

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Code (Type) Identifier

Length

(first byte)

Length

(second byte)

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Message

Multilink Protocol (MP, which also goes by several aliases such as MLPPP and MLP) can

be used to aggregate the bandwidth of these physical links to create a single, high-speed

bundle. I describe how this is done in the operational topic on MP.

After MP is configured and starts working, it operates by employing a strategy for dividing

up regular PPP frames amongst the many individual physical links that comprise the MP

bundle. This is usually accomplished by chopping up the PPP frames into pieces called

fragments and spreading these fragments across the physical links. This allows the traffic

on the physical links to be easily balanced.

PPP Multilink Protocol Frame Fragmentation Process

To accomplish this fragmentation process, a three step process is followed:

1. Original PPP Frame Creation: The data or other information to be sent is first

formatted as a “whole” PPP frame, but in a modified form, as described below.

2. Fragmentation: The full-sized PPP frame is chopped into fragments by MP.

3. Encapsulation: Each fragment is encapsulated in the Information field of a new PPP

MP fragment frame, along with control information to allow the fragments to be

reassembled by the recipient.

Several of the fields that normally appear in a “whole” PPP frame aren’t needed if that

frame is going to then be divided and placed into other PPP Multilink frames, so when

fragmentation is to occur, they are omitted when the original PPP frame is constructed for

efficiency’s sake. Specifically:

☯ The Flag fields at the start and end are used only for framing for transmission and

aren’t needed in the logical frame being fragmented.

☯ The FCS field is not needed, because each fragment has its own FCS field.

Table 42: PPP Multilink Protocol Fragment Frame Format

Field Name Size (bytes) Description

B 1/8 (1 bit)

Beginning Fragment Flag: When set to 1, flags this fragment as the

first of the split-up PPP frame. It is set to 0 for other fragments.

E 1/8 (1 bit)

Ending Fragment Flag: When set to 1, flags this fragment as the last

of the split-up PPP frame. It is set to 0 for other fragments.

Reserved

2/8 (2 bits)

6/8 (6 bits)

Reserved: Not used, set to zero.

Sequence

Number

1 1/2 (12 bits)

3 (24 bits)

Sequence Number: When a frame is split up, the fragments are given

consecutive sequence numbers so the receiving device can properly

reassemble them.

Fragment Data Variable Fragment Data: The actual fragment from the original PPP frame.

☯ The special “compression” options that are possible for any PPP frame are used when

creating this original frame: Address and Control Field Compression (APCP) and

Protocol Field Compression (PFC). This means that there are no Address or Control

fields in the frame, and the Protocol field is only one byte in size. Note that this inher-

ently restricts fragments to carrying only certain types of information.

These changes save a full eight bytes on each PPP frame to be fragmented. As a result,

the original PPP frame has a very small header, consisting of only a one-byte Protocol field.

The Protocol value of each fragment is set to 0x003D to indicate a MP fragment, while the

Protocol field of the original frame becomes the first byte of “data” in the first fragment.

Key Concept: The PPP Multilink Protocol normally divides data amongst physical

links by creating an original PPP frame with unnecessary headers removed, and

then dividing it into fragment frames. Each fragment includes special headers to

allow reassembly of the original frame by the recipient device.

PPP Multilink Protocol Fragment Frame Format

The Information field of each fragment uses a substructure that contains a four-field MP

header along with one fragment of the original PPP frame, as shown in Table 42.

Figure 41: PPP Multilink Protocol Long Fragment Frame Format

The long PPP Multilink Protocol frame format uses a full byte for flags and a 24-bit Sequence Number.

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Flags

Sequence Number

(bytes 1 and 2)

Sequence Number

(byte 3)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Begin-

ning

Frag-

ment

(B)

Ending

Frag-

ment

(E)

Reserved

480

Fragment Data

Frame Check Sequence (FCS)

(may also be 4 bytes)

Padding

As you can see, the MP frame format comes in two versions: the long format uses a 4-byte

header, while the short format requires only 2 bytes. The default MP header format uses a

24-bit Sequence Number and has 6 reserved bits, as shown in Figure 41. It is possible

when MP is set up, for devices to negotiate the Multilink Short Sequence Number Header

Format configuration option. If this is done successfully, shorter 12-bit Sequence Numbers

are used instead. Four of the reserved bits are also truncated, to save 2 bytes on each

frame, as illustrated in Figure 42. (Considering that 12 bits still allows for over 4,000

fragments per PPP frame, this is usually more than enough!)

The Fragment Data field contains the actual fragment to be sent. Since the original PPP

header (including the Protocol field) is at the start of the original PPP frame, this will appear

at the start of the first fragment. The remaining fragments will have just portions of the Infor-

mation field of the original PPP frame. The last fragment will end with the last bytes of the

original PPP frame.

The receiving device will collect all the fragments for each PPP frame, extract the fragment

data and MP headers from each. It will use the Sequence Numbers to reassemble the

fragments and then process the resulting PPP frame.

Figure 42: PPP Multilink Protocol Short Fragment Frame Format

The short version of the PPP Multilink Protocol format uses 4 bits for flags and a 12-bit Sequence Number.

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Flags Sequence Number

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Fragment Data

Begin-

ning

Frag-

ment

(B)

Ending

Frag-

ment

(E)

Reserved

Frame Check Sequence (FCS)

(may also be 4 bytes)

PPP Multilink Protocol Fragmentation Demonstration

A demonstration of fragmenting a PPP data frame can be seen in Figure 43. At top is the

same PPP data frame shown in Figure 33. The eight bytes grayed out are the ones not

used when a frame is to be fragmented. Thus, the PPP frame used for MP is 24 bytes long,

as seen in the smaller table at left (note that the eight bytes are not created and removed, I

just showed them in the upper table for illustration). This frame is split into 8-byte chunks,

each carried in the Fragment Data fields of an MP fragment. Note the consecutive

Sequence Number (“Seq”) values in the fragment frames. Also, note that the Beginning

Fragment field is set only for the first fragment, and the Ending Fragment only for the last

one.

Figure 43: PPP Multilink Protocol (MP) Fragmentation Demonstration

This diagram shows how a single PPP frame is fragmented into three smaller ones, and how the control fields

are set for each fragment.

Original PPP Frame

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

PPP Multilink Frame #2 (bytes 9 to 16)

PPP Multilink Frame #3 (bytes 17 to 24)

PPP Multilink Frame #1 (bytes 1 to 8)

8162432

21 2A 00 1D

47 9F BC 19

88 18 E5 01

73 A3 69 AF

1B 90 54 BA

00 7C D1

Flag = 7E Addr = FF Ctrl = 03 Prot1 = 00

Prot1 = 3D 0 0 88

18 E5 01 73

A3 69 AF Pad = 00

Pad = 00 FCS = ???? Flag = 7E

Flag = 7E Addr = FF Ctrl = 03 Prot1 = 00

Prot1 = 3D 0 1 1B

90 54 BA 00

7C D1 AA Pad = 00

Pad = 00 FCS = ???? Flag = 7E

Flag = 7E Addr = FF Ctrl = 03 Prot1 = 00

Prot1 = 3D 1 0 21

2A 00 1D 47

9F BC 19 Pad = 00

Pad = 00 FCS = ???? Flag = 7E

Seq = 0C2

Seq = 0C3

Seq = 0C1

TCP/IP Network Interface / Internet "Layer Connection"

Protocols

The second layer of the OSI Reference Model is the data link layer; it corresponds to the

TCP/IP network interface layer. It is there that most LAN, WAN and WLAN technologies are

defined, such as Ethernet and IEEE 802.11. The third layer is the network layer, also called

the internet layer in the TCP/IP model, where internetworking protocols are defined, the

most notable being the Internet Protocol. These two layers are intimately related, because

messages sent at the network layer must be carried over individual physical networks at the

data link layer. They perform different tasks but as neighbors in the protocol stack, must

cooperate with each other.

There is a set of protocols that serves the important task of linking together these two layers

and allowing them to work together. The problem with them is deciding where exactly they

should live! They are sort of the “black sheep” of the networking world—nobody denies their

importance, but they always think they belong in “the other guy's” layer. For example, since

these protocols pass data on layer two networks, the folks who deal with layer two technol-

ogies say they belong at layer three. But those who work with layer three protocols consider

these “low level” protocols that provide services to layer three, and hence put them as part

of layer two.

So where do they go? Well, to some extent it doesn't really matter. Even if they are “black

sheep” I consider them somewhat special, so I gave them their own home. Welcome to

“networking layer limbo”, also known as “OSI layer two-and-a-half”. ☺ This is where a

couple of protocols are described that serve as “glue” between the data link and network

layers. The main job performed here is address resolution, or providing mappings between

layer two and layer three addresses. This resolution can be done in either direction, and is

represented by the two TCP/IP protocols ARP and RARP (which, despite their similarities,

are used for rather different purposes in practice.)

Background Information: I suggest familiarity with the basics of layer two and

layer three before proceeding here. In particular, some understanding of IP

addressing is helpful, though not strictly necessary. In general, if you are going to

read about IP anyway, you would be better off covering that material before proceeding to

this section.

Address Resolution and the TCP/IP Address Resolution

Protocol (ARP)

Communication on an internetwork is accomplished by sending data at layer three using a

network layer address, but the actual transmission of that data occurs at layer two using a

data link layer address. This means that every device with a fully-specified networking

protocol stack will have both a layer two and a layer three address. It is necessary to define

some way of being able to link these addresses together. Usually, this is done by taking a

network layer address and determining what data link layer address goes with it. This

process is called address resolution.

In this section I look at the problem of address resolution at both a conceptual and practical

level, with a focus on how it is done in the important TCP/IP protocol suite. I begin with a

section that overviews address resolution in general terms and describes the issues

involved in the process. I then describe the TCP/IP Address Resolution Protocol (ARP),

probably the best-known and most commonly used address resolution technique. I also

provide a brief overview of how address resolution is done for multicast addresses in IP,

and the method used in the new IP version 6.

Address Resolution Concepts and Issues

Due to the prominence of TCP/IP in the world of networking, most discussions of address

resolution jump straight to the TCP/IP Address Resolution Protocol (ARP). This protocol is

indeed important, and we will take a look at it in the next section. However, the basic

problem of address resolution is not unique to any given implementation that deals with it,

such as TCP/IP's ARP. To provide better understanding of resolving addresses between the

data link layer and the network layer and to support for our examination of ARP, I think it's a

good idea to start by looking at the matter in more general terms.

To that end, I provide here some background information on address resolution, exploring

various concepts and issues related to the technique in general terms. I begin by discussing

the need for address resolution in general terms. I then describe the two main methods for

solving the address resolution problem: direct mapping and dynamic resolution. I also

discuss some of the efficiency issues involved in practical dynamic address resolution, with

a focus on the importance of caching.

The Need For Address Resolution

I can imagine that some people might balk at the notion of address resolution and the need

for protocols that perform this function. In my chapter on the OSI Reference Model I talked

extensively about how the whole point of having conceptual layers was to separate logical

functions and allow higher-layer protocols to be hidden from lower-layer details. Given this,

why do we need address resolution protocols that tie protocols and layers together?

I did say that layers are distinct, true. However, I also tried to make the point that the OSI

Reference Model is exactly that—a model. There are often practicalities that arise that

require solutions that don't strictly fit the layer model. When the model doesn't fit reality, the

model must yield. And so it is in dealing with the problem of address resolution.

Addressing at Layer Two and Layer Three

When we consider the seven layers of the OSI Reference Model, there are two that deal

with addressing: the data link layer and the network layer. The physical layer is not strictly

concerned with addressing at all, only sending at the bit level. The layers above the network

layer all work with network layer addresses.

So the next obvious question is: why is addressing is done at two different layers? The

answer is that they are very different types of addresses that are used for different

purposes. Layer two addresses (such as IEEE 802 MAC addresses) are used for local

transmissions between hardware devices that can communicate directly. They are used to

implement basic LAN, WLAN and WAN technologies. In contrast, layer three addresses

(most commonly Internet Protocol or IP addresses) are used in internetworking, to create

the equivalent of a massive “virtual” network at the network layer.

The most important distinction between these types of addresses is the distinction between

layers two and three themselves: layer two deals with directly-connected devices (on the

same network) while layer three deals with indirectly-connected devices (as well as

directly-connected). Say, for example, you want to connect to the Web server at http://

www.tcpipguide.com. This is a web site that runs on a server that has an Ethernet card in it

for connecting it to its Internet service provider site. However, even if you know its MAC

address, you cannot use it to talk directly to this server using the Ethernet card in your

home PC, because the devices are on different networks—in fact, they may be on different

continents!

Instead, you communicate at layer three, using the Internet Protocol and higher layer

protocols such as TCP and HTTP. Your request is routed from your home machine, through

a sequence of routers, to the server at The TCP/IP Guide, and the response is routed back

to you. The communication is, logically, at layers three and above; you send the request not

to the MAC address of the server’s network card, but rather to the server’s IP address.

However, while we can virtually connect devices at layer three, these connections are

really conceptual only. When you send a request using IP, it is sent one hop at a time, from

one physical network to the next. At each of these hops, an actual transmission occurs at

the physical and data link layers. When your request is sent to your local router at layer

three, the actual request is encapsulated in a frame using whatever method you physically

connect to the router, and passed to it using the router's data link layer address. The same

happens for each subsequent step, until finally, the router nearest the destination sends to

the destination using its data link (MAC) address. This is illustrated in Figure 44.

Converting Layer Three Addresses to Layer Two: Address Resolution

The basic problem is that IP addresses are too high level for the physical hardware on

networks to deal with; they don't understand what they are. When your request shows up at

the router that connects to The TCP/IP Guide, it can see the http://www.tcpipguide.com

server's IP address, but that isn't helpful: it needs to send to server's MAC address.

The identical issue exists even with communication between devices on a LAN. Even if the

Web server is sitting on the same desk as the client, the communication is logically at the IP

layer, but must also be accomplished at the data link layer. This means we need a way of

translating between the addresses at these two layers. This process is called address

resolution.

Key Concept: Address resolution is required because internetworked devices

communicate logically using layer three addresses, but the actual transmissions

between devices take place using layer two (hardware) addresses.