rfc1490.txt

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

   Internet Protocol [9] (IP) datagrams sent over a Frame Relay network
   conform to the encapsulation described previously.  Within this
   context, IP could be encapsulated in two different ways.










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


           1.  NLPID value indicating IP

           +-----------------------+-----------------------+
           | Q.922 Address                                 |
           +-----------------------+-----------------------+
           | Control (UI)  0x03    | NLPID = 0xCC          |
           +-----------------------+-----------------------+
           | IP Packet             .                       |
           |                       .                       |
           |                       .                       |
           +-----------------------+-----------------------+


           2.  NLPID value indicating SNAP

           +-----------------------+-----------------------+
           | Q.922 Address                                 |
           +-----------------------+-----------------------+
           | Control (UI)  0x03    |     pad     0x00      |
           +-----------------------+-----------------------+
           |  NLPID = 0x80         |                       |  SNAP Header
           +-----------------------+  OUI = 0x00-00-00     +  Indicating
           |                                               |  IP
           +-----------------------+-----------------------+
           |  PID = 0x0800                                 |
           +-----------------------+-----------------------+
           |                   IP packet                   |
           |                       .                       |
           |                       .                       |
           |                       .                       |
           +-----------------------+-----------------------+

   Although both of these encapsulations are supported under the given
   definitions, it is advantageous to select only one method as the
   appropriate mechanism for encapsulating IP data.  Therefore, IP data
   shall be encapsulated using the NLPID value of 0xCC indicating IP as
   shown in option 1 above.  This (option 1) is more efficient in
   transmission (48 fewer bits), and is consistent with the
   encapsulation of IP in X.25.

9.  Other Protocols over Frame Relay

   As with IP encapsulation, there are alternate ways to transmit
   various protocols within the scope of this definition.  To eliminate
   the conflicts, the SNAP encapsulation is only used if no NLPID value
   is defined for the given protocol.

   As an example of how this works, ISO CLNP has a NLPID defined (0x81).



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


   Therefore, the NLPID field will indicate ISO CLNP and the data packet
   will follow immediately.  The frame would be as follows:

                  +---------------------------------------------+
                  |               Q.922 Address                 |
                  +----------------------+----------------------+
                  | Control     (0x03)   | NLPID  - 0x81 (CLNP) |
                  +----------------------+----------------------+
                  | remainder of CLNP packet                    |
                  |                   .                         |
                  |                   .                         |
                  +---------------------------------------------+

   In this example, the NLPID is used to identify the data packet as
   CLNP.  It is also considered part of the CLNP packet and as such, the
   NLPID should not be removed before being sent to the upper layers for
   processing.  The NLPID is not duplicated.

   Other protocols, such as IPX, do not have a NLPID value defined.  As
   mentioned above, IPX would be encapsulated using the SNAP header.  In
   this case, the frame would be as follows:

                  +---------------------------------------------+
                  |               Q.922 Address                 |
                  +----------------------+----------------------+
                  | Control       0x03   | pad  0x00            |
                  +----------------------+----------------------+
                  | NLPID  - 0x80 (SNAP) | OUI - 0x00 00 00     |
                  +----------------------+                      |
                  |                                             |
                  +---------------------------------------------+
                  | PID = 0x8137                                |
                  +---------------------------------------------+
                  |   IPX packet                                |
                  |                   .                         |
                  |                   .                         |
                  +---------------------------------------------+

