[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2686                                  
INTERNET-DRAFT                                           Carsten Bormann
Expires: March 1997                                  Universitaet Bremen
                                                          September 1996


              The Multi-Class Extension to Multi-Link PPP
                  draft-ietf-issll-isslow-mcml-00.txt


Status of this memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

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

   This document is a product of the IETF ISSLL working group.  It is
   also a submission to the IETF PPPEXT working group.
   Comments are solicited and should be addressed to the two working
   groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
   ppp@merit.edu and/or the author.



Bormann                                                         [Page 1]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

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.

   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.

   The present document defines the real-time encapsulation format part
   of the architecture.  As described in more detail in the architecture
   document, such a 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.


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-

Bormann                                                         [Page 2]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   priority packets are likely to have on the order of 21 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
   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).

   An on 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 without ambiguity.

   d)   The scheme must work well with existing chips and router
        systems.  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 asynchronous 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.

   The current draft 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 draft to ``PPP
   in Frame Relay'' [3].



3.  Implementation models

   This section introduces a number of terms for types of
   implementations that are likely to emerge.  It is important to have
   these different implementation models in mind as there is no single
   approach that fits all models best.


Bormann                                                         [Page 3]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

3.1.  Sender types

   There are two fundamental approaches to real-time transmission on
   low-bitrate links:

   Sender type 1
        The PPP real-time framing implementation is able to control the
        transmission of each byte being transmitted with some known,
        bounded delay (e.g., due to FIFOs).  For example, this is
        generally true of PC host implementations, which directly access
        serial interface chips byte by byte or by filling a very small
        FIFO.  For type 1 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.  This approach allows the minimum
        variation in access delay for high-priority packets; also,
        fragmentation overhead is only incurred when actually needed.

   Sender type 2
        With type 2 senders, the interface between the PPP real-time
        framing implementation and the transmission hardware is not in
        terms of streams of bytes, but in terms of frames, e.g., in the
        form of multiple (prioritized) send queues directly supported by
        hardware.  This is often true of router systems for synchronous
        links, in particular those that have to support a large number
        of low-bitrate links.  As type 2 senders have no way to suspend
        a frame once it has been handed down for transmission, they
        typically will use a queues-of-fragments approach, where long
        packets are always split into units that are small enough to
        maintain the access delay goals for higher-priority 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.

3.2.  Receiver types

   Although the actual work of formulating transmission streams for
   real-time applications is performed at the sender, the ability of the
   receiver to immediately make use of the information received depends
   on its characteristics:

   Receiver type 1
        Type 1 receivers have full control over the stream of bytes
        received within PPP frames, i.e., bytes received are available
        immediately to the PPP real-time framing implementation (with
        some known, bounded delay e.g. due to FIFOs etc.).

   Receiver type 2
        With type 2 receivers, the PPP real-time framing implementation
        only gets hold of a frame when it has been received completely,
        i.e., the final flag has been processed (typically by some HDLC

Bormann                                                         [Page 4]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

        chip that directly fills a memory buffer).

4.  Using existing mechanisms

   Suspending the transmission of packets and resuming their
   transmission later on is a kind of fragmentation.  Fragmentation is
   existing functionality of the IP layer.  As fragmentation and
   reassembly also are useful in a logical link composed of multiple
   physical links, PPP Multilink (a standards track protocol) already
   defines a fragmentation mechanism [2].  Unfortunately, neither
   approach, as is, fulfills all the requirements listed above.


4.1.  Using IP fragmentation

   An IPv4 header already contains fields that allow a large IP datagram
   to be fragmented into small parts.  A queues-of-fragments type sender
   might simply indicate a small MTU to its IP stack and thus cause all
   larger datagrams to be fragmented down to a size that allows the
   access delay goals to be met[1].  (Also, a PPP implementation can
   negotiate down the MTU of its peer, causing the peer to fragment to a
   small size, which might be considered a crude form of negotiating an
   access delay goal with the peer system -- if that system supports
   priority queueing at the fragment level.)

   Unfortunately, a full, 20 byte IP header is needed for each fragment
   (larger when IP options are used).  This limits the minimum size of
   fragment that can be used without too much overhead.  (Also, the size
   of non-final fragments must be a multiple of 8, further limiting the
   choice.)  With path MTU discovery, IP level fragmentation causes TCP
   implementations to use small MSSs -- this further increases the per-
   packet overhead to 40 bytes per fragment.

   In any case, fragmentation at the IP level persists on the path
   further down to the datagram receiver, increasing the transmission
   overheads and router load throughout the network.  With its high
   overhead and the adverse effect on the Internet, IP level
   fragmentation can only be a stop-gap mechanism when no other
   fragmentation protocol is available in the peer implementation.


