Extending Point-to-Point Protocol for Integrated Services

Andrei Gurtov Research seminar on IP QoS

Motivation
n n

Real-time traffic requires a bound delay Large packets block the slow link
n

1500 B packet takes 400 ms on 28.8 bps Small Maximum Transfer Unit (MTU) is inefficient (header overhead, TCP)

IP should have large MTU

n

High-priority packets must suspend lowpriority packets

n

infinite number of levels of nesting

The main design goal for providing IS over slow links is to minimize the end-to-end delay. It is also important to achieve the lowest possible overhead as the bandwidth is scare on a slow link. The solution should not decrease the performance of non-real time traffic, the normal MTU should be available for the network layer. In ideal, up to an infinite number of levels of suspention should be possible. In practice, about eight levels should be enough on a link where packet size varies from 22 to 1500 bytes. For a slower modem link, two levels can suffice, for example audio suspends any longer packet including video, and video suspends other very long packets.

Two Approaches
n

Sender can interrupt frame transmission = sender type 1

n n

suspend/resume approach RFC 2687 PPP in Real-time Oriented HDLC-like Framing

Sender cannot interrupt frame transmission = sender type 2

n n

fragmentation approach RFC2686 The Multi-Class Extension to Multi-link PPP

Sender type 1. Such PPP implementation is able to control the transmission of each byte sent to hardware. For example, this is generally true of PC host implementations, which directly access serial interface chips byte by byte. For such senders, a suspend/resume type approach will be typically used: When a long frame is to be sent, the attempt is to send it undivided; only if higher priority packets come up during the transmission will the lower-priority long frame be suspended and later resumed. Sender type 2. The interface between the PPP and the transmission hardware is not in terms of streams of bytes, but in terms of frames. This is often true for routers that have to support a large number of slow links. Such senders have no way to suspend a frame once it has been handed down for transmission. They use a queues-offragments approach, where long packets are always split into units that are small enough to maintain the access delay goals for higherpriority traffic. There is a trade-off between the variation in access delay resulting from a large fragment size and the overhead that is incurred for every long packet by choosing a small fragment size.

Fragmentation Scheme
n

Predictable
n

admission control can make decisions

n n n n

Robust against errors Compatible with PPP Compatible with hardware Future proof

The fragmentation scheme for type 2 senders must be predictable enough that the admission control can make decisions based on its characteristics. The scheme must be robust against errors, at least with the same level of error detection as PPP. The scheme must in general cooperate well with PPP and should be as compatible to existing PPP standards as possible. The scheme must work well with existing chips and routers, because for some links framing and checksum computaion in implemented in hardware. It should not also treat synchtonous and asyncronous links differently. The scheme must be future proof. In particular, the emergence of V.80 based modems may significantly change the way PPP is used with modems.

Point-to-Point Protocol Basics

n

Based on High-level Data Link Control (HDLC) No frame length in the header (flag framing) Parameters are negotiated by Link Control Protocol (LCP) Address, Control, Protocol compression Character Escaping (Stuffing)

+---------------+ | Flag (0x7e) |

+---------------+---------------+ | Address 0xff | Control 0x03 |

+---------------+---------------+ | PID(H) y | PID(L) x |

+---------------+---------------+ | | data . | |

+---------------+---------------+ | FCS |

+---------------+---------------+ | Flag (0x7e) |

+---------------+