10.  Bridging Model for Frame Relay

   The model for bridging in a Frame Relay network is identical to the
   model for remote bridging as described in IEEE P802.1g "Remote MAC
   Bridging" [13] and supports the concept of "Virtual Ports". Remote
   bridges with LAN ports receive and transmit MAC frames to and from
   the LANS to which they are attached. They may also receive and
   transmit MAC frames through virtual ports to and from other remote
   bridges.  A virtual port may represent an abstraction of a remote
   bridge's point of access to one, two or more other remote bridges.



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


   Remote Bridges are statically configured as members of a remote
   bridge group by management. All members of a remote bridge group are
   connected by one or more virtual ports. The set of remote MAC bridges
   in a remote bridge group provides actual or *potential* MAC layer
   interconnection between a set of LANs and other remote bridge groups
   to which the remote bridges attach.

   In a Frame Relay network there must be a full mesh of Frame Relay VCs
   between bridges of a remote bridge group.  If the frame relay network
   is not a full mesh, then the bridge network must be divided into
   multiple remote bridge groups.

   The frame relay VCs that interconnect the bridges of a remote bridge
   group may be combined or used individually to form one or more
   virtual bridge ports.  This gives flexibility to treat the Frame
   Relay interface either as a single virtual bridge port, with all VCs
   in a group, or as a collection of bridge ports (individual or grouped
   VCs).

   When a single virtual bridge port provides the interconnectivity for
   all bridges of a given remote bridge group (i.e. all VCs are combined
   into a single virtual port), the standard Spanning Tree Algorithm may
   be used to determine the state of the virtual port.  When more than
   one virtual port is configured within a given remote bridge group
   then an "extended" Spanning Tree Algorithm is required.  Such an
   extended algorithm is defined in IEEE 802.1g [13].  The operation of
   this algorithm is such that a virtual port is only put into backup if
   there is a loop in the network external to the remote bridge group.

   The simplest bridge configuration for a Frame Relay network is the
   LAN view where all VCs are combined into a single virtual port.
   Frames, such as BPDUs,  which would be broadcast on a LAN, must be
   flooded to each VC (or multicast if the service is developed for
   Frame Relay services). Flooding is performed by sending the packet to
   each relevant DLC associated with the Frame Relay interface. The VCs
   in this environment are generally invisible to the bridge.  That is,
   the bridge sends a flooded frame to the frame relay interface and
   does not "see" that the frame is being forwarded to each VC
   individually.  If all participating bridges are fully connected (full
   mesh) the standard Spanning Tree Algorithm will suffice in this
   configuration.

   Typically LAN bridges learn which interface a particular end station
   may be reached on by associating a MAC address with a bridge port.
   In a Frame Relay network configured for the LAN-like single bridge
   port (or any set of VCs grouped together to form a single bridge
   port), however, the bridge must not only associated a MAC address
   with a bridge port, but it must also associate it with a connection



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


   identifier.  For Frame Relay networks, this connection identifier is
   a DLCI.  It is unreasonable and perhaps impossible to require bridges
   to statically configure an association of every possible destination
   MAC address with a DLC.  Therefore, Frame Relay LAN-modeled bridges
   must provide a mechanism to allow the Frame Relay bridge port to
   dynamically learn the associations.  To accomplish this dynamic
   learning, a bridged packet shall conform to the encapsulation
   described within section 7.  In this way, the receiving Frame Relay
   interface will know to look into the bridged packet to gather the
   appropriate information.

   A second Frame Relay bridging approach, the point-to-point view,
   treats each Frame Relay VC as a separate bridge port.  Flooding and
   forwarding packets are significantly less complicated using the
   point-to-point approach because each bridge port has only one
   destination.  There is no need to perform artificial flooding or to
   associate DLCIs with destination MAC addresses.  Depending upon the
   interconnection of the VCs, an extended Spanning Tree algorithm may
   be required to permit all virtual ports to remain active as long as
   there are no true loops in the topology external to the remote bridge
   group.

   It is also possible to combine the LAN view and the point-to-point
   view on a single Frame Relay interface.  To do this, certain VCs are
   combined to form a single virtual bridge port while other VCs are
   independent bridge ports.

   The following drawing illustrates the different possible bridging
   configurations.  The dashed lines between boxes represent virtual
   circuits.

                                                 +-------+
                              -------------------|   B   |
                             /            -------|       |
                            /            /       +-------+
                           /             |
                 +-------+/              \       +-------+
                 |   A   |                -------|   C   |
                 |       |-----------------------|       |
                 +-------+\                      +-------+
                           \
                            \                    +-------+
                             \                   |   D   |
                              -------------------|       |
                                                 +-------+

   Since there is less than a full mesh of VCs between the bridges in
   this example, the network must be divided into more than one remote



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


   bridge group.  A reasonable configuration is to have bridges A, B,
   and C in one group, and have bridges A and D in a second.

   Configuration of the first bridge group combines the VCs
   interconnection the three bridges (A, B, and C) into a single virtual
   port.  This is an example of the LAN view configuration.  The second
   group would also be a single virtual port which simply connects
   bridges A and D.  In this configuration the standard Spanning Tree
   Algorithm is sufficient to detect loops.

   An alternative configuration has three individual virtual ports in
   the first group corresponding to the VCs interconnecting bridges A, B
   and C.  Since the application of the standard Spanning Tree Algorithm
   to this configuration would detect a loop in the topology, an
   extended Spanning Tree Algorithm would have to be used in order for
   all virtual ports to be kept active.  Note that the second group
   would still consist of a single virtual port and the standard
   Spanning Tree Algorithm could be used in this group.

   Using the same drawing, one could construct a remote bridge scenario
   with three bridge groups.  This would be an example of the point-to-
   point case.  Here, the VC connecting A and B, the VC connecting A and
   C, and the VC connecting A and D are all bridge groups with a single
   virtual port.



























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


11.  Appendix A

        List of Commonly Used NLPIDs

           0x00    Null Network Layer or Inactive Set
                   (not used with Frame Relay)
           0x80    SNAP
           0x81    ISO CLNP
           0x82    ISO ESIS
           0x83    ISO ISIS
           0xCC    Internet IP

        List of PIDs of OUI 00-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-0B              802.6
                                0x00-0D              Fragments
                                0x00-0E              BPDUs as defined by
                                                       802.1(d) or
                                                       802.1(g)[12].

12.  Appendix B - Connection Oriented procedures.

   This appendix contains additional information and instructions for
   using CCITT Q.933 and other CCITT standards for encapsulating data
   over frame relay.  The information contained here is similar (and in
   some cases identical) to that found in Annex F to ANSI T1.617 written
   by Rao Cherukuri of IBM.  The authoritative source for this
   information is in Annex F an