rfc1294.txt

RFC 的详细文档！

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


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


























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


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


























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


           Format of Bridged 802.6 Frame
         +-------------------------------+
         |        Q.922 Address          |
         | Control 0x03  | pad(s)  0x00  |
         +-------------------------------+
         | NLPID   0x80  | OUI     0x00  |
         +---------------+             --+
         | OUI  0x80-C2                  |
         +-------------------------------+
         | PID 0x00-05 or 0x00-0B        |
         +-------------------------------+
         |   Reserved    |     BEtag     |  Common
         +---------------+---------------+  PDU
         |            BAsize             |  Header
         +-------------------------------+
         | MAC destination address       |
         +-------------------------------+
         | (remainder of MAC frame)      |
         +-------------------------------+
         |                               |
         +-    Common PDU Trailer       -+
         |                               |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+

      The Common Protocol Data Unit (PDU) Header and Trailer are
      conveyed to allow pipelining at the egress bridge to an 802.6
      subnetwork.  Specifically, the Common PDU 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.

      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.







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


          Format of BPDU Frame
      +-------------------------------+
      |        Q.922 Address          |
      +-------------------------------+
      |Control  0x03  | pad(s)  0x00  |
      +-------------------------------+
      | NLPID   0x80  | OUI     0x00  |
      +---------------+             --+
      | OUI  0x80-C2                  |
      +-------------------------------+
      | PID 0x00-0E                   |
      +-------------------------------+  ----
      | 802.1(d) Protocol Identifier  |  BPDU, as defined
      +-------------------------------+  by 802.1(d),
      | Version = 00  |  BPDU Type    |  section 5.3
      +-------------------------------+
      | (remainder of BPDU)           |
      +-------------------------------+  ----
      | FCS                           |
      +-------------------------------+

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




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


   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.










































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


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








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


9.  Fragmentation Issues

   Fragmentation allows the exchange of packets that are greater than
   the maximum frame size supported by the underlying network.  In the
   case of Frame Relay, the network may support a maximum frame size as
   small as 262 octets.  Because of this small maximum size, it is
   advantageous to support fragmentation and reassembly.

   Unlike IP fragmentation procedures, the scope of Frame Relay
   fragmentation procedure is limited to the boundary (or DTEs) of the
   Frame Relay network.

   The general format of fragmented packets is the same as any other
   encapsulated protocol.  The most significant difference being that
   the fragmented packet will contain the encapsulation header.  That
   is, a packet is first encapsulated (with the exception of the address
   and control fields) as defined above. Large packets are then broken
   up into frames appropriate for the given Frame Relay network and are
   encapsulated using the Frame Relay fragmentation format.  In this
   way, a station receiving fragments may reassemble them and then put
   the reassembled packet through the same processing path as a packet
   that had not been fragmented.

   Within Frame Relay fragments are encapsulated using the SNAP format
   with an OUI of 0x00-80-C2 and a PID of 0x00-0D.  Individual fragments
   will, therefore, have the following format:

























Bradley, Brown, Malis                                          [Page 14]