rfc2583.txt

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

Network Working Group                                       R. Carlson
Request for Comments: 2583                                         ANL
Category: Informational                                     L. Winkler
                                                                   ANL
                                                              May 1999


            Guidelines for Next Hop Client (NHC) Developers

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Abstract

   This document provides guidelines for developers of the Next Hop
   Resolution Protocol Clients (NHC).  It assumes that the clients are
   directly connected to an ATM based NBMA network.  The same principles
   will apply to clients connected to other types of NBMA networks.  The
   intent is to define the interaction between the NHC code and the
   TCP/IP protocol stack of the local host operating system.  The NHC is
   capable of sending NHRP requests to a Next Hop Resolution Protocol
   Server (NHS) to resolve both inter and intra LIS addresses.  The NHS
   reply may be positive (ACK) indicating a short-cut path is available
   or negative (NAK) indicating that a shortcut is not available and the
   routed path must be used.  The NHC must cache (maintain state) for
   both the ACK and NAK replies in order to use the correct shortcut or
   routed path.  The NAK reply must be cached to avoid making repeated
   requests to the NHS when the routed path is being used.

2. Overview

   In the Classical IP over ATM model [1], an ATM attached host
   communicates with an ATMARP server to resolve IP to ATM address
   semantics.  This model supports the concept of a Logical IP Subnet
   (LIS) with intra LIS communications using direct PVCs/SVCs and inter
   LIS communications using IP routers to forward packets.  This model
   easily maps to the conventional LAN model of subnets and routers.
   The Next Hop Resolution Protocol (NHRP) [2] defines how the LIS model
   can be modified to allow direct ATM SVCs (shortcut paths) for inter
   LIS traffic.  With NHRP, nodes directly attached to an ATM network
   can bypass the IP routers and establish a direct switched virtual



Carlson & Winkler            Informational                      [Page 1]

RFC 2583             Guidelines for NHC Developers              May 1999


   circuit to improve performance when needed.

   The NHS code replaces the ATMARP code in the ATMARP server.  Each NHS
   serves a set of destination client hosts and cooperates with other
   NHSs to resolve NHRP next hop requests within their own logical ATM
   network. The NHC to NHS and NHS to NHS protocol interactions are
   described in [2].  Other documents in the NHRP series define the
   general applicability [3] and the transition from ATMARP servers to
   NHSs [4].

   The NHC code replaces the ATMARP code in the local workstations.
   This code will take the destination IP address and map it into the
   ATM End Station Address (AESA) for both intra and inter LIS
   destinations.  The returned AESA will be stored in a local cache
   table.  In addition to storing the positive replies, the NHC will
   need to store the negative replies to avoid making repeated NHS calls
   when using the routed path.

   This document describes a base line method for caching the returned
   information.  Other methods may be used as long as the same
   functionality is provided.

3. IP Processing

   In the Classical IP LIS model [1] the TCP/IP protocol stack treats
   the ATM network as a simple data link layer protocol.  When an
   application sends data using the Classical IP protocol, IP performs a
   routing table lookup to determine if the destination is reachable via
   a local interface or whether an intermediate router is the next hop
   to the IP destination.

   If the destination is found to be local (e.g. in the same LIS as the
   source) the packet will be passed to the local ATM interface with the
   next hop IP address set to the destination nodes IP address.  At this
   point the ATMARP table will be searched to determine the ATM Address
   of the destination node.  If no ATMARP table entry is found an ATMARP
   request will be sent to the ATMARP server.  This server can reply
   with a positive (ACK) or negative (NAK) answer depending on the
   current information it has in its cache.  If an ACK is received the
   host's local ATMARP table is filled in appropriately and the source
   is now able to send IP datagrams to the destination.  If a NAK is
   returned, the calling application is notified of this error condition
   (e.g., ICMP destination unreachable).

   If the destination is found to be remote (e.g., in a different LIS
   from the source) the IP address of the next hop router is extracted
   from the IP routing table and the ATM Address of this router is
   looked up in the ATMARP table.  Since the router is in the same LIS



Carlson & Winkler            Informational                      [Page 2]

RFC 2583             Guidelines for NHC Developers              May 1999


   as the source node, the ATMARP procedure described above will find
   the correct ATM Address or the packet will be marked as undeliverable
   and the user application will be notified of the error.

   The ATMARP service functions exactly as the existing ARP service
   provided on Ethernet broadcast networks.  Since the ARP service will
   only try and resolve addresses for nodes that are in a single IP
   subnet, the ARP table only needs to keep positive answers.  No state
   information is retained about failed mappings.

