rfc2427.txt

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

   to allow pipelining at the egress bridge to an 802.6 subnetwork.
   Specifically, the CPDU Header contains the BAsize field, which
   contains the length of the PDU.  If this field is not available to
   the egress 802.6 bridge, then that bridge cannot begin to transmit
   the segmented PDU until it has received the entire PDU, calculated
   the length, and inserted the length into the BAsize field.  If the
   field is available, the egress 802.6 bridge can extract the length
   from the BAsize field of the Common PDU Header, insert it into the
   corresponding field of the first segment, and immediately transmit
   the segment onto the 802.6 subnetwork.  Thus, the bridge can begin
   transmitting the 802.6 PDU before it has received the complete PDU.






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


   One should note that the Common PDU Header and Trailer of the
   encapsulated frame should not be simply copied to the outgoing 802.6
   subnetwork because the encapsulated BEtag value may conflict with the
   previous BEtag value transmitted by that bridge.

                         Format of BPDU Frame
                  +-------------------------------+
                  |         Q.922 Address         |
                  +-------------------------------+
                  |        Control   0x03         |
                  +-------------------------------+
                  |          PAD     0x00         |
                  +-------------------------------+
                  |         NLPID    0x80         |
                  +-------------------------------+
                  |        OUI 0x00-80-C2         |
                  +-------------------------------+
                  |          PID 0x00-0E          |
                  +-------------------------------+
                  |                               |
                  |       BPDU as defined by      |
                  |     802.1(d) or 802.1(g)[12]  |
                  |                               |
                  +-------------------------------+
                  |              FCS              |
                  +-------------------------------+

                 Format of Source Routing BPDU Frame
                  +-------------------------------+
                  |         Q.922 Address         |
                  +-------------------------------+
                  |        Control   0x03         |
                  +-------------------------------+
                  |          PAD     0x00         |
                  +-------------------------------+
                  |         NLPID    0x80         |
                  +-------------------------------+
                  |        OUI 0x00-80-C2         |
                  +-------------------------------+
                  |          PID 0x00-0F          |
                  +-------------------------------+
                  |                               |
                  |      Source Routing BPDU      |
                  |                               |
                  |                               |
                  +-------------------------------+
                  |              FCS              |
                  +-------------------------------+



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


5.  Data Link Layer Parameter Negotiation

   Frame Relay stations may choose to support the Exchange
   Identification (XID) specified in Appendix III of Q.922 [1].  This
   XID exchange allows the following parameters to be negotiated at the
   initialization of a Frame Relay circuit: maximum frame size N201,
   retransmission timer T200, and the maximum number of outstanding
   Information (I) frames K.

   A station may indicate its unwillingness to support acknowledged mode
   multiple frame operation by specifying a value of zero for the
   maximum window size, K.

   If this exchange is not used, these values must be statically
   configured by mutual agreement of Data Link Connection (DLC)
   endpoints, or must be defaulted to the values specified in Section
   5.9 of Q.922:

                     N201: 260 octets

                        K:  3 for a 16 Kbps link,
                            7 for a 64 Kbps link,
                           32 for a 384 Kbps link,
                           40 for a 1.536 Mbps or above link

                    T200: 1.5 seconds [see Q.922 for further details]

   If a station supporting XID receives an XID frame, it shall respond
   with an XID response.  In processing an XID, if the remote maximum
   frame size is smaller than the local maximum, the local system shall
   reduce the maximum size it uses over this DLC to the remotely
   specified value.  Note that this shall be done before generating a
   response XID.

   The following diagram describes the use of XID to specify non-use of
   acknowledged mode multiple frame operation.















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


               Non-use of Acknowledged Mode Multiple Frame Operation
                      +---------------+
                      |    Address    |     (2,3 or 4 octets)
                      |               |
                      +---------------+
                      | Control 0xAF  |
                      +---------------+
                      | format  0x82  |
                      +---------------+
                      | Group ID 0x80 |
                      +---------------+
                      | Group Length  |     (2 octets)
                      |    0x00-0E    |
                      +---------------+
                      |      0x05     |     PI = Frame Size (transmit)
                      +---------------+
                      |      0x02     |     PL = 2
                      +---------------+
                      |    Maximum    |     (2 octets)
                      |   Frame Size  |
                      +---------------+
                      |      0x06     |     PI = Frame Size (receive)
                      +---------------+
                      |      0x02     |     PL = 2
                      +---------------+
                      |    Maximum    |     (2 octets)
                      |   Frame Size  |
                      +---------------+
                      |      0x07     |     PI = Window Size
                      +---------------+
                      |      0x01     |     PL = 1
                      +---------------+
                      |      0x00     |
                      +---------------+
                      |      0x09     |     PI = Retransmission Timer
                      +---------------+
                      |      0x01     |     PL = 1
                      +---------------+
                      |      0x00     |
                      +---------------+
                      |      FCS      |     (2 octets)
                      |               |
                      +---------------+

