rfc2427.txt

<VC++网络游戏建摸与实现>源代码

   however, be correct. Though it does violate the purity of layering,
   Frame Relay may use the address in the header as the sender hardware
   address.  It should also be noted that the target hardware address,
   in both ARP request and reply, will also be invalid.  This should not
   cause problems since ARP does not rely on these fields and in fact,
   an implementation may zero fill or ignore the target hardware address
   field entirely.

   As an example of how this address replacement scheme may work, refer
   to figure 1.  If station A (protocol address pA) wished to resolve
   the address of station B (protocol address pB), it would format an
   ARP request with the following values:

              ARP request from A
                ar$op     1 (request)
                ar$sha    unknown
                ar$spa    pA
                ar$tha    undefined
                ar$tpa    pB






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


   Because station A will not have a source address associated with it,
   the source hardware address field is not valid.  Therefore, when the
   ARP packet is received, it must extract the correct address from the
   Frame Relay header and place it in the source hardware address field.
   This way, the ARP request from A will become:

              ARP request from A as modified by B
                ar$op     1 (request)
                ar$sha    0x1061 (DLCI 70) from Frame Relay header
                ar$spa    pA
                ar$tha    undefined
                ar$tpa    pB

   Station B's ARP will then be able to store station A's protocol
   address and Q.922 address association correctly.  Next, station B
   will form a reply message.  Many implementations simply place the
   source addresses from the ARP request into the target addresses and
   then fills in the source addresses with its addresses.  In this case,
   the ARP response would be:

              ARP response from B
                ar$op     2 (response)
                ar$sha    unknown
                ar$spa    pB
                ar$tha    0x1061 (DLCI 70)
                ar$tpa    pA

   Again, the source hardware address is unknown and when the response
   is received, station A will extract the address from the Frame Relay
   header and place it in the source hardware address field.  Therefore,
   the response will become:

              ARP response from B as modified by A
                ar$op     2 (response)
                ar$sha    0x0C21 (DLCI 50)
                ar$spa    pB
                ar$tha    0x1061 (DLCI 70)
                ar$tpa    pA

   Station A will now correctly recognize station B having protocol
   address pB associated with Q.922 address 0x0C21 (DLCI 50).

   Reverse ARP (RARP) [8] works in exactly the same way.  Still using
   figure 1, if we assume station C is an address server, the following
   RARP exchanges will occur:






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


          RARP request from A             RARP request as modified by C
             ar$op  3 (RARP request)         ar$op  3  (RARP request)
             ar$sha unknown                  ar$sha 0x1401 (DLCI 80)
             ar$spa undefined                ar$spa undefined
             ar$tha 0x0CC1 (DLCI 60)         ar$tha 0x0CC1 (DLCI 60)
             ar$tpa pC                       ar$tpa pC

   Station C will then look up the protocol address corresponding to
   Q.922 address 0x1401 (DLCI 80) and send the RARP response.

         RARP response from C            RARP response as modified by A
                 ar$op  4  (RARP response)       ar$op  4 (RARP response)
                 ar$sha unknown                  ar$sha 0x0CC1 (DLCI 60)
                 ar$spa pC                       ar$spa pC
                 ar$tha 0x1401 (DLCI 80)         ar$tha 0x1401 (DLCI 80)
                 ar$tpa pA                       ar$tpa pA

   This means that the Frame Relay interface must only intervene in the
   processing of incoming packets.

   In the absence of suitable multicast, ARP may still be implemented.
   To do this, the end station simply sends a copy of the ARP request
   through each relevant DLC, thereby simulating a broadcast.

   The use of multicast addresses in a Frame Relay environment, as
   specified by [19], is presently being considered by Frame Relay
   providers.  In time, multicast addressing may become useful in
   sending ARP requests and other "broadcast" messages.

   Because of the inefficiencies of emulating broadcasting in a Frame
   Relay environment, a new address resolution variation was developed.
   It is called Inverse ARP [11] and describes a method for resolving a
   protocol address when the hardware address is already known.  In
   Frame Relay's case, the known hardware address is the DLCI.  Support
   for Inverse ARP is not required to implement this specification, but
   it has proven useful for Frame Relay interface autoconfiguration.
   See [11] for its description and an example of its use with Frame
   Relay.

   Stations must be able to map more than one IP address in the same IP
   subnet (CIDR address prefix) to a particular DLCI on a Frame Relay
   interface. This need arises from applications such as remote access,
   where servers must act as ARP proxies for many dial-in clients, each
   assigned a unique IP address while sharing bandwidth on the same DLC.
   The dynamic nature of such applications result in frequent address
   association changes with no affect on the DLC's status as reported by
   Frame Relay PVC Status Signaling.




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


   As with any other interface that utilizes ARP, stations may learn the
   associations between IP addresses and DLCIs by processing unsolicited
   ("gratuitous") ARP requests that arrive on the DLC.  If one station
   (perhaps a terminal server or remote access server) wishes to inform
   its peer station on the other end of a Frame Relay DLC of a new
   association between an IP address and that PVC, it should send an
   unsolicited ARP request with the source IP address equal to the
   destination IP address, and both set to the new IP address being used
   on the DLC.  This allows a station to "announce" new client
   connections on a particular DLCI.  The receiving station must store
   the new association, and remove any old existing association, if
   necessary, from any other DLCI on the interface.

7.  IP over Frame Relay

   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.

         1.  NLPID value indicating IP

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




















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


         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.

8.  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).
   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 (UI)  0x03   | NLPID   0x81 (CLNP)  |
                  +----------------------+----------------------+
                  |           remainder of CLNP packet          |
                  |                      .                      |
                  |                      .                      |
                  +---------------------------------------------+




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


   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 (UI)  0x03   |      pad  0x00       |
                  +----------------------+----------------------+
                  | NLPID    0x80 (SNAP) | OUI - 0x00 00 00     |
                  +----------------------+                      |
                  |                                             |
                  +---------------------------------------------+
                  |                PID    0x8137                |
                  +---------------------------------------------+
                  |                 IPX packet                  |
                  |                      .                      |
                  |                      .                      |
                  +---------------------------------------------+

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

   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.




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


   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