rfc2427.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          C. Brown
Request for Comments: 2427                                   Consultant
STD: 55                                                        A. Malis
Obsoletes: 1490, 1294                       Ascend Communications, Inc.
Category: Standards Track                                September 1998


              Multiprotocol Interconnect over Frame Relay

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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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

Acknowledgments

   This document could not have been completed without the support of
   Terry Bradley of Avici Systems, Inc..  Comments and contributions
   from many sources, especially those from Ray Samora of Proteon, Ken
   Rehbehn of Visual Networks, Fred Baker and Charles Carvalho of Cisco
   Systems, 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 (though
   it was deleted in the final version) and Floyd Backes and Laura
   Bridge of 3Com 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 and the IP over NBMA working
   groups of the IETF.




Brown & Malis               Standards Track                     [Page 1]

RFC 2427             Multiprotocol over Frame Relay       September 1998


1.  Conventions and Acronyms

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [16].

   All drawings in this document are drawn with the left-most bit as the
   high order bit for transmission.  For example, the drawings 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.

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



Brown & Malis               Standards Track                     [Page 2]

RFC 2427             Multiprotocol over Frame Relay       September 1998


      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.

3.  Frame Format

   All protocols must encapsulate their packets within a Q.922 Annex A
   frame [1].  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:















Brown & Malis               Standards Track                     [Page 3]

RFC 2427             Multiprotocol over Frame Relay       September 1998


                  +---------------------------+
                  |    flag (7E hexadecimal)  |
                  +---------------------------+
                  |       Q.922 Address*      |
                  +--                       --+
                  |                           |
                  +---------------------------+
                  |    Control (UI = 0x03)    |
                  +---------------------------+
                  | Pad (when required) (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 data portion (beyond the
   encapsulation header) of the frame to a two octet boundary.  If
   present, the pad is a single octet and must have a value of zero.
   Explicit directions of when to use the pad field are discussed later
   in this document.

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



Brown & Malis               Standards Track                     [Page 4]

RFC 2427             Multiprotocol over Frame Relay       September 1998


   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. Appendix A 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            |
            +-----------------------+

   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.





Brown & Malis               Standards Track                     [Page 5]

RFC 2427             Multiprotocol over Frame Relay       September 1998


4.1.  Routed Frames

   Some protocols will have an assigned NLPID, but because the NLPID
   numbering space is 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 the presence of a SNAP header) 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.

   When a SNAP header is present as described above, a one octet pad is
   used to align the protocol data on a two octet boundary as shown
   below.

                       Format of Routed Frames
                         with a SNAP Header
                  +-------------------------------+
                  |         Q.922 Address         |
                  +---------------+---------------+
                  | Control  0x03 | pad     0x00  |
                  +---------------+---------------+
                  | NLPID    0x80 | Organization- |
                  +---------------+               |
                  | ally Unique Identifier (OUI)  |
                  +-------------------------------+
                  |   Protocol Identifier (PID)   |
                  +-------------------------------+
                  |                               |
                  |         Protocol Data         |
                  |                               |
                  +-------------------------------+
                  |              FCS              |
                  +-------------------------------+

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

                   Format of Routed NLPID Protocol
                  +-------------------------------+
                  |         Q.922 Address         |
                  +---------------+---------------+