rfc1735.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

   code and data structures may be realized differently.

   Each NAS has a forwardingTable consisting of entries with the fields:

       <networkLayerAddrPrefix, type, outIf, outIfAddr>

   The networkLayerAddrPrefix field identifies a set of IP addresses
   known to the NAS.  It consists of two subfields <ipAddr, mask>.

   The type field indicates the type of the networkLayerAddrPrefix.  The
   possible values are:

   - locallyServed: The NAS is itself serving the
     networkLayerAddrPrefix.  The outIf field denotes the NBMA interface
     via which the served terminals can be reached and the outIfAddr
     field has no meaning.  Such a forwardingTable entry has been
     created by manual configuration.

   - nasLearned: The NAS has learned about the networkLayerAddrPrefix
     from another NAS.  The outIf and outIfAddr fields, respectively,
     denote the NBMA interface and IP address of this next hop NAS.
     Such a forwardingTable entry is a result of network layer address
     prefix information exchange with one of the NAS' peer NASs.




Heinanen & Govindan                                             [Page 6]

RFC 1735                    NBMA ARP (NARP)                December 1994


   - externallyLearned: The NAS has learned about the
     networkLayerAddrPrefix from a peer router outside the served NBMA.
     The outIf and outIfAddr fields, respectively, denote the NBMA
     interface and IP address of this next hop NAS.  Such a
     forwardingTable entry is a result of network layer address prefix
     information exchange with one of the NAS' peer routers.

   The protocol used to exchange networkLayerAddrPrefix information
   among the NASs can be any regular IP intra-domain or inter-domain
   routing protocol.

   In addition to the forwardingTable, each NAS has an NARP cacheTable
   consisting of entries with the fields:

       <networkLayerAddr, nbmaAddr, timeStamp>

   The entries in the cacheTable are learned from NARP replies
   traversing the NAS.  In case of a negative cache entry the nbmaAddr
   is empty.  The timeStamp field records the time when the cacheTable
   entry has been created or updated.  It is used to determine if an
   entry is a very recent one and to age old entries after a certain
   hold period.

   The following pseudocode defines how NBMA NARP requests and replies
   are processed by an NAS.

  procedure processRequest(request);
    let bestMatch == matchForwardingTable(request.dIPa) do
       if bestMatch then
          if bestMatch.type == locallyServed then
             let nbmaAddr == arp(request.dIPa) do
                if nbmaAddr then
                   genPosAuthReply(request.sIPa, request.dIPa, nbmaAddr)
                else
                   genNegAuthReply(request.sIPa, request.dIPa)
                end
             end
          elseif bestMatch.type == nasLearned then
             if not requestForAuthInfo?(request) or
                   realBusyRightNow?() then
                let cacheMatch == matchCacheTable(request.dIPa) do
                   if cacheMatch and
                         (not requestForAuthInfo?(request) or
                            realRecentCacheEntry?(cacheMatch)) then
                      if cacheMatch.nbmaAddr == EMPTY then
                         genNegNonAuthReply(request.sIPa, request.dIPa)
                      else
                         genPosNonAuthReply(request.sIPa, request.dIPa,



Heinanen & Govindan                                             [Page 7]

RFC 1735                    NBMA ARP (NARP)                December 1994


                            cacheMatch.nbmaAddr)
                      end
                   else /* no cache match */
                      forwardRequest(request, bestMatch.OutIf,
                         bestMatch.OutIfAddr)
                   end
                end
             else /* request for authoritative information */
                forwardRequest(request, bestMatch.OutIf,
                   bestMatch.OutIfAddr)
             end
          else /* bestMatch.type == externallyLearned */
             genNegAuthReply(request.sIPa, request.dIPa)
          end
       else /* no match in forwardingTable */
          genNegAuthReply(request.sIPa, request.dIPa)
       end
    end
  end

  procedure processReply(reply);
    addCacheTableEntry(reply.dIPa, reply.nbmaAddr, currentTime);
    if reply.sIPa == selfIpAddr then
       /* reply is to the NAS itself */
    else
       let bestMatch == matchForwardingTable(reply.sIPa) do
          if bestMatch then
             forwardReply(reply, bestMatch.outIf, bestMatch.outIfAddr)
          end
       end
    end
  end

   The semantics of the procedures used in the pseudocode are explained
   below.

   matchForwardingTable(ipAddress) returns the forwardingTable entry
   whose networkLayerAddrPrefix field is the longest match for ipAddress
   or FALSE if no match is found.

   arp(ipAddress) resolves the NBMA address corresponding to ipAddress.
   It returns FALSE if the resolution fails.

   genPosAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) and
   genPosNonAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) generate a
   positive, authoritative and non-authoritative reply with
   sourceIpAddr, destIpAddr, and destNbmaAddr in Source IP address,
   Destination IP address, and NBMA Address fields, respectively.



