Charles M. Kozierok The TCP-IP Guide

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

Configure-Request frame. Again, LQR is the only quality protocol presently defined. The

configuration option also specifies a reporting period that indicates the longest period of

time the requesting device wants to go between receiving reports.

LQR Counters

Assuming that the negotiation is successful, LQR will be enabled. A number of counters are

set up that keep track of various link statistics, and a timer used to regulate the sending of

quality reports over the link. Each time the timer expires a special link quality report is

generated and sent in a PPP frame over the link. These are sent using the special PPP

Protocol field hexadecimal value 0xC025.

Each counter holds information about a different statistic regarding the use of the link. Each

of these counters is reset to zero when LQR is set up and then incremented each time a

transmission is made or an event occurs that is relevant to the counter. The statistics

tracked include the following:

☯ The number of frames sent/received.

☯ The number of octets (bytes) in all frames sent/received.

☯ The number of errors that have occurred.

☯ The number of frames that had to be discarded.

☯ The number of link quality reports generated.

These counters are only reset at the start of the link, so they contain figures kept cumula-

tively over the life of the connection. The counters can be used in the absolute sense,

meaning that the counter value itself is reported. Alternately, they can be expressed as

relative (or delta) values, which represent the change since the last report. This is done

when a report is received simply by subtracting the previous report's numbers from those in

the current report.

Using Link Quality Reports

LQR specifies the quality reporting mechanism, but not specific standards for link quality,

since these are so implementation-dependent. Based on the numbers in these reports, a

device can decide for itself what conclusions to draw about link quality, and in turn what

action to take, if any. For example:

☯ Some devices might decide to shut down a link if the absolute number of errors seen

in any report reaches a certain threshold.

☯ Some might look at the trend in successive reporting periods and take action if they

detect certain trends, such as an increase in the rate of discarded frames.

☯ Some devices might just log the information and take no action at all.

Note that LQR aggregates its statistics for all higher-layer protocols transmitted over a

particular link. It doesn't keep track of statistics for different higher-layer protocols

separately (which makes sense, since the quality of the link shouldn't vary from one higher

layer protocol to the next).

PPP Compression Control Protocol (CCP) and Compression Algorithms

PPP is, of course, primarily used to provide data link layer connectivity to physical serial

links. One of the biggest problems with serial links compared to many other types of layer

one connections is that they are relatively slow. Consider that while 10 Mbps regular

Ethernet is considered sluggish by modern LAN standards, it is actually much faster than

most serial lines used for WAN connectivity, which can be 10, 100 or even 1000 times

slower.

One way to improve performance over serial links is to use compression on the data sent

over the line. Depending on the data transferred, this can double the performance

compared to uncompressed transmissions, and can in some cases do even better than

that. For this reason, many hardware devices include the ability to compress the data

stream at the physical layer. The best example of this is probably the set of compression

protocols used on analog modems.

Some physical links don't provide any compression capabilities, but could still benefit from

it. To this end, an optional compression feature was created for PPP. It is implemented

using two distinct protocol components:

☯ PPP Compression Control Protocol (CCP): This protocol is responsible for negoti-

ating and managing the use of compression on a PPP link.

☯ PPP Compression Algorithms: A set of compression algorithms that perform the

actual compression and decompression of data. Several of these are defined in

Internet standards (RFCs). In addition, it is possible for two devices to negotiate the

use of a proprietary compression method if they want to use one not defined by a

public standard.

Key Concept: PPP includes an optional compression feature, which can improve

performance over slow physical links. A variety of different compression algorithms

are supported. To enable compression, both devices on a PPP link use the PPP

Compression Control Protocol (CCP) to negotiate a compression algorithm to use. The

compression algorithm is then used to compress and decompress PPP data frames.

CCP Operation: Compression Setup

When most people talk about compression in PPP they mention CCP, which is considered

“the” compression protocol for PPP. However, CCP is actually used only to configure and

control the use of compression; it is the algorithms that do the real work of compressing and

decompressing. This “separation of powers” provides flexibility, since it allows each imple-

mentation to choose what type of compression they wish to use.

CCP is analogous to the Network Control Protocols (NCPs) that negotiate parameters

specific to a network layer protocol sent on the link. An NCP lets two devices decide how

they will carry layer three traffic, such as how IPCP lets the devices determine how to carry

IP. CCP lets two devices decide how they will compress data, in the same basic way.

