idnits 2.17.1 draft-carlson-nhrp-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 333 looks like a reference -- Missing reference section? '2' on line 335 looks like a reference -- Missing reference section? '3' on line 337 looks like a reference -- Missing reference section? '4' on line 339 looks like a reference -- Missing reference section? '5' on line 341 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Carlson 2 ANL 3 L. Winkler 4 ANL 5 April, 1999 7 Guidelines for Next Hop Client (NHC) Developers 8 10 1. Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To view the entire list of current Internet-Drafts, please check the 23 "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 25 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 2. Abstract 30 This document provides guidelines for developers of the Next Hop 31 Resolution Protocol Clients (NHC). It assumes that the clients are 32 directly connected to an ATM based NBMA network. The same principles 33 will apply to clients connected to other types of NBMA networks. The 34 intent is to define the interaction between the NHC code and the 35 TCP/IP protocol stack of the local host operating system. The NHC is 36 capable of sending NHRP requests to a Next Hop Resolution Protocol 37 Server (NHS) to resolve both inter and intra LIS addresses. The NHS 38 reply may be positive (ACK) indicating a short-cut path is available 39 or negative (NAK) indicating that a shortcut is not available and the 40 routed path must be used. The NHC must cache (maintain state) for 41 both the ACK and NAK replies in order to use the correct shortcut or 42 routed path. The NAK reply must be cached to avoid making repeated 43 requests to the NHS when the routed path is being used. 45 3. Overview 47 In the Classical IP over ATM model [1], an ATM attached host 48 communicates with an ATMARP server to resolve IP to ATM address 49 semantics. This model supports the concept of a Logical IP Subnet 50 (LIS) with intra LIS communications using direct PVCs/SVCs and inter 51 LIS communications using IP routers to forward packets. This model 52 easily maps to the conventional LAN model of subnets and routers. The 53 Next Hop Resolution Protocol (NHRP) [2] defines how the LIS model can 54 be modified to allow direct ATM SVCs (shortcut paths) for inter LIS 55 traffic. With NHRP, nodes directly attached to an ATM network can 56 bypass the IP routers and establish a direct switched virtual circuit 57 to improve performance when needed. 59 The NHS code replaces the ATMARP code in the ATMARP server. Each NHS 60 serves a set of destination client hosts and cooperates with other 61 NHSs to resolve NHRP next hop requests within their own logical ATM 62 network. The NHC to NHS and NHS to NHS protocol interactions are 63 described in [2]. Other documents in the NHRP series define the 64 general applicability [3] and the transition from ATMARP servers to 65 NHSs [4]. 67 The NHC code replaces the ATMARP code in the local workstations. This 68 code will take the destination IP address and map it into the ATM End 69 Station Address (AESA) for both intra and inter LIS destinations. The 70 returned AESA will be stored in a local cache table. In addition to 71 storing the positive replies, the NHC will need to store the negative 72 replies to avoid making repeated NHS calls when using the routed path. 74 This document describes a base line method for caching the returned 75 information. Other methods may be used as long as the same 76 functionality is provided. 78 4. IP Processing 80 In the Classical IP LIS model [1] the TCP/IP protocol stack treats the 81 ATM network as a simple data link layer protocol. When an application 82 sends data using the Classical IP protocol, IP performs a routing 83 table lookup to determine if the destination is reachable via a local 84 interface or whether an intermediate router is the next hop to the IP 85 destination. 87 If the destination is found to be local (e.g. in the same LIS as the 88 source) the packet will be passed to the local ATM interface with the 89 next hop IP address set to the destination nodes IP address. At this 90 point the ATMARP table will be searched to determine the ATM Address 91 of the destination node. If no ATMARP table entry is found an ATMARP 92 request will be sent to the ATMARP server. This server can reply with 93 a positive (ACK) or negative (NAK) answer depending on the current 94 information it has in its cache. If an ACK is received the host's 95 local ATMARP table is filled in appropriately and the source is now 96 able to send IP datagrams to the destination. If a NAK is returned, 97 the calling application is notified of this error condition (e.g., 98 ICMP destination unreachable). 100 If the destination is found to be remote (e.g., in a different LIS 101 from the source) the IP address of the next hop router is extracted 102 from the IP routing table and the ATM Address of this router is looked 103 up in the ATMARP table. Since the router is in the same LIS as the 104 source node, the ATMARP procedure described above will find the 105 correct ATM Address or the packet will be marked as undeliverable and 106 the user application will be notified of the error. 108 The ATMARP service functions exactly as the existing ARP service 109 provided on Ethernet broadcast networks. Since the ARP service will 110 only try and resolve addresses for nodes that are in a single IP 111 subnet, the ARP table only needs to keep positive answers. No state 112 information is retained about failed mappings. 114 5. NHC Processing 116 In this section we briefly describe what is required in order for a 117 host to take advantage of shortcuts through the ATM network. On the 118 host, a NHC process initiates various NHRP requests in order to obtain 119 access to the NHRP service. Within the ATM subnetwork, the ATMARP 120 server is replaced with a NHS. As defined in [4] the NHS is required 121 to respond to both ATMARP and NHRP Resolution requests. In the nodes 122 wishing to take advantage of shortcut paths across the ATM subnetwork, 123 the ATMARP client code must be replaced with NHC code. This allows 124 the source node to ask for the ATM AESA of both local and remote 125 nodes. Finally the source node must be modified to know when it 126 should ask for the ATM AESA of a remote node and when the local LIS 127 router should be used. These modifications are described in the 128 remainder of this document. 130 The protocol processing described in [2] states a source may query a 131 NHS for the ATM AESA of a destination node. However as is pointed out 132 in [5], to achieve shortcut paths through the ATM network, it is not 133 enough to simply replace the ATMARP client code with the NHC code. 134 This is because the source host will never ask the NHS for the ATM 135 AESA of a node in a remote LIS. When the source consults the IP 136 routing table, it performs the local/remote test, before the NHC code 137 is processed. As a result, the IP address of the next hop router will 138 be used by the NHC instead of the IP address of the remote (inter LIS) 139 host. The NHC code must ignore the result of the IP routing table 140 lookup and perform its own local/remote test. 142 The NHC must perform the following functions: 143 1. Test to see if the destination node is `local' to this LIS. 144 If so use the existing ATMARP rules described in [1]. 145 2. If not test to see if the destination node is able to accept 146 a `shortcut' path. If so save the IP to ATM AESA mapping in 147 the local NHC cache. 148 3. If not; use the routed path and save this state in the NHC 149 cache so future requests don't test for a shortcut again. 150 4. Allow user application to override system default operation 151 and explicitly request a shortcut or routed path for a flow. 153 It is required that this routed path state will be maintained in the 154 same manner as the existing ATMARP service. That is a timer will be 155 used to expire old information and some administrative function exists 156 to manually delete data if needed. 158 6. Need for State 159 It is obvious that the IP to ATM AESA mappings should be maintained in 160 a local cache to improve network performance. This soft state is 161 maintained in today's ARP and ATMARP systems using timers to purge old 162 or unused data. The NHC will maintain both inter and intra LIS IP to 163 ATM Address mappings in the same manner. It may be less obvious that 164 an NHC will also need to maintain this same soft state for inter LIS 165 mappings using the routed path. If this state is not maintained, the 166 source node will send requests to the NHS asking if a shortcut path 167 can be setup every time a packet is sent over the routed path. 168 Some of the features of this state are: 169 1. Cache lookups must be fast as they are done on every packet. 170 2. The cache lookup must be on the destination IP address 171 instead of the next-hop router IP address. 172 3. Both ACK and NAK data should be cached for the length of the 173 holding time parameter in the NHRP response. 175 Since state must be maintained, the questions of where to maintain it, 176 how to manually managed it, and how to selectively override it need to 177 be addressed. No matter where this state information is kept, a 178 method for manually examining and changing this state information must 179 be provided. This is essential to insure that the network is 180 operating properly. 182 There are several possible locations for storing this state 183 information, they are: 184 1. Store state in the `ARP' table. This is the traditional 185 location for this IP to ATM address mappings. This table 186 must be extended to handle the caching of negative (routed 187 path) information. This solution provides a system wide 188 service that may be used by the NHC. 189 2. Store state in the IP routing table. This is the 190 traditional location for the local/remote state information. 191 3. Store state in an ATM MIB structure. This is the 192 traditional location for storing ATM VCC data. It also 193 provides a system wide service that is geared toward ATM 194 services. This avoids munging the 'ARP' table to hold 195 negative data. 196 4. Store state in the TCP Process Control Block. This allows a 197 per process tailoring of shortcut or routed path 198 information. This works well for TCP connections, but not 199 UDP style services. 200 5. Store state in the socket structure. This also allows per 201 process tailoring of the state information. 202 6. Store state in a newly defined table. 204 The NHC should also support both local (per-process) and global (per- 205 system) state. This would allow a system wide default while allowing 206 a specific application to tailor the operation for a specific task. 207 For example assume a site runs both a DNS server and FTP server on a 208 single host. Inter LIS communications to the DNS server should take 209 the routed path to avoid setup overhead. While an FTP session would 210 benefit from the shortcut path to improve performance. Supporting 211 both operations from a single client will require both a global state 212 (e.g. use shortcut for FTP) and a local state (e.g. use routed path 213 for DNS). 215 6.1 Using TCP 217 TCP is a connection orientated protocol that provides per-process 218 state information using a TCP Protocol Control Block (PCB). This PCB 219 can be used to save the shortcut/routed path state information. Using 220 a quad-state flag that shows the USE_SHORT_CUT, TRY_SHORT_CUT, 221 USE_ROUTED_PATH, or TRY_ROUTED_PATH states would allow each process to 222 use the service it chooses. The advantage of this approach is that it 223 allows per flow control over the use of the shortcut or routed path. 224 The disadvantage is that this PCB is only created for TCP connections. 225 UDP connections will only use the system default action. 227 A second option is to store this information in the socket PCB and use 228 the socket function (setsockopt) to save this information. This 229 option will allow both TCP and UDP applications to set a per flow 230 action to override the system default operation. To enable this 231 option, the IP kernel code will need to be modified to allow this 232 quad-state flag to be set. In addition this flag will need to be 233 checked when each packet is sent to determine the if the shortcut or 234 routed path is being used. 236 6.2 Using UDP 238 UDP is a connectionless orientated protocol that doesn't provide any 239 support for state information. It relies on the application to 240 provide the necessary state information. In this case where should 241 the state be stored? The user application could store this itself and 242 pass this down to the kernel in some manner. Another option is to 243 store this information in an ATM MIB structure. A third option is to 244 allow a socket option (setsockopt) that the user application can set 245 to override the default behavior. 247 6.3 Using ICMP 249 In keeping with the tradition of using ICMP echo packets for Internet 250 management functions (e.g. ping, traceroute) then it will be necessary 251 to allow these applications to run over the shortcut and routed paths. 252 The user will need to be able to specify which path to use and a 253 default action needs to be defined too. 255 7. Conclusions 257 NHRP provides new services and functionality for IP nodes using ATM 258 networks. To use these services the client must store state 259 information that describes whether a destination node is reachable via 260 a shortcut or a routed path. 262 The state information should be stored on a global per-application 263 basis with per-process override functionality. This allows short 264 lived functions (e.g. DNS requests) and long lived requests (e.g. ftp 265 sessions) to use different paths. Storing state only based on the 266 destination address means that all processes must use the same path 267 and this creates unreasonable demands on the network. To accomplish 268 this the /etc/services file should be modified to carry a new flag to 269 indicate the per-application default (shortcut vs. routed path) 270 behavior. 272 This state information is required to avoid having the client make a 273 call to the NHS for every packet it sends along the routed path. It 274 is recommended that the IP routing table be modified to support a new 275 flag. This flag will indicate whether the NHS returned an ACK or NAK 276 to the NHRP request. 278 In addition, application programmers and system administrators require 279 the ability to explicitly request a specific service (e.g. use the 280 routed path or shortcut path). This includes the ability to verify 281 network operation by specifying how ICMP echo requests (e.g. ping, 282 traceroute) are handled. The NHC must support the manual setting of 283 this state information. A new socket option that allows the user to 284 specify the operation needs to be supported. 286 To support this capability a new socket option will be created to 287 allow the user application to control the operation of a particular 288 connection (flow). This option will allow the user to specify that a 289 connection use one of the following: 290 1. USE_SYSTEM_DEFAULT. Use the shortcut or routed path based 291 on the system configuration information for this 292 application. (This is the default behavior.) 293 2. USE_SHORT_CUT. If a shortcut path exists, then use it to 294 deliver the data. If it doesn't exist, then try and create 295 it. If the shortcut cannot be created, fail the connection 296 and notify the user. 297 3. TRY_SHORT_CUT. If a shortcut path exists, then use it to 298 deliver the data. If it doesn't exist, then try and create 299 it. If the shortcut cannot be created, try using the routed 300 path. 301 4. USE_ROUTED_PATH. Use the routed path regardless of whether 302 a shortcut exists or not. 303 5. TRY_ROUTED_PATH. If a shortcut doesn't exist, don't try and 304 create it, use the routed path instead. 306 8. Security 308 Some of the security issues are addressed in the other NHRP documents. 309 Some specific questions for the NHC are: 310 * How do we verify the returned ATM Address? Do we need to? 311 [If it is bogus then things don't work right? Is this the 312 same as spoofing? Can I spoof both the ATM Address and IP 313 address of another host?] 315 * Is there a denial of service attack possible? 316 * Are there any problems with having the state stored on a per 317 process bases? 318 * Are there any problems with having the user request/set a 319 specific path? 321 9. Authors Address 323 Richard Carlson 324 Argonne National Laboratory 325 RACarlson@anl.gov 327 Linda Winkler 328 Argonne National Laboratory 329 lwinkler@anl.gov 331 10. References: 333 [1] "Classical IP and ARP over ATM", RFC-2225, M. Laubach J. Halpern, 334 April 1998. 335 [2] "NBMA Next Hop Resolution Protocol (NHRP)", RFC-2332, J. Luciani 336 D. Katz D. Piscitello B. Cole N. Doraswamy, April 1998. 337 [3] "NHRP Protocol Applicability Statement", RFC-2333, D. Cansever, 338 April 1998. 339 [4] "Classical IP to NHRP Transition", RFC-2336, J. Luciani, July 340 1998. 341 [5] "Local/Remote Forwarding Decision in Switched Data link 342 Subnetworks", RFC-1937, Y. Rekhter & D. Kandlur, May 1996.