4.2.  Using PPP Multilink as-is


   The PPP Multilink Protocol (MP) provides for sequence numbering and
   begin/end bits, allowing packets to be split into fragments.
_________________________
  [1] This assumes that the IP stack is able to priority-tag frag-
ments,  or  that  the  PPP implementation is able to correlate the
fragments to the initial one that carries the information relevant
for  prioritizing,  or  that  only  initial fragments can be high-
priority.


Bormann                                                         [Page 5]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996


       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 to suspend
   sending a sequence of fragments of one packet for sending 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.

4.3.  Limitations of multilink as-is

   Multilink-as-is is not the ideal 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 suspendable.

   Second, the ``end'' bit is in the multilink header, which is the
   wrong place for suspend/resume type senders.  To make a big packet
   suspendable, it must be sent with the ``end'' bit off, and (unless
   the packet was suspended a small number of bytes before its end) an
   empty fragment has to be sent afterwards to ``close'' the packet.
   The minimum overhead for sending a suspendable packet thus is twice
   the multilink header size (six bytes, including a compressed
   multilink protocol field) plus one PPP framing (three bytes).  Each
   suspension costs another six bytes (not counting the overhead of the
   framing for the intervening packet).


Bormann                                                         [Page 6]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   Third, the multi-link header is relatively large; as delay bounds
   become small (for queues-of-fragments type implementations) or the
   frequency of small high-priority packets increases (for
   suspend/resume type implementations), the overhead may become
   significant.

   The general approach of this document is to start from PPP Multilink
   and provide a number of extensions to add functionality and reduce
   the overhead of using PPP Multilink for real-time transmission.

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

   Similarly, for the long sequence number format:












Bormann                                                         [Page 7]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996


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

6.  Sending the final bit at the end of the packet

   As explained above, having the ``end'' bit within the packet header
   causes additional overhead with suspend/resume type senders.  This
   section defines an alternative way to convey the end bit that allows
   deferring the decision whether the fragment is final or needs to be
   suspended to the point in time when the fragment is ended.

   In this scheme, the value of the end bit is contained in the last
   byte of each frame information field.  If the byte has the value
   SUSPEND (0xC3), the end bit is zero (i.e., the fragment is not the
   last one of the packet); the byte is NOT part of the data of the
   packet.  If the byte has the value END (0xDE), the end bit is one
   (i.e., this is the last fragment of the packet); the byte is NOT part
   of the data of the packet.  If the byte has any other value, the end
   bit is one (i.e., this is the last fragment of the packet); the byte
   IS part of the data of the fragment.  (Assuming an equal distribution
   of final bytes[2], the average overhead of this scheme for non-
_________________________
  [2] Actually,  the  distribution is not at all equal: In a trace
of slightly more than a million packets on a  busy  Ethernet,  the
values 0xDE and 0xC3 both occurred only 244 times as the last byte
of a packet.  Obviously, the distribution will not be  as  unequal
when data compression and/or encryption are in use.


Bormann                                                         [Page 8]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   suspended frames is 1/128 byte; the overhead for suspended frames is
   exactly 1 byte.)

   As the end bit is then no longer required in the header, the free bit
   can be used as an additional bit for the class number in the short
   sequence number fragment format:

     Figure 4: Short Sequence Number Fragment Format With Classes and
   Trailing End Bit
                +---------------+---------------+
   PPP Header:  | Address 0xff  | Control 0x03  |
                +---------------+---------------+
                | PID(H)  0x00  | PID(L)  0x3d  |
                +-+-+-+-+-------+---------------+
   MP Header:   |B|class|    sequence number    |
                +-+-+-+-+-------+---------------+
                |    fragment data              |
                |               .               |
                |               .               |
                |               .               |
                |               ................+
                |               . SSP/TRM (opt) :
                +---------------+---------------+
   PPP FCS:     |              FCS              |
                +---------------+---------------+


   For the long sequence number fragment format, the freed bit is sent
   as zero.

