Network Working Group C. Bormann Request for Comments: 2686 Universitaet Bremen TZI Category: Standards Track September 1999 The Multi-Class Extension to Multi-Link PPP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.
AbstractA companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links . The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. This document proposes the fragment-oriented solution for the real- time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol  and provide a small number of extensions to add functionality and reduce the overhead. 1]. As described in more detail in the architecture document, a real-time encapsulation format is
required as, e.g., 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 400 ms. This adds a worst-case delay that causes real-time applications to operate with round-trip delays on the order of at least a second -- unacceptable for real-time conversation. The PPP extensions defined in this document allow a sender to fragment the packets of various priorities into multiple classes of fragments, allowing high-priority packets to be sent between fragments of lower priorities. A companion document based on these extensions  defines a suspend/resume-oriented solution for those cases where the best possible delay is required and the senders are of type 1 . RFC 2119 .
eight levels of suspension (including one level where long real-time packets suspend long non-real-time packets). On 28.8kbit/s modems, there seems to be a practical requirement for at least two levels of suspension (i.e., audio suspends any longer packet including video, video suspends other very long packets). On an architectural level, there are several additional requirements for the fragmentation scheme: a) The scheme must be predictable enough that admission control can make decisions based on its characteristics. As is argued in , this will often only be the case when additional hints about the characteristics of the flow itself are available (application hints). b) The scheme must be robust against errors, at least with the same level of error detection as PPP. c) The scheme must in general cooperate nicely with PPP. In particular, it should be as compatible to existing PPP standards as possible. On a link that (based on PPP negotiation) makes use of the scheme, it should always be possible to fall back to standard LCP (PPP Link Control Protocol [6, 7]) without ambiguity. d) The scheme must work well with existing chips and router systems. (See  for a more extensive discussion of implementation models.) For synchronous links this means using HDLC framing; with much existing hardware, it is also hard to switch off the HDLC per-frame CRC. For asynchronous links, there is much more freedom in design; on the other hand, a design that treats them much different from synchronous links would lose a number of desirable properties of PPP. e) 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. This document does not address additional requirements that may be relevant in conjunction with Frame Relay; however, there seems to be little problem in applying the principles of this document to "PPP in Frame Relay" .
2]) provides for sequence numbering and begin/end bits, allowing packets to be split into fragments (Figure 1). Figure 1: Multilink Short Sequence Number Fragment Format  +---------------+---------------+ PPP Header: | Address 0xff | Control 0x03 | +---------------+---------------+ | PID(H) 0x00 | PID(L) 0x3d | +-+-+-+-+-------+---------------+ MP Header: |B|E|0|0| sequence number | +-+-+-+-+-------+---------------+ | fragment data | | . | | . | | . | +---------------+---------------+ PPP FCS: | FCS | +---------------+---------------+ (Note that the address, control, and most significant PID bytes are often negotiated to be compressed away.) MP's monotonically increasing sequence numbering (contiguous numbers are needed for all fragments of a packet) does not allow suspension of the sending of a sequence of fragments of one packet in order to send another packet. It is, however, possible to send intervening packets that are not encapsulated in multilink headers; thus, MP supports two levels of priority. The multilink-as-is approach can be built using existing standards; multilink capability is now widely deployed and only the sending side needs to be aware that they are using this for giving priority to real-time packets.
if the packets are sent in rounds on multiple links, the order they are processed at the receiver may differ from the order they were sent). A problem not solved by this specification is that the multi-link header is relatively large; as delay bounds become small (for queues-of-fragments type implementations) the overhead may become significant. 2], i.e. uses a separate sequence number space and reassembly buffer.
Similarly, for the long sequence number format: Figure 3: Long Sequence Number Fragment Format With Classes +---------------+---------------+ PPP Header: | Address 0xff | Control 0x03 | +---------------+---------------+ | PID(H) 0x00 | PID(L) 0x3d | +-+-+-+-+-+-+-+-+---------------+ MP Header: |B|E| class |0|0|sequence number| +-+-+-+-+-+-+-+-+---------------+ | sequence number (L) | +---------------+---------------+ | fragment data | | . | | . | | . | +---------------+---------------+ PPP FCS: | FCS | +---------------+---------------+ Together with the ability to send packets without a multilink header, this provides four levels of suspension with 12-bit headers (probably sufficient for many practical applications) and sixteen levels with 24-bit headers (only four of the six free bits are used in this case -- based on the rationale given above, sixteen levels should generally be more than sufficient).
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.
The values defined in this document for the use of this option are: - Code = 2: long sequence number fragment format with classes - Code = 6: short sequence number fragment format with classes The Multilink Header Format option MUST NOT occur more than once in a Configure-Request or Configure-Ack, and, if it is present, the Short Sequence Number Header Format option () MUST NOT also be present. If no instance of this option or the Short Sequence Number Header Format option is present, but an MRRU option  is present, then by default, long sequence number multilink headers with class 0 only are used; this is equivalent to code equals 2 and number of suspendable classes equals 1. An instance of the Short Sequence Number Header Format Option is equivalent to an instance of this option with code equals 6 and number of suspendable classes equal to 1. The number of suspendable classes bounds the allowable class numbers: only class numbers numerically lower than 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. Implementations SHOULD at least support the value 4 for the short sequence number fragment format, and the value 8 for the long sequence number fragment format, unless configured differently. Bit combinations that would indicate class numbers outside the negotiated range MAY be used for other semantics if negotiated by other means outside the scope of this document (e.g., ).
Figure 5: 0 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Prefix Elision option MUST NOT occur more than once in a Configure-Request or Configure-Nak. If this option is offered on a link which is intended to join an existing multilink bundle, a system MUST offer the same prefix elision option value previously negotiated for the bundle, or none if none was negotiated previously. IMPLEMENTATION NOTE: as with most PPP options that indicate capabilities of the receiver to the sender, the sense of this option is an indication from the receiver to the sender of the packets concerned. Often, only the senders will have sufficient control over their usage of classes to be able to supply useful values for this option. A receiver willing to accept prefix-elided packets SHOULD request this option with empty content; the sender then can use Configure-Nak to propose the class-to-prefix mapping desired. 2].  Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.  Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.  Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP", Work in Progress.  Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.