doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc2583.txt b/doc/rfc/rfc2583.txt
new file mode 100644
index 0000000..40e3e86
--- /dev/null
+++ b/doc/rfc/rfc2583.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+
+   TCP is a connection orientated protocol that provides per-process
+   state information using a TCP Protocol Control Block (PCB).  This PCB
+   can be used to save the shortcut/routed path state information. Using
+   a quad-state flag that shows the USE_SHORT_CUT, TRY_SHORT_CUT,
+   USE_ROUTED_PATH, or TRY_ROUTED_PATH states would allow each process
+   to use the service it chooses.  The advantage of this approach is
+   that it allows per flow control over the use of the shortcut or
+   routed path.  The disadvantage is that this PCB is only created for
+   TCP connections.  UDP connections will only use the system default
+   action.
+
+   A second option is to store this information in the socket PCB and
+   use the socket function (setsockopt) to save this information.  This
+   option will allow both TCP and UDP applications to set a per flow
+   action to override the system default operation.  To enable this
+   option, the IP kernel code will need to be modified to allow this
+   quad-state flag to be set.  In addition this flag will need to be
+   checked when each packet is sent to determine the if the shortcut or
+   routed path is being used.
+
+
+
+
+
+
+
+Carlson & Winkler            Informational                      [Page 5]
+
+RFC 2583             Guidelines for NHC Developers              May 1999
+
+
+5.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 in 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.
+
+5.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 shortcut 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.
+
+6. Conclusions
+
+   NHRP provides new services and functionality for IP nodes using ATM
+   networks.  To use these services the client must store state
+   information that describes whether a destination node is reachable
+   via a shortcut or a routed path.
+
+   The state information should be stored on a global per-application
+   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.  To accomplish
+   this the /etc/services file should be modified to carry a new flag to
+   indicate the per-application default (shortcut vs. routed path)
+   behavior.
+
+   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.  It
+   is recommended that the IP routing table be modified to support a new
+   flag.  This flag will indicate whether the NHS returned an ACK or NAK
+   to the NHRP request.
+
+   In addition, application programmers and system administrators
+   require the ability to explicitly request a specific service (e.g.
+   use the routed path or shortcut 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
+
+
+
+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 to
+   allow the user application to control the operation of a particular
+   connection (flow).  This option will allow the user to specify that a
+   connection use one of the following:
+
+   *      USE_SYSTEM_DEFAULT.  Use the shortcut or routed path based on
+          the system configuration information for this application.
+          (This is the default behavior.)
+   *      USE_SHORT_CUT.  If a shortcut path exists, then use it to
+          deliver the data.  If it doesn't exist, then try and create
+          it.  If the shortcut cannot be created, fail the connection
+          and notify the user.
+   *      TRY_SHORT_CUT.  If a shortcut path exists, then use it to
+          deliver the data.  If it doesn't exist, then try and create
+          it.  If the shortcut cannot be created, try using the routed
+          path.
+   *      USE_ROUTED_PATH.  Use the routed path regardless of whether a
+          shortcut exists or not.
+   *      TRY_ROUTED_PATH.  If a shortcut doesn't exist, don't try and
+          create it, use the routed path instead.
+
+7. Security
+
+   The security issues for NHRP are addressed in other NHRP documents
+   [2,3].  Some specific security issues for the NHC developer are
+   discussed below.
+
+   *      Address spoofing at the IP or ATM layer may allow an attacker
+          to hi-jack an IP connection or service. This threat may be
+          reduced by limiting the scope of the ATM routing domain.  In
+          this way only trusted IP hosts will be able to reach and use
+          the services of the NHS.
+   *      Denial of service attacks may be launched at both the IP and
+          ATM layers of the NHS.  At the ATM layer, the attacker may
+          repeatedly generate signaling messages that consuming system
+          resources thus preventing NHCs from using the NHS services.
+          At the IP layer, the attacker may register false IP to ATM
+          mappings thus preventing a NHC from registering the correct IP
+          to ATM mapping.
+   *      When a NHC creates or accepts a short-cut path it bypasses the
+          site border router.  Therefore, any security features in the
+          border router are also bypassed.  This threat may be reduced
+          by limiting the scope of the ATM routing domain, increasing
+
+
+
+
+
+
+Carlson & Winkler            Informational                      [Page 7]
+
+RFC 2583             Guidelines for NHC Developers              May 1999
+
+
+          security features in the NHC host, allowing the NHS to
+          evaluate security features when short-cut paths are requested
+          or a compination of all of these methods.
+
+8. Authors' Addresses
+
+   Richard Carlson
+   Argonne National Laboratory
+
+   EMail: RACarlson@anl.gov
+
+
+   Linda Winkler
+   Argonne National Laboratory
+
+   EMail: lwinkler@anl.gov
+
+9. References:
+
+   [1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC
+       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, July
+       1998.
+
+   [5] Rekhter, Y. and D. Kandlur, "Local/Remote Forwarding Decision in
+       Switched Data link Subnetworks", RFC 1937, May 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carlson & Winkler            Informational                      [Page 8]
+
+RFC 2583             Guidelines for NHC Developers              May 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by
+   the Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carlson & Winkler            Informational                      [Page 9]
+