rfc1662.txt

pptp第二层隧道模块

Simpson                                                        [Page 12]
RFC 1662                   HDLC-like Framing                   July 1994


6.  Asynchronous to Synchronous Conversion

   There may be some use of asynchronous-to-synchronous converters (some
   built into modems and cellular interfaces), resulting in an
   asynchronous PPP implementation on one end of a link and a
   synchronous implementation on the other.  It is the responsibility of
   the converter to do all stuffing conversions during operation.

   To enable this functionality, synchronous PPP implementations MUST
   always respond to the Async-Control-Character-Map Configuration
   Option with the LCP Configure-Ack.  However, acceptance of the
   Configuration Option does not imply that the synchronous
   implementation will do any ACCM mapping.  Instead, all such octet
   mapping will be performed by the asynchronous-to-synchronous
   converter.




































Simpson                                                        [Page 13]
RFC 1662                   HDLC-like Framing                   July 1994


7.  Additional LCP Configuration Options

   The Configuration Option format and basic options are already defined
   for LCP [1].

   Up-to-date values of the LCP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [10].  This document concerns the
   following values:

      2       Async-Control-Character-Map




7.1.  Async-Control-Character-Map (ACCM)

   Description

      This Configuration Option provides a method to negotiate the use
      of control character transparency on asynchronous links.

      Each end of the asynchronous link maintains two Async-Control-
      Character-Maps.  The receiving ACCM is 32 bits, but the sending
      ACCM may be up to 256 bits.  This results in four distinct ACCMs,
      two in each direction of the link.

      For asynchronous links, the default receiving ACCM is 0xffffffff.
      The default sending ACCM is 0xffffffff, plus the Control Escape
      and Flag Sequence characters themselves, plus whatever other
      outgoing characters are flagged (by prior configuration) as likely
      to be intercepted.

      For other types of links, the default value is 0, since there is
      no need for mapping.

         The default inclusion of all octets less than hexadecimal 0x20
         allows all ASCII control characters [6] excluding DEL (Delete)
         to be transparently communicated through all known data
         communications equipment.

      The transmitter MAY also send octets with values in the range 0x40
      through 0xff (except 0x5e) in Control Escape format.  Since these
      octet values are not negotiable, this does not solve the problem
      of receivers which cannot handle all non-control characters.
      Also, since the technique does not affect the 8th bit, this does
      not solve problems for communications links that can send only 7-
      bit characters.




Simpson                                                        [Page 14]
RFC 1662                   HDLC-like Framing                   July 1994


         Note that this specification differs in detail from later
         amendments, such as 3309:1991/Amendment 2 [3].  However, such
         "extended transparency" is applied only by "prior agreement".
         Use of the transparency methods in this specification
         constitute a prior agreement with respect to PPP.

         For compatibility with 3309:1991/Amendment 2, the transmitter
         MAY escape DEL and ACCM equivalents with the 8th (most
         significant) bit set.  No change is required in the receiving
         algorithm.

         Following ACCM negotiation, the transmitter SHOULD cease
         escaping DEL.

      However, it is rarely necessary to map all control characters, and
      often it is unnecessary to map any control characters.  The
      Configuration Option is used to inform the peer which control
      characters MUST remain mapped when the peer sends them.

      The peer MAY still send any other octets in mapped format, if it
      is necessary because of constraints known to the peer.  The peer
      SHOULD Configure-Nak with the logical union of the sets of mapped
      octets, so that when such octets are spuriously introduced they
      can be ignored on receipt.

   A summary of the Async-Control-Character-Map Configuration Option
   format is shown below.  The fields are transmitted from left to
   right.

    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      |    Length     |               ACCM
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ACCM (cont)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      2

   Length

      6






Simpson                                                        [Page 15]
RFC 1662                   HDLC-like Framing                   July 1994


   ACCM

      The ACCM field is four octets, and indicates the set of control
      characters to be mapped.  The map is sent most significant octet
      first.

      Each numbered bit corresponds to the octet of the same value.  If
      the bit is cleared to zero, then that octet need not be mapped.
      If the bit is set to one, then that octet MUST remain mapped.  For
      example, if bit 19 is set to zero, then the ASCII control
      character 19 (DC3, Control-S) MAY be sent in the clear.

         Note: The least significant bit of the least significant octet
         (the final octet transmitted) is numbered bit 0, and would map
         to the ASCII control character NUL.




































Simpson                                                        [Page 16]
RFC 1662                   HDLC-like Framing                   July 1994


A.  Recommended LCP Options

   The following Configurations Options are recommended:

   High Speed links

      Magic Number
      Link Quality Monitoring
      No Address and Control Field Compression
      No Protocol Field Compression


   Low Speed or Asynchronous links

      Async Control Character Map
      Magic Number
      Address and Control Field Compression
      Protocol Field Compression



B.  Automatic Recognition of PPP Frames

   It is sometimes desirable to detect PPP frames, for example during a
   login sequence.  The following octet sequences all begin valid PPP
   LCP frames:

      7e ff 03 c0 21
      7e ff 7d 23 c0 21
      7e 7d df 7d 23 c0 21

   Note that the first two forms are not a valid username for Unix.
   However, only the third form generates a correctly checksummed PPP
   frame, whenever 03 and ff are taken as the control characters ETX and
   DEL without regard to parity (they are correct for an even parity
   link) and discarded.

   Many implementations deal with this by putting the interface into
   packet mode when one of the above username patterns are detected
   during login, without examining the initial PPP checksum.  The
   initial incoming PPP frame is discarded, but a Configure-Request is
   sent immediately.









Simpson                                                        [Page 17]
RFC 1662                   HDLC-like Framing                   July 1994


C.  Fast Frame Check Sequence (FCS) Implementation

   The FCS was originally designed with hardware implementations in
   mind.  A serial bit stream is transmitted on the wire, the FCS is
   calculated over the serial data as it goes out, and the complement of
   the resulting FCS is appended to the serial stream, followed by the
   Flag Sequence.

   The receiver has no way of determining that it has finished
   calculating the received FCS until it detects the Flag Sequence.
   Therefore, the FCS was designed so that a particular pattern results
   when the FCS operation passes over the complemented FCS.  A good
   frame is indicated by this "good FCS" value.



C.1.  FCS table generator

   The following code creates the lookup table used to calculate the
   FCS-16.

   /*
    * Generate a FCS-16 table.
    *
    * Drew D. Perkins at Carnegie Mellon University.
    *
    * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
    */

   /*
    * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16.
    */
   #define P       0x8408


   main()
   {
       register unsigned int b, v;
       register int i;

       printf("typedef unsigned short u16;\n");
       printf("static u16 fcstab[256] = {");
       for (b = 0; ; ) {
           if (b % 8 == 0)
               printf("\n");

           v = b;
           for (i = 8; i--; )



Simpson                                                        [Page 18]
RFC 1662                   HDLC-like Framing                   July 1994


               v = v & 1 ? (v >> 1) ^ P : v >> 1;

           printf("\t0x%04x", v & 0xFFFF);
           if (++b == 256)
               break;
           printf(",");
       }
       printf("\n};\n");
   }



C.2.  16-bit FCS Computation Method

   The following code provides a table lookup computation for
   calculating the Frame Check Sequence as data arrives at the
   interface.  This implementation is based on [7], [8], and [9].

   /*
    * u16 represents an unsigned 16-bit number.  Adjust the typedef for
    * your hardware.
    */
   typedef unsigned short u16;

   /*