rfc1490.txt

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

   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



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


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

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











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


                       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.

































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


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

   Fragmentation allows the exchange of packets that are greater than
   the maximum frame size supported by the underlying network.  In the



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


   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
   recommended, but not required, 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:

                   +---------------+---------------+
                   |         Q.922 Address         |
                   +---------------+---------------+
                   | Control 0x03  | pad     0x00  |
                   +---------------+---------------+
                   | NLPID   0x80  | OUI     0x00  |
                   +---------------+---------------+
                   | OUI                  0x80-C2  |
                   +---------------+---------------+
                   | PID                  0x00-0D  |
                   +---------------+---------------+
                   |        sequence number        |
                   +-+-------+-----+---------------+
                   |F| RSVD  |offset               |
                   +-+-------+-----+---------------+
                   |    fragment data              |
                   |               .               |
                   |               .               |
                   |               .               |
                   +---------------+---------------+
                   |              FCS              |
                   +---------------+---------------+

   The sequence field is a two octet identifier that is incremented



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


   every time a new complete message is fragmented.  It allows detection
   of lost frames and is set to a random value at initialization.

   The reserved field is 4 bits long and is not currently defined.  It
   must be set to 0.

   The final bit is a one bit field set to 1 on the last fragment and
   set to 0 for all other fragments.

   The offset field is an 11 bit value representing the logical offset
   of this fragment in bytes divided by 32. The first fragment must have
   an offset of zero.

   The following figure shows how a large IP datagram is fragmented over
   Frame Relay.  In this example, the complete datagram is fragmented
   into two Frame Relay frames.



































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


                           Frame Relay Fragmentation Example
                                              +-----------+-----------+
                                              |     Q.922 Address     |
                                              +-----------+-----------+
                                              | Ctrl 0x03 | pad  0x00 |
                                              +-----------+-----------+
                                              |NLPID 0x80 | OUI 0x00  |
                                              +-----------+-----------+
                                              | OUI          0x80-C2  |
            +-----------+-----------+         +-----------+-----------+
            |ctrl 0x03  |NLPID 0xCC |         | PID          0x00-0D  |
            +-----------+-----------+         +-----------+-----------+
            |                       |         | sequence number   n   |
            |                       |         +-+------+--+-----------+
            |                       |         |0| RSVD |offset (0)    |
            |                       |         +-+------+--+-----------+
            |                       |         | ctrl 0x03 |NLPID 0xCC |
            |                       |         +-----------+-----------+
            |                       |         |   first m bytes of    |
            |  large IP datagram    |   ...   |     IP datagram       |
            |                       |         |                       |
            |                       |         +-----------+-----------+
            |                       |         |          FCS          |
            |                       |         +-----------+-----------+
            |                       |
            |                       |         +-----------+-----------+
            |                       |         |     Q.922 Address     |
            |                       |         +-----------+-----------+
            |                       |         | Ctrl 0x03 | pad  0x00 |
            +-----------+-----------+         +-----------+-----------+
                                              |NLPID 0x80 | OUI 0x00  |
                                              +-----------+-----------+
                                              | OUI          0x80-C2  |
                                              +-----------+-----------+
                                              | PID          0x00-0D  |
                                              +-----------+-----------+
                                              | sequence number   n   |
                                              +-+------+--+-----------+
                                              |1| RSVD |offset (m/32) |
                                              +-+------+--+-----------+
                                              |    remainder of IP    |