Heinanen & Govindan                                             [Page 8]

RFC 1735                    NBMA ARP (NARP)                December 1994


   genNegAuthReply(sourceIpAddr, destIpAddr) and
   genNegNonAuthReply(sourceIpAddr, destIpAddr) respectively generate a
   negative, authoritative and non-authoritative reply with sourceIpAddr
   and destIpAddr in Source IP address and Destination IP address
   fields, respectively.

   requestForAuthInfo?(request) tests if request is a Request for
   authoritative information.

   realBusyRightNow?() returns TRUE if the NAS is heavily loaded and
   FALSE otherwise.

   realRecentCacheEntry?(cacheTableEntry) returns TRUE if the
   cacheTableEntry is very recently updated and FALSE otherwise.

   matchCacheTable(ipAddr) returns a cacheTable entry whose
   networkLayerAddr field is equal to ipAddr or FALSE if no match is
   found.

   forwardRequest(request, interface, ipAddr) decrements the Hop count
   field of request, recomputes the NARP Checksum field, and forwards
   request to ipAddr of interface provided that the value of the Hop
   count field remains positive.

   addCacheTableEntry(ipAddr, nbmaAddr, time) adds a new entry to the
   cacheTable or overwrites an existing entry whose networkLayerAddr
   field is equal to ipAddr.

   forwardReply(reply, interface, ipAddr) decrements the Hop count field
   of request, recomputes the NARP Checksum field, and forwards reply to
   ipAddr of interface provided that the value of the Hop count field
   remains positive.

   Like NASs, each NBMA terminal has a forwardingTable and a cacheTable.
   The forwardingTable is either manually configured or filled via
   reachability information exchange with the terminal's NASs or peer
   routers.

   When the terminal wishes to find out the NBMA address of a particular
   destination terminal, it first checks if a matching entry is found in
   the forwardingTable.  If not, the destination is unreachable and the
   terminal gives up.  If a forwardingTable entry is found, and if the
   next hop belongs to one of the terminal's NASs, the terminal next
   consults its cacheTable to obtain the NBMA address.  If no cache
   match is found, the terminal generates a NARP request to the next hop
   NAS.  If the reply to the NARP request is positive, the terminal
   learns the NBMA address and updates its cacheTable with the new
   information.



Heinanen & Govindan                                             [Page 9]

RFC 1735                    NBMA ARP (NARP)                December 1994


6. Discussion

   The NARP semantics resembles closely the ATMARP semantics described
   in [2].  The only actual differences are:

   - NARP requests and replies include a hop count to prevent them from
     looping forever in case of misconfigured NAS routing.

   - NARP request and replies distinguish between authoritative and
     non-authoritative information.

   In order to keep the NBMA terminals as simple as possible, it would
   be desirable to extend the the ATMARP protocol a little further so
   that it could be also used as the terminal-NAS protocol.  This could
   be easily accomplished just by adding three new operation codes to
   ATMARP to cover the different kinds of queries and responses.  NARP
   would then become the NAS-NAS protocol.  Finally, if the NASs are
   co-located with the "classical" ATM ARP servers, the terminals would
   not need to make any distinction between between local and foreign IP
   subnetworks.

   The NASs can also act as "connectionless servers" for the terminal by
   advertizing to it all destinations no matter if they are inside or
   outside the served NBMA.  Then, the terminal could choose either to
   try to resolve the NBMA address of the destination or just to send
   the IP packets to the NAS.  The latter option may be desirable if
   communication with the destination is short-lived and/or doesn't
   require much network resources.

   NARP supports portability of NBMA terminals.  A terminal can be moved
   anywhere within the NBMA network and still keep its original IP
   address as long as its NAS(s) remain the same.  Requests for
   authoritative information will always return the correct NBMA
   address.

References

   [1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Protocol Addresses to 48.bit Ethernet Address
       for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
       November 1982.

   [2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-
       Packard Laboratories, January 1994.

   [3] Piscitello, D., and J. Lawrence, "Transmission of IP Datagrams
       over the SMDS Service, RFC 1209, Bell Communications Research,
       March 1991.



Heinanen & Govindan                                            [Page 10]

RFC 1735                    NBMA ARP (NARP)                December 1994


Acknowledgements

   We would like to thank John Burnett of Adaptive, Dennis Ferguson of
   ANS, Joel Halpern of Network Systems, and Paul Francis of Bellcore
   for their valuable insight and comments to earlier versions of this
   draft.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Juha Heinanen
   Telecom Finland
   PO Box 228
   SF-33101 Tampere
   Finland

   Phone: [phone]
   EMail: [e-mail]


   Ramesh Govindan
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]
   EMail: [e-mail]





















Heinanen & Govindan                                            [Page 11]