rfc1490.txt

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

                                              |        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 18]

RFC 1490             Multiprotocol over Frame Relay            July 1993


   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.  Note
   that there is no reassembly timer, nor is one needed.  This is
   because the Frame Relay service is required to deliver frames in
   order.

   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.

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



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


           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 20]

RFC 1490             Multiprotocol over Frame Relay            July 1993


                                  ~~~~~~~~~~~~~~~
                                 (                )
               +-----+          (                  )             +-----+
               |     |-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
      correlation 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 21]

RFC 1490             Multiprotocol over Frame Relay            July 1993


   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 22]

RFC 1490             Multiprotocol over Frame Relay            July 1993


   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



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


   addressing may become useful in sending ARP requests and other
   "broadcast" messages.

   Because of the inefficiencies of 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.  Using
   Inverse ARP for Frame Relay follows the same pattern as ARP and RARP
   use.  That is the source hardware address is inserted at the
   receiving station.

   In our example, station A may use Inverse ARP to discover the
   protocol address of the station associated with its DLCI 50.  The
   Inverse ARP request would be as follows:

              InARP Request from A (DLCI 50)
              ar$op   8       (InARP request)
              ar$sha  unknown
              ar$spa  pA
              ar$tha  0x0C21  (DLCI 50)
              ar$tpa  unknown

   When Station B receives this packet, it will modify the source
   hardware address with the Q.922 address from the Frame Relay header.
   This way, the InARP request from A will become:

              ar$op   8       (InARP request)
              ar$sha  0x1061
              ar$spa  pA
              ar$tha  0x0C21
              ar$tpa  unknown.

   Station B will format an Inverse ARP response and send it to station
   A as it would for any ARP message.

8.  IP over Frame Relay