rfc1294.txt

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


RFC 1294             Multiprotocol over Frame Relay         January 1992


          +---------------+---------------+
          |         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
   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 15]

RFC 1294             Multiprotocol over Frame Relay         January 1992


                        Frame Relay Fragmentation Example
                                           +-----------+-----------+
                                           |     Q.922 Address     |
                                           +-----------+-----------+
                                           | Ctrl 0x03 | pad  0x00 |
                                           +-----------+-----------+
                                           |NLPID 0x80 | OUI 0x00  |
                                           +-----------+-----------+
                                           | OUI          0x80-C2  |
         +-----------+-----------+         +-----------+-----------+
         | pad 0x00  |NLPID 0xCC |         | PID          0x00-0D  |
         +-----------+-----------+         +-----------+-----------+
         |                       |         | sequence number   n   |
         |                       |         +-----------+-----------+
         |                       |         |0| RSVD |offset (0)    |
         |                       |         +-----------+-----------+
         |                       |         | pad 0x00  |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    |
                                           |        datagram       |
                                           +-----------+-----------+
                                           |          FCS          |
                                           +-----------+-----------+

   Fragments must be sent in order starting with a zero offset and
   ending with the final fragment.  These fragments must not be



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


   interrupted with other packets or information intended for the same
   DLC. An end station must be able to re-assemble up to 2K octets and
   is suggested to support up to 8K octet re-assembly.  If at any time
   during this re-assembly process, a fragment is corrupted or a
   fragment is missing, the entire message is dropped.  The upper layer
   protocol is responsible for any retransmission in this case.

   This fragmentation algorithm is not intended to reliably handle all
   possible failure conditions.  As with IP fragmentation, there is a
   small possibility of reassembly error and delivery of an erroneous
   packet.  Inclusion of a higher layer checksum greatly reduces this
   risk.

10.  Address Resolution

   There are situations in which a Frame Relay station may wish to
   dynamically resolve a protocol address.  Address resolution 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(s)  0x00      |
         +-----------------------+-----------------------+
         |  NLPID = 0x80         |                       |  SNAP Header
         +-----------------------+  OUI = 0x00-00-00     +  Indicating
         |                                               |  ARP
         +-----------------------+-----------------------+
         |  PID = 0x0806                                 |
         +-----------------------+-----------------------+
         |                   ARP packet                  |
         |                       .                       |
         |                       .                       |
         |                       .                       |
         +-----------------------+-----------------------+















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


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

        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.



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


                         ~~~~~~~~~~~~~~~
                        (                )
      +-----+          (                  )             +-----+
      |     |-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.

         DLCI to Q.922 Address Table for Figure 1

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

      If you know about frame relay, you should understand the
      corrolation between DLCI and Q.922 address.  For the uninitiated,
      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



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


   will be invalid.  The address found in the frame header will,
   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

   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




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


   Again, the source hardware address is unknown and when the request 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] will work in exactly the same way.  Still
   using figure 1, if we assume station C is an address server, the
   following RARP exchanges will occur:

         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 is
   presently under study by Frame Relay providers.  At such time that
   the issues surrounding multicasting are resolved, multicast
   addressing may become useful in sending ARP requests and other
   "broadcast" messages.



Bradley, Brown, Malis                                          [Page 21]