Here we explain the basic stracture of a PPP frame. Each frame begins and ends with a Flag Sequence, which is the binary sequence 01111110 (hexadecimal 0x7e). PPP header does not have a length field: the frame boundaries are determined with flags. The Address field is a single octet, which contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. Individual station addresses are not assigned. The Control field is a single octet, which contains the binary sequence 00000011 (hexadecimal 0x03. The Frame Check Sequence field defaults to 16 bits and protects the data from errors. Most PPP implementaions agree to omit the address, control and one byte of the protocol field. For data transparency, the control bytes need to be masked if they occur in the payload data. This can potentially double the size of a frame and badly affects scheduling in IS.

Multi-link PPP [RFC1990]

n

Allows to fragment/reassemble packets

n n

Each fragment sent as a frame 4 bytes overhead per fragment normal packet can ben sent between fragments Sender
PPP
link2 fragment2 fragment1 link1

One level of priority nesting

n

Receiver
PPP

The goal of multilink operation is to coordinate multiple independent links between a fixed pair of systems, providing a virtual link with greater bandwidth than any of the individual links. RFC1990 defines a method for splitting, recombining and sequencing packets across multiple logical data links. A four-byte sequencing header preserves the order of packets. Multi-link PPP can be uses as-is for IS to provide one level of suspention, because a non-fragmented packet can be sent during the fragments. In other words, a large low prioirity packet is fragmented, and when a high priority packet arrives it has only to wait until the current fragment is transmitted.

Extending PPP-Multilink
n n

Need more levels of nesting than one RFC 2686 The Multi-Class Extension to Multilink PPP
n

September 1999, Standard Track =prioity level

Extend Multilink to include class id

n

n n

Run one multilink protocol per class Allows 4 (16) levels of suspension with short (long) header format

To achive more than one level of suspension, we could run multilink multiple times over one link. To implement this, a few reserved bits in the mulilink header are used to distinquish between different multilink entities. These bits define a class to which the fragment belongs. It allows four level of suspension with a short multi-link sequence number, and 16 levels with a long one.

Multi-class Multilink Header

PPP Header: +---------------+---------------+ | Address 0xff | Control 0x03 | +---------------+---------------+ | PID(H) 0x00 | PID(L) 0x3d | +-+-+-+-+-------+---------------+ |B|E|cls| sequence number | +-+-+-+-+-------+---------------+ | fragment data | | . | | . | | . | +---------------+---------------+ | FCS | +---------------+---------------+

MP Header:

PPP FCS:

This slide shows the multi-class multilink header format, with class identifier bits highlighted. Other fields are unmodified from the basic multi-link header and have the following meaning. The (B)eginning 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)nding fragment bit is a one bit field set to 1 on the last fragment and set to 0 for all other fragments. A fragment may have both the (B)eginning and (E)nding fragment bits set to 1. The sequence field is a 24 bit or 12 bit number that is incremented for every fragment transmitted. By default, the sequence field is 24 bits long, but can be negotiated to be only 12 bits with an LCP configuration option described next. The class id is 2 bits long when the use of short sequence numbers has been negotiated, 6 bits otherwise.

Multilink Header Format Option

n n

Option Negotiated by LCP Code

n

long or short sequence numbers

Number of supported classes

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 27 | Length = 4 | Code | # Susp Clses |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This LCP option advises the peer that the implementation wishes to receive fragments with a format given by the code number, with the given maximum number of suspendable classes. Two code values are defined: Code = 2: long sequence number fragment format with classes Code = 6: short sequence number fragment format with classes

The number of suspendable classes bounds the allowable class numbers: only class numbers below this limit can be used for suspendable classes. Implementations may want to negotiate a number smaller than made possible by the packet format to limit their reassembly buffer space requirements.

PPP Prefix Elision

n

Typically fragments in each class would have same header (prefix)

n

beginning of the user packet

Remove prefix on sending and add on receiving

n n

prefix elision complements header/data compression

For some applications, all packets of a certain class will have a common beginning. In this case, the following optimisation is possible: the class number can be associated with a prefix of bytes that are removed from each packet before transmission and that are implicitly added to the reassembled packet after reception. If some packets of the same priority level have several distinct prefixes, it is possible to use several classes of the same priority just to support the prefix elision. Prefix elision is not a replacement for header compression or data compression: it allows implementations to compress away prefixes that often are not reachable by header or data compression methods.

10

Prefix Elision Option

n n
0

Negotiated by LCP Tells the prefix for given class

1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 26 | Option Length | Class | Prefix Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix... | Class |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Prefix...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This LCP option advises the peer that, in each of the given classes, the implementation expects to receive only packets with a certain prefix. This prefix is not to be sent as part of the information in the fragments of this class. Apart from the type and length fields common to all LCP options, the option contains a sequence of zero or more prefix lengths and data.

11

Suspend-Resume for PPP

n

n n

RFC2687, PPP is a Real-time Oriented HDLC-like Framing September 1999, Standard track Defines
n n

compact format of fragment real-time frame format

n

multiple fragments per frame

RFC2687 defines the suspend/resume-oriented solution for the realtime encapsulation format part of IS. The new fragment and frame formats are as compatible to existing hardware, as possible. Other requirements stated for a fragmentation-based approach are also valid here. A compact frame format is more optimized toward the operation over a signle link and involves less overhead than the multilink PPP fragment format. A suspend/resume-oriented solution requires a new frame format to encapsulate several fragments in a frame, but it can provide the better worst-case latency than the prefragmenting-oriented solution defined in RFC2686.

12

Compact Fragment Header

n

Cannot use Multi-link PPP directly for suspention multilink header

n n

Last fragment indicator is in header E-bit is 1

Send big packets with E=0, after dummy frames with E=1 Several bytes overhead for sending a suspendable frame

The direct use of multi-link as-is for suspend/resume approach is not possible, because whether a fragment is the last one in the packet is told by the E-bit located in the header of the frame. Thus, if a big frame is sent unfragmented, it cannot be suspended. The following trick allows to overcome this. We send frames with E-bit set to zero, that is as not the last fragment. If this packet has not been suspended, a dummy fragment is sent after to indicate that transmission of the packet is completed. Such approach, however, involves a significant overhead for sending a suspendable packet.

