rfc1549.txt

RFC 的详细文档！

Network Working Group                                 W. Simpson, Editor
Request for Comments: 1549                                    Daydreamer
Category: Standards Track                                  December 1993


                          PPP in HDLC 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.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   This document describes the use of HDLC for framing PPP encapsulated
   packets. This document is the product of the Point-to-Point Protocol
   Working Group of the Internet Engineering Task Force (IETF).
   Comments should be submitted to the [e-mail] mailing
   list.

Table of Contents

   1.   Introduction ..................................................2
   1.1  Specification of Requirements .................................2
   1.2  Terminology ...................................................3
   2.   Physical Layer Requirements ...................................3
   3.   The Data Link Layer ...........................................4
   3.1  Frame Format ..................................................5
   3.2  Modification of the Basic Frame ...............................7
   4.   Asynchronous HDLC .............................................7
   5.   Bit-synchronous HDLC ..........................................5
   6.   Octet-synchronous HDLC ........................................12
   APPENDIX A. Fast Frame Check Sequence (FCS) Implementation .........13
   A.1  FCS Computation Method ........................................13
   A.2  Fast FCS table generator ......................................15
   SECURITY CONSIDERATIONS ............................................16
   REFERENCES .........................................................17
   ACKNOWLEDGEMENTS ...................................................17
   CHAIR'S ADDRESS ....................................................18
   EDITOR'S ADDRESS ...................................................18





Simpson                                                         [Page 1]

RFC 1549                      HDLC Framing                Decvember 1993


1.  Introduction

   This specification provides for framing over both bit-oriented and
   octet-oriented synchronous links, and asynchronous links with 8 bits
   of data and no parity.  These links MUST be full-duplex, but MAY be
   either dedicated or circuit-switched.  PPP uses HDLC as a basis for
   the framing.

   An escape mechanism is specified to allow control data such as
   XON/XOFF to be transmitted transparently over the link, and to remove
   spurious control data which may be injected into the link by
   intervening hardware and software.

   Some protocols expect error free transmission, and either provide
   error detection only on a conditional basis, or do not provide it at
   all.  PPP uses the HDLC Frame Check Sequence for error detection.
   This is commonly available in hardware implementations, and a
   software implementation is provided.

1.1 Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

    MUST

      This word, or the adjective "required", means that the definition
      is an absolute requirement of the specification.

    MUST NOT

      This phrase means that the definition is an absolute prohibition
      of the specification.

    SHOULD

      This word, or the adjective "recommended", means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications must be understood and carefully
      weighed before choosing a different course.

    MAY

      This word, or the adjective "optional", means that this item is
      one of an allowed set of alternatives.  An implementation which
      does not include this option MUST be prepared to interoperate with
      another implementation which does include the option.




Simpson                                                         [Page 2]

RFC 1549                      HDLC Framing                Decvember 1993


1.2 Terminology

   This document frequently uses the following terms:

    datagram

      The unit of transmission in the network layer (such as IP).  A
      datagram may be encapsulated in one or more packets passed to the
      data link layer.

    frame

      The unit of transmission at the data link layer.  A frame may
      include a header and/or a trailer, along with some number of units
      of data.

    packet

      The basic unit of encapsulation, which is passed across the
      interface between the network layer and the data link layer.  A
      packet is usually mapped to a frame; the exceptions are when data
      link layer fragmentation is being performed, or when multiple
      packets are incorporated into a single frame.

    peer

      The other end of the point-to-point link.

    silently discard

      This means the implementation discards the packet without further
      processing.  The implementation SHOULD provide the capability of
      logging the error, including the contents of the silently
      discarded packet, and SHOULD record the event in a statistics
      counter.

2. Physical Layer Requirements

   PPP is capable of operating across most DTE/DCE interfaces (such as,
   EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35).  The only
   absolute requirement imposed by PPP is the provision of a full-duplex
   circuit, either dedicated or circuit-switched, which can operate in
   either an asynchronous (start/stop), bit-synchronous, or octet-
   synchronous mode, transparent to PPP Data Link Layer frames.

    Interface Format

      PPP presents an octet interface to the physical layer.  There is



Simpson                                                         [Page 3]