Similarly, just as each NCP is like a “lite” version of LCP, CCP is also like a “lite” version of

LCP. It is used to set up a compression connection called a CCP link within an LCP link

between two devices. Once established, compressed frames can be sent between the two

devices. CCP also provides messaging capabilities for managing and eventually termi-

nating a CCP link, again very similar to how each network layer protocol sets up a NCP link

within LCP. A CCP link is maintained independently of any NCP links.

CCP uses the same subset of seven LCP message types that the NCPs use, and adds two

additional ones. The use of these messages for each of the “life stages” of a CCP link is as

follows, which should look very familiar if you've already read about how the NCPs and LCP

itself work:

☯ Link Configuration: Like the NCPs, compression configuration is done once CCP

reaches the Network-Layer Protocol phase. The process of setting up compression

and negotiating parameters is accomplished using Configure-Request, Configure-Ack,

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

except the configuration options are particular to CCP.

☯ Link Maintenance: Code-Reject messages can be sent to indicate invalid code

values in CCP frames. The two new message types are Reset-Request and Reset-

Ack, which are used to reset the compression (the CCP link) in the event of a detected

failure in decompression.

☯ Link Termination: A CCP link can be terminated using Terminate-Request and

Terminate-Ack. Again, remember that like the NCP links, the CCP link is set up within

an LCP link, and closing it doesn't terminate the LCP link which controls PPP overall.

CCP Configuration Options and Compression Algorithms

CCP configuration options are used for only one purpose: to negotiate the type of

compression to be used by the two devices, and the specifics of how that algorithm is to be

employed. The device initiating the negotiation sends a Configure-Request with one option

for each of the compression algorithms it supports. The other device compares this list of

options to the algorithms it understands. It also checks for any specific details relevant to

the option to see if it agrees on how that algorithm should be used. It then sends back the

appropriate reply (Ack, Nak or Reject) and a negotiation ensues until the two devices come

up with a common algorithm both understand. If so, compression is turned on; otherwise, it

is not enabled.

The CCP configuration options begin with a Type value that indicates the compression

algorithm. When the Type value is 0, this indicates that the option contains information

about a special, proprietary compression algorithm not covered by any RFC standards,

which can be used if both devices understand it. Several values from 1 to 254 indicate

compression algorithms that have been defined for use with CCP. Table 31 shows the most

common values of the Type field, including the compression algorithm each corresponds to

and the number of the RFC that defines it:

Compression Algorithm Operation: Compressing and Decompressing Data

Once an algorithm has been successfully negotiated, the compression algorithm is used to

compress data before transmission, and to decompress it once received. To compress, the

transmitting device takes the data that would normally be put in the Information field of an

uncompressed PPP frame and runs it through the compression algorithm. To indicate that a

frame has been compressed, the special value 0x00FD (hexadecimal) is placed in the PPP

Protocol field. When compression is used with multiple links and the links are compressed

independently, a different value is used: 0x00FB. Recall that in a regular uncompressed

frame, the Protocol field indicates what layer three protocol the data comes from; since we

still need to know this, the original Protocol value is actually prepended to the data before

compression. When the data is decompressed, this value is used to restore the original

Protocol field, so the receiving device knows what higher layer the data belongs to.

For example, if we use IPCP to encapsulate IP data in PPP, the uncompressed frame would

have a value of 0x8021 (hex) in the Protocol field. This value (0x8021) would be placed at

the start of the data to be compressed. The compressed data would be put in a PPP frame

with a Protocol value of 0x00FD. The receiving device would see the value 0x00FD in the

Protocol field, recognize the frame as compressed, decompress it and restore the original

frame with 0x8021 as the Protocol value. The PPP general frame format topic covers this in

more detail.

In theory, a compression algorithm can put more than one PPP data frame into a

compressed PPP data frame. Despite this, many if not most of the algorithms maintain a

one-to-one correspondence, putting each PPP data frame into one compressed frame.

Note that LCP frames are not compressed, nor are the control frames used for other

protocols. For example, a data frame carrying IP traffic would be compressed, but a control

frame for IPCP (the Network Control Protocol for IP) would not be.

Table 31: PPP Compression Control Protocol (CCP) Compression Algorithms

CCP Option

Type Value

Defining

RFC

Compression Algorithm (As Given in RFC Title)

0 — Proprietary

1 and 2 1978 PPP Predictor Compression Protocol

17 1974 PPP Stac LZS Compression Protocol

