As per Relevance of the word shortcut, we have this rfc below:
Network Working Group R.
Request for Comments: 2583
Category: Informational L.
May 1999
Guidelines for Next Hop Client (NHC)
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
This document provides guidelines for developers of the Next
Resolution Protocol Clients (NHC). It assumes that the clients
directly connected to an ATM based NBMA network. The same
will apply to clients connected to other types of NBMA networks.
intent is to define the interaction between the NHC code and
TCP/IP protocol stack of the local host operating system. The NHC
capable of sending NHRP requests to a Next Hop Resolution
Server (NHS) to resolve both inter and intra LIS addresses. The
reply may be positive (ACK) indicating a short-cut path is
or negative (NAK) indicating that a shortcut is not available and
routed path must be used. The NHC must cache (maintain state)
both the ACK and NAK replies in order to use the correct shortcut
routed path. The NAK reply must be cached to avoid making
requests to the NHS when the routed path is being used
2.
In the Classical IP over ATM model [1], an ATM attached
communicates with an ATMARP server to resolve IP to ATM
semantics. This model supports the concept of a Logical IP
(LIS) with intra LIS communications using direct PVCs/SVCs and
LIS communications using IP routers to forward packets. This
easily maps to the conventional LAN model of subnets and routers
The Next Hop Resolution Protocol (NHRP) [2] defines how the LIS
can be modified to allow direct ATM SVCs (shortcut paths) for
LIS traffic. With NHRP, nodes directly attached to an ATM
can bypass the IP routers and establish a direct switched
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
serves a set of destination client hosts and cooperates with
NHSs to resolve NHRP next hop requests within their own logical
network. The NHC to NHS and NHS to NHS protocol interactions
described in [2]. Other documents in the NHRP series define
general applicability [3] and the transition from ATMARP servers
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
ATM End Station Address (AESA) for both intra and inter
destinations. The returned AESA will be stored in a local
table. In addition to storing the positive replies, the NHC
need to store the negative replies to avoid making repeated NHS
when using the routed path
This document describes a base line method for caching the
information. Other methods may be used as long as the
functionality is provided
3. IP
In the Classical IP LIS model [1] the TCP/IP protocol stack
the ATM network as a simple data link layer protocol. When
application sends data using the Classical IP protocol, IP performs
routing table lookup to determine if the destination is reachable
a local interface or whether an intermediate router is the next
to the IP destination
If the destination is found to be local (e.g. in the same LIS as
source) the packet will be passed to the local ATM interface with
next hop IP address set to the destination nodes IP address. At
point the ATMARP table will be searched to determine the ATM
of the destination node. If no ATMARP table entry is found an
request will be sent to the ATMARP server. This server can
with a positive (ACK) or negative (NAK) answer depending on
current information it has in its cache. If an ACK is received
host's local ATMARP table is filled in appropriately and the
is now able to send IP datagrams to the destination. If a NAK
returned, the calling application is notified of this error
(e.g., ICMP destination unreachable).
If the destination is found to be remote (e.g., in a different
from the source) the IP address of the next hop router is
from the IP routing table and the ATM Address of this router
looked up in the ATMARP table. Since the router is in the same
Carlson & Winkler Informational [Page 2]
RFC 2583 Guidelines for NHC Developers May 1999
as the source node, the ATMARP procedure described above will
the correct ATM Address or the packet will be marked as
and the user application will be notified of the error
The ATMARP service functions exactly as the existing ARP
provided on Ethernet broadcast networks. Since the ARP service
only try and resolve addresses for nodes that are in a single
subnet, the ARP table only needs to keep positive answers. No
information is retained about failed mappings
4. NHC
In this section we briefly describe what is required in order for
host to take advantage of shortcuts through the ATM network. On
host, a NHC process initiates various NHRP requests in order
obtain access to the NHRP service. Within the ATM subnetwork,
ATMARP server is replaced with a NHS. As defined in [4] the NHS
required to respond to both ATMARP and NHRP Resolution requests.
the nodes wishing to take advantage of shortcut paths across the
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
remote nodes. Finally the source node must be modified to know
it should ask for the ATM AESA of a remote node and when the
LIS router should be used. These modifications are described in
remainder of this document
The protocol processing described in [2] states a source may query
NHS for the ATM AESA of a destination node. However as is
out in [5], to achieve shortcut paths through the ATM network, it
not enough to simply replace the ATMARP client code with the
code. This is because the source host will never ask the NHS for
ATM AESA of a node in a remote LIS. When the source consults the
routing table, it performs the local/remote test, before the NHC
is processed. As a result, the IP address of the next hop
will be used by the NHC instead of the IP address of the
(inter LIS) host. The NHC code must ignore the result of the
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
setup a `shortcut' path. If successful; save the IP to
AESA mapping in the local NHC cache
3. If not successful; use the routed path and save this state
the NHC cache so future requests don't test for a
again
Carlson & Winkler Informational [Page 3]
RFC 2583 Guidelines for NHC Developers May 1999
4. Allow user application to override system default
and explicitly request a shortcut or routed path for a flow
It is required that this routed path state will be maintained in
same manner as the existing ATMARP service. That is a timer will
used to expire old information and some administrative
exists to manually delete data if needed
5. Need for
It is obvious that the IP to ATM AESA mappings should be
in a local cache to improve network performance. This soft state
maintained in today's ARP and ATMARP systems using timers to
old or unused data. The NHC will maintain both inter and intra
IP to ATM Address mappings in the same manner. It may be
obvious that an NHC will also need to maintain this same soft
for inter LIS mappings using the routed path. If this state is
maintained, the source node will send requests to the NHS asking if
shortcut path can be setup every time a packet is sent over
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
of the next-hop router IP address
3. Both ACK and NAK data should be cached for the length of
holding time parameter in the NHRP response
Since state must be maintained, the questions of where to
it, how to manually managed it, and how to selectively override
need to be addressed. No matter where this state information
kept, a method for manually examining and changing this
information must be provided. This is essential to insure that
network is operating properly
There are several possible locations for storing this
information, they are
1. Store state in the `ARP' table. This is the
location for this IP to ATM address mappings. This table
be extended to handle the caching of negative (routed path
information. This solution provides a system wide service
may be used by the NHC
2. Store state in the IP routing table. This is the
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
location for storing ATM VCC data. It also provides a
wide service that is geared toward ATM services. This
munging the `ARP' table to hold negative data
4. Store state in the TCP Process Control Block. This allows
per process tailoring of shortcut or routed path information
This works well for TCP connections, but not UDP
services
5. Store state in the socket structure. This also allows
process tailoring of the state information
6. Store state in a newly defined table
The NHC should also support both local (per-process) and
(per-system) state. This would allow a system wide default
allowing a specific application to tailor the operation for
specific task. For example assume a site runs both a DNS server
FTP server on a single host. Inter LIS communications to the
server should take the routed path to avoid setup overhead. While
FTP session would benefit from the shortcut path to
performance. Supporting both operations from a single client
require both a global state (e.g. use shortcut for FTP) and a
state (e.g. use routed path for DNS).
5.1 Using
TCP is a connection orientated protocol that provides per-
state information using a TCP Protocol Control Block (PCB). This
can be used to save the shortcut/routed path state information.
a quad-state flag that shows the USE_SHORT_CUT, TRY_SHORT_CUT
USE_ROUTED_PATH, or TRY_ROUTED_PATH states would allow each
to use the service it chooses. The advantage of this approach
that it allows per flow control over the use of the shortcut
routed path. The disadvantage is that this PCB is only created
TCP connections. UDP connections will only use the system
action
A second option is to store this information in the socket PCB
use the socket function (setsockopt) to save this information.
option will allow both TCP and UDP applications to set a per
action to override the system default operation. To enable
option, the IP kernel code will need to be modified to allow
quad-state flag to be set. In addition this flag will need to
checked when each packet is sent to determine the if the shortcut
routed path is being used
Carlson & Winkler Informational [Page 5]
RFC 2583 Guidelines for NHC Developers May 1999
5.2 Using
UDP is a connectionless orientated protocol that doesn't provide
support for state information. It relies on the application
provide the necessary state information. In this case where
the state be stored? The user application could store this
and pass this down to the kernel in some manner. Another option
to store this information in an ATM MIB structure. A third option
to allow a socket option (setsockopt) that the user application
set to override the default behavior
5.3 Using
In keeping with the tradition of using ICMP echo packets for
management functions (e.g. ping, traceroute) then it will
necessary to allow these applications to run over the shortcut
routed paths. The user will need to be able to specify which path
use and a default action needs to be defined too
6.
NHRP provides new services and functionality for IP nodes using
networks. To use these services the client must store
information that describes whether a destination node is
via a shortcut or a routed path
The state information should be stored on a global per-
basis with per-process override functionality. This allows
lived functions (e.g. DNS requests) and long lived requests (e.g.
sessions) to use different paths. Storing state only based on
destination address means that all processes must use the same
and this creates unreasonable demands on the network. To
this the /etc/services file should be modified to carry a new flag
indicate the per-application default (shortcut vs. routed path
behavior
This state information is required to avoid having the client make
call to the NHS for every packet it sends along the routed path.
is recommended that the IP routing table be modified to support a
flag. This flag will indicate whether the NHS returned an ACK or
to the NHRP request
In addition, application programmers and system
require the ability to explicitly request a specific service (e.g
use the routed path or shortcut path). This includes the ability
verify network operation by specifying how ICMP echo requests (e.g
ping, traceroute) are handled. The NHC must support the
setting of this state information. A new socket option that
Carlson & Winkler Informational [Page 6]
RFC 2583 Guidelines for NHC Developers May 1999
the user to specify the operation needs to be supported
To support this capability a new socket option will be created
allow the user application to control the operation of a
connection (flow). This option will allow the user to specify that
connection use one of the following
* USE_SYSTEM_DEFAULT. Use the shortcut or routed path based
the system configuration information for this application
(This is the default behavior.)
* USE_SHORT_CUT. If a shortcut path exists, then use it
deliver the data. If it doesn't exist, then try and
it. If the shortcut cannot be created, fail the
and notify the user
* TRY_SHORT_CUT. If a shortcut path exists, then use it
deliver the data. If it doesn't exist, then try and
it. If the shortcut cannot be created, try using the
path
* USE_ROUTED_PATH. Use the routed path regardless of whether
shortcut exists or not
* TRY_ROUTED_PATH. If a shortcut doesn't exist, don't try
create it, use the routed path instead
7.
The security issues for NHRP are addressed in other NHRP
[2,3]. Some specific security issues for the NHC developer
discussed below
* Address spoofing at the IP or ATM layer may allow an
to hi-jack an IP connection or service. This threat may
reduced by limiting the scope of the ATM routing domain.
this way only trusted IP hosts will be able to reach and
the services of the NHS
* Denial of service attacks may be launched at both the IP
ATM layers of the NHS. At the ATM layer, the attacker
repeatedly generate signaling messages that consuming
resources thus preventing NHCs from using the NHS services
At the IP layer, the attacker may register false IP to
mappings thus preventing a NHC from registering the correct
to ATM mapping
* When a NHC creates or accepts a short-cut path it bypasses
site border router. Therefore, any security features in
border router are also bypassed. This threat may be
by limiting the scope of the ATM routing domain,
Carlson & Winkler Informational [Page 7]
RFC 2583 Guidelines for NHC Developers May 1999
security features in the NHC host, allowing the NHS
evaluate security features when short-cut paths are
or a compination of all of these methods
8. Authors'
Richard
Argonne National
EMail: RACarlson@anl.
Linda
Argonne National
EMail: lwinkler@anl.
9. References
[1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM",
2225, April 1998.
[2] Luciani, J., Katz, D., Piscitello, D., Cole B. and N. Doraswamy
"NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[3] Cansever, D., "NHRP Protocol Applicability Statement", RFC 2333,
April 1998.
[4] Luciani, J., "Classical IP to NHRP Transition", RFC 2336,
1998.
[5] Rekhter, Y. and D. Kandlur, "Local/Remote Forwarding Decision
Switched Data link Subnetworks", RFC 1937, May 1996.
Carlson & Winkler Informational [Page 8]
RFC 2583 Guidelines for NHC Developers May 1999
10. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided
the Internet Society
Carlson & Winkler Informational [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