7.  Prefix elision: Compressing common header bytes

   For some applications, all packets of a certain class will have a
   common protocol identifier (or even more than one common prefix
   byte).  In this case, the following optimization 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
   prepended to the reassembled packet after reception.

   Note that if only some of the packets to be transmitted at a certain
   level of priority have the common prefix, it may still be possible to
   utilize this method by allocating two class numbers and only
   associating one of them with the prefix.  (This is the reason four of
   the unused bits in the long sequence number format have been
   allocated to the class number instead of the three that generally
   should suffice.)

   Prefix elision is not a replacement for header compression or data
   compression: it allows to compress away prefixes that often are not
   reachable by these other methods.




Bormann                                                         [Page 9]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

8.  The compact fragment format

   This section describes an optional multilink fragment format that is
   more optimized towards single-link operation and frequent suspension
   (type 1)/a small fragment size (type 2).  This format has been
   designed to retain the overall HDLC based format of frames, so that
   existing synchronous HDLC chips and async to sync converters can be
   used on the link.  If the design can be optimized for async only
   operation, more design alternatives are available [4]; with the
   advent of V.80 style modems, asynchronous communications may decrease
   in importance, though.

   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 application on most kinds of links.
   We therefore define a third, compact multilink header format option.

   As, with a compact header, we can expect all packets to be sent over
   the multilink, we can provide an additional compression mechanism for
   this format: the MP protocol identifier is not sent with the compact
   fragment header.  This obviously requires prior negotiation (similar
   to the way address and control field compression are negotiated), as
   well as avoiding the bit combination 0xFF, as the start of a new LCP
   negotiation could otherwise not be reliably detected.


9.  Normal header:


            Figure 5:  Compact Fragment Format (Normal Header).
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | R |  sequence |   class   | 1 |
   +---+---+---+---+---+---+---+---+
   |            data               |
   :                               :
   +...............................+
   :       SUSPEND/TERMINATE       :
   +---+---+---+---+---+---+---+---+
   |             Frame             |
   |              CRC              |
   +---+---+---+---+---+---+---+---+


   Having the last bit always be 1 helps with HDLC chips that operate
   specially on least significant bits in HDLC addresses.

   The R bit is the inverted equivalent of the B bit in the other
   fragment formats, i.e. R = 1 means that this fragment resumes a
   packet previous fragments of which have been sent already.

   The following trick avoids the case of a header byte of 0xFF: For
   class 7, the R bit can never be one.  This means that class 7 frames

Bormann                                                        [Page 10]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   cannot be suspended/resumed.  (This is also the reason the sense of
   the B bit is inverted to an R bit in the compact fragment format.)

   [[[The sequence number is not particularly useful with class 7 and
   could be used to distinguish eight more classes -- this would add
   complexity but also increase the usefulness of prefix elision.  The
   author currently does not see a strong requirement for this.]]]

