rfc1294.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                         T. Bradley
Request for Comments: 1294                                      C. Brown
                                          Wellfleet Communications, Inc.
                                                                A. Malis
                                                      BBN Communications
                                                            January 1992

              Multiprotocol Interconnect over Frame Relay

1.  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.

2.  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.  Systems with the ability to transfer
   both this encapsulation method, 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.

3.  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. This document could not
   have been completed without the expertise of the IP over Large Public
   Data Networks working group of the IETF.

4.  Conventions

   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.



Bradley, Brown, Malis                                           [Page 1]

RFC 1294             Multiprotocol over Frame Relay         January 1992


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

5.  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.

6.  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:


















Bradley, Brown, Malis                                           [Page 2]

RFC 1294             Multiprotocol over Frame Relay         January 1992


         +-----------------------------+
         |    flag (7E hexadecimal)    |
         +-----------------------------+
         |       Q.922 Address*        |
         +--                         --+
         |                             |
         +-----------------------------+
         | Control (UI = 0x03)         |
         +-----------------------------+
         | Optional Pad(s)   (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 an optional field used to align the remainder of the
   frame to a convenient boundary for the sender.  There may be zero or
   more pad octets within the pad field and all must have a value of
   zero.

   The Network Level Protocol ID (NLPID) field is administered by ISO
   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



Bradley, Brown, Malis                                           [Page 3]

RFC 1294             Multiprotocol over Frame Relay         January 1992


   encapsulation scheme, a NLPID value of 0x00 is invalid under the
   Frame Relay encapsulation. The known NLPID values are listed in the
   Appendix.

   For full interoperability with older Frame Relay encapsulation
   formats, a station may implement section 15, Backward Compatibility.

   There is no commonly implemented 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.

7.  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
   indication that the destination may use to correctly interpret the
   contents of the frame.  This indication 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
   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



Bradley, Brown, Malis                                           [Page 4]

RFC 1294             Multiprotocol over Frame Relay         January 1992


   protocol.  Note that OUI 0x00-00-00 specifies that the following PID
   is an EtherType.

7.1.  Routed Frames

   Some protocols will have an assigned NLPID, but because the NLPID
   numbering space is so limited many protocols do not have a specific
   NLPID 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), OUI 0x00-00-00 (which indicates an
   EtherType follows), and the EtherType of the protocol in use.

             Format of Routed Frames
         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  | pad(s)  0x00  |
         +-------------------------------+
         | NLPID   0x80  | OUI     0x00  |
         +---------------+             --+
         | OUI  0x00-00                  |
         +-------------------------------+
         |           EtherType           |
         +-------------------------------+
         |         Protocol Data         |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+

   In the few cases when a protocol has an assigned NLPID (see
   appendix), 48 bits can be saved using the format below:

          Format of Routed NLPID Protocol
         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  |     NLPID     |
         +-------------------------------+
         |         Protocol Data         |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+









Bradley, Brown, Malis                                           [Page 5]

RFC 1294             Multiprotocol over Frame Relay         January 1992


   In the particular case of an Internet IP datagram, the NLPID is 0xCC.

           Format of Routed IP Datagram
         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  |  NLPID  0xCC  |
         +-------------------------------+
         |          IP Datagram          |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+

7.2.  Bridged Frames

   The second type of Frame Relay traffic is bridged packets. These
   packets are encapsulated using the NLPID value of 0x80 indicating
   SNAP and the following SNAP header identifies the format of the
   bridged packet.  The OUI value used for this encapsulation is the
   802.1 organization code 0x00-80-C2.  The following two octets (PID)
   specify the form of the MAC header, which immediately follows the
   SNAP header.  Additionally, the PID indicates whether the original
   FCS is preserved within the bridged frame.

   The 802.1 organization has reserved the following values to be used
   with Frame Relay:

            PID Values for OUI 0x00-80-C2

         with preserved FCS   w/o preserved FCS    Media
         ------------------   -----------------    ----------------
         0x00-01              0x00-07              802.3/Ethernet
         0x00-02              0x00-08              802.4
         0x00-03              0x00-09              802.5
         0x00-04              0x00-0A              FDDI
         0x00-05              0x00-0B              802.6

      In addition, the PID value 0x00-0E, when used with OUI 0x00-80-C2,
      identifies Bridged Protocol Data Units (BPDUs).

   A packet bridged over Frame Relay will, therefore, have one of the
   following formats:









Bradley, Brown, Malis                                           [Page 6]

RFC 1294             Multiprotocol over Frame Relay         January 1992


          Format of Bridged Ethernet/802.3 Frame
         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  | pad(s)  0x00  |
         +-------------------------------+
         | NLPID   0x80  | OUI     0x00  |
         +---------------+             --+
         | OUI  0x80-C2                  |
         +-------------------------------+
         | PID 0x00-01 or 0x00-07        |
         +-------------------------------+
         | MAC destination address       |
         +-------------------------------+
         | (remainder of MAC frame)       |
         +-------------------------------+
         | LAN FCS (if PID is 0x00-01)   |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+

          Format of Bridged 802.4 Frame
         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  | pad(s)  0x00  |
         +-------------------------------+
         | NLPID   0x80  | OUI     0x00  |
         +---------------+             --+
         | OUI  0x80-C2                  |
         +-------------------------------+
         | PID 0x00-02 or 0x00-08        |
         +-------------------------------+
         |  pad  0x00    | Frame Control |
         +-------------------------------+
         | MAC destination address       |
         +-------------------------------+
         | (remainder of MAC frame)      |
         +-------------------------------+
         | LAN FCS (if PID is 0x00-02)   |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+