rfc2686.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

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







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


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

6.  Negotiable options

   The following PPP LCP options are already defined by MP:

   o    Multilink Maximum Received Reconstructed Unit

   o    Multilink Short Sequence Number Header Format

   o    Endpoint Discriminator

   This document defines two new LCP options:

   o    Multilink Header Format

   o    Prefix Elision

6.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 4:

    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 = 27   |  Length = 4   |     Code      | # Susp Clses  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This LCP option advises the peer that the implementation wishes to
   receive fragments with a format given by the code number, with the
   maximum number of suspendable classes (see below) given.

   When this option is negotiated, the accepting 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.  (Note that an implementation MAY
   continue to send packets outside of multilink in any case.)  If this
   option is offered on a link which is intended to join an existing
   bundle, a system MUST offer the same multilink header format option
   value previously negotiated for the bundle, or none if none was
   negotiated previously.





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


   The values defined in this document for the use of this option are:

   -    Code = 2: long sequence number fragment format with classes

   -    Code = 6: short sequence number fragment format with classes

   The Multilink Header Format option MUST NOT occur more than once in a
   Configure-Request or Configure-Ack, and, if it is present, the Short
   Sequence Number Header Format option ([2]) MUST NOT also be present.
   If no instance of this option or the Short Sequence Number Header
   Format option is present, but an MRRU option [2] is present, then by
   default, long sequence number multilink headers with class 0 only are
   used; this is equivalent to code equals 2 and number of suspendable
   classes equals 1.  An instance of the Short Sequence Number Header
   Format Option is equivalent to an instance of this option with code
   equals 6 and number of suspendable classes equal to 1.

   The number of suspendable classes bounds the allowable class numbers:
   only class numbers numerically lower than this limit can be used for
   suspendable classes.  Implementations MAY want to negotiate a number
   smaller than made possible by the packet format to limit their
   reassembly buffer space requirements.  Implementations SHOULD at
   least support the value 4 for the short sequence number fragment
   format, and the value 8 for the long sequence number fragment format,
   unless configured differently.  Bit combinations that would indicate
   class numbers outside the negotiated range MAY be used for other
   semantics if negotiated by other means outside the scope of this
   document (e.g., [6]).

6.2.  Prefix elision option

   This LCP option advises the peer that, in each of the given classes,
   the implementation expects to receive only packets with a certain
   prefix; this prefix is not to be 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 negotiated, the accepting
   implementation MUST either transmit all subsequent multilink packets
   of each of the given classes with the given prefix removed from the
   start of the packet or Configure-Nak or Configure-Reject the option.
   If none of the formats with classes has been negotiated, class number
   0 may be used to indicate a common prefix for all packets sent within
   multilink fragments.

   Apart from the type and length octets common to all LCP options, the
   option contains a sequence of zero or more sequences of a single-
   octet class number, a single-octet length of the prefix for that
   class, and the octets in that prefix:




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


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

   The Prefix Elision option MUST NOT occur more than once in a
   Configure-Request or Configure-Nak.  If this option is offered on a
   link which is intended to join an existing multilink bundle, a system
   MUST offer the same prefix elision option value previously negotiated
   for the bundle, or none if none was negotiated previously.

   IMPLEMENTATION NOTE: as with most PPP options that indicate
   capabilities of the receiver to the sender, the sense of this option
   is an indication from the receiver to the sender of the packets
   concerned.  Often, only the senders will have sufficient control over
   their usage of classes to be able to supply useful values for this
   option.  A receiver willing to accept prefix-elided packets SHOULD
   request this option with empty content; the sender then can use
   Configure-Nak to propose the class-to-prefix mapping desired.

7.  Security Considerations

   Operation of this protocol is believed to be no more and no less
   secure than operation of the PPP multilink protocol [2].

8.  References

   [1]  Bormann, C., "Providing Integrated Services over Low-bitrate
        Links", RFC 2689, September 1999.

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

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

   [4]  Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP",
        Work in Progress.

   [5]  Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
        RFC 2687, September 1999.





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


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

   [7]  Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
        1662, July 1994.

   [8]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

9.  Author's Address

   Carsten Bormann
   Universitaet Bremen FB3 TZI
   Postfach 330440
   D-28334 Bremen, GERMANY

   Phone: +49.421.218-7024
   Fax:   +49.421.218-7000
   EMail: [e-mail]

10.  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 1996
   Montreal IETF gave useful input on the design tradeoffs in various
   environments.  The members of the ISSLL subgroup on low bitrate links
   (ISSLOW) have helped reducing the large set of options that initial
   versions of this specification had.






















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


11.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Bormann                     Standards Track                    [Page 11]