Guidelines for Next Hop Client (NHC) Developers
RFC 2583

Document Type RFC - Informational (May 1999; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2583 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       R. Carlson
Request for Comments: 2583                                         ANL
Category: Informational                                     L. Winkler
                                                              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
Show full document text