[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                 R. Andrades
INTERNET DRAFT                                        isochrone, Inc.
Document: draft-andrades-framing-ext-00.txt           F. Burg
Expires: March 20, 1997                               AT&T
                                                      September 20, 1996


                    QOSPPP Framing Extensions to PPP
                   (draft-andrades-framing-ext-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

   The Point-to-Point Protocol (PPP) [2] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
   PPP datagrams are often encapsulated in HDLC frames [1] when used
   over standard analog modems.

   This document describes the extensions to PPP encapsulation and
   HDLC framing to support Quality of Service (QoS) over low bandwidth
   links.

   This document is a submission to the IETF ISSLL working group.
   Comments are solicited and should be addressed to the working
   group's mailing list at issll@mercury.lcs.mit.edu and/or the author.


Andrades, Burg                                                  [Page 1]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


Table of Contents

    1. Introduction...............................................3
    2. Current Implementation ....................................3
    2.1  QOSPPP Extensions to HDLC framing........................3
    2.2  QOSPPP Extensions to PPP encapsulation...................7
    2.3  QOSPPP Extensions to Link Establishment Protocol.........7
    2.4  Planned QOSPPP Features..................................8
    3. Comparison with other proposals...........................10
    4. Other Possibilities.......................................16
    5. Security Considerations...................................18
    6. Acknowledgments...........................................19
    7. References................................................19
    8. Author's Address..........................................20


Andrades, Burg                                                  [Page 2]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


1.  Introduction

    QOSPPP provides an architectural framework for providing multimedia
    and other advanced services, requiring QoS over the Internet. Our
    current work is aimed at the consumer market which usually uses
    comparatively low bandwidth analog modems for Internet access. The
    links from the consumer's residences to their Internet Service
    Providers usually run the PPP protocol [2] encapsulated in
    asynchronous HDLC frames [1], and so our goal was to add QoS to
    this framing scheme. The current document describes our attempt to
    extend the PPP encapsulation in asynchronous HDLC framing to
    support QoS over these links. One goal was to maintain as much
    compatibility as possible with current PPP implementations and to
    fall back to the standard PPP/HDLC framing scheme if we detect that
    the extensions are not available on the peer. The framework also
    included a signalling engine which is used to negotiate parameters
    for the QoS connections, and a packet scheduler which contains
    the actual scheduling algorithms. The signalling protocol could be
    Q.2931 or RSVP or a variant of one of these. The term QOSPPP is
    used to refer to the entire framework and not just the framing.
    The complete QOSPPP architecture will be described in more detail
    in a future document.

    Several Internet Services Providers still offer SLIP connections;
    however, we felt that this would very soon be obsolete and did not
    attempt to address it. At this stage we have not attempted to work
    out the framing extensions for synchronous HDLC, since it is not
    used in the market we are addressing; however, we feel that the
    current work can easily be adapted to that area.

    Section 2 describes the current implementation and work in progress.
    Section 3 compares this framing scheme with those [5,6] proposed by
    Carsten Bormann. Section 4 considers merging the features of QOSPPP
    with [6].


2.  Current Implementation


2.1  QOSPPP Extensions to HDLC framing

    The aim of QOSPPP is to allow a customer to run a mix of
    applications with varying communications needs. Currently most PPP
    implementations offer a single class of service, best-effort, which
    is most suited for conventional data applications (e.g. Telnet, ftp,
    WWW, email). However, newer Internet applications such as packet
    telephony, video conferencing, etc. require a new class of service
    with bandwidth guarantees and upper bounds of the delay and jitter
    seen by their packets.


Andrades, Burg                                                  [Page 3]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    QOSPPP supports four classes of service, ABR, UBR, CBR and VBR. We
    use these terms in the same sense as defined by the ATM Forum [7].
    However, the basic concepts are the same for any other definition
    of class of service.

    ABR or Available Bit Rate supports traditional data applications,
    which do not need bandwidth guarantees, nor any strict bounds on
    their delay and jitter. They typically have variable sized packets.
    However, ABR applications ARE QoS aware and will specify their
    maximum datagram size, expected bandwidth usage, and maximum
    tolerable delays. The class of service is specified in the flowspec
    along with other parameters like bandwidth, delay and jitter.
    The application programming interface (API) MUST provide an
    interface by which the flowspec can be communicated by the
    application to the transport stack, but this is out of the scope of
    this document. While the network does not guarantee the latter
    two, it does use them to estimate buffer sizes and expected load.
    UBR or Unspecified Bit Rate is for legacy applications that are not
    QoS aware. ABR and UBR are equivalent to the framing layer and so
    are both referred to as ABR for the remainder of this document.

    CBR or Constant Bit Rate is for applications that transmit data at
    regular intervals. The datagrams are usually small and of fixed
    length (though the latter is not a requirement). An example is a
    packet phone which does not do silence detection. They do have
    strict upper bounds on the delay and jitter they can tolerate as
    well as strict bandwidth requirements. VBR or Variable Bit Rate is
    similar to CBR, except that the rate of packet transmission is not
    fixed. The transmission rate may vary upto a maximum rate, and it
    also defines a long term average rate. CBR and VBR are equivalent
    to the framing layer and so are both referred to as QoS streams
    for the remainder of this document.

    The framing layer then has to support two classes of datagrams,
    normal data applications and QoS. Most of this support is done by a
    packet scheduler and signalling engine at a layer higher than the
    framing layer, and so will not be discussed in this document.
    However, one aspect of QoS that is strongly influenced by the
    framing layer is the delay bounds of QoS streams. This is because
    the delay allowance of QoS streams tends to be in the range of tens
    of milliseconds. However, several popular data applications (e.g.
    WWW traffic) tend to use large size packets since they are more
    efficient. On a 28,800 link, a 1500 byte packet (which is the MTU
    used by most PPP implementations, and many data applications use
    the MTU) takes approximately half a second to transmit, making the
    link unavailable for that time. (In practice, the bandwidth
    available with a 28,800 modem is often less than 28,800, depending
    on the line conditions.) This clearly indicates that in order to
    support QoS streams on low bandwidth links, some change in the
    standard PPP framing is required. One possible way to handle it
    would be to use a much smaller MTU. However, in order to support


Andrades, Burg                                                  [Page 4]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    delay bounds of around 20 ms for QoS streams, it would be necessary
    to restrict the MTU of ABR traffic to around 36 bytes, which is
    clearly unacceptable.

    Another approach (which is what QOSPPP does) is to allow an ABR
    datagram that is currently being transmitted to be preempted by a
    QoS stream with stricter delay bounds. When the QoS packet is
    complete, the preempted ABR datagram will resume transmission. The
    difference between preemption and conventional fragmentation is
    that each resuming segment of the ABR datagram does NOT carry a
    header telling the receiving end how to put the pieces back
    together again. The preemption is indicated by stuffing a
    preemption flag byte which is defined as 0x7c. The end of
    preemption is indicated by transmitting a standard HDLC Flag byte.
    When preemption ends, the interrupted frame is automatically
    resumed at the point where it was suspended, with no extra header
    bytes. The current implementation supports a single level of
    preemption, however we are planning a new version with support for
    multiple levels of preemption, see section 2.4.

    In this document we use the terms priority and preemption class
    interchangeably although that may not be the common usage.

    The preemption is explained by the following diagram. Assume that
    there are two active streams, a TCP stream (maybe a Web browser)
    which is ABR, and a voice stream (the latter for a packet phone
    application) which is CBR (or VBR if silence detection is
    implemented). Initially, in the absence of any voice data, the
    framer begins transmission of a packet of the TCP stream. After
    some time, a voice packet is queued for transmission and the
    framer suspends transmission of the TCP stream to begin sending
    the voice packet. When transmission of the voice packet is
    complete, the framer resumes transmission of the suspended TCP
    packet. Note that one voice packet can not interrupt another
    voice packet. The payload size of the voice packet (16 bytes in
        the example), depend on the encoding algorithm used. Also note
        that each FCS in the following diagram protects only the frame
        it is a part of, (the one that is terminated by the HDLC Flag byte
    immediately after the FCS), and not any intermediate (preempting)
    frames, Each stream can negotiate the use of an FCS of a different
    strength (size). The new Suspend Flag byte needs to be added to the
    ACCM for transparency. Note that in the diagram, and elsewhere in
        this document, the term PID     always refers to the PPP protocol ID.


Andrades, Burg                                                  [Page 5]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


Preempted packet - (starts earlier in time)
--------------------------- - - - -----------------------------
|HDLC |IP PID | TCP data \        \ TCP data |FCS       |HDLC |
|Flag |0x21   |           \        \ (contd.)|(2 bytes) |Flag |
|0x7e |       |            \        \        |          |0x7e |
------------------------------ - - - --------------------------
                        Suspend    Resume
                           /          \
                         /              \
                       /                  \
                     /                      \
                   /                          \
                 / Preempting packet            \
               /   (Starts later in time -        \
             /     completes earlier)               \
             ----------------------------------------
             |Suspend |CBR |Voice data|FCS    |HDLC |
             |Flag    |PID | 16 bytes |(0 or 2|Flag |
             |0x7c    |    |          | bytes)|0x7e |
             ----------------------------------------


    As can be seen from the preceding diagram, the preempting packet's
    frame format is the same as the standard PPP frame except for the
    use of a new Suspend Flag (0x7c) instead of the HDLC Flag (0x7e).

    One other difference is that the length of the FCS field can be
    different for different PIDs. PPP currently defines three different
    FCS', 16-bit, 32-bit and NULL FCS. We use the 16-bit FCS for all
    data streams (it is the default anyway). The NULL FCS can be
    negotiated for CBR streams that have a small MTU by the signalling
    engine. However, this choice, if desired, must be made by the
    application. The interface by which the application may negotiate
    the choice of an FCS is out of the scope of this document. In
    any examples in this document, the length of the FCS shown is just
    for illustration.

    In the special case, when we have only a single active QoS stream,
    we omit sending the CBR PID in preempting frames, since it is
    implicit from the Suspend Flag, and reduces the Framing overhead
    by a byte.


Andrades, Burg                                                  [Page 6]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


2.2  QOSPPP Extensions to PPP encapsulation

    All CBR and VBR streams are each assigned a unique PPP protocol ID
    (PID) by the signalling engine. These PID values are taken from
    the unused values as specified in [8]. We plan to get a range of
    these unused PIDs allocated for this purpose. Unlike the PIDs
    currently assigned to protocols by the IETF, the PIDs used by
    QOSPPP are not necessarily the same in both directions, because
    of the way the signalling engine works. We try to pick the PIDs
    from the 1-byte PID space (and since we do not expect too many
    streams to be simultaneously active over these low bandwidth
    links, it isn't difficult to find enough 1-byte PIDs).


2.3  QOSPPP Extensions to Link Establishment Protocol

    PPP uses the Link Control Protocol (LCP) [2] to establish
    parameters for the link. Up-to-date values of the LCP Code field
    are specified in the most recent "Assigned Numbers" RFC [8].

    QOSPPP adds the following configuration option:

        --------------------------------------------------------
        |Option | Length | version   | Preemptive | Link Speed |
        |0x55   | = 8    | (4 bytes) | scheduling | Monitoring |
        |       |        |           |  (1 byte)  | (1 byte)   |
        --------------------------------------------------------

    Option: This is a new LCP configuration option code value.

    Version: This field is currently set to 1. Future versions
    may set this field to other values to indicate other
    preemption schemes.

    Preemptive scheduling: This is set to 0 to indicate that QoS
    streams are not currently supported (even though the peer
    apparently is QOSPPP-enabled). The current QOSPPP framing uses a
    value of 1 in this field. In the future, we plan to use this field
    to indicate the number of levels of preemption supported
    (Currently it is one level).

    Link Speed Monitoring: This is currently set to 0 to indicate
    that Link Speed Monitoring is not required. The purpose of
    Link Speed Monitoring is to enable an implementation to track
    changes in the link bandwidth and adjust it's packet scheduling
    accordingly. No protocol has yet been defined for Link Speed
    Monitoring.


Andrades, Burg                                                  [Page 7]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    The node at one end sends a configuration message indicating that
    it supports preemption, and the maximum number of preemption levels
    it supports. If the other node responds with a reject (i.e. it is
        a non QoS-aware implementation and does not recognize the new LCP
        option code), then the sender will disable the preemption
        capability and send a new configuration message without the
        preemption option (and disable the preemption feature locally for
        the current session).  If the other side responds with a NAK
        requesting a smaller number of levels of preemption, we will
        adjust our behavior accordingly and resend the configuration
        message reflecting the requested changes.


2.4  Planned QOSPPP Features

    We will try to choose the PID values so that their Hamming distance
    is at least two, allowing single bit errors in the PID field to be
    detected.

    In the QOSPPP Framing engine the FCS field can be  turned off for
    individual CBR and VBR streams. We could also adopt Carsten's idea
    [6] of using an 8-bit CRC for CBR and VBR streams. Thus the
    effective Framing overhead can be reduced by a byte for CBR and
    VBR streams. We propose to use the 8-bit FCS described in the V.76
    specification [9], unless the IETF already has a standard for
    an 8-bit FCS.

    Another planned extension to QOSPPP is multiple levels of
    preemption. In this we will put different streams into
    different preemption classes and allow a packet of a stream of a
    higher preemption class to preempt a currently transmitting packet
    of a stream of a lower preemption class. Currently, we do not
    plan to support dynamic priorities (where two streams' relative
    priorities can change dynamically). The QOSPPP frame format can
    support multiple preemption levels without any change.


    Multiple preemption levels are explained by the following diagram
    that shows two levels of preemption. Assume that there are three
    active streams, a TCP stream (maybe a Web browser), a video
    stream and a voice stream (the latter two for video conferencing).
    Assume that the video stream belongs to a higher preemption level
    than the TCP stream and the voice stream belongs to a higher


Andrades, Burg                                                  [Page 8]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    preemption level than the video stream. Initially, in the absence
    of any voice or video data, the framer begins transmission of a
    packet of the TCP stream. After some time, a video packet is queued
    for transmission and the framer suspends transmission of the TCP
    stream to begin sending the video packet. Before transmission of
    the video packet is complete, a voice packet is queued for
    transmission. The framer suspends transmission of the video stream
    to begin sending the voice packet. When transmission of the voice
    packet is complete, the framer resumes transmission of the
    suspended video packet. When transmission of the video packet is
    complete, the framer resumes transmission of the suspended TCP
    packet.  Note that a video packet can not interrupt a voice packet
    or another video packet, and one voice packet can not interrupt
    another voice packet.


Preempted packet - (starts earlier in time)
--------------------------- - - - -----------------------------
|HDLC |IP PID | TCP data \        \ TCP data |FCS       |HDLC |
|Flag |0x21   |           \        \ (contd.)|(2 bytes) |Flag |
|0x7e |       |            \        \        |          |0x7e |
------------------------------ - - - --------------------------
                        Suspend    Resume
                           /          \
                         /              \
                       /                  \
                     /                      \
                   /                          \
                 / First level of Preemption    \
               /   (Starts later in time -        \
             /     completes earlier)               \
             --------------- - - - - ----------------
             |Suspend |CBR |Video data|FCS    |HDLC |
             |Flag    |PID |'n' bytes |(1 or 2|Flag |
             |0x7c    |    |          | bytes)|0x7e |
             --------------- - - - - ----------------
                        Suspend    Resume
                           /          \
                         /              \
                       /                  \
                     /                      \
                   /                          \
                 / Second level of Preemption   \
               /   (Starts still later in time -  \
             /     completes first)                 \
             ----------------------------------------
             |Suspend |CBR |Voice data|FCS    |HDLC |
             |Flag    |PID |'m' bytes |(1 or 2|Flag |
             |0x7c    |    |          | bytes)|0x7e |
             ----------------------------------------


Andrades, Burg                                                  [Page 9]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    Note that the suspended packets have to be resumed in the reverse
    (stack-like or LIFO) order; i.e. if streamA preempts streamB
    preempts streamC, then when streamC completes, streamB must
    resume (and complete) before streamA is resumed. Currently we do
    not expect to support resumption of suspended packets in a
    different order (which, by the way, would necessarily imply
    implementing dynamic priorities).


3. Comparison with other proposals

    In all the descriptions below we are assuming that the
    address-control field compression and protocol field compression
    options have been negotiated by the link control protocol, and that
    all PIDs used for the real-time streams are 1 byte.


Case 0. The QOSPPP fragmentation format

    |--------------------------------------|
    |Preemption FLAG                       |
    |--------------------------------------|
    |PID (1 byte - opt)                    |
    |--------------------------------------|
    |Fragment Data                         |
    |--------------------------------------|
    |FCS (2 bytes or 0 bytes - negotiable) |
    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|

    This frame has between 5 and 2 bytes of overhead per preemption;
    the minimum of two bytes is in the case when there is only a single
    active stream of a high preemption class, and it has been
    negotiated not to require the use of a CRC; the maximum of five
    bytes is when there are multiple active streams of high preemption
    classes (either in the same class, or in preemption classes), and
    they require the use of a 2 byte CRC. We could also consider using
    a 1 byte CRC (as suggested by Carsten Bormann), for streams whose
    packets are rather short. Note that there is no overhead on the
    interrupted packet. Therefore every low priority packet carries 5
    bytes of framing overhead (regardless of whether it is preempted
    or not), and every higher priority packet carries 2 to 5 bytes of
    overhead.

    There is no limit on the number of preemption levels, except the
    number of bits in a PID (though not all combinations are valid).

    In the case of multiple levels of preemption, it assumes that
    suspended frames will be resumed in the reverse order, from that
    in which they were suspended.


Andrades, Burg                                                 [Page 10]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    In the absence of preemption, the frame format is exactly the same
    as regular PPP.

    We will consider the following proposals from Carsten Bormann and
    try to consider all the optimizations too.


Case 1. Using PPP Multi-Link as-is (short sequence number fragment
format)

    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|
    |PID (1 byte)                          |
    |--------------------------------------|
    | B | E | 0 | 0 |    sequence number   |
    |--------------------------------------|
    |sequence number                       |
    |--------------------------------------|
    |Fragment Data                         |
    |--------------------------------------|
    |FCS (2 bytes)                         |
    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|

    In this scheme, every lower priority packet needs to be sent in at
    least two MLPPP frames. (Since we do not know whether it is going
    to be interrupted or not, we must begin transmitting with the "E"
    bit set to "0". Therefore, even if it is not interrupted, we need
    to send a final (empty) fragment with the "E" bit set to "1" to
    terminate the packet). Now, the MLPPP frame has 7 bytes of framing
    overhead, therefore every lower priority packet has 7*2= 14 bytes
    of framing overhead. However, the MLPPP packet actually carries a
    PPP packet within it adding an additional 1 byte overhead (for the
    PPP PID) making the total framing overhead 15 bytes. We can save
    one byte by not transmitting two consecutive Flag bytes making the
    total framing overhead 14 bytes as opposed to 5 bytes for a normal
    PPP frame. For every preemption, the lower priority packet needs to
    be terminated with an MLPPP trailer (3 bytes) and restarted with an
    MLPPP header  (4 bytes) adding an additional 7 bytes overhead.
    Additionally, the preempting packet needs it's PPP header of 5
    bytes, giving a total framing overhead of 12 bytes per preemption.
    Dropping consecutive Flag bytes will save two bytes giving a total
    framing overhead of 10 bytes per preemption as opposed to 5 bytes
    for a normal PPP frame. In case the interrupted packet is resumed
    near it's end (e.g. it has fewer than say 8 bytes left to
    transmit), we can assume that it will not be interrupted again and
    can send the last fragment with the "E" bit set to "1", thus
    eliminating the 6 bytes of the empty MLPPP header at the end.


Andrades, Burg                                                 [Page 11]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    It supports a single level of preemption.

    It can be used even if the other end does not support QoS. This
    however, assumes that the other end supports MLPPP; We are not sure
    how many implementations, (aside from Windows NT 4.0), and how
    many service providers support MLPPP for analog lines.


Case 2. Extending PPP Multi-Link to multiple class (short sequence
number fragment format)

    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|
    |PID (1 byte)                          |
    |--------------------------------------|
    | B | E |  class  |   sequence number  |
    |--------------------------------------|
    |sequence number                       |
    |--------------------------------------|
    |Fragment Data                         |
    |--------------------------------------|
    |FCS (2 bytes)                         |
    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|

    The difference between this scheme and case 1 is that it supports
    4 levels of preemption. However, now preempted packets carry an
    MLPPP header (plus a PPP PID), instead of a normal PPP header
    (except for one of the preemption levels which uses normal PPP
    frames). Thus the preempted packets carry (7(MLPPP header) +
    1(PPP PID) = ) 8 bytes of framing overhead per packet. So the total
    framing overhead per preemption is (7 (preempted) + 8 (preempting)
    = ) 15 bytes. Again, dropping consecutive Flag bytes will save two
    bytes giving a total framing overhead of 13 bytes per preemption
    as opposed to 5 bytes for a normal PPP frame.

    It is backward compatible to case 1; i.e. if the remote end does
    not support QoS, we can fall back to case 1, restricting ourselves
    to a single level of preemption.

    In the case of multiple levels of preemption, suspended frames can
    be resumed in any order, not necessarily the reverse order  from
    that in which they were suspended.


Andrades, Burg                                                 [Page 12]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


Case 3. The Compact Fragment Format (Normal header)


    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|
    |R |    Sequence   |    Class      | 1 |
    |--------------------------------------|
    |Fragment Data                         |
    |--------------------------------------|
    |FCS (2 bytes)                         |
    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|


    It supports 7 levels of preemption.

    In the case of multiple levels of preemption, suspended frames can
    be resumed in any order, not necessarily the reverse order  from
    that in which they were suspended.

    The header above has 5 bytes of overhead per frame which is the
    same as the normal PPP header.  However [6] seems to imply that all
    fragments will be sent using the header described above, not just
    the interrupting packet. (This needs to be clarified with Carsten
    Bormann.) This means that every time a lower priority packet is
    preempted by a higher priority packet, the lower priority packet
    is terminated by an FCS and Flag byte (3 bytes), and when it
    resumes, it will carry a 2 byte header, adding 5 bytes of overhead
    per preemption. Also the Higher priority packet will need 5 bytes
    of framing overhead, making the total framing overhead (5+5=) 10
    bytes per preemption. Again, dropping consecutive Flag bytes will
    save two bytes giving a total framing overhead of 8 bytes per
    preemption as opposed to 5 bytes for a normal PPP frame.


Case 4. The Compact Fragment Format (Insertion Header)

    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|
    |Length L                      | C | 0 |
    |--------------------------------------|
    |Inserted Packet (Length L)            |
    |--------------------------------------|
    |FCS (1 byte)                          |
    |--------------------------------------|

    It supports 2 levels of preemption.


Andrades, Burg                                                 [Page 13]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    This frame format carries 3 bytes of overhead for the preempting
    packet. Also, it does not impose any additional overhead on the
    packet being interrupted.

    It does have the restriction that the higher priority packet be
    not more than 64 bytes in length.


Comparison of Overhead

    Cases 1 & 2 have more overhead than the rest. Case 1 is useful
    only if it is necessary to support (a single level of) preemption
    even for links where the peer does not support QoS. Even this is
    debatable for two reasons:
    (1)  How many implementations actually support MLPPP for analog
    lines, and,

    (2)  Preemption by itself is generally not sufficient to support
    QoS for analog lines, one also needs to do some form of header
    compression, especially considering the increased size of the
    MLPPP headers. Would the remote end which does not have support
    for QoS support the header compression scheme?

    Case 2 does not seem useful considering that it requires the remote
    end to support a non-standard extension to MLPPP. If the remote end
    has to be modified to support this extension, one should question
    why it can not be modified to support some other, more efficient,
    extension. It does have the advantage of being able to gracefully
    fallback to case 1, but as mentioned above, the value of this
    advantage seems to be rather dubious. We shall not consider cases
    1 & 2 any longer.

    Case 4 appears to have less overhead (3 bytes as opposed to 5
    bytes for case 0 & 8 bytes for case 3), than any other. However,
    one of the optimizations that caused a 1 byte reduction in
    overhead (the smaller FCS) can also be applied to cases 0 and 3.
    The second optimization (dropping the intermediate Flag byte) is
    achieved mainly by putting a length field in the header and
    shrinking the class number to 1 bit. The former restricts the
    length of high priority packets to 64 bytes which may be O.K., the
    latter restricts the number of high priority streams to 2, which
    makes it O.K. as an optimization of case 3 rather than as a
    separate case (which anyway, is what Carsten presents it as).

    Let us examine cases 0 & 3. Consider the following scenarios for
    cases 0 & 3 (with case 4 as an optimization of case 3).

    1.  normal case, case 0 has 5 bytes overhead, case 3 has 8 bytes
    2.  8-bit FCS, overhead reduces by 1 byte for both cases.
    3.  No FCS, overhead reduces by 2 bytes for both cases.


Andrades, Burg                                                 [Page 14]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    4.  A single high priority stream, reduces case 0 overhead by 1
    byte by dropping the PID. If the length of the packet is less than
    64 bytes, case 3 reduces to case 4. This means that cases 0 & 3 are
    identical, assuming the FCS is the same size in both.
    5.  Upto 2 high priority streams whose packet lengths are less than
    64 bytes, and which use an 8-bit FCS can have their overhead reduced
    to 3 bytes for case 3 by using the case 4 optimizations. This
    compares with 4 bytes for case 0 under the same conditions, except
    that you can do it for a greater number of streams.
    6.  Case 0 overhead can be reduced by 1 byte by dropping the
    intermediate Flag byte, however this can be done only for streams
    that have fixed size packets, and it carries the danger of two
    packets (the preempted and the preempting,) being corrupted if
    any byte of the preempting packet is dropped.

    As can be seen, there does not appear to be a clear advantage
    of one scheme over the other.

    Note that the frame formats of cases 1 & 2 actually indicate
    fragmentation rather than preemption, since each frame carries
    a header telling the receiver how to put it back together. The
    idea behind preemption is precisely to avoid the overhead of this
    kind of header. However, although the frame format makes it look
    like fragmentation, calling it preemption is justifiable
    from the point of view of the actual operation of the protocol;
    i.e., with conventional fragmentation, the stack will decide
    on how to fragment a packet either when it is given a packet from
    the higher layer, or, when it decides to begin transmission. In
    preemption, the decision of how, when, etc. to "fragment" is made
    at the time a higher priority "preempting" packet becomes eligible
    for transmission. This distinction can only be made at the sending
    side, for the receiver it does look like fragmentation.


Comparison of error detection capability

    Case 3 packets have a sequence number which will allow it to detect
    a lost fragment. Of course, even in case 0, lost fragments can be
    caught by the FCS, but the sequence number provides an additional
    check.


Comparison of number of levels of preemption

    Consider cases 0 and 3 alone as case 4 is an optimization of case 3.

    Case 0 supports an arbitrary number of levels of preemption,
    limited only by the PID space. Case 3 supports 7 levels of
    preemption. There does not seem to be much to choose between them
    here as 7 levels of preemption are probably enough.


Andrades, Burg                                                 [Page 15]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


Comparison of support for dynamic priorities

    Case 3 appears to have slightly better support for dynamic
    priorities. However, let us see if this advantage is meaningful.

    There is one way in which the use of dynamic priorities can affect
    the framing format. Consider the case where there are three stream
    A, B and C, in the increasing order of priorities. Assume that the
    priorities are dynamic so the priority ordering may change over
    time. Now consider a scenario where stream B has preempted stream
    A and stream C has preempted stream B. Suppose stream A gets a
    priority boost making it temporarily of higher priority that stream
    B (but lower than stream C). Therefore when stream C completes
    transmission of it's packet, there is an issue of whether we should
    resume transmission of stream A or stream B. Carsten's proposals
    (cases 2 & 3) give the implementation the choice in this matter,
    QOSPPP does not.

    This does not mean that dynamic priorities are impossible with
    QOSPPP. Dynamic priorities can still be used in controlling the
    decision of preemption of one stream by another, they simply can
    not be used for making the resumption decision. Also, the scenario
    above could be considered farfetched by some. For that matter, the
    whole idea of dynamic priorities might be considered irrelevant
    for the applications we are considering; the alternative is to
    allow a slightly larger jitter, which might be perfectly
    acceptable.

    Case 0, being limited to a strict stack-like sequence of
    suspends-resumes might be slightly simpler to implement.


4.  Other Possibilities

    Based on the discussion above, we propose a new framing format
    which attempts to borrow the best features of both the QOSPPP
    framing and Carsten's proposals.

    Use a preemption flag and the requirement that packets be resumed
    in the reverse order from that in which they were suspended.

    In the case of a single higher priority stream, keep the option of
    dropping the PID byte. This however, has to be negotiated by LCP.


Andrades, Burg                                                 [Page 16]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    QOSPPP uses UDP header compression. This consists of not
        transmitting the UDP and IP headers of any packet that is
        associated with a specific PID. The receiver automatically prepends
        the UDP & IP headers to every incoming packet.The information needed
        for the headers is transmitted when the PID is negotiated by the
        signalling engine (the checksum can be generated by the receiver
        on the reconstructed received packet - or we can use the
        optimization of setting the checksum to 0).     Carsten proposes prefix
        elision [6] which is basically associating each class or PID with a
        prefix of bytes that begin every packet belong to that class or PID
        and then not transmitting those bytes. The receiver automatically
        prepends the prefix to every packet it receives. UDP header
        compression gives better reduction in overhead than prefix elision
        for UDP streams. It does not handle non-UDP streams, but we assume
        Van Jacobson does a fairly good job at that. Are there other
        non-UDP, non-TCP streams that we have to consider? If so, we can do
        prefix elision for these streams. (This will have to be negotiated
        by the signalling protocol on a per-stream basis).

    The sequence number gives us some additional error detection
    capability. However, it is more useful for the packet being
    interrupted than the interrupting packet, as the former is spread
    out over a longer time and has a higher probability of being
    corrupted. Therefore we will put it only in the packet being
    resumed. This also has the advantage that in case a packet is not
    interrupted, it will have exactly the same format as a regular PPP
    frame. We shall therefore call it a fragment number and every
    fragment being resumed will have this as the first byte. The first
    fragment has an implicit fragment number of 0.

    The signalling protocol will negotiate the size of the FCS for each
    stream.

    We can use one of Carsten's values of 0xDE or 0xC3 for the
    Preemption flag. Maybe we should run tests over a PPP link (before
    the byte stuffing stage) rather than over an Ethernet as he did.

    The use or non-use of dynamic priorities is an independent decision
    which will not affect the frame format. Also, it needs to be
    implemented on the sending side alone (for the framing scheme we
    are considering), so both sides need not have it.

    The frame format is shown below.


Andrades, Burg                                                 [Page 17]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


    |--------------------------------------|
    |Preemption Flag                       |
    |--------------------------------------|
    |PID (opt)                             |
    |--------------------------------------|
    |Fragment Data                         |
    |--------------------------------------|
    |FCS (1, or 2 bytes)                                   |
    |--------------------------------------|
    |HDLC Flag                             |
    |--------------------------------------|
    |Fragment # for resuming packet        |
    |--------------------------------------|

    We can also continue to use the optimizations of case 4 (Insertion
    headers) as follows.

    |--------------------------------------|
    |Preemption Flag                       |
    |--------------------------------------|
    |Length L                      | S | 0 |
    |--------------------------------------|
    |Inserted Packet (Length L)            |
    |--------------------------------------|
    |FCS (1, or 2 bytes)                   |
    |--------------------------------------|


    This is similar to that described by Carsten. The difference is
    that now we are not using the concept of Class any more, so the
    "C" bit becomes a stream identifier and is renamed to be an "S"
    bit (a purely cosmetic change). There can be only two such streams,
    and they must be negotiated by a signalling protocol. A stream using
        insertion headers can continue to use the normal preemption frame
        format interchangeably.

    This scheme has the standard 5 bytes of PPP framing overhead for
    lower priority packets that are not interrupted, and 6 to 3 bytes
    of framing overhead per preemption. In the "normal" case when we
    have multiple high priority streams and they all use a 1 byte FCS,
    there will be 5 bytes of framing overhead per preemption, which is
    the same as regular PPP. Upto two of these streams can take
    advantage of the insertion header format to reduce the overhead to
    3 bytes.


5.  Security Considerations

    This document does not raise any new security issues.


Andrades, Burg                                                 [Page 18]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


6.  Acknowledgments

    Much of the work in implementing the QOSPPP architecture and
    testing the concepts presented in this document was done by
    Murali Aravamudan and Kumar Vishwanathan of isochrone, Inc.
    Andreas Papanicolau and Khasha Mohammadi of AT&T also provided
    many helpful insights in the design of the architecture.


7.  References

    [1]  Simpson, W., Editor, "PPP in HDLC Framing", RFC 1662,
         STD 51, Daydreamer, July 1994.

    [2]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
                 RFC 1661, STD 51, Daydreamer, July 1994.

    [3]  Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
         Daydreamer, January 1994.

    [4]  McGregor, G., "The PPP Internet Control Protocol", RFC 1332,
         Merit, May 1992.

    [5]  Bormann, Carsten, "Providing integrated services over
         low-bitrate links", work in progress, Internet Draft
         (draft-ietf-issll-isslow-00.txt), Universitaet Bremen,
         June 1996.

    [6]  Bormann, Carsten, "The Multi-Class Extensions to Multi-Link
         PPP", work in progress, Internet Draft,
         (draft-ietf-issll-isslow-mcml-00.txt), Universitaet Bremen,
         September 1996.

         http://www-rn.informatik.uni-bremen.de/research/mcml.html,
         Universitaet Bremen, July 1996.

    [7]  "ATM User-Network Interface (UNI) Specification Version 3.1",
         The ATM Forum, 1995.

    [8]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
         RFC 1700, USC/Information Sciences Institute, October 1994.

    [9]  Burg, F., editor, "Recommendation V.76 - Generic Multiplexer
         using V.42 LAPM-based procedures", International
         Telecommunication Union, April 1996.


Andrades, Burg                                                 [Page 19]


INTERNET DRAFT    QOSPPP Framing Extensions to PPP    September 20, 1996


8.  Author's Address


   Questions about this memo can be directed to:

    Richard Andrades
    isochrone, Inc.                     Phone: (908) 544 5508
    One Main Street                     Fax:   (908) 544 2059
    Suite 511                           Email: richard@isochrone.com
    Eatontown, NJ 07724


    Fred M. Burg
    AT&T
    307 Middletown-Lincroft Road        Phone: (908) 576 4322
    Room 3L209                          Fax:   (908) 576 4689
    Lincroft, NJ 07738                  Email: fred.burg@att.com


Andrades, Burg                                                 [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/