13

Compact Fragment Header

n

New compact fragment format

n

1 byte sequence number is used only for loss detection, reduce to 3 bits 0 1 2 3 4 5 6 7 leave out PID +---+---+---+---+---+---+---+---+
| R | | : sequence | data class | 1 | | : +---+---+---+---+---+---+---+---+
Resumes = not first fragment

Optimization for single link

n

+---+---+---+---+---+---+---+---+

While the formats defined in RFC2687 and RFC2686 are based on the PPP multilink protocol, operation over multiple links is in many cases not required. When operating over a single link, the multilink sequence number is used only for loss detection. Even a 12-bit sequence number clearly is larger than required for this on most kinds of links. The following compact multilink header format is defined with a three-bit sequence number. As there is little need for sending packets outside the multilink, the protocol identifier is not sent with the compact fragment header. Having the least significant bit always be 1 helps with HDLC chips. The R bit is the inverted equivalent of the B bit in the other multilink fragment formats, i.e. R = 1 means that this fragment resumes a packet previous fragments of which have been sent already. Class 7 frames by design cannot be suspended/resumed to avoid the control sequence (0xFF).

14

Real-time Frame Format

n n

n n

Packet can be suspended any time Need a delimiter to separate fragments in a frame No framing overhead for fragments Fragment Suspend Escape (FSE)
n n

means end of a fragment advanced stuffing for data transparrency

This slide desribes the new real-time encapsulaiton format for PPP, that is a new frame structure. It is more efficient than the normal PPP frame format and can contain several fragments. The new format should work fine with existing hardware. The new frame format is simply a collection of fragments in the compact header format. Fragments are separated using a special delimeter byte called Fragment Suspend Escape (FSE). Instead of E-bit in the multilink header, the following scheme is deifned. Any normal frame ending also ends the current fragment with E implicitly set to one. Other fragments in the frame are assumed ro me suspended and thus are not last in their packets (E=0). The data part the last fragment can end in an FSE to indicate that the last fragment is not the last (E = 0).

15

Real-time Frame Format

0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R | sequence | class | 1 | +---+---+---+---+---+---+---+---+ | data | : : +---+---+---+---+---+---+---+---+ + FSE + +---+---+---+---+---+---+---+---+ | R | sequence | class | 1 | +---+---+---+---+---+---+---+---+ | data | : : +---+---+---+---+---+---+---+---+ | Frame | | CRC | +---+---+---+---+---+---+---+---+

This slide gives a possible frame structure that contains two fragments. The value chosen for FSE is 0xDE (this is a relatively unlikely byte to occur in today's data streams, it does not trigger octet stuffing and triggers bit stuffing only for 1/8 of the possible preceding bytes). The detection and handling of FSE bytes is done at a layer above HDLC framing. The remaining problem of data transparency is solved by an advanced escaping sceme. Eight different escape patterns are defined, for example: 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data This technique allows to reduce the worse case increase in the frame size due to stuffing of FSE to 25%.

16

Multilink header format option

n

Same option as was shown for multiclass multi-link Two new header types
n

Compact header with short or long sequence numbers

1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 27 | Length = 4 | Code | # Susp Clses |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This LCP option, as has been already described, advises the peer that the implementation wishes to receive fragments with a format given by the code number, with the given maximum number of suspendable classes. RFC2687 defines two new values for Code, in addition to those already defined in RFC2686: - Code = 11: basic and extended compact real-time fragment format with classes, in FSE-encoded HDLC frame - Code = 15: basic compact real-time fragment format with classes, in FSE-encoded HDLC frame

17

Conclusion
n n n

Extending PPP for IS Multi-link PPP is the base Extensions

n n n n

multiple classes of fragments prefix elision new fragment format new frame format

RFC2687 and RFC2686 extend Point-to-Point Protocol to support Integrated Services over slow links. The multilink PPP protocol provides fragmentation/reassembly scheme, and it is taken as a starting point. For senders that cannot interrupt a frame transmission, RFC2686 provides a multi-class extension of the multi-link protocol to provide several priority levels of fragments. RFC2686 also defines a new compression technique called prefix ellision. If all packets in a class begin with the same sequence of bytes, these bytes are not transmitted on the link. Prefix elision allows to compress bytes that are often not reachable by the header or body compression. For senders that are capable to interrupt the transmission of a current frame, RFC2687 defines a new frame format that can carry several fragments inside. In contrast with the pure fragmentation approach (RFC2686) packets are fragmented on the fly if necessary, i.e. when a higher priority packet has arrived. A new compact fragment format is also defined. It is smaller than the multi-link fragment format, and in the case of operation over a single link involves only 1-byte header.

18