6.  Address Resolution for PVCs

   This document only describes address resolution as it applies to
   PVCs.  SVC operation will be discussed in future documents.



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


   There are situations in which a Frame Relay station may wish to
   dynamically resolve a protocol address over PVCs.  This may be
   accomplished using the standard Address Resolution Protocol (ARP) [6]
   encapsulated within a SNAP encoded Frame Relay packet as follows:

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


     Where the ARP packet has the following format and values:


         Data:
           ar$hrd   16 bits     Hardware type
           ar$pro   16 bits     Protocol type
           ar$hln    8 bits     Octet length of hardware address (n)
           ar$pln    8 bits     Octet length of protocol address (m)
           ar$op    16 bits     Operation code (request or reply)
           ar$sha   noctets     source hardware address
           ar$spa   moctets     source protocol address
           ar$tha   noctets     target hardware address
           ar$tpa   moctets     target protocol address

           ar$hrd - assigned to Frame Relay is 15 decimal
                     (0x000F) [7].

           ar$pro - see assigned numbers for protocol ID number for
                    the protocol using ARP. (IP is 0x0800).

           ar$hln - length in bytes of the address field (2, 3, or 4)

           ar$pln - protocol address length is dependent on the
                    protocol (ar$pro) (for IP ar$pln is 4).




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


           ar$op -  1 for request and 2 for reply.

           ar$sha - Q.922 source hardware address, with C/R, FECN,
                    BECN, and DE set to zero.

           ar$tha - Q.922 target hardware address, with C/R, FECN,
                    BECN, and DE set to zero.

   Because DLCIs within most Frame Relay networks have only local
   significance, an end station will not have a specific DLCI assigned
   to itself.  Therefore, such a station does not have an address to put
   into the ARP request or reply.  Fortunately, the Frame Relay network
   does provide a method for obtaining the correct DLCIs. The solution
   proposed for the locally addressed Frame Relay network below will
   work equally well for a network where DLCIs have global significance.

   The DLCI carried within the Frame Relay header is modified as it
   traverses the network.  When the packet arrives at its destination,
   the DLCI has been set to the value that, from the standpoint of the
   receiving station, corresponds to the sending station.  For example,
   in figure 1 below, if station A were to send a message to station B,
   it would place DLCI 50 in the Frame Relay header.  When station B
   received this message, however, the DLCI would have been modified by
   the network and would appear to B as DLCI 70.

                              ~~~~~~~~~~~~~~~
                             (                )
           +-----+          (                  )             +-----+
           |     |-50------(--------------------)---------70-|     |
           |  A  |        (                      )           |  B  |
           |     |-60-----(---------+            )           |     |
           +-----+         (        |           )            +-----+
                            (       |          )
                             (      |         )  <---Frame Relay
                              ~~~~~~~~~~~~~~~~         network
                                    80
                                    |
                                 +-----+
                                 |     |
                                 |  C  |
                                 |     |
                                 +-----+

                                 Figure 1

      Lines between stations represent data link connections (DLCs).
      The numbers indicate the local DLCI associated with each
      connection.



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


              DLCI to Q.922 Address Table for Figure 1

              DLCI (decimal)  Q.922 address (hex)
                   50              0x0C21
                   60              0x0CC1
                   70              0x1061
                   80              0x1401

      For authoritative description of the correlation between DLCI and
      Q.922 [1] addresses, the reader should consult that specification.
      A summary of the correlation is included here for convenience. The
      translation between DLCI and Q.922 address is based on a two byte
      address length using the Q.922 encoding format.  The format is:

                8   7   6   5   4   3    2   1
              +------------------------+---+--+
              |  DLCI (high order)     |C/R|EA|
              +--------------+----+----+---+--+
              | DLCI (lower) |FECN|BECN|DE |EA|
              +--------------+----+----+---+--+

      For ARP and its variants, the FECN, BECN, C/R and DE bits are
      assumed to be 0.

   When an ARP message reaches a destination, all hardware addresses
   will be invalid.  The address found in the frame header will,