INTERNET-DRAFT R. Carlson
ANL
L. Winkler
ANL
February, 1998
Guidelines for Next Hop Client (NHC) developers
<draft-carlson-nhrp-00.txt>
1. Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
To view the entire list of current Internet-Drafts, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (US Ease Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
This document provides guidelines for developers of ATM attached host
implementations of the Next Hop Resolution Protocol Client (NHC)
protocol. The intent is to define the interaction between the NHC code
and the TCP/IP protocol stack of the local 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 short-cut or routed
path. The NAK reply must be cached to avoid making repeated requests to
the NHS when the routed path is being used.
3. 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 NHRP [2]
protocol defines how the LIS model can be modified to allow direct ATM
SVCs (shortcut) for inter LIS traffic. With NHRP, nodes directly
Carlson, WInkler [Page 1]
INTERNET-DRAFT February, 1998
attached to an ATM network can bypass the routers and establish a direct
ATM VC to improve performance when needed.
The NHS code replaces the ATMARP code in the ATMARP server. Each NHS
serves a set of destination hosts and cooperates with other NHSs to
resolve NBMA next hop requests within their own logical NBMA
subnetwork.. 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 AESA
address 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. [Should this be a generic set of functional
statements or should there be some specific recommendations?]
4. 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 AESA 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 AESA of this router is looked up in the ATMARP
table. Since the router is in the same LIS as the source node, the
ATMARP procedure described above will find the correct AESA 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 subnet,
Carlson, WInkler [Page 2]
INTERNET-DRAFT February, 1998
the ARP table only needs to keep positive answers. No state information
is retained about failed mappings.
5. 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 NMBA subnetwork, the ATMARP server is
replaced with an NHS. As defined in [4] the NHS is required to respond
to both ATMARP and NHRP Resolution requests. In the hosts wishing to
take advantage of shortcut paths across the NBMA subnetwork, the ATMARP
client code must be replaced with NHC code. This allows the source node
to ask for the AESA of both local and remote nodes. Finally the source
node must be modified to know when it should ask for the 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 an
NHS for the AESA of a destination node. However, to achieve shortcut
paths through the NBMA, 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 AESA of a node in a remote LIS. When the
source consults the IP routing table, it performes 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 test to see if the destination node is able to accept a
`short-cut' path. If so save the IP to AESA mapping in the
local NHC cache.
3. If not use the routed path and save this state in the NHC cache
so future requests don't test for a short-cut again.
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.
6. Need for State
It is obvious that the IP to AESA mappings should be maintained in a
local cache to improve network performance. This soft state is
maintained in todays ARP and ATMARP systems using timers to purge old
unused data. The NHC will maintain both inter and intra LIS IP to AESA
mappings in the same manner. It may be less obvious that an NHC will
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 short-cut path can be setup every time a
packet is sent over the routed path.
Carlson, WInkler [Page 3]
INTERNET-DRAFT February, 1998
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 AESA 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 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.
3. Store state in the Process Control Block. This allows a per
process tailoring of short-cut or routed path information.
This works well for TCP connections, but not UDP style
services.
4. Store state in the socket structure. This also allows per
process tailoring of the state information.
5. Store state in the IP routing table. This is the traditional
location for the local/remote 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 a FTP session would benefit from
the short-cut path to improve performance. Supporting both operations
from a single client will require both a global state (e.g. short-cut)
and a local state (e.g. use routed path for DNS).
6.1 Using TCP
TCP is a connection orientated protocol that provides per-process state
information using a PCB. This PCB can be used to save the short-
cut/routed path state information. Using a tri-state flag that shows the
USE_SHORT_CUT, NO_SHORT_CUT, or REQUEST_PENDING states would allow each
process to use the service it chooses. [What changes need to be made to
the TCP or IP kernel code so this information is used? What are the
advantages/disadvantages of this approach?]
Carlson, WInkler [Page 4]
INTERNET-DRAFT February, 1998
6.2 Using UDP
UDP is a connectionless orientated protocol that doesn't provide any
support for state information. It relies on the application to provide
the necessary state information. In this case where should the state be
stored? The user application could store this itself and pass this down
to the kernel in some manner. Another option is to store this
information is an ATM MIB structure. A third option is to allow a
socket option (setsockopt) that the user application can set to override
the default behavior.
Creating a new socket options will allow the user application to control
the operation of a particular connection. The option will allow the
user to specify that a connection use one of the following:
1. USE_SHORT_CUT. If a short-cut path exists, then use it to
deliver the data. If it doesn't exist, then try and create it.
If the short-cut cannot be created, fail the connection and
notify the user.
2. TRY_SHORT_CUT. If a short-cut path exists, then use it to
deliver the data. If it doesn't exist, then try and create it.
If the short-cut cannot be created, try using the routed path
(this is the default behavior.
3. USE_ROUTED_PATH. Use the routed path regardless of whether a
short-cut exists or not.
4. TRY_ROUTED_PATH. If a short-cut doesn't exist, don't try and
create it. Use the routed path instead.
[What changed need to be made to the UDP or IP kernel code so this
information is used? Should it be the same IP changes used for TCP?
What are the advantages/disadvantages of this approach?]
6.3 Using ICMP
In keeping with the tradition of using ICMP echo packets for Internet
management functions (e.g. ping, traceroute) then it will be necessary
to allow these applications to run over the short-cut and routed paths.
The user will need to be able to specify which path to use and a default
action needs to be defined too. [What changes need to be made to ICMP
or IP kernel code so this information is used? How will the user
specify the particular operation (socket options)?]
7. Conclusions
NHRP provides new services and functionality for IP node using ATM
networks. To use these services the client must store state information
that describes wither a destination node is reachable via a short-cut or
the routed path. This state information is required to avoid having the
client make a call to the NHS for every packet it sends along the routed
path. The recommended method for storing this state is ? [need to
make a specific recomendation]
The state information should be stored on a global per-system basis with
per-process override functionality. This allows short lived functions
(e.g. DNS requests) and long lived requests (e.g. ftp sessions) to use
different paths. Storing state only based on the destination address
means that all processes must use the same path and this creates
unreasonable demands on the network.
Carlson, WInkler [Page 5]
INTERNET-DRAFT February, 1998
Application programmers and system administrators require the ability to
explicitly request a specific service (e.g. use the routed path or
short-cut path). This includes the ability to verify network operation
by specifying how ICMP echo requests (e.g. ping, traceroute) are
handled. The NHC must support the manual setting of this state
information. A new socket option that allows the user to specify the
operation needs to be supported.
8. Security
Some of the security issues are addressed in the other NHRP documents.
Some specific questions for the NHC are.
How do we verify the returned AESA? Do we need to? [if it is
bogus then things dont work right? Is this the same as spoofing? Can
I spoof both the AESA and IP address of another host?]
Is there a denial of service attack possible?
Are there any problems with having the state stored on a per-
process bases?
Are there any problems with having the user request/set a specific
path?
9. Authors Address
Richard Carlson
Argonne National Laboratory
RACarlson@anl.gov
Linda Winkler
Argonne National Laboratory
lwinkler@anl.gov
10. References:
[1] "Classical IP and ARP over ATM", RFC1577, M. Laubach, January
1994.
[2] "NBMA Next Hop Resolution Protocol (NHRP)", draft-ietf-rolc-nhrp-
11.txt, J. Luciani, D. Katz, D. Piscitello, Bruce Cole, March 1997
[3] "NHRP Protocol Applicability Statement", draft-ietf-ion-nhrp-appl-
01.txt, D. Cansever, March 1997.
[4] "Classical IP to NHRP Transition", draft-ietf-ion-transition-02.txt,
J. Luciani, May 1997.
Carlson, WInkler [Page 6]
