Internet Draft M.S. Nunes Document: draft-nunes-pppext-mcp-00.txt INESC Expires: December 2002 June 2002 Multi-Class PPP with Channel Preemption and Dynamic Fragmentation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines the encapsulation and mechanisms that allows PPP packets to be transported over low-bitrate links such as modem lines, ISDN B-channels, and sub-T1 links with guarantee of quality of service for time sensitive services. A mechanism of channel preemption is defined, allowing the immediate occupation of the channel with the most priority packet, resuming the transmission of the lower priority frame without need to retransmit the octets already sent. This mechanism allows a dynamic packet fragmentation, guaranteeing simultaneously a low transmission delay for the services more sensitive to transmission delays and an efficient channel occupation. It is a recursive mechanism, which means that the packet that made the channel preemption can itself be preempted by another higher priority packet, and this process can be repeated whenever a higher priority packet requests transmission. The proposed mechanism is compatible with existing hardware and drivers for asynchronous and synchronous HDLC controllers. 1. Introduction The quality of service required by time-sensitive services like packet voice and audio could not be guaranteed over low-bitrate links such as 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s ISDN B-channels, unless specific measures are taken, as recognized in [1] and [2]. Nunes Informational - Expires December 2002 Page 1 Internet-draft Multi-Class PPP with Channel Preemption June 2002 and Dynamic Fragmentation For instance, the transmission of a 1500 byte packet on a 28.8 kbit/s modem link makes this link unavailable for the transmission of real- time information for about 416 ms. This causes real-time applications to operate with round-trip delays on the order of at least a second, what is unacceptable for real-time conversation. Several proposals have been made in order to solve this problem, namely the Multi-Class Extension to Multi-Link PPP [2] and PPP in a Real-time Oriented HDLC-like Framing [3]. Next with analyze both solutions, summarizing its main advantages and indicating the problems identified. 2. Multi-Class extension to Multi-Link PPP In [2] a multi-class extension to Multi-Link PPP is proposed, where the definition of several service classes together with the fragmentation mechanism of the PPP Multilink protocol [4] allows the support of real- time services over low-bitrate links. The fragment format proposed in [2] is shown in figure 1 for the Short Sequence Number Fragment Format. Figure 1: Short Sequence Number Fragment Format With Classes +---------------+---------------+ PPP Header: | Address 0xff | Control 0x03 | +---------------+---------------+ | PID(H) 0x00 | PID(L) 0x3d | +-+-+-+-+-------+---------------+ MP Header: |B|E|cls| sequence number | +-+-+-+-+-----------------------+ | fragment data | | . | | . | | . | +-------------------------------+ PPP FCS: | FCS | +-------------------------------+ Similarly, for the long sequence number the format is similar, the only differences are the class and sequence number field lengths, which are increased to 4 bits and 3 byte, respectively. The main drawback of this proposal is the need to have a low maximum fragment size in order to achieve the required delay bound for time sensitive packets. For instance, if a maximum delay bound of 10 ms is required on a 28.8 Kbit/s link, the maximum fragment data plus headers and trailers should be limited to 36 byte, which implies a low transmission efficiency due to the large number of fragments required to transmit large packets. For instance, using the short segment fragment format, the maximum fragment data size is 28 byte, what means that a packet of 1500 byte needs to be transmitted in 54 fragments. Nunes Informational - Expires December 20022 Internet-draft Multi-Class PPP with Channel Preemption June 2002 and Dynamic Fragmentation 3. PPP in a Real-time Oriented HDLC-like framing fragmentation In order to solve the problem identified in previous section it was proposed in [3] a suspend/resume-oriented approach for the encapsulation format of real-time services. As shown in figure 2, fragments of packets that are to be suspended are terminated within the HDLC frame by a special "fragment suspend escape" byte (FSE). Figure 2: Example frame with FSE delimiter 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R | sequence | class | 1 | +---+---+---+---+---+---+---+---+ | data | | | : : +-------------------------------+ + FSE + +---+---+---+---+---+---+---+---+ | R | sequence | class | 1 | +---+---+---+---+---+---+---+---+ | data | | | : : +-------------------------------+ | Frame | | CRC | +-------------------------------+ The main problem of this proposal is that of data transparency. In the scheme described, an FSE is always followed by a compact fragment header, as shown in figure 3. In these headers, the combination of a class field set to 7 with R=1 is reserved. Data transparency is achieved by making a special procedure in case of the occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF. Depending on the combination of FSE/0xnF (where n is the first four-bit field in the second byte, RSTU in Figure 3), the n field gives a sequence of four bits indicating where in the received data stream FSE bytes, which cannot simply be transmitted in the data stream, are to be added by the receiver: 0x8F: insert one FSE, back to data 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data 0xAF: insert one FSE, copy one data byte, insert one FSE, back to data 0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back to data 0xCF: insert two FSE bytes, back to data 0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back Nunes Informational - Expires December 2002 Page 3 Internet-draft Multi-Class PPP with Channel Preemption June 2002 and Dynamic Fragmentation to data 0xEF: insert three FSE bytes, back to data 0xFF: insert four FSE bytes, back to data Figure 3: Data transparency with FSE bytes present 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R | sequence | class | 1 | +---+---+---+---+---+---+---+---+ | data | | | : : +---+---+---+---+---+---+---+---+ + FSE + fragment NOT terminated +---+---+---+---+---+---+---+---+ | R | S | T | U | 1 | 1 | 1 | 1 | R always is 1 +---+---+---+---+---+---+---+---+ | data | fragment continues | | : : This mechanism, which is required to achieve data transparency, increases the complexity of the implementation and the transmission overhead. 4. Proposal of Multi-Class Multi-Link PPP with dynamic fragmentation and channel preemption (MCP) The general approach of this proposal is to start from the Multi-Class Extensions to Multi-link PPP [2] and provide a small number of extensions to add functionality and increase the performance for time- sensitive services, while keeping a low overhead. The quality of service of the different services is guaranteed with a mechanism of channel preemption, which allows the immediate occupation of the channel with the most priority frame, resuming the transmission of the lower priority frame, without need to retransmit the octets already sent. This preemption mechanism guarantees, simultaneously, a low transmission delay for the services that are more sensitive to transmission delays and an efficient channel occupation. This mechanism is recursive, which means that the frame that preempted the channel can itself be preempted by another higher priority frame, and this process can be repeated whenever a higher priority frame requests transmission. Figure 4 shows the fragment format proposed for short sequence number. Nunes Informational - Expires December 2002 Page 4 Internet-draft Multi-Class PPP with Channel Preemption June 2002 and Dynamic Fragmentation Figure 4: Short Sequence Number Fragment Format +-------------------------------+ PPP Header: | Address 0xff | +-------------------------------+ | Control 0x03 | +-------------------------------+ | PID(H) 0x00 | +-------------------------------+ | PID(L) 0x3d | +---+---+-----------------------+ MCP Header: |- -|cls| sequence number | +---+---+-----------------------+ | fragment data | | : | +---+---+---+---+---+---+---+---+ MCP Trailer | B | E | 0 0 0 0 0 0 | +---+---+---+---+---+---+---+---+ PPP FCS: | FCS | | | +-------------------------------+ Similarly, the long sequence number format is shown in figure 5: Figure 5: Long Sequence Number Fragment Format +-------------------------------+ PPP Header: | Address 0xff | +-------------------------------+ | Control 0x03 | +-------------------------------+ | PID(H) 0x00 | +-------------------------------+ | PID(L) 0x3d | +---+---------------------------+ MCP Header: |- -| cls | +---+---------------------------+ | sequence number( 3 byte) | | : | +-------------------------------+ | fragment data | |: | +---+---+---+---+---+---+---+---+ MCP Trailer | B | E | 0 0 0 0 0 0 | +---+---+---+---+---+---+---+---+ PPP FCS: | FCS | | | +-------------------------------+ As shown in figures 4 and 5, the only modification relative to the Multi-Class extension to Multi-Link PPP [2] is that the BE field was moved to the end of the packet, just before the FCS field. Nunes Informational - Expires December 2002 Page 5 Internet-draft Multi-Class PPP with Channel Preemption June 2002 and Dynamic Fragmentation This allows to minimize the delay of channel preemption with a higher priority frame, measured from the moment it was detected by the scheduler. For compatibility with the PPP Multilink [4], the first two bits of the third byte, corresponding to the original BE bits of the MP header, are reserved. Several options are available, one is to mark them always as zero, since the BE field was moved to the MCP Trailer. Figure 6 exemplifies the preemption of a data packet by a voice packet. Figure 6: Example of preemption of a data packet by a voice packet +-------------------------------+ | HDLC Flag + PPP Header | | | +-------------------------------+ |- -|c=1| sequence number=20 | +----+ ----------- +---+---+-----------------------+ | | | fragment data (D1) | | | | : | | D1 | (t0) +---+---+---+---+---+---+---+---+ | | |B=1|E=0| 0 0 0 0 0 0 | | | +---+---+---+---+---+---+---+---+ | | | FCS (2 byte) | | | +-------------------------------+ | | | HDLC Flag + PPP Header | | | | | | | +-------------------------------+ | | |- -|c=0| sequence number=30 | |----| +---+ ---- +---+---+-----------------------+ | | | V | | fragment data V | | | | | | : | | | +---+ ---- +---+---+---+---+---+---+---+---+ | | |B=1|E=1| 0 0 0 0 0 0 | | D2 | +---+---+---+---+---+---+---+---+ | | | FCS (2 byte) | | | +-------------------------------+ | | | HDLC Flag + PPP Header | | | | | | | +-------------------------------+ +----+ |- -|c=1| sequence number=21 | +---+---+-----------------------+ | fragment data (D2) | | : | +---+---+---+---+---+---+---+---+ |B=0|E=1| 0 0 0 0 0 0 | +---+---+---+---+---+---+---+---+ | FCS (2 byte) | +-------------------------------+ It results is the transmission of three fragments (D1, V, D2). In the example the Data packet was classified with cls=1 and the voice Nunes Informational - Expires December 2002 Page 6 Internet-draft Multi-Class PPP with Channel Preemption June 2002 and Dynamic Fragmentation packets with cls=0. As seen in the figure, each class has a specific sequence counter, starting at 20 and 30 respectively in the figure. For asynchronous transmissions, the preemption delay measured from the instant of detection of the higher priority packet (t0 in figure 6) corresponds to terminate the transmission of a data byte currently being transmitted, insert the trailer octet with the BE field followed by the FCS, so the total delay is between 3 and 4 octets. Even for a low bitrate channel of 28.8 Kbit/s and considering a 10 bit asynchronous character, this gives a delay between 1 ms and 1.4 ms, a value low enough for the large majority of real-time services. It is worth noting that the preemption delay jitter is almost constant, lower then one byte transmission, what is another advantage to real-time services. For synchronous HDLC controllers the preemption delay is increased by the time needed to finish the transmission buffer of the HDLC controller, with typical values of 16 bytes, which for a 28.8 Kbit/s channel gives a delay of 4.4 ms, still a value considered good for interactive voice communications. To improve the efficiency of the system the trailer byte can be removed for the classes which are not allowed to be preempted by others, as is the case of voice and other real-time channels. 6. Security Considerations Operation of this protocol is believed to be no more and no less secure than operation of the PPP Multilink Protocol [4]. 7. References 1 Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999. 2 Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999. 3 Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999. 4 Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 8. Author's Address Mario Nunes INESC Rua Alves Redol, N.9 Phone: +351-213100256 1000 Lisboa, Portugal Email: mario.nunes@inesc.pt Nunes Informational - Expires December 2002 Page 7