10.  Insertion header:

   In many cases, when a frame is suspended, a very short frame is
   interspersed and the suspended frame is then immediately continued.
   In certain cases, it may be beneficial to further reduce the overhead
   associated with this by removing the intermediate flag(s) and
   replacing the 16-bit (or larger) CRC by a smaller CRC.

   If the compact fragment format with insertion headers is negotiated,
   a frame in the compact fragment format can start with the content of
   one or more short packets, called ``insertions''.  Each of these
   packets is protected by an 8-bit CRC, computed over the insertion
   header byte and the data part sent in the insertion.  At the end of
   the insertion, no flag is sent, but another (insertion or normal)
   header follows immediately.  The frame finally ends in a normal
   header, data for this header, and a frame CRC that covers the entire
   of all inserted and normal packets.  Alternatively, the frame can
   simply be ended after an inserted packet by sending the frame CRC and
   terminating flag(s).

          Figure 6:  Compact Fragment Format (Insertion Header).
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |        length L       | C | 0 |
   +---+---+---+---+---+---+---+---+
   :                               :
   :        Inserted packet        :
   :          (length L)           :
   :                               :
   +---+---+---+---+---+---+---+---+
   |           8-bit CRC           |
   +---+---+---+---+---+---+---+---+
   |          next header          |
   :     (insertion or normal)     :
   :      (possibly repeated)      :
   +---+---+---+---+---+---+---+---+
   |    Frame CRC (covering all    |
   |  all data between the flags)  |
   +---+---+---+---+---+---+---+---+


   The class number of a packet in the insertion is computed from the C-
   bit as ``class = C + 8'', i.e., we reserve classes 8 and 9 for
   inserted packets.  As an example, one could use class number 8 for
   compressed RTP (saving one or two additional bytes with prefix

Bormann                                                        [Page 11]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   elision) and 9 for any other packet type.  (Note that, as with class
   7, classes 8 and 9 cannot be suspended, as there is no way to
   indicate suspension or resumption.)

   Since not all serial hardware can immediately deliver initial parts
   of frames that have not yet completely arrived (see ``type 2
   receivers'' in section 3 above), the use of the insertion header may
   be counter-productive in achieving latency goals; it therefore can be
   negotiated separately from the use of the normal compact header..
   Also, because the initial byte of the HDLC frame has a zero LSB, this
   format may not be applicable if chips are used that do strange things
   with the last bit of address field bytes.



   Implementation note: A sender should not send too many insertions
   before a normal header fragment in one frame, as the overall
   reliability of the actual data part of the frame (as indicated by the
   frame CRC) suffers.


11.  Negotiable options

   The following options are already defined by MP:

   o    Multilink Maximum Received Reconstructed Unit

   o    Multilink Short Sequence Number Header Format

   o    Endpoint Discriminator

11.1.  Multilink header format option


   A summary of the Multilink Header Format Option format is shown
   below.  The fields are transmitted from left to right.

                                 Figure 7:
    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |  Length = 3   |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This option advises the peer that the implementation wishes to
   receive fragments with a format given by the code number.  By
   default, long sequence number multilink headers without classes and
   the end bit in the header are used.  When this option is received, an
   implementation MUST either transmit all subsequent multilink packets
   on all links of the bundle with the multilink header format given or
   configure-NAK or configure-Reject the option.


Bormann                                                        [Page 12]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   The value defined for code are:

   -    0 or option not present: long sequence number fragment format

   -    2: long sequence number fragment format with classes

   -    3: long sequence number fragment format with classes and
        trailing end bit

   -    4 or Short Sequence Number Header Format Option (type 18)
        present: short sequence number fragment format

   -    6: short sequence number fragment format with classes

   -    7: short sequence number fragment format with classes and
        trailing end bit

   -    11: compact fragment format (always with classes and trailing
        end bit) with normal header only

   -    15: compact fragment format (always with classes and trailing
        end bit) with normal and insertion headers

   [[[Note for further discussion: The number of alternatives is too
   large.  The variations possible should be restricted to have a good
   chance that two peer implementations have one option in common.]]]

11.2.  Prefix elision option


   This option advises the peer that the implementation wishes to send
   only packets with a certain prefix in each of the given classes; the
   prefix is not sent as part of the information in the fragment(s) of
   this class.  By default, this common prefix is empty for all classes.
   When this option is received, an implementation MUST either add the
   prefix given for the class to all subsequently received multilink
   packets of each of the given classes on all links of the bundle or
   configure-NAK or configure-Reject the option.

   If one of the formats with classes has not been negotiated, class 0
   is used to indicate a common prefix for all packets sent within
   multilink fragments.

                                 Figure 8:
    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 = TBD  | Option Length |    Class      | Prefix Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix...
   +-+-+-+-+-+-+-+-+



Bormann                                                        [Page 13]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   Note that the sense of this option is an indication from the sender
   to the receiver, unlike most PPP options that indicate capabilities
   of the receiver to the sender.

12.  Acknowledgements

   David Oran suggested using PPP Multilink for real-time framing and
   reminded the author of his earlier attempts of making Multilink more
   useful for this purpose.  The participants in a lunch BOF at the
   Montreal IETF gave useful input on the design tradeoffs in various
   environments.


