rfc2686.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

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.

Abstract

   A companion document describes an architecture for providing
   integrated services over low-bitrate links, such as modem lines, ISDN
   B-channels, and sub-T1 links [1].  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
   [2] and provide a small number of extensions to add functionality and
   reduce the overhead.

1.  Introduction

   As an extension to the "best-effort" services the Internet is well-
   known for, additional types of services ("integrated services") that
   support the transport of real-time multimedia information are being
   developed for, and deployed in the Internet.

   The present document defines the fragment-oriented solution for the
   real-time encapsulation format part of the architecture, i.e. for the
   queues-of-fragments type sender [1].  As described in more detail in
   the architecture document, a real-time encapsulation format is



Bormann                     Standards Track                     [Page 1]

RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999


   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 [5] defines a
   suspend/resume-oriented solution for those cases where the best
   possible delay is required and the senders are of type 1 [1].

1.1.  Specification Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [8].

2.  Requirements

   The main design goal for the components of an architecture that
   addresses real-time multimedia flows over low-bitrate links is that
   of minimizing the end-to-end delay.  More specifically, the worst
   case delay (after removing possible outliers, which are equivalent to
   packet losses from an application point of view) is what determines
   the playout points selected by the applications and thus the delay
   actually perceived by the user.

   In addition, every attempt should obviously be undertaken to maximize
   the bandwidth actually available to media data; overheads must be
   minimized.

   The solution should not place unnecessary burdens on the non-real-
   time flows.  In particular, the usual MTU should be available to
   these flows.

   The most general approach would provide the ability to suspend any
   packet (real-time or not) for a more urgent real-time packet, up to
   an infinite number of levels of nesting.  On the other hand, it is
   likely that there would rarely be a requirement for a real-time
   packet to suspend another real-time packet that is not at least about
   twice as long.  Typically, the largest packet size to be expected on
   a PPP link is the default MTU of 1500 bytes.  The smallest high-
   priority packets are likely to have on the order of 22 bytes
   (compressed RTP/G.723.1 packets).  In the 1:72 range of packet sizes
   to be expected, this translates to a maximum requirement of about



Bormann                     Standards Track                     [Page 2]

RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999


   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
        [1], 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 [1] 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" [3].









Bormann                     Standards Track                     [Page 3]

RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999


3.  Using PPP Multilink as-is

   Transmitting only part of a packet to allow higher-priority traffic
   to intervene and resuming its transmission later on is a kind of
   fragmentation.  The existing PPP Multilink Protocol (MP, [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 [2]

                +---------------+---------------+
   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.

3.1.  Limitations of multilink as-is

   Multilink-as-is is not the complete solution for a number of reasons.
   First, because of the single monotonically increasing serial number,
   there is only one level of suspension:  "Big" packets that are sent
   via multilink can be suspended by "small" packets sent outside of
   multilink; the latter are not fragmentable (and therefore, the
   content of one packet cannot be sent in parallel on multiple links;



Bormann                     Standards Track                     [Page 4]

RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999


   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.

4.  Extending PPP Multilink to multiple classes

   The obvious approach to providing more than one level of suspension
   with PPP Multilink is to run Multilink multiple times over one link.
   Multilink as it is defined provides no way for more than one instance
   to be active.  Fortunately, a number of bits are unused in the
   Multilink header: two bits in the short sequence number format (as
   can be seen in Figure 1), six in the long sequence number format.

   This document defines (some of the) previously unused bits as a class
   number:

       Figure 2: 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              |
                +---------------+---------------+

   Each class runs a separate copy of the mechanism defined in [2], i.e.
   uses a separate sequence number space and reassembly buffer.











Bormann                     Standards Track                     [Page 5]

RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999


   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