home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-issll-isslow-mcml-02.txt < prev    next >
Text File  |  1997-07-25  |  21KB  |  523 lines
  1.  
  2.  
  3. INTERNET-DRAFT                                           Carsten Bormann
  4. Expires: November 1997                               Universitaet Bremen
  5.                                                                 May 1997
  6.  
  7.  
  8.               The Multi-Class Extension to Multi-Link PPP
  9.                   draft-ietf-issll-isslow-mcml-02.txt
  10.  
  11.  
  12. Status of this memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet-Drafts as reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  26.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30.    Distribution of this document is unlimited.
  31.  
  32. Abstract
  33.  
  34.    A companion document describes an architecture for providing
  35.    integrated services over low-bitrate links, such as modem lines, ISDN
  36.    B-channels, and sub-T1 links [1].  The main components of the
  37.    architecture are: a real-time encapsulation format for asynchronous
  38.    and synchronous low-bitrate links, a header compression architecture
  39.    optimized for real-time flows, elements of negotiation protocols used
  40.    between routers (or between hosts and routers), and announcement
  41.    protocols used by applications to allow this negotiation to take
  42.    place.
  43.  
  44.    This document proposes the fragment-oriented solution for the real-
  45.    time encapsulation format part of the architecture.  The general
  46.    approach is to start from the PPP Multilink fragmentation protocol
  47.    [2] and provide a small number of extensions to add functionality and
  48.    reduce the overhead.
  49.  
  50.    This document is a product of the IETF ISSLL working group.
  51.    Comments are solicited and should be addressed to the two working
  52.    groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
  53.    ppp@merit.edu and/or the author.
  54.  
  55.  
  56.  
  57. Bormann                                                         [Page 1]
  58.  
  59. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  60.  
  61. 1.  Introduction
  62.  
  63.    As an extension to the ``best-effort'' services the Internet is well-
  64.    known for, additional types of services (``integrated services'')
  65.    that support the transport of real-time multimedia information are
  66.    being developed for and deployed in the Internet.
  67.  
  68.    A companion document describes an architecture for providing
  69.    integrated services over low-bitrate links, such as modem lines, ISDN
  70.    B-channels, and sub-T1 links [1].  The main components of the
  71.    architecture are: a real-time encapsulation format for asynchronous
  72.    and synchronous low-bitrate links, a header compression architecture
  73.    optimized for real-time flows, elements of negotiation protocols used
  74.    between routers (or between hosts and routers), and announcement
  75.    protocols used by applications to allow this negotiation to take
  76.    place.
  77.  
  78.    The present document defines the fragment-oriented solution for the
  79.    real-time encapsulation format part of the architecture, i.e. for the
  80.    queues-of-fragments type sender [1].  As described in more detail in
  81.    the architecture document, a real-time encapsulation format is
  82.    required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link
  83.    makes this link unavailable for the transmission of real-time
  84.    information for about 400 ms.  This adds a worst-case delay that
  85.    causes real-time applications to operate with round-trip delays on
  86.    the order of at least a second -- unacceptable for real-time
  87.    conversation.  The PPP extensions defined in this document allow a
  88.    sender to fragment the packets of various priorities into multiple
  89.    classes of fragments, allowing high-priority packets to be sent
  90.    between fragments of lower priorities.
  91.  
  92.    A companion document based on these extensions [5] defines a
  93.    suspend/resume-oriented solution for those cases where the best
  94.    possible delay is required and the senders are of type 1 [1].
  95.  
  96.  
  97. 2.  Requirements
  98.  
  99.    The main design goal for the components of an architecture that
  100.    addresses real-time multimedia flows over low-bitrate links is that
  101.    of minimizing the end-to-end delay.  More specifically, the worst
  102.    case delay (after removing possible outliers, which are equivalent to
  103.    packet losses from an application point of view) is what determines
  104.    the playout points selected by the applications and thus the delay
  105.    actually perceived by the user.
  106.  
  107.    In addition, every attempt should obviously be undertaken to maximize
  108.    the bandwidth actually available to media data; overheads must be
  109.    minimized.
  110.  
  111.    The solution should not place unnecessary burdens on the non-real-
  112.    time flows.  In particular, the usual MTU should be available to
  113.    these flows.
  114.  
  115. Bormann                                                         [Page 2]
  116.  
  117. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  118.  
  119.    The most general approach would provide the ability to suspend any
  120.    packet (real-time or not) for a more urgent real-time packet, up to
  121.    an infinite number of levels of nesting.  On the other hand, it is
  122.    likely that there would rarely be a requirement for a real-time
  123.    packet to suspend another real-time packet that is not at least about
  124.    twice as long.  Typically, the largest packet size to be expected on
  125.    a PPP link is the default MTU of 1500 bytes.  The smallest high-
  126.    priority packets are likely to have on the order of 22 bytes
  127.    (compressed RTP/G.723.1 packets).  In the 1:72 range of packet sizes
  128.    to be expected, this translates to a maximum requirement of about
  129.    eight levels of suspension (including one level where long real-time
  130.    packets suspend long non-real-time packets).  On 28.8kbit/s modems,
  131.    there seems to be a practical requirement for at least two levels of
  132.    suspension (i.e., audio suspends any longer packet including video,
  133.    video suspends other very long packets).
  134.  
  135.    On an architectural level, there are several additional requirements
  136.    for the fragmentation scheme:
  137.  
  138.    a)   The scheme must be predictable enough that admission control can
  139.         make decisions based on its characteristics.  As is argued in
  140.         [1], this will often only be the case when additional hints
  141.         about the characteristics of the flow itself are available
  142.         (application hints).
  143.  
  144.    b)   The scheme must be robust against errors, at least with the same
  145.         level of error detection as PPP.
  146.  
  147.    c)   The scheme must in general cooperate nicely with PPP.  In
  148.         particular, it should be as compatible to existing PPP standards
  149.         as possible.  On a link that (based on PPP negotiation) makes
  150.         use of the scheme, it should always be possible to fall back to
  151.         standard LCP without ambiguity.
  152.  
  153.    d)   The scheme must work well with existing chips and router
  154.         systems.  (See [1] for a more extensive discussion of
  155.         implementation models.)  For synchronous links this means using
  156.         HDLC framing; with much existing hardware, it is also hard to
  157.         switch off the HDLC per-frame CRC.  For asynchronous links,
  158.         there is much more freedom in design; on the other hand, a
  159.         design that treats them much different from synchronous links
  160.         would lose a number of desirable properties of PPP.
  161.  
  162.    e)   The scheme must be future proof.  In particular, the emergence
  163.         of V.80 based modems may significantly change the way PPP is
  164.         used with modems.
  165.  
  166.    This document does not address additional requirements that may be
  167.    relevant in conjunction with Frame Relay; however, there seems to be
  168.    little problem in applying the principles of this document to ``PPP
  169.    in Frame Relay'' [3].
  170.  
  171.  
  172.  
  173. Bormann                                                         [Page 3]
  174.  
  175. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  176.  
  177. 3.  Using PPP Multilink as-is
  178.  
  179.    Transmitting only part of a packet to allow higher-priority traffic
  180.    to intervene and resuming its transmission later on is a kind of
  181.    fragmentation.  The existing PPP Multilink Protocol (MP, [2])
  182.    provides for sequence numbering and begin/end bits, allowing packets
  183.    to be split into fragments (Figure 1).
  184.  
  185.        Figure 1: Multilink Short Sequence Number Fragment Format [2]
  186.  
  187.  
  188.                 +---------------+---------------+
  189.    PPP Header:  | Address 0xff  | Control 0x03  |
  190.                 +---------------+---------------+
  191.                 | PID(H)  0x00  | PID(L)  0x3d  |
  192.                 +-+-+-+-+-------+---------------+
  193.    MP Header:   |B|E|0|0|    sequence number    |
  194.                 +-+-+-+-+-------+---------------+
  195.                 |    fragment data              |
  196.                 |               .               |
  197.                 |               .               |
  198.                 |               .               |
  199.                 +---------------+---------------+
  200.    PPP FCS:     |              FCS              |
  201.                 +---------------+---------------+
  202.  
  203.    (Note that the address, control, and most significant PID bytes are
  204.    often negotiated to be compressed away.)
  205.  
  206.    MP's monotonically increasing sequence numbering (contiguous numbers
  207.    are needed for all fragments of a packet) does not allow to suspend
  208.    sending a sequence of fragments of one packet for sending another
  209.    packet.  It is, however, possible to send intervening packets that
  210.    are not encapsulated in multilink headers; thus, MP supports two
  211.    levels of priority.
  212.  
  213.    The multilink-as-is approach can be built using existing standards;
  214.    multilink capability is now widely deployed and only the sending side
  215.    needs to be aware that they are using this for giving priority to
  216.    real-time packets.
  217.  
  218. 3.1.  Limitations of multilink as-is
  219.  
  220.    Multilink-as-is is not the complete solution for a number of reasons.
  221.    First, because of the single monotonically increasing serial number,
  222.    there is only one level of suspension:  ``Big'' packets that are sent
  223.    via multilink can be suspended by ``small'' packets sent outside of
  224.    multilink; the latter are not fragmentable (and therefore also cannot
  225.    be distributed to multiple links).
  226.  
  227.    A problem not solved by this specification is that the multi-link
  228.    header is relatively large; as delay bounds become small (for queues-
  229.    of-fragments type implementations) the overhead may become
  230.  
  231. Bormann                                                         [Page 4]
  232.  
  233. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  234.  
  235.    significant.
  236.  
  237. 4.  Extending PPP Multilink to multiple classes
  238.  
  239.    The obvious approach to providing more than one level of suspension
  240.    with PPP Multilink is to run Multilink multiple times over one link.
  241.    Multilink as it is defined provides no way for more than one instance
  242.    to be active.  Fortunately, a number of bits are unused in the
  243.    Multilink header: two bits in the short sequence number format (as
  244.    can be seen in Figure 1), six in the long sequence number format.
  245.  
  246.    This document defines (some of the) previously unused bits as a class
  247.    number:
  248.  
  249.        Figure 2: Short Sequence Number Fragment Format With Classes
  250.                 +---------------+---------------+
  251.    PPP Header:  | Address 0xff  | Control 0x03  |
  252.                 +---------------+---------------+
  253.                 | PID(H)  0x00  | PID(L)  0x3d  |
  254.                 +-+-+-+-+-------+---------------+
  255.    MP Header:   |B|E|cls|    sequence number    |
  256.                 +-+-+-+-+-------+---------------+
  257.                 |    fragment data              |
  258.                 |               .               |
  259.                 |               .               |
  260.                 |               .               |
  261.                 +---------------+---------------+
  262.    PPP FCS:     |              FCS              |
  263.                 +---------------+---------------+
  264.  
  265.    Each class runs a separate copy of the mechanism defined in [2], i.e.
  266.    uses a separate sequence number space and reassembly buffer.
  267.  
  268.    Similarly, for the long sequence number format:
  269.  
  270.        Figure 3:  Long Sequence Number Fragment Format With Classes
  271.  
  272.                 +---------------+---------------+
  273.    PPP Header:  | Address 0xff  | Control 0x03  |
  274.                 +---------------+---------------+
  275.                 | PID(H)  0x00  | PID(L)  0x3d  |
  276.                 +-+-+-+-+-+-+-+-+---------------+
  277.    MP Header:   |B|E| class |0|0|sequence number|
  278.                 +-+-+-+-+-+-+-+-+---------------+
  279.                 |      sequence number (L)      |
  280.                 +---------------+---------------+
  281.                 |        fragment data          |
  282.                 |               .               |
  283.                 |               .               |
  284.                 |               .               |
  285.                 +---------------+---------------+
  286.    PPP FCS:     |              FCS              |
  287.                 +---------------+---------------+
  288.  
  289. Bormann                                                         [Page 5]
  290.  
  291. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  292.  
  293.    Together with the ability to send packets without a multilink header,
  294.    this provides four levels of suspension with 12-bit headers (probably
  295.    sufficient for many practical applications) and sixteen levels with
  296.    24-bit headers (only four of the six free bits are used in this case
  297.    -- based on the rationale given above, sixteen levels should
  298.    generally be more than sufficient).
  299.  
  300. 5.  Prefix elision: Compressing common header bytes
  301.  
  302.    For some applications, all packets of a certain class will have a
  303.    common protocol identifier (or even more than one common prefix
  304.    byte).  In this case, the following optimization is possible: the
  305.    class number can be associated with a prefix of bytes that are
  306.    removed from each packet before transmission and that are implicitly
  307.    prepended to the reassembled packet after reception.
  308.  
  309.    Note that if only some of the packets to be transmitted at a certain
  310.    level of priority have the common prefix, it may still be possible to
  311.    utilize this method by allocating two class numbers and only
  312.    associating one of them with the prefix.  (This is the reason why
  313.    four of the unused bits in the long sequence number format have been
  314.    allocated to the class number instead of the three that generally
  315.    should suffice.)
  316.  
  317.    Prefix elision is not a replacement for header compression or data
  318.    compression: it allows to compress away prefixes that often are not
  319.    reachable by these other methods.
  320.  
  321.  
  322. 6.  Negotiable options
  323.  
  324.    The following PPP LCP options are already defined by MP:
  325.  
  326.    o    Multilink Maximum Received Reconstructed Unit
  327.  
  328.    o    Multilink Short Sequence Number Header Format
  329.  
  330.    o    Endpoint Discriminator
  331.  
  332.    This document defines two new LCP options:
  333.  
  334.    o    Multilink Header Format
  335.  
  336.    o    Prefix Elision
  337.  
  338. 6.1.  Multilink header format option
  339.  
  340.  
  341.    A summary of the Multilink Header Format Option format is shown
  342.    below.  The fields are transmitted from left to right.
  343.  
  344.  
  345.  
  346.  
  347. Bormann                                                         [Page 6]
  348.  
  349. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  350.  
  351.  
  352.                                  Figure 4:
  353.     0                   1                   2
  354.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  355.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  356.    |  Type = TBD   |  Length = 3   |     Code      |
  357.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  358.  
  359.  
  360.    This LCP option advises the peer that the implementation wishes to
  361.    receive fragments with a format given by the code number.  By
  362.    default, long sequence number multilink headers without classes are
  363.    used.  When this option is received, an implementation MUST either
  364.    transmit all subsequent multilink packets on all links of the bundle
  365.    with the multilink header format given or configure-NAK or configure-
  366.    Reject the option.
  367.  
  368.    The values defined for the use of this option are:
  369.  
  370.    -    Neither this option nor the Short Sequence Number Header Format
  371.         Option (type 18) [2] is present: long sequence number fragment
  372.         format
  373.  
  374.    -    This option present with code = 2: long sequence number fragment
  375.         format with classes
  376.  
  377.    -    Short Sequence Number Header Format Option (type 18) present:
  378.         short sequence number fragment format
  379.  
  380.    -    This option present with code = 6: short sequence number
  381.         fragment format with classes
  382.  
  383.    An implementation MUST NOT request a combination of both the Short
  384.    Sequence Number Header Format Option and this option.
  385.  
  386.  
  387. 6.2.  Prefix elision option
  388.  
  389.  
  390.    This LCP option advises the peer that the implementation wishes to
  391.    send only packets with a certain prefix in each of the given classes;
  392.    this prefix is not sent as part of the information in the fragment(s)
  393.    of this class.  By default, this common prefix is empty for all
  394.    classes.  When this option is received, an implementation MUST either
  395.    add the prefix given for the class to all subsequently received
  396.    multilink packets of each of the given classes or configure-NAK or
  397.    configure-Reject the option.
  398.  
  399.    If none of the formats with classes has been negotiated, class number
  400.    0 may be used to indicate a common prefix for all packets sent within
  401.    multilink fragments.
  402.  
  403.    Apart from the type and length octets common to all LCP options, the
  404.  
  405. Bormann                                                         [Page 7]
  406.  
  407. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  408.  
  409.    option contains a sequence of zero or more sequences of a class
  410.    number, a length of the prefix for that class, and the octets in that
  411.    prefix:
  412.  
  413.                                  Figure 5:
  414.     0                   1                   2                   3
  415.     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
  416.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.    |   Type = TBD  | Option Length |    Class      | Prefix Length |
  418.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.    |   Prefix...
  420.    +-+-+-+-+-+-+-+-+
  421.  
  422.  
  423.    NOTA BENE: the sense of this option is an indication from the sender
  424.    to the receiver, UNLIKE most PPP options that indicate capabilities
  425.    of the receiver to the sender.
  426.  
  427. 7.  Acknowledgements
  428.  
  429.    David Oran suggested using PPP Multilink for real-time framing and
  430.    reminded the author of his earlier attempts of making Multilink more
  431.    useful for this purpose.  The participants in a lunch BOF at the 1996
  432.    Montreal IETF gave useful input on the design tradeoffs in various
  433.    environments.  The members of the ISSLL subgroup on low bitrate links
  434.    (ISSLOW) have helped reducing the large set of options that initial
  435.    versions of this draft had.
  436.  
  437.  
  438. 8.  References
  439.  
  440.  
  441.    [1]  C. Bormann, ``Providing integrated services over low-bitrate
  442.         links'', Work in Progress (draft-ietf-issll-isslow-02.txt), May
  443.         1997.
  444.  
  445.    [2]  K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The
  446.         PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes
  447.         RFC1717).
  448.  
  449.    [3]  W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996.
  450.  
  451.    [4]  R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work
  452.         in Progress (draft-andrades-framing-ext-00.txt), September 1996.
  453.  
  454.    [5]  C. Bormann, ``PPP in a real-time oriented HDLC-like framing'',
  455.         Work in Progress (draft-ietf-issll-isslow-rtf-01.txt), May 1997.
  456.  
  457.  
  458. 9.  Addresses
  459.  
  460.  
  461.  
  462.  
  463. Bormann                                                         [Page 8]
  464.  
  465. INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPP      May 1997
  466.  
  467. 9.1.  Working Group
  468.  
  469.    The ISSLL working group can be contacted via the co-chairs, Eric
  470.    Crawley <esc@baynetworks.com> and John Wroclawski <jtw@lcs.mit.edu>,
  471.    or via its WG mailing list <issll@mercury.lcs.mit.edu>.
  472.  
  473. 9.2.  Author's address
  474.  
  475.  
  476.    Carsten Bormann
  477.    Universitaet Bremen FB3 TZI
  478.    Postfach 330440
  479.    D-28334 Bremen, GERMANY
  480.    cabo@tzi.uni-bremen.de
  481.    phone +49.421.218-7024
  482.    fax +49.421.218-7000
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521. Bormann                                                         [Page 9]
  522.  
  523.