rfc1490.txt

RFC 的详细文档！

Network Working Group                                        T. Bradley
Request for Comments: 1490               Wellfleet Communications, Inc.
Obsoletes: 1294                                                C. Brown
                                         Wellfleet Communications, Inc.
                                                               A. Malis
                                                   Ascom Timeplex, Inc.
                                                              July 1993


              Multiprotocol Interconnect over Frame Relay

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo describes an encapsulation method for carrying network
   interconnect traffic over a Frame Relay backbone.  It covers aspects
   of both Bridging and Routing.  Additionally, it describes a simple
   fragmentation procedure for carrying large frames over a frame relay
   network with a smaller MTU.

   Systems with the ability to transfer both the encapsulation method
   described in this document, and others must have a priori knowledge
   of which virtual circuits will carry which encapsulation method and
   this encapsulation must only be used over virtual circuits that have
   been explicitly configured for its use.

Acknowledgements

   Comments and contributions from many sources, especially those from
   Ray Samora of Proteon, Ken Rehbehn of Netrix Corporation, Fred Baker
   and Charles Carvalho of Advanced Computer Communications and Mostafa
   Sherif of AT&T have been incorporated into this document. Special
   thanks to Dory Leifer of University of Michigan for his contributions
   to the resolution of fragmentation issues and Floyd Backes from DEC
   and Laura Bridge from Timeplex for their contributions to the
   bridging descriptions. This document could not have been completed
   without the expertise of the IP over Large Public Data Networks
   working group of the IETF.






Bradley, Brown & Malis                                          [Page 1]

RFC 1490             Multiprotocol over Frame Relay            July 1993


1.  Conventions and Acronyms

   The following language conventions are used in the items of
   specification in this document:

      o Must, Shall or Mandatory -- the item is an absolute
        requirement of the specification.

      o Should or Recommended -- the item should generally be
        followed for all but exceptional circumstances.

      o May or Optional -- the item is truly optional and may be
        followed or ignored according to the needs of the
        implementor.

   All drawings in this document are drawn with the left-most bit as the
   high order bit for transmission.  For example, the dawings might be
   labeled as:

              0   1   2   3   4   5   6   7 bits
              +---+---+---+---+---+---+---+

              +---------------------------+
              |    flag (7E hexadecimal)  |
              +---------------------------+
              |       Q.922 Address*      |
              +--                       --+
              |                           |
              +---------------------------+
              :                           :
              :                           :
              +---------------------------+

   Drawings that would be too large to fit onto one page if each octet
   were presented on a single line are drawn with two octets per line.
   These are also drawn with the left-most bit as the high order bit for
   transmission.  There will be a "+" to distinguish between octets as
   in the following example.













Bradley, Brown & Malis                                          [Page 2]

RFC 1490             Multiprotocol over Frame Relay            July 1993


        |---   octet one     ---|---   octet two  ---|
        0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

        +--------------------------------------------+
        | Organizationally Unique                    |
        +--                     +--------------------+
        | Identifier            | Protocol           |
        +-----------------------+--------------------+
        | Identifier            |
        +-----------------------+

   The following are common acronyms used throughout this document.

      BECN - Backward Explicit Congestion Notification
      BPDU - Bridge Protocol Data Unit
      C/R  - Command/Response bit
      DCE  - Data Communication Equipment
      DE   - Discard Eligibility bit
      DTE  - Data Terminal Equipment
      FECN - Forward Explicit Congestion Notification
      PDU  - Protocol Data Unit
      PTT  - Postal Telephone & Telegraph
      SNAP - Subnetwork Access Protocol