4. NHC Processing

   In this section we briefly describe what is required in order for a
   host to take advantage of shortcuts through the ATM network.  On the
   host, a NHC process initiates various NHRP requests in order to
   obtain access to the NHRP service. Within the ATM subnetwork, the
   ATMARP server is replaced with a NHS.  As defined in [4] the NHS is
   required to respond to both ATMARP and NHRP Resolution requests.  In
   the nodes wishing to take advantage of shortcut paths across the ATM
   subnetwork, the ATMARP client code must be replaced with NHC code.
   This allows the source node to ask for the ATM AESA of both local and
   remote nodes.  Finally the source node must be modified to know when
   it should ask for the ATM AESA of a remote node and when the local
   LIS router should be used.  These modifications are described in the
   remainder of this document.

   The protocol processing described in [2] states a source may query a
   NHS for the ATM AESA of a destination node.  However as is pointed
   out in [5], to achieve shortcut paths through the ATM network, it is
   not enough to simply replace the ATMARP client code with the NHC
   code.  This is because the source host will never ask the NHS for the
   ATM AESA of a node in a remote LIS.  When the source consults the IP
   routing table, it performs the local/remote test, before the NHC code
   is processed.  As a result, the IP address of the next hop router
   will be used by the NHC instead of the IP address of the remote
   (inter LIS) host.  The NHC code must ignore the result of the IP
   routing table lookup and perform its own local/remote test.

   The NHC must perform the following functions:

   1.     Test to see if the destination node is `local' to this LIS.
          If so use the existing ATMARP rules described in [1].
   2.     If not; send an NHRP message to the local NHS and attempt to
          setup a `shortcut' path.  If successful; save the IP to ATM
          AESA mapping in the local NHC cache.
   3.     If not successful; use the routed path and save this state in
          the NHC cache so future requests don't test for a shortcut
          again.



Carlson & Winkler            Informational                      [Page 3]

RFC 2583             Guidelines for NHC Developers              May 1999


   4.     Allow user application to override system default operation
          and explicitly request a shortcut or routed path for a flow.

   It is required that this routed path state will be maintained in the
   same manner as the existing ATMARP service.  That is a timer will be
   used to expire old information and some administrative function
   exists to manually delete data if needed.

5. Need for State

   It is obvious that the IP to ATM AESA mappings should be maintained
   in a local cache to improve network performance.  This soft state is
   maintained in today's ARP and ATMARP systems using timers to purge
   old or unused data.  The NHC will maintain both inter and intra LIS
   IP to ATM Address mappings in the same manner.  It may be less
   obvious that an NHC will also need to maintain this same soft state
   for inter LIS mappings using the routed path.  If this state is not
   maintained, the source node will send requests to the NHS asking if a
   shortcut path can be setup every time a packet is sent over the
   routed path.

   Some of the features of this state are:

   1.     Cache lookups must be fast as they are done on every packet.
   2.     The cache lookup must be on the destination IP address instead
          of the next-hop router IP address.
   3.     Both ACK and NAK data should be cached for the length of the
          holding time parameter in the NHRP response.

   Since state must be maintained, the questions of where to maintain
   it, how to manually managed it, and how to selectively override it
   need to be addressed.  No matter where this state information is
   kept, a method for manually examining and changing this state
   information must be provided.  This is essential to insure that the
   network is operating properly.

   There are several possible locations for storing this state
   information, they are:

   1.     Store state in the `ARP' table.  This is the traditional
          location for this IP to ATM address mappings.  This table must
          be extended to handle the caching of negative (routed path)
          information. This solution provides a system wide service that
          may be used by the NHC.
   2.     Store state in the IP routing table.  This is the traditional
          location for the local/remote state information.





Carlson & Winkler            Informational                      [Page 4]

RFC 2583             Guidelines for NHC Developers              May 1999


   3.     Store state in an ATM MIB structure.  This is the traditional
          location for storing ATM VCC data.  It also provides a system
          wide service that is geared toward ATM services.  This avoids
          munging the `ARP' table to hold negative data.
   4.     Store state in the TCP Process Control Block.  This allows a
          per process tailoring of shortcut or routed path information.
          This works well for TCP connections, but not UDP style
          services.
   5.     Store state in the socket structure.  This also allows per
          process tailoring of the state information.
   6.     Store state in a newly defined table.

   The NHC should also support both local (per-process) and global
   (per-system) state.  This would allow a system wide default while
   allowing a specific application to tailor the operation for a
   specific task.  For example assume a site runs both a DNS server and
   FTP server on a single host.  Inter LIS communications to the DNS
   server should take the routed path to avoid setup overhead.  While an
   FTP session would benefit from the shortcut path to improve
   performance.  Supporting both operations from a single client will
   require both a global state (e.g. use shortcut for FTP) and a local
   state (e.g. use routed path for DNS).

5.1 Using TCP