18 2118 Microsoft Point-To-Point Compression (MPPC) Protocol

19 1993 PPP Gandalf FZA Compression Protocol

21 1977 PPP BSD Compression Protocol

23 1967 PPP LZS-DCP Compression Protocol (LZS-DCP)

26 1979 PPP Deflate Protocol

Compression can be combined with encryption; in this case compression is done before

encryption.

Note: The compression performed by CCP has nothing to do with the header

compression options that can be negotiated as part of LCP. That type of

“compression” doesn't involve compressing a data stream using a compression

algorithm, but rather a simple way of saving space in headers when both ends of a link

agree to do so.

PPP Encryption Control Protocol (ECP) and Encryption Algorithms

The PPP authentication protocols PAP and CHAP can be used to ensure that only autho-

rized devices can establish a PPP connection. Once that is done, PPP normally provides

no other security to the data being transmitted. In particular, all data is normally sent “in the

clear” (unencrypted), making it easy for someone who intercepts it to read. For important

data that must be kept secure, encryption prior to transmission is a good idea. This can be

done at higher layers using something like IPSec, but PPP also provides an optional feature

that allows data to be encrypted and decrypted at the data link layer itself.

Note: This topic is very similar in structure and content to the preceding one that

covers PPP compression, because the features are implemented in a very similar

way. For the benefit of those who may not be reading in sequence I have provided

a standalone description in this topic, without assuming you have read the prior topic on

compression. This means this topic may seem almost like “deja vu” if you just read the topic

on CCP.

PPP data encryption is implemented using two protocol components:

☯ PPP Encryption Control Protocol (ECP): This protocol is responsible for negotiating

and managing the use of encryption on a PPP link.

☯ PPP Encryption Algorithms: A family of encryption algorithms that perform the

actual encryption and decryption of data. Several of these are defined in Internet

standards (RFCs), and two devices can also negotiate a proprietary encryption

method if they want to use one not defined by a public standard.

ECP is usually the only part mentioned when encryption in PPP is discussed. ECP is in fact

used only to configure and control the use of encryption; it is the algorithms that do the real

work. This technique allows each implementation to choose what type of encryption they

wish to use. The original ECP defined only a single encryption method, and a couple of

others have since been added.

Key Concept: PPP includes an optional encryption feature, which provides privacy

for data transported over PPP. A number of encryption algorithms are supported. To

enable encryption, both devices on a PPP link use the PPP Encryption Control

Protocol (ECP) to negotiate which algorithm to use. The selected algorithm is then used to

encrypt and decrypt PPP data frames.

ECP Operation: Compression Setup

Like CCP, ECP is analogous to the Network Control Protocols (NCPs) that negotiate

parameters specific to a network layer protocol sent on the link, but deals with how devices

encrypt data rather than how they transport layer three traffic. This also means that like the

NCPs, ECP is a "lite" version of LCP and works in the same basic way. Once an ECP link is

negotiated, encrypted frames can be sent between devices. When no longer needed, the

ECP link can be terminated.

ECP uses the same subset of seven LCP message types that the NCPs use, and adds two

more. The use of these messages for each of the “life stages” of an ECP link is as follows:

☯ Link Configuration: Like the NCPs (and also like CCP of course), encryption configu-

ration is done once ECP reaches the Network-Layer Protocol phase. The process of

setting up encryption and negotiating parameters is accomplished using Configure-

Request, Configure-Ack, Configure-Nak and Configure-Reject messages just as

described in the LCP topic, except the configuration options are particular to ECP.

☯ Link Maintenance: Code-Reject messages can be sent to indicate invalid code

values in ECP frames. The two new message types are Reset-Request and Reset-

Ack, which are used to reset the encryption (the ECP link) in the event of a detected

failure in decryption.

☯ Link Termination: An ECP link can be terminated using Terminate-Request and

Terminate-Ack. Again, remember that like the NCP links, the ECP link is set up within

an LCP link, so closing it doesn't terminate the LCP link.

ECP Configuration Options and Encryption Algorithms

ECP configuration options are used only to negotiate the type of encryption algorithm to be

used by the two devices, and the specifics of how that algorithm is to be employed. The

device initiating the negotiation sends a Configure-Request with one option for each of the

encryption algorithms it supports. The other device compares this list of options to the

algorithms it understands. It also checks for any details relevant to the option to see if it

