rfc2687.txt

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

   |            data               |
   :                               :
   +---+---+---+---+---+---+---+---+
   +              FSE              + previous fragment implicitly E = 0
   +---+---+---+---+---+---+---+---+
   | R |  sequence |   class   | 1 |
   +---+---+---+---+---+---+---+---+
   |            data               |
   :                               :
   +---+---+---+---+---+---+---+---+
   |             Frame             | previous fragment implicitly E = 1
   |              CRC              |
   +---+---+---+---+---+---+---+---+

   The value chosen for FSE is 0xDE (this is a relatively unlikely byte
   to occur in today's data streams, it does not trigger octet stuffing
   and triggers bit stuffing only for 1/8 of the possible preceding
   bytes).

   The remaining problem is that of data transparency.  In the scheme
   described so far, an FSE is always followed by a compact fragment
   header.  In these headers, the combination of a class field set to 7





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


   with R=1 is reserved.  Data transparency is achieved by making the
   occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF
   special.

            Figure 3:  Data transparency with FSE bytes present

           0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | R |  sequence |   class   | 1 |
          +---+---+---+---+---+---+---+---+
          |            data               |
          :                               :
          +---+---+---+---+---+---+---+---+
          +              FSE              + fragment NOT terminated
          +---+---+---+---+---+---+---+---+
          | R | S | T | U | 1 | 1 | 1 | 1 | R always is 1
          +---+---+---+---+---+---+---+---+
          |            data               | fragment continues
          :                               :

   In a combination of FSE/0xnF (where n is the first four-bit field in
   the second byte, RSTU in Figure 3), the n field gives a sequence of
   four bits indicating where in the received data stream FSE bytes,
   which cannot simply be transmitted in the data stream, are to be
   added by the receiver:

0x8F: insert one FSE, back to data
0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data
0xAF: insert one FSE, copy one data byte, insert one FSE, back to data
0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back
      to data
0xCF: insert two FSE bytes, back to data
0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back
      to data
0xEF: insert three FSE bytes, back to data
0xFF: insert four FSE bytes, back to data

   The data bytes following the FSE/0xnF combinations and corresponding
   to the zero bits in the N field may not be FSE bytes.

   This scheme limits the worst case expansion factor by FSE processing
   to about 25 %.  Also, it is designed such that a single data stream
   can either trigger worst-case expansion by octet stuffing (or by bit
   stuffing) or worst-case FSE processing, but never both.  Figure 4
   illustrates the scheme in a few examples; FSE/0xnF pairs are written
   in lower case.





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


                 Figure 4:  Data transparency examples

            Data stream                     FSE-stuffed stream

            DD DE DF E0                     DD de 8f DF E0
            01 DE 02 DE 03                  01 de af 02 03
            DE DA DE DE DB                  de bf DA DB
            DE DE DE DE DE DA               de ff de 8f DA

   In summary, the real-time frame format is a HDLC-like frame delimited
   by flags and containing a final FCS as defined in [7], but without
   address and control fields, containing as data a sequence of FSE-
   stuffed fragments in compact fragment format, delimited by FSE bytes.
   As a special case, the final FSE may occur as the last byte of the
   data content (i.e. immediately before the FCS bytes) of the HDLC-like
   frame, to indicate that the last fragment in the frame is suspended
   and no final fragment is in the frame (e.g., because the desirable
   maximum size of the frame has been reached).

7.  Implementation notes

7.1.  MRU Issues

   The LCP parameter MRU defines the maximum size of the packets sent on
   the link.  Async-to-sync converters that are monitoring the LCP
   negotiations on the link may interpret the MRU value as the maximum
   HDLC frame size to be expected.

   Implementations of this specification should preferably negotiate a
   sufficiently large MRU to cover the worst-case 25 % increase in frame
   size plus the increase caused by suspended fragments.  If that is not
   possible, the HDLC frame size should be limited by monitoring the
   HDLC frame sizes and possibly suspending the current fragment by
   sending an FSE with an empty final fragment (FSE immediately followed
   by the end of the information field, i.e. by CRC bytes and a flag) to
   be able to continue in a new HDLC frame.  This strategy also helps
   minimizing the impact of lengthening the HDLC frame on the safety of
   the 16-bit FCS at the end of the HDLC frame.

7.2.  Implementing octet-stuffing and FSE processing in one automaton

   The simplest way to add real-time framing to an implementation may be
   to perform HDLC processing as usual and then, on the result, to
   perform FSE processing.  A more advanced implementation may want to
   combine the two levels of escape character processing.  Note,
   however, that FSE processing needs to wait until two bytes from the
   HDLC frame are available and followed by a third to ensure that the
   bytes are not the final HDLC FCS bytes, which are not subject to FSE



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


   processing.  I.e., on the reception of normal data byte, look for an
   FSE in the second-to-previous byte, and, on the reception of a
   frame-end, look for an FSE as the last data byte.

8.  Negotiable options

   The following options are already defined by MP [2]:

   o    Multilink Maximum Received Reconstructed Unit

   o    Multilink Short Sequence Number Header Format

   o    Endpoint Discriminator

   The following options are already defined by MCML [5]:

   o    Multilink Header Format

   o    Prefix Elision

   This document defines two new code points for the Multilink Header
   Format option.

8.1.  Multilink header format option

   The multilink header format option is defined in [5].  A summary of
   the Multilink Header Format Option format is shown below.  The fields
   are transmitted from left to right.

           Figure 5:  Multilink header format option

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

    As defined in [5], 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.  This specification defines two additional values for
    Code, in addition to those defined in [5]:

   -  Code = 11: basic and extended compact real-time fragment format
      with classes, in FSE-encoded HDLC frame

   -  Code = 15: basic compact real-time fragment format with classes,
      in FSE-encoded HDLC frame



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


   An implementation MUST NOT request a combination of both LCP
   Address-and-Control-Field-Compression (ACFC) and the code values 11
   or 15 for this option.

   The number of suspendable classes negotiated for the compact real-
   time fragment format only limits the use of class numbers that allow
   suspending.  As class numbers of 7 and higher do not require
   additional reassembly space, they are not subject to the class number
   limit negotiated.

9.  Security Considerations

   Operation of this protocol is believed to be no more and no less
   secure than operation of the PPP multilink protocol [2].  Operation
   with a small sequence number range increases the likelihood that
   fragments from different packets could be incorrectly reassembled
   into one packet.  While most such packets will be discarded by the
   receiver because of higher-layer checksum failures or other
   inconsistencies, there is an increase in likelihood that contents of
   packets destined for one host could be delivered to another host.
   Links that carry packets where this raises security considerations
   SHOULD use the extended sequence number range for multi-fragment
   packets.

10.  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., "The Multi-Class Extension to Multi-Link PPP", RFC
        2686, 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.





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


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

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

Acknowledgements

   The participants in a lunch BOF at the Montreal IETF 1996 gave useful
   input on the design tradeoffs in various environments.  Richard
   Andrades, Fred Burg, and Murali Aravamudan insisted that there should
   be a suspend/resume solution in addition to the pre-fragmenting one
   defined in [5].  The members of the ISSLL subgroup on low bitrate
   links (ISSLOW) have helped in coming up with a set of requirements
   that shaped this solution.




























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


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 13]