rfc1662.txt

this is a linux pptp software

      The use of other FCS lengths may be defined at a later time, or by
      prior agreement.

      The FCS field is calculated over all bits of the Address, Control,
      Protocol, Information and Padding fields, not including any start
      and stop bits (asynchronous) nor any bits (synchronous) or octets
      (asynchronous or synchronous) inserted for transparency.  This
      also does not include the Flag Sequences nor the FCS field itself.

         When octets are received which are flagged in the Async-
         Control-Character-Map, they are discarded before calculating
         the FCS.

      For more information on the specification of the FCS, see the
      Appendices.

   The end of the Information and Padding fields is found by locating
   the closing Flag Sequence and removing the Frame Check Sequence
   field.













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


3.2.  Modification of the Basic Frame

   The Link Control Protocol can negotiate modifications to the standard
   HDLC-like frame structure.  However, modified frames will always be
   clearly distinguishable from standard frames.

   Address-and-Control-Field-Compression

      When using the standard HDLC-like framing, the Address and Control
      fields contain the hexadecimal values 0xff and 0x03 respectively.
      When other Address or Control field values are in use, Address-
      and-Control-Field-Compression MUST NOT be negotiated.

      On transmission, compressed Address and Control fields are simply
      omitted.

      On reception, the Address and Control fields are decompressed by
      examining the first two octets.  If they contain the values 0xff
      and 0x03, they are assumed to be the Address and Control fields.
      If not, it is assumed that the fields were compressed and were not
      transmitted.

         By definition, the first octet of a two octet Protocol field
         will never be 0xff (since it is not even).  The Protocol field
         value 0x00ff is not allowed (reserved) to avoid ambiguity when
         Protocol-Field-Compression is enabled and the first Information
         field octet is 0x03.
























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


4.  Octet-stuffed framing

   This chapter summarizes the use of HDLC-like framing with 8-bit
   asynchronous and octet-synchronous links.



4.1.  Flag Sequence

   The Flag Sequence indicates the beginning or end of a frame.  The
   octet stream is examined on an octet-by-octet basis for the value
   01111110 (hexadecimal 0x7e).



4.2.  Transparency

   An octet stuffing procedure is used.  The Control Escape octet is
   defined as binary 01111101 (hexadecimal 0x7d), most significant bit
   first.

   As a minimum, sending implementations MUST escape the Flag Sequence
   and Control Escape octets.

   After FCS computation, the transmitter examines the entire frame
   between the two Flag Sequences.  Each Flag Sequence, Control Escape
   octet, and any octet which is flagged in the sending Async-Control-
   Character-Map (ACCM), is replaced by a two octet sequence consisting
   of the Control Escape octet followed by the original octet
   exclusive-or'd with hexadecimal 0x20.

      This is bit 5 complemented, where the bit positions are numbered
      76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE
      when comparing documents).

   Receiving implementations MUST correctly process all Control Escape
   sequences.

   On reception, prior to FCS computation, each octet with value less
   than hexadecimal 0x20 is checked.  If it is flagged in the receiving
   ACCM, it is simply removed (it may have been inserted by intervening
   data communications equipment).  Each Control Escape octet is also
   removed, and the following octet is exclusive-or'd with hexadecimal
   0x20, unless it is the Flag Sequence (which aborts a frame).

   A few examples may make this more clear.  Escaped data is transmitted
   on the link as follows:




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



      0x7e is encoded as 0x7d, 0x5e.    (Flag Sequence)
      0x7d is encoded as 0x7d, 0x5d.    (Control Escape)
      0x03 is encoded as 0x7d, 0x23.    (ETX)

   Some modems with software flow control may intercept outgoing DC1 and
   DC3 ignoring the 8th (parity) bit.  This data would be transmitted on
   the link as follows:

      0x11 is encoded as 0x7d, 0x31.    (XON)
      0x13 is encoded as 0x7d, 0x33.    (XOFF)
      0x91 is encoded as 0x7d, 0xb1.    (XON with parity set)
      0x93 is encoded as 0x7d, 0xb3.    (XOFF with parity set)




4.3.  Invalid Frames

   Frames which are too short (less than 4 octets when using the 16-bit
   FCS), or which end with a Control Escape octet followed immediately
   by a closing Flag Sequence, or in which octet-framing is violated (by
   transmitting a "0" stop bit where a "1" bit is expected), are
   silently discarded, and not counted as a FCS error.



4.4.  Time Fill

4.4.1.  Octet-synchronous

   There is no provision for inter-octet time fill.

   The Flag Sequence MUST be transmitted during inter-frame time fill.