agrees on how that algorithm should be used. It then sends back the appropriate reply (Ack,

Nak or Reject) and a negotiation ensues until the two devices come up with a common

algorithm both understands. If so, encryption is enabled, and otherwise, it is left turned off.

The ECP configuration options begin with a Type value that indicates the encryption

algorithm. When the Type value is 0, this indicates that the option contains information

about a special, proprietary encryption method not covered by any RFC standards, which

can be used if both devices understand it. Values in the range from 1 to 254 indicate

encryption algorithms that have been defined for use with ECP; at present, only two are

defined. Table 32 shows the values of the Type field, including the encryption algorithm

each corresponds to and the number of the RFC that defines it:

Note: Type value 1 was for the original DES algorithm, defined in RFC 1969,

which was superseded by DES version 2 in RFC 2419.

Encryption Algorithm Operation: Encrypting and Decrypting Data

After an encryption algorithm has been successfully negotiated, it is used to encrypt data

before transmission, and to decrypt data received. To encrypt, the transmitting device takes

the data that would normally be put in the Information field of an unencrypted PPP frame

and runs it through the encryption algorithm. To indicate that a frame has been encrypted,

the special value 0x0053 (hexadecimal) is placed in the PPP Protocol field. When

encryption is used with multiple links and the links are encrypted independently, a different

value is used: 0x0055. Recall that in a regular unencrypted frame, the Protocol field

indicates what layer three protocol the data comes from; since we still need to know this,

the original Protocol value is actually prepended to the data before encryption. When the

data is decrypted, this value is used to restore the original Protocol field, so the receiving

device knows what higher layer the data belongs to.

For example, if we use IPCP to encapsulate IP data in PPP, the unencrypted frame would

have a value of 0x8021 (hex) in the Protocol field. This value (0x8021) would be placed at

the start of the data to be encrypted. The encrypted data would be put in a PPP frame with

a Protocol value of 0x0053. The receiving device would see the value 0x0053 in the

Protocol field, recognize the frame as encrypted, decrypt it and restore the original frame

with 0x8021 as the Protocol value.The discussion of the PPP general frame format covers

this more completely.

Each encrypted PPP data frame carries exactly one PPP data frame. Note that unlike what

we saw in compression, LCP frames and the control frames used for other protocols can be

encrypted. Compression can be combined with encryption; in this case compression is

done before encryption.

Table 32: PPP Encryption Control Protocol (ECP) Encryption Algorithms

ECP Option

Type Value

Defining

RFC

Encryption Algorithm (As Given in RFC Title)

0 — Proprietary

2 2420 The PPP Triple-DES Encryption Protocol (3DESE)

3 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis)

PPP Multilink Protocol (MP/MLP/MLPPP)

Most of the time, there is only a single physical layer link between two devices. There are

some situations, however, when there may actually be two layer one connections between

the same pair of devices. This may seem strange; why would there be more than one link

between any pair of machines?

There are in fact a number of situations in which this can occur. One common one is when

two links are intentionally placed between a pair of devices. This is often done to increase

performance by “widening the pipe” between two devices, without going to a newer, more

expensive technology. For example, if two machines are connected to each other using a

regular analog modem and it is too slow, a relatively simple solution is to just use two

analog modem pairs connecting the machines to double bandwidth.

A slightly different situation occurs when multiplexing creates the equivalent of several

physical layer “channels” between two devices even if they only have one hardware link

between them. Consider ISDN for example. The most common form of ISDN service (ISDN

basic rate interface or BRI) creates two 64,000 bps B channels between a pair of devices.

These B channels are time division multiplexed and carried along with a D channel on a

single pair of copper wire, but to the devices they appear as if there were two physical layer

links between devices, each of which carries 64 kbps of data. And the ISDN primary rate

interface (PRI) actually creates 23 or even more channels, all between the same pair of

hardware devices.

In a situation where we have multiple links, we could of course just establish PPP over each

connection independently. However, this is far from an ideal solution, because we would

then have to manually distribute our traffic over the two (or more) channels or links that

connect them. If you wanted to connect to the Internet, you'd have to make separate

connections and then choose which to use for each action. Not exactly a recipe for fun, and

what's worse is that you could never use all the bandwidth for a single purpose, such as

downloading the latest 100 megabyte Microsoft security patch.

What we really want is a solution that will let us combine multiple links and use them as if

they were one high-performance link. Some hardware devices actually allow this to be done

at the hardware level itself; in ISDN this technology is sometimes called bonding when done