2.  Introduction

   The following discussion applies to those devices which serve as end
   stations (DTEs) on a public or private Frame Relay network (for
   example, provided by a common carrier or PTT.  It will not discuss
   the behavior of those stations that are considered a part of the
   Frame Relay network (DCEs) other than to explain situations in which
   the DTE must react.

   The Frame Relay network provides a number of virtual circuits that
   form the basis for connections between stations attached to the same
   Frame Relay network.  The resulting set of interconnected devices
   forms a private Frame Relay group which may be either fully
   interconnected with a complete "mesh" of virtual circuits, or only
   partially interconnected.  In either case, each virtual circuit is
   uniquely identified at each Frame Relay interface by a Data Link
   Connection Identifier (DLCI).  In most circumstances, DLCIs have
   strictly local significance at each Frame Relay interface.

   The specifications in this document are intended to apply to both
   switched and permanent virtual circuits.





Bradley, Brown & Malis                                          [Page 3]

RFC 1490             Multiprotocol over Frame Relay            July 1993


3.  Frame Format

   All protocols must encapsulate their packets within a Q.922 Annex A
   frame [1,2].  Additionally, frames shall contain information
   necessary to identify the protocol carried within the protocol data
   unit (PDU), thus allowing the receiver to properly process the
   incoming packet.  The format shall be as follows:

                  +---------------------------+
                  |    flag (7E hexadecimal)  |
                  +---------------------------+
                  |       Q.922 Address*      |
                  +--                       --+
                  |                           |
                  +---------------------------+
                  | Control (UI = 0x03)       |
                  +---------------------------+
                  | Optional Pad      (0x00)  |
                  +---------------------------+
                  | NLPID                     |
                  +---------------------------+
                  |             .             |
                  |             .             |
                  |             .             |
                  |           Data            |
                  |             .             |
                  |             .             |
                  +---------------------------+
                  |   Frame Check Sequence    |
                  +--           .           --+
                  |       (two octets)        |
                  +---------------------------+
                  |   flag (7E hexadecimal)   |
                  +---------------------------+

           * Q.922 addresses, as presently defined, are two octets and
             contain a 10-bit DLCI.  In some networks Q.922 addresses
             may optionally be increased to three or four octets.

   The control field is the Q.922 control field.  The UI (0x03) value is
   used unless it is negotiated otherwise.  The use of XID (0xAF or
   0xBF) is permitted and is discussed later.

   The pad field is used to align the remainder of the frame to a two
   octet boundary. There may be zero or one pad octet within the pad
   field and, if present, must have a value of zero.

   The Network Level Protocol ID (NLPID) field is administered by ISO



Bradley, Brown & Malis                                          [Page 4]

RFC 1490             Multiprotocol over Frame Relay            July 1993


   and CCITT.  It contains values for many different protocols including
   IP, CLNP and IEEE Subnetwork Access Protocol (SNAP)[10]. This field
   tells the receiver what encapsulation or what protocol follows.
   Values for this field are defined in ISO/IEC TR 9577 [3]. A NLPID
   value of 0x00 is defined within ISO/IEC TR 9577 as the Null Network
   Layer or Inactive Set.  Since it cannot be distinguished from a pad
   field, and because it has no significance within the context of this
   encapsulation scheme, a NLPID value of 0x00 is invalid under the
   Frame Relay encapsulation. The Appendix contains a list of some of
   the more commonly used NLPID values.

   There is no commonly implemented minimum maximum frame size for Frame
   Relay.  A network must, however, support at least a 262 octet
   maximum.  Generally, the maximum will be greater than or equal to
   1600 octets, but each Frame Relay provider will specify an
   appropriate value for its network.  A Frame Relay DTE, therefore,
   must allow the maximum acceptable frame size to be configurable.

   The minimum frame size allowed for Frame Relay is five octets between
   the opening and closing flags assuming a two octet Q.922 address
   field.  This minimum increases to six octets for three octet Q.922
   address and seven octets for the four octet Q.922 address format.

4.  Interconnect Issues

   There are two basic types of data packets that travel within the
   Frame Relay network: routed packets and bridged packets.  These
   packets have distinct formats and therefore, must contain an
   indicator that the destination may use to correctly interpret the
   contents of the frame.  This indicator is embedded within the NLPID
   and SNAP header information.

   For those protocols that do not have a NLPID already assigned, it is
   necessary to provide a mechanism to allow easy protocol
   identification.  There is a NLPID value defined indicating the
   presence of a SNAP header.

   A SNAP header is of the form:

            +--------------------------------------------+
            | Organizationally Unique                    |
            +--                     +--------------------+
            | Identifier            | Protocol           |
            +-----------------------+--------------------+
            | Identifier            |
            +-----------------------+

   All stations must be able to accept and properly interpret both the



Bradley, Brown & Malis                                          [Page 5]

RFC 1490             Multiprotocol over Frame Relay            July 1993


   NLPID encapsulation and the SNAP header encapsulation for a routed
   packet.

   The three-octet Organizationally Unique Identifier (OUI) identifies
   an organization which administers the meaning of the Protocol
   Identifier (PID) which follows.  Together they identify a distinct
   protocol.  Note that OUI 0x00-00-00 specifies that the following PID
   is an Ethertype.

4.1.  Routed Frames

   Some protocols will have an assigned NLPID, but because the NLPID
   numbering space is so limited, not all protocols have specific NLPID
   values assigned to them. When packets of such protocols are routed
   over Frame Relay networks, they are sent using the NLPID 0x80 (which
   indicates a SNAP follows) followed by SNAP.  If the protocol has an
   Ethertype assigned, the OUI is 0x00-00-00 (which indicates an
   Ethertype follows), and PID is the Ethertype of the protocol in use.
   There will be one pad octet to align the protocol data on a two octet
   boundary as shown below.

                      Format of Routed Frames
                          with Ethertypes

                  +-------------------------------+
                  |        Q.922 Address          |
                  +---------------+---------------+
                  |Control  0x03  | pad     0x00  |
                  +---------------+---------------+
                  | NLPID   0x80  | OUI     0x00  |
                  +---------------+             --+
                  | OUI  0x00-00                  |
                  +-------------------------------+
                  |           Ethertype           |
                  +-------------------------------+
                  |         Protocol Data         |
                  +-------------------------------+
                  | FCS                           |
                  +-------------------------------+