RFC 1549                      HDLC Framing                Decvember 1993


      no provision for sub-octets to be supplied or accepted.


    PPP does not impose any restrictions regarding transmission rate,
      other than that of the particular DTE/DCE interface.

    Control Signals

      PPP does not require the use of control signals, such as Request
      To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and
      Data Terminal Ready (DTR).

      When available, using such signals can allow greater functionality
      and performance.  In particular, such signals SHOULD be used to
      signal the Up and Down events in the LCP Option Negotiation
      Automaton [1].  When such signals are not available, the
      implementation MUST signal the Up event to LCP upon
      initialization, and SHOULD NOT signal the Down event.

      Because signalling is not required, the physical layer MAY be
      decoupled from the data link layer, hiding the transient details
      of the physical transport.  This has implications for mobility in
      cellular radio networks, and other rapidly switching links.

      When moving from cell to cell within the same zone, an
      implementation MAY choose to treat the entire zone as a single
      link, even though transmission is switched among several
      frequencies.  The link is considered to be with the central
      control unit for the zone, rather than the individual cell
      transceivers.  However, the link SHOULD re-establish its
      configuration whenever the link is switched to a different
      administration.

      Due to the bursty nature of data traffic, some implementations
      have choosen to disconnect the physical layer during periods of
      inactivity, and reconnect when traffic resumes, without informing
      the data link layer.  Robust implementations should avoid using
      this trick over-zealously, since the price for decreased setup
      latency is decreased security.  Implementations SHOULD signal the
      Down event whenever "significant time" has elapsed since the link
      was disconnected.  The value for "significant time" is a matter of
      considerable debate, and is based on the tariffs, call setup
      times, and security concerns of the installation.

3. The Data Link Layer

   PPP uses the principles, terminology, and frame structure of the
   International Organization For Standardization's (ISO) 3309-1979



Simpson                                                         [Page 4]

RFC 1549                      HDLC Framing                Decvember 1993


   High-level Data Link Control (HDLC) frame structure [2], as modified
   by "Addendum 1: Start/stop transmission" [3], which specifies
   modifications to allow HDLC use in asynchronous environments.

   The PPP control procedures use the definitions and Control field
   encodings standardized in ISO 4335-1979 [4] and ISO 4335-
   1979/Addendum 1-1979 [5].  PPP framing is also consistent with CCITT
   Recommendation X.25 LAPB [6], and CCITT Recommendation Q.922 [7],
   since those are also based on HDLC.

   The purpose of this specification is not to document what is already
   standardized in ISO 3309.  It is assumed that the reader is already
   familiar with HDLC, or has access to a copy of [2] or [6].  Instead,
   this document attempts to give a concise summary and point out
   specific options and features used by PPP.

   To remain consistent with standard Internet practice, and avoid
   confusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least
   Significant Bit order, reading from left to right, unless otherwise
   indicated.  Note that this is contrary to standard ISO and CCITT
   practice which orders bits as transmitted (network bit order).  Keep
   this in mind when comparing this document with the international
   standards documents.

3.1 Frame Format

   A summary of the PPP HDLC frame structure is shown below.  This
   figure does not include start/stop bits (for asynchronous links), nor
   any bits or octets inserted for transparency.  The fields are
   transmitted from left to right.

              +----------+----------+----------+
              |   Flag   | Address  | Control  |
              | 01111110 | 11111111 | 00000011 |
              +----------+----------+----------+
              +----------+-------------+---------+
              | Protocol | Information | Padding |
              | 16 bits  |      *      |    *    |
              +----------+-------------+---------+
              +----------+----------+------------------+
              |   FCS    |   Flag   | Inter-frame Fill |
              | 16 bits  | 01111110 | or next Address  |
              +----------+----------+------------------+

   The Protocol, Information and Padding fields are described in the
   Point-to-Point Protocol Encapsulation [1].




Simpson                                                         [Page 5]

RFC 1549                      HDLC Framing                Decvember 1993


    Flag Sequence

      The Flag Sequence indicates the beginning or end of a frame, and
      always consists of the binary sequence 01111110 (hexadecimal
      0x7e).

      The Flag Sequence is a frame separator.  Only one Flag Sequence is
      required between two frames.  Two consecutive Flag Sequences
      constitute an empty frame, which is ignored, and not counted as a
      FCS error.

    Address Field

      The Address field is a single octet and contains the binary
      sequence 11111111 (hexadecimal 0xff), the All-Stations address.
      PPP does not assign individual station addresses.  The All-
      Stations address MUST always be recognized and received.  The use
      of other address lengths and values may be defined at a later
      time, or by prior agreement.  Frames with unrecognized Addresses
      SHOULD be silently discarded.

    Control Field

      The Control field is a single octet and contains the binary
      sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
      (UI) command with the P/F bit set to zero.  The use of other
      Control field values may be defined at a later time, or by prior
      agreement.  Frames with unrecognized Control field values SHOULD
      be silently discarded.

    Frame Check Sequence (FCS) Field

      The Frame Check Sequence field is normally 16 bits (two octets).
      The use of other FCS lengths may be defined at a later time, or by
      prior agreement.  The FCS is transmitted with the coefficient of
      the highest term first.

      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.

         Note: 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 ISO