at layer one. For those hardware units that don't provide this capability, PPP makes it

available in the form of the PPP Multilink Protocol (MP). This protocol was originally

described in RFC 1717, and was updated in RFC 1990.

Note: The PPP Multilink Protocol is properly abbreviated “MP”, but it is common to

see any of a multitude of other abbreviations used for it. Many of these are actually

derived from changing the order of the words in the name into “Multilink PPP”, so

you will frequently see this called “ML PPP”, “MLPPP”, “MPPP”, “MLP” and so forth. These

are technically “incorrect” but widely used, especially “MLPPP”. I use the correct abbrevi-

ation in this Guide.

PPP Multilink Protocol Architecture

MP is an optional feature of PPP, so it must be designed to integrate seamlessly into

regular PPP operation. To accomplish this, MP is implemented as a new architectural

“sublayer” within PPP. In essence, an MP sublayer is inserted between the “regular” PPP

mechanism and any network layer protocols using PPP, as shown in Figure 31. This allows

MP to take all network layer data to be sent over the PPP link and spread it over multiple

physical connections, without causing either the normal PPP mechanisms or the network

layer protocol interfaces to PPP to “break”.

Figure 31: Multilink PPP Architecture

The column on the left shows the TCP/IP model architecture with corresponding OSI Reference Model layer

numbers. The center column shows the normal PPP layer architecture. When Multilink PPP is used, there are

separate PPP implementations running over each of two or more physical links. Multilink PPP sits, architec-

turally, between these links and any network layer protocols to be transported over those links. (In this

diagram only IP is shown, since it is most common, but Multilink PPP can in fact work with multiple network

layer protocols, each being sent over each physical link.)

Upper Layer

Protocols

PPP

Architecture

TCP / UDP

PPP

Physical Link

(Serial, Dial-Up,

ISDN, etc.)

Multilink PPP

PPP #1

Physical

Link #1

PPP #2

Physical

Link #2

TCP / UDP

Multilink PPP

Architecture

Upper Layer

Protocols

OSI and TCP/IP

Model Layers

Application

Transport

Internet3

Network

Interface

Key Concept: The PPP Multilink Protocol (MP) allows PPP to bundle multiple

physical links and use them like a single, high-capacity link. It must be enabled

during link configuration. Once operational, it works by fragmenting whole PPP

frames and sending the fragments over different physical links.

PPP Multilink Protocol Setup and Configuration

To use MP, both devices must have it implemented as part of their PPP software and must

negotiate its use. This is done by LCP as part of the negotiation of basic link parameters in

the Link Establishment phase (just like Link Quality Reporting). Three new configuration

options are defined to be negotiated to enable MP:

☯ Multilink Maximum Received Reconstructed Unit: Provides the basic indication

that the device starting the negotiation supports MP and wants to use it. The option

contains a value specifying the maximum size of PPP frame it supports. If the device

receiving this option does not support MP it must respond with a Configure-Reject LCP

message.

☯ Multilink Short Sequence Number Header Format: Allows devices to negotiate use

of a shorter sequence number field for MP frames, for efficiency. (See the topic on MP

frames for more.)

☯ Endpoint Discriminator: Uniquely identifies the system; used to allow devices to

determine which links go to which other devices.

Before MP can be used, a successful negotiation of at least the Multilink Maximum

Received Reconstructed Unit option must be performed on each of the links between the

two devices. Once this is done and an LCP link exists for each of the physical links, a virtual

bundle is made of the LCP links and MP is enabled.

PPP Multilink Protocol Operation

As mentioned above, MP basically sits between the network layer and the regular PPP links

and acts as a “middleman”. Here is what it does for each “direction” of communication:

☯ Transmission: MP accepts datagrams received from any of the network layer

protocols configured using appropriate NCPs. It first encapsulates them into a

modified version of the regular PPP frame. It then takes that frame and decides how to

transmit it over the multiple physical links. Typically, this is done by dividing the frame

into fragments that are evenly spread out over the set of links. These are then encap-

sulated and sent over the physical links. However, an alternate strategy can also be

implemented as well, such as alternating full-sized frames between the links. Also,

smaller frames are typically not fragmented, nor are control frames such as those used

for link configuration.

☯ Reception: MP takes the fragments received from all physical links and reassembles

them into the original PPP frame. That frame is then processed like any PPP frame, by

looking at its Protocol field and passing it to the appropriate network layer protocol.