4.4.2.  Asynchronous

   Inter-octet time fill MUST be accomplished by transmitting continuous
   "1" bits (mark-hold state).

   Inter-frame time fill can be viewed as extended inter-octet time
   fill.  Doing so can save one octet for every frame, decreasing delay
   and increasing bandwidth.  This is possible since a Flag Sequence may
   serve as both a frame end and a frame begin.  After having received
   any frame, an idle receiver will always be in a frame begin state.




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


   Robust transmitters should avoid using this trick over-zealously,
   since the price for decreased delay is decreased reliability.  Noisy
   links may cause the receiver to receive garbage characters and
   interpret them as part of an incoming frame.  If the transmitter does
   not send a new opening Flag Sequence before sending the next frame,
   then that frame will be appended to the noise characters causing an
   invalid frame (with high reliability).

   It is suggested that implementations will achieve the best results by
   always sending an opening Flag Sequence if the new frame is not
   back-to-back with the last.  Transmitters SHOULD send an open Flag
   Sequence whenever "appreciable time" has elapsed after the prior
   closing Flag Sequence.  The maximum value for "appreciable time" is
   likely to be no greater than the typing rate of a slow typist, about
   1 second.



4.5.  Transmission Considerations

4.5.1.  Octet-synchronous

   The definition of various encodings and scrambling is the
   responsibility of the DTE/DCE equipment in use, and is outside the
   scope of this specification.


4.5.2.  Asynchronous

   All octets are transmitted least significant bit first, with one
   start bit, eight bits of data, and one stop bit.  There is no
   provision for seven bit asynchronous links.


















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


5.  Bit-stuffed framing

   This chapter summarizes the use of HDLC-like framing with bit-
   synchronous links.



5.1.  Flag Sequence

   The Flag Sequence indicates the beginning or end of a frame, and is
   used for frame synchronization.  The bit stream is examined on a
   bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e).

   The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be
   used.  When not avoidable, such an implementation MUST ensure that
   the first Flag Sequence detected (the end of the frame) is promptly
   communicated to the link layer.  Use of the shared zero mode hinders
   interoperability with bit-synchronous to asynchronous and bit-
   synchronous to octet-synchronous converters.



5.2.  Transparency

   After FCS computation, the transmitter examines the entire frame
   between the two Flag Sequences.  A "0" bit is inserted after all
   sequences of five contiguous "1" bits (including the last 5 bits of
   the FCS) to ensure that a Flag Sequence is not simulated.

   On reception, prior to FCS computation, any "0" bit that directly
   follows five contiguous "1" bits is discarded.



5.3.  Invalid Frames

   Frames which are too short (less than 4 octets when using the 16-bit
   FCS), or which end with a sequence of more than six "1" bits, are
   silently discarded, and not counted as a FCS error.



5.4.  Time Fill

   There is no provision for inter-octet time fill.

   The Flag Sequence SHOULD be transmitted during inter-frame time fill.
   However, certain types of circuit-switched links require the use of



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


   mark idle (continuous ones), particularly those that calculate
   accounting based on periods of bit activity.  When mark idle is used
   on a bit-synchronous link, the implementation MUST ensure at least 15
   consecutive "1" bits between Flags during the idle period, and that
   the Flag Sequence is always generated at the beginning of a frame
   after an idle period.

      This differs from practice in ISO 3309, which allows 7 to 14 bit
      mark idle.



5.5.  Transmission Considerations

   All octets are transmitted least significant bit first.

   The definition of various encodings and scrambling is the
   responsibility of the DTE/DCE equipment in use, and is outside the
   scope of this specification.

   While PPP will operate without regard to the underlying
   representation of the bit stream, lack of standards for transmission
   will hinder interoperability as surely as lack of data link
   standards.  At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently
   most widely available, and on that basis is recommended as a default.

   When configuration of the encoding is allowed, NRZI is recommended as
   an alternative, because of its relative immunity to signal inversion
   configuration errors, and instances when it MAY allow connection
   without an expensive DSU/CSU.  Unfortunately, NRZI encoding
   exacerbates the missing x1 factor of the 16-bit FCS, so that one
   error in 2**15 goes undetected (instead of one in 2**16), and triple
   errors are not detected.  Therefore, when NRZI is in use, it is
   recommended that the 32-bit FCS be negotiated, which includes the x1
   factor.

   At higher speeds of up to 45 Mbps, some implementors have chosen the
   ANSI High Speed Synchronous Interface [HSSI].  While this experience
   is currently limited, implementors are encouraged to cooperate in
   choosing transmission encoding.