rfc2687.txt

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

Network Working Group                                         C. Bormann
Request for Comments: 2687                       Universitaet Bremen TZI
Category: Standards Track                                 September 1999


             PPP in a Real-time Oriented HDLC-like Framing

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   A companion document describes an architecture for providing
   integrated services over low-bitrate links, such as modem lines, ISDN
   B-channels, and sub-T1 links [1].  The main components of the
   architecture are: a real-time encapsulation format for asynchronous
   and synchronous low-bitrate links, a header compression architecture
   optimized for real-time flows, elements of negotiation protocols used
   between routers (or between hosts and routers), and announcement
   protocols used by applications to allow this negotiation to take
   place.

   This document proposes the suspend/resume-oriented solution for the
   real-time encapsulation format part of the architecture.  The general
   approach is to start from the PPP Multilink fragmentation protocol
   [2] and its multi-class extension [5] and add suspend/resume in a way
   that is as compatible to existing hard- and firmware as possible.

1.  Introduction

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

   The present document defines the suspend/resume-oriented solution for
   the real-time encapsulation format part of the architecture.  As
   described in more detail in the architecture document, a real-time
   encapsulation format is required as, e.g., a 1500 byte packet on a



Bormann                     Standards Track                     [Page 1]

RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999


   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.

   A true suspend/resume-oriented approach can only be implemented on a
   type-1 sender [1], but provides the best possible delay performance
   to this type of senders.  The format defined in this document may
   also be of interest to certain type-2-senders that want to exploit
   the better bit-efficiency of this format as compared to [5].  The
   format was designed so that it can be implemented by both type-1 and
   type-2 receivers.

1.1.  Specification Language

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

2.  Requirements

   The requirements for this document are similar to those listed in
   [5].

   A suspend/resume-oriented solution can provide better worst-case
   latency than the pre-fragmenting-oriented solution defined in [5].
   Also, as this solution requires a new encapsulation scheme, there is
   an opportunity to provide a slightly more efficient format.

   Predictability, robustness, and cooperation with PPP and existing
   hard- and firmware installations are as important with suspend/resume
   as with pre-fragmenting.  A good suspend/resume solution achieves
   good performance even with type-2 receivers [1] and is able to work
   with PPP hardware such as async-to-sync converters.

   Finally, a partial non-requirement: While the format defined in this
   draft is based on the PPP multilink protocol ([2], also abbreviated
   as MP), operation over multiple links is in many cases not required.

3.  General Approach

   As in [5], the general approach is to start out from PPP multilink
   and add multiple classes to obtain multiple levels of suspension.
   However, in contrast to [5], more significant changes are required to
   be able to suspend the transmission of a packet at any point and
   inject a higher priority packet.




Bormann                     Standards Track                     [Page 2]

RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999


   The applicability of the multilink header for suspend/resume type
   implementations is limited, as the "end" bit is in the multilink
   header, which is the wrong place for suspend/resume operation.  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).

   Also, the existing multi-link header is relatively large; as the
   frequency of small high-priority packets increases, the overhead
   becomes significant.

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

   This document introduces two new features:

   1)   A compact fragment format and header, and

   2)   a real-time frame format.

4.  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 senders)/a small fragment size (type 2 senders), with
   optional support for multiple links.

   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 the following compact multilink header format
   option with a three-bit sequence number.

   As, with a compact header, there is little need for sending packets
   outside 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 a method for avoiding the bit combination





Bormann                     Standards Track                     [Page 3]

RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999


   0xFF (the first octet in an LCP frame before any LCP options have
   been negotiated), as the start of a new LCP negotiation could
   otherwise not be reliably detected.

                  Figure 1:  Compact Fragment Format

                    0   1   2   3   4   5   6   7
                  +---+---+---+---+---+---+---+---+
                  | R |  sequence |   class   | 1 |
                  +---+---+---+---+---+---+---+---+
                  |            data               |
                  :                               :
                  +---+---+---+---+---+---+---+---+

   Having the least significant bit always be 1 helps with HDLC chips
   that operate specially on least significant bits in HDLC addresses.
   (Initial bytes with the least significant bit set to zero are used
   for the extended compact fragment format, see next section.)

   The R bit is the inverted equivalent of the B bit in the other
   multilink 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 (which
   would mean R=1, sequence=7, and class=7): If the class field is set
   to 7, the R bit MUST never be set to one.  I.e., class 7 frames by
   design 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 -- class 7 would be useless otherwise, as a new packet could
   never be begun.)

   As the sequence number is not particularly useful with the class
   field set to 7, it is used to distinguish eight more classes -- for
   some minor additional complexity, the applicability of prefix elision
   is significantly increased by providing more classes with possibly
   different elided prefixes.

   For purposes of prefix elision, the actual class number of a fragment
   is computed as follows:

   -  If the class field is 0 to 6, the class number is 0 to 6,

   -  if the class field is 7 and the sequence field is 0 to 7, the
      class number is 7 to 14.







Bormann                     Standards Track                     [Page 4]

RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999


   As a result of this scheme, the classes 0 to 6 can be used for
   suspendable packets, and classes 7 to 14 (where the class field is 7
   and the R bit must always be off) can be used for non-suspendable
   high-priority classes, e.g., eight highly compressed voice streams.

5.  The Extended Compact Fragment Format

   For operation over multiple links, a three-bit sequence number will
   rarely be sufficient.  Therefore, we define an optional extended
   compact fragment format.  The option, when negotiated, allows both
   the basic compact fragment format and the extended compact fragment
   format to be used; each fragment indicates which format it is in.

               Figure 1:  Extended Compact Fragment Format

                     0   1   2   3   4   5   6   7
                   +---+---+---+---+---+---+---+---+
                   | R |  seq LSB  |   class   | 0 |
                   +---+---+---+---+---+---+---+---+
                   |      sequence -- MSB      | 1 |
                   +---+---+---+---+---+---+---+---+
                   |            data               |
                   :                               :
                   +---+---+---+---+---+---+---+---+

   In the extended compact fragment format, the sequence number is
   composed of three least significant bits from the first octet of the
   fragment header and seven most significant bits from the second
   octet.  (Again, the least significant bit of the second octet is
   always set to one for compatibility with certain HDLC chips.)

   For prefix elision purposes, fragments with a class field of 7 can
   use the basic format to indicate classes 7 to 14 and the extended
   format to indicate classes 7 to 1030.  Different classes may use
   different formats concurrently without problems.  (This allows some
   classes to be spread over a multi-link and other classes to be
   confined to a single link with greater efficiency.)  For class fields
   0 to 6, i.e. suspendable classes, one of the two compact fragment
   formats SHOULD be used consistently within each class.

   If the use of the extended compact fragment format has been
   negotiated, receivers MAY keep 10-bit sequence numbers for all
   classes to facilitate senders switching formats in a class.  When a
   sender starts sending basic format fragments in a class that was
   using extended format fragments, the 3-bit sequence number can be
   taken as a modulo-8 version of the 10-bit sequence number, and no
   discontinuity need result.  In the inverse case, if a 10-bit sequence
   number has been kept throughout by the receiver (and no major slips



Bormann                     Standards Track                     [Page 5]

RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999


   of the sequence number have occurred), no discontinuity will result,
   although this cannot be guaranteed in the presence of errors.
   (Discontinuity, in this context, means that a receiver has to
   resynchronize sequence numbers by discarding fragments until a
   fragment with R=0 has been seen.)

6.  Real-Time Frame Format

   This section defines how fragments with compact fragment headers are
   mapped into real-time frames.  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.  Note that if the design could be optimized for async only
   operation, more design alternatives would be available [4]; with the
   advent of V.80 style modems, asynchronous communications is likely to
   decrease in importance, though.

   The compact fragment format provides a compact rendition of the PPP
   multilink header with classes and a reduced sequence number space.
   However, it does not encode the E-bit of the PPP multilink header,
   which indicates whether the fragment at hand is the last fragment of
   a packet.

   For a solution where packets can be suspended at any point in time,
   the E-bit needs to be encoded near the end of each fragment.  The
   real-time frame format, to ensure maximum compatibility with type 2
   receivers, encodes the E-bit in the following way: Any normal frame
   ending also ends the current fragment with E implicitly set to one.
   This ensures that packets that are ready for delivery to the upper
   layers immediately trigger a receive interrupt even at type-2
   receivers.

   Fragments of packets that are to be suspended are terminated within
   the HDLC frame by a special "fragment suspend escape" byte (FSE).
   The overall structure of the HDLC frame does not change; the
   detection and handling of FSE bytes is done at a layer above HDLC
   framing.

   The suspend/resume format with FSE detection is an alternative to
   address/control field compression (ACFC, LCP option 8).  It does not
   apply to frames that start with 0xFF, the standard PPP-in-HDLC
   address field; these frames are handled as defined in [6] and [7].
   (This provision ensures that attempts to renegotiate LCP do not cause
   ambiguities.)







Bormann                     Standards Track                     [Page 6]

RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999


   For frames that do not start with 0xFF, suspend/resume processing
   performs a scan of every HDLC frame received.  The FCS of the HDLC
   frame is checked and stripped.  Compact fragment format headers (both
   basic and extended) are handled without further FSE processing.
   (Note that, as the FSE byte was chosen such that it never occurs in
   compact fragment format headers, this does not require any specific
   code.)

   Within the remaining bytes of the HDLC frame ("data part"), an FSE
   byte is used to indicate the end of the current fragment, with an E
   bit implicitly cleared.  All fragments up to the last FSE are
   considered suspended (E = 0); the final fragment is terminated (E =
   1), or, if it is empty, ignored (i.e., the data part of an HDLC frame
   can end in an FSE to indicate that the last fragment has E = 0).

   Each fragment begins with a normal header, so the structure of a
   frame could be:

                Figure 2:  Example frame with FSE delimiter

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | R |  sequence |   class   | 1 |
   +---+---+---+---+---+---+---+---+