13.  References


   [1]  C. Bormann, Providing integrated services over low-bitrate
        links, work in progress (draft-ietf-issll-isslow-00.txt), June
        1996.

   [2]  K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The
        PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes
        RFC1717).

   [3]  W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996.

   [4]  R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'',
        September 20, 1996, Work in Progress (draft-andrades-framing-
        ext-00.txt).


14.  Addresses


14.1.  Working Group

   The ISSLL working group can be contacted via the co-chairs, Eric
   Crawley <esc@baynetworks.com> and John Wroclawski <jtw@lcs.mit.edu>,
   or via its WG mailing list <issll@mercury.lcs.mit.edu>.

14.2.  Author's address


   Carsten Bormann
   Universitaet Bremen FB3 TZI
   Postfach 330440
   D-28334 Bremen, GERMANY
   cabo@informatik.uni-bremen.de
   phone +49.421.218-7024





Bormann                                                        [Page 14]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

A.  Benchmarks

   For the following considerations, we will define the ``normal'' PPP
   header overhead to be four bytes: one byte of protocol identifier
   (assuming address and control field compression as well as the use of
   protocols that have protocol identifiers that can be compressed to
   one byte), two bytes of CRC and one byte of flag.  These assumptions
   are not entirely accurate, as the protocol identifier and the CRC are
   subject to bit- or octet-stuffing, slightly increasing the overhead.
   In addition, many of the synchronous serial chips used today cannot
   easily output frames that are delimited by only a single flag byte.

   Just sending two packets sequentially using standard encapsulation
   thus costs 8 bytes:

           Pid1 . . . 2*CRC Flag Pid2 . . . 2*CRC Flag

   Basic 12-bit multilink adds 3 bytes of header overhead to each
   packet, as well as six bytes (the same three bytes plus four bytes
   normal PPP overhead, minus the protocol identifier) to each
   additional fragment.

           MPPid 2*MPH Pid . . . 2*CRC Flag
           Pid . . . 2*CRC Flag
           MPPid 2*MPH . . . 2*CRC Flag

   Being able to insert a real-time frame into a long packet
   encapsulated in basic multilink therefore requires 9 more bytes of
   overhead than just sending the two packets sequentially using
   standard encapsulation.  The six-byte overhead will generally recur
   for longer packets, as the final bit is in the packet header and thus
   at least one additional fragment (zero length, just to carry the
   final bit) is required.

   12-bit multilink with classes does not change the overhead at the top
   level of priorities, unless the header prefix option is used and is
   useful (i.e., only a small number of PPP protocol identifiers is in
   use).  In that case, 1 byte of overhead is saved per low-priority
   packet.

   The compact header reduces the additional per-packet overhead to 1
   byte (or 0 bytes if the header prefix option is effective).  The
   total additional overhead for the insertion of a real-time frame thus
   is only 6 to 4 bytes, if the special insertion header cannot be used.

           NH [Pid] . . . 2*CRC Flag
           NH [Pid] . . . 2*CRC Flag
           NH . . . 2*CRC Flag

   If the insertion header can be used, the additional overhead is
   reduced by two more bytes, i.e., 4 to 2 bytes (of which one is the
   block check byte).


Bormann                                                        [Page 15]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996


           NH [Pid] . . . 2*CRC Flag
           IH [Pid] . . . 1*CRC NH . . . 2*CRC Flag


   H.223 achieves even better numbers by using a per-packet CRC only (2
   bytes saved) and, in the best case that the inserted packet is of a
   repetitive length that has been defined in the multiplex table, a
   common header for both elements of the second frame (1 more byte
   saved).  The first saving does not seem to be practical with many
   current synchronous chips (although it could be made an option, in
   particular for asynchronous applications -- some way would have to be
   found to protect the compact header then, though); the second saving
   is dubious in a more dynamic, multiple-packet-stream environment.

B.  Usage Scenarios

   Scenario: Two low-bitrate links are in the path between two internet
   telephones that use G.723.1 compression for 20 byte audio packets (as
   per G.723.1), with C-RTP headers of 2 bytes.  These are repeated
   every 30 ms.

   To simplify the calculations, background traffic consists of a
   continuous, infinite length packet.  For packet size distributions
   found in actual use, the resulting numbers would be more favorable to
   compact headers.

   For the compact header, the PPP overhead is four bytes; for insertion
   headers, it is two bytes; in both cases, any packet that was
   interrupted needs to be resumed with an additional overhead of four
   bytes.  For the 12-bit header without classes, the PPP overhead for
   the audio frames also is four bytes; the overhead per fragment of
   other data is six bytes.

   As an rather lenient performance requirement, we allow a round-trip
   delay budget of 300 ms (note that investigations show that this delay
   already significantly reduces the mean opinion score).  Of the 150 ms
   available per path, 70 ms are reserved for delays in the rest of the
   path, so 40 ms is the delay budget per link; we neglect transmission
   delays.  (If better values than 70 ms in the network become
   realistic, it is likely that one would want to reduce the overall
   delay instead of allocating more of it to the low-speed links).


B.1.  GSM Scenario (9600 bit/s)

   We assume a transparent, full-duplex 9600 bit/s link as could be
   found on a full rate traffic channel in the GSM mobile phone system.
   For these considerations, we ignore the additional delays that are
   encountered in the air interface and its interleaving mechanisms.

   At 1200 bytes per second, a maximum of 36 bytes can be transmitted
   per 30 ms; note that for 22 bytes of payload at 1200 byte/s, about 20

Bormann                                                        [Page 16]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   ms of the 40 ms delay budget are already taken for the actual sending
   of the packet.  A regular fragmentation schedule would therefore have
   to operate in 20 ms units, at about 24 bytes per fragment (of which
   six are taken for fragmentation overhead -- an efficiency of about 75
   %).  At 1200 bytes per second, the load during a talkspurt is 26/1200
   seconds every 30 ms, i.e., 22 ms every 30 ms; the capacity remaining
   for data is about 170 byte/s.

   It is obvious that an efficient fragmentation mechanism is required
   to allow significant data to flow during talkspurts.  With insertion
   headers, the overhead per packet can be limited to 6 bytes, leaving
   room for 8 bytes of actual data per 30 ms, or 270 byte/s.

   Note that, as the access delay is very small with a suspend/resume
   mode, part of the delay budget could be used by the application for
   assembling two G.723.1 frames into one packet (at 40 + 2 C-RTP
   bytes); there is then room for 24 bytes of non-audio data per 60 ms,
   or 400 byte/s.


B.2.  V.34 Modem scenario (24000 to 28800 bit/s)

   We assume a link speed of 3000 byte/s as not all V.34 modem
   communication reaches the full speed of 3600 byte/s (28800 bit/s).
   At this speed, the transmission of 22 bytes of audio payload takes
   about 8 ms, so about 32 ms of the 40 ms link delay budget is
   available for access delay.  With a regular fragmentation schedule
   based on 12-bit headers, this allows a fragment size of 90 bytes plus
   6 bytes of fragment overhead, i.e. about 7 % loss due to
   fragmentation.  As 26 out of the 90 bytes that can be sent in 30 ms
   are used for the audio packets, an average of 64/96 such 90 byte
   fragments can be sent per 30 ms, leading to a remaining data
   throughput of about 2000 byte/s.

   With compact headers (including the insertion option) and
   suspend/resume operation, the audio information can be sent using
   only two bytes of overhead per audio packet, leaving 66 of the 90
   bytes that can be sent in 30 ms to data packets, of which four bytes
   is lost to PPP overhead, resulting in a remaining data throughput of
   about 2070 byte/s.  If the application makes use of the reduced
   jitter of suspend/resume by combining two audio packets into one, 136
   of 180 bytes that can be sent in 60 ms are available to data packets,
   of which, again, four bytes is lost to PPP overhead, resulting in a
   remaining data throughput of about 2200 byte/s.


B.3.  ISDN scenario (56000 to 64000 bit/s)

   We assume a link speed of 7000 (US) to 8000 (non-US) byte/s.  For a
   regular fragmentation schedule, similar calculations lead to a
   fragment size of 260 to 300 bytes, for about 2 % of fragmentation
   overhead.  The approximate numbers resulting for remaining data
   throughput, based on 64 kbit/s (8000 byte/s) are: 7000 byte/s for a

Bormann                                                        [Page 17]


INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996

   regular schedule of 300 byte fragments, 7070 byte/s for compact
   headers, and 7200 byte/s for compact headers making use of double
   size packets.



















































Bormann                                                        [Page 18]