idnits 2.17.1 draft-ietf-rolc-apr-03.txt: 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-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity. ** 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 1 longer page, the longest (page 1) being 578 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 246 has weird spacing: '... a peer on a ...' == Line 247 has weird spacing: '...owledge of th...' -- 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.) -- The document date (November 1995) is 10389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Postel 81' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC1620' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC1755' is defined on line 398, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LANE' -- Possible downref: Non-RFC (?) normative reference: ref. 'Postel 81' ** Obsolete normative reference: RFC 1577 (Obsoleted by RFC 2225) ** Downref: Normative reference to an Informational RFC: RFC 1620 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Yakov Rekhter 2 Cisco Systems 3 Dilip Kandlur 4 T.J. Watson Research Center, IBM Corp. 5 Curtis Villamizar 6 ANS 7 November 1995 9 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 Please check the 1id-abstracts.txt listing contained in the 26 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 27 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 28 current status of any Internet Draft. 30 Abstract 32 The IP architecture assumes that each Data Link subnetwork is labeled 33 with a single IP subnet number. A pair of hosts with the same subnet 34 number communicate directly (with no routers); a pair of hosts with 35 different subnet numbers always communicate through one or more 36 routers. As indicated in RFC1620, these assumptions may be too 38 Expiration Date May 1996 [Page 1]FORMFEED 39 restrictive for large data networks, and specifically for networks 40 based on switched virtual circuit (SVC) based technologies (e.g. ATM, 41 Frame Relay, X.25), as these assumptions impose constraints on 42 communication among hosts and routers through a network. The 43 restrictions may preclude full utilization of the capabilities 44 provided by the underlying SVC-based Data Link subnetwork. This 45 document describes extensions to the IP architecture that relaxes 46 these constraints, thus enabling the full utilization of the services 47 provided by SVC-based Data Link subnetworks. 49 1 Background 51 The following briefly recaptures the concept of the IP Subnet. The 52 topology is assumed to be composed of hosts and routers 53 interconnected via links (Data Link subnetworks). An IP address of a 54 host with an interface attached to a particular link is a tuple 55 , where host number is 56 unique within the subnet address prefix. When a host needs to send 57 an IP packet to a destination, the host needs to determine whether 58 the destination address identifies an interface that is connected to 59 one of the links the host is attached to, or not. This referred to 60 as the "local/remote" decision. The outcome of the "local/remote" 61 decision is based on (a) the destination address, and (b) the address 62 and the prefix length associated with the the local interfaces. If 63 the outcome is "local", then the host resolves IP address to Link 64 Layer address (e.g. by using ARP), and then sends the packet directly 65 to that destination (using the Link layer services). If the outcome 66 is "remote", then the host uses one of its first-hop routers (thus 67 relying on the services provided by IP routing). 69 To summarize, two of the important attributes of the IP subnet model 70 are: 72 hosts with a common subnet address prefix are assumed to be 73 attached to a common link (subnetwork), and thus communicate with 74 each other directly, without any routers - "local"; 76 hosts with different subnet address prefixes are assumed to be 77 attached to different links (subnetworks), and thus communicate 79 Expiration Date May 1996 [Page 2]FORMFEED 80 with each other only through routers - "remote". 82 A typical example of applying the IP subnet architecture to an SVC- 83 based Data Link subnetwork is "Classical IP and ARP over ATM" 84 (RFC1577). RFC1577 provides support for ATM deployment that follows 85 the traditional IP subnet model and introduces the notion of a 86 Logical IP Subnetwork (LIS). The consequence of this model is that a 87 host is required to setup an ATM SVC to any host within its LIS; for 88 destinations outside its LIS the host must forward packets through a 89 router. It is important to stress that this "local/remote" decision 90 is based solely on the information carried by the destination address 91 and the address and prefix lengths associated with the local 92 interfaces. 94 2 Motivations 96 The diversity of TCP/IP applications results in a wide range of 97 traffic characteristics. Some applications last for a very short 98 time and generate only a small number of packets between a pair of 99 communicating hosts (e.g. ping, DNS). Other applications have a short 100 lifetime, but generate a relatively large volume of packets (e.g. 101 FTP). There are also applications that have a relatively long 102 lifetime, but generate relatively few packets (e.g. Telnet). 103 Finally, we anticipate the emergence of applications that have a 104 relatively long lifetime and generate a large volume of packets (e.g. 105 video-conferencing). 107 SVC-based Data Link subnetworks offer certain unique capabilities 108 that are not present in other (non-SVC) subnetworks (e.g. Ethernet, 109 Token Ring). The ability to dynamically establish and tear-down SVCs 110 between communicating entities attached to an SVC-based Data Link 111 subnetwork enables the dynamic dedication and redistribution of 112 certain communication resources (e.g. bandwidth) among the entities. 113 This dedication and redistribution of resources could be accomplished 114 by relying solely on the mechanism(s) provided by the Data Link 115 layer. 117 The unique capabilities provided by SVC-based Data Link subnetworks 119 Expiration Date May 1996 [Page 3]FORMFEED 120 do not come "for free". The mechanisms that provide dedication and 121 redistribution of resources have certain overhead (e.g. the time 122 needed to establish an SVC, resources associated with maintaining a 123 state for an SVC). There may also be a monetary cost associated with 124 establishing and maintaining an SVC. Therefore, it is very important 125 to be cognizant of such an overhead and to carefully balance the 126 benefits provided by the mechanisms against the overhead introduced 127 by such mechanisms. 129 One of the key issues for using SVC-based Data Link subnetworks in 130 the TCP/IP environment is the issue of switched virtual circuit (SVC) 131 management. This includes SVC establishment and tear-down, class of 132 service specification, and SVC sharing. At one end of the spectrum 133 one could require SVC establishment between communicating entities 134 (on a common Data Link subnetwork) for any application. At the other 135 end of the spectrum, one could require communicating entities to 136 always go through a router, regardless of the application. Given the 137 diversity of TCP/IP applications, either extreme is likely to yield a 138 suboptimal solution with respect to the ability to efficiently 139 exploit capabilities provided by the underlying Data Link layer. 141 The traditional IP subnet model is too restrictive for flexible and 142 adaptive use of SVC-based Data Link subnetworks - the use of a 143 subnetwork is driven by information completely unrelated to the 144 characteristics of individual applications. To illustrate the 145 problem consider "Classical IP and ARP over ATM" (RFC1577). RFC1577 146 provides support for ATM deployment that follows the traditional IP 147 subnet model, and introduces the notion of a Logical IP Subnetwork 148 (LIS). The consequence of this model is that a host is required to 149 setup an SVC to any host within its LIS, and it must forward packets 150 to destinations outside its LIS through a router. This 151 "local/remote" forwarding decision is based solely on the information 152 carried in the source and destination addresses and the subnet mask 153 associated with the source address, and has no relation to the nature 154 of the applications that generated these packets. This leads to a 155 situation where SVC management is controlled by totally irrelevant 156 factors. 158 Expiration Date May 1996 [Page 4]FORMFEED 159 3 QoS/Traffic Driven "Local/Remote" Decision 161 Consider a host attached to an SVC-based Data Link subnetwork, and 162 assume that the "local/remote" decision the host could make is not 163 constrained by the IP subnet model. When such a host needs to send a 164 packet to a destination, the host might consider any of the following 165 options: 167 Use a best-effort SVC to the first hop router. 169 Use a SVC to the first hop router dedicated to a particular type 170 of service (ie: predictive real time). 172 Use a dedicated SVC to the first hop router. 174 Use a best-effort SVC to a router closer to the destination than 175 the first hop router. 177 Use a SVC to a router closer to the destination than the first hop 178 router dedicated to a particular type of service. 180 Use a dedicated SVC to a router closer to the destination than the 181 first hop router. 183 Use a best-effort SVC directly to the destination (if the 184 destination is on the same Data Link subnetwork as the host). 186 Use a SVC directly to the destination dedicated to a particular 187 type of service (if the destination is on the same Data Link 188 subnetwork as the host). 190 Use a dedicated SVC directly to the destination (if the 191 destination is on the same Data Link subnetwork as the host). 193 We may observe that the forwarding decision at the host is more 194 flexible than the "local/remote" decision of the IP subnet model. We 195 may also observe that the host's forwarding decision allows to take 196 into account QoS and/or traffic requirements of the applications 197 and/or cost factors associated with establishing and maintaining a 198 VC, and thus improve the overall SVC management. Therefore, removing 200 Expiration Date May 1996 [Page 5]FORMFEED 201 constraints imposed by the IP subnet model is an important step 202 towards better SVC management. 204 3.1 Extending the scope of possible "local" outcomes 206 A source may have a SVC (either dedicated or shared) to a destination 207 if both the source and the destination are on a common Data Link 208 subnetwork. The ability to have the SVC (either dedicated or shared) 209 is completely decoupled from the source and destination IP addresses, 210 but is coupled to the QoS and/or traffic characteristics of the 211 application. In other words, the ability to establish a direct VC 212 (either dedicated or shared) between a pair of hosts on a common Data 213 Link subnetwork has nothing to do with the IP addresses of the hosts. 214 In contrast with the IP subnet model (or the LIS mode), the "local" 215 outcome becomes divorced from the addressing information. 217 3.2 Allowing the "remote" outcome where applicable 219 A source may go through one or more routers to reach a destination if 220 either (a) the destination is not on the same Data Link subnetwork as 221 the source, or (b) the destination is on the same Data Link 222 subnetwork as the source, but the QoS and/or traffic requirements of 223 the application on the source do not justify a direct (either 224 dedicated or shared) VC. 226 When the destination is not on the same Data Link subnetwork as the 227 source, the source could select between either (a) using its first- 228 hop (default) router, or (b) establishing a "shortcut" to a router 229 closer to the destination than the first-hop router. The source 230 should be able to select between these two choices irrespective of 231 the source and destination IP addresses. 233 When the destination is on the same Data Link subnetwork as the 234 source, but the QoS and/or traffic requirements do not justify a 235 direct VC, the source should be able to go through a router 236 irrespective of the source and destination IP addresses. 238 Expiration Date May 1996 [Page 6]FORMFEED 239 In contrast with the IP subnet model (or the LIS model) the "remote" 240 outcome, and its particular option (first-hop router vs router closer 241 to the destination than the first-hop router), becomes divorced from 242 the addressing information. 244 3.3 Sufficient conditions for direct connectivity 246 The ability of a host to establish an SVC to a peer on a common 247 switched Data Link subnetwork is predicated on its knowledge of the 248 Link Layer address of the peer or an intermediate point closer to the 249 destination. This document assumes the existence of mechanism(s) 250 that can provide the host with this information. Some of the possible 251 alternatives are NHRP, ARP, or static configuration; other 252 alternatives are not precluded. The ability to acquire the Link 253 Layer address of the peer should not be viewed as an indication that 254 the host and the peer can establish an SVC - the two may be on 255 different Data Link subnetworks, or may be on a common Data Link 256 subnetwork that is partitioned. 258 3.4 Some of the implications 260 Since the "local/remote" decision would depend on factors other than 261 the addresses of the source and the destination, a pair of hosts may 262 simultaneously be using two different means to reach each other, 263 forwarding traffic for applications with different QoS/and or traffic 264 characteristics differently. 266 3.5 Address assignment 268 It is expected that if the total number of hosts and routers on a 269 common SVC-based Data Link subnetwork is sufficiently large, then the 270 hosts and routers could be partitioned into groups, where each group 271 would have hosts and routers. The routers within a group would act as 272 the first-hop routers for the hosts in the group. If the total number 273 of hosts and routers is not large, then all these hosts and routers 275 Expiration Date May 1996 [Page 7]FORMFEED 276 could form a single group. Criteria for determining group sizes are 277 outside the scope of this document. 279 To provide scalable routing each group should be given an IP address 280 prefix, and elements within the group should be assigned addresses 281 out of this prefix. The routers in a group would then advertise (via 282 appropriate routing protocols) routes to the prefix associated with 283 the group. These routes would be advertised as "directly reachable" 284 (with metric 0). Thus, routers within a group would act as the last- 285 hop routers for the hosts within the group. 287 3.6 Using Point to Point Links 289 If RFC1577 is used as an underlying model, the router based overlay 290 is assumed to be comprised of LIS. The LIS model may not be 291 appropriate for some situation. A large group may be served by a 292 single router or a small number of routers to provide some 293 redundancy. 295 The desired behavior can be accomplished using RFC1577 LIS by 296 allowing the LIS to become very small, containing two hosts each and 297 relaxing the restriction prohibiting shortcut VC. If the all zeros 298 network address is to be reserved, a four address LIS is needed for 299 each host in the group. ATM ARP service is also needed. The LIS 300 model clearly has some inefficiencies for such a case. 302 An alternate way to model the relation among hosts and routers within 303 each group is by modelling VC as point to point links. Using 304 numbered point to point links, the two addreses on the link need not 305 be adjacent. If each end of the link has a distinct address, the 306 model is a numbered point to point link. A router may allow the use 307 of a single address for the entire router, reusing the same address 308 as the near end of all of the point to point connections. Similarly, 309 a host can use a single address for point to point links to more than 310 one router, if a backup router is used. This model is an unnumbered 311 point to point link, unnumbered since the link endpoints are not 312 uniquely numbered, just the nodes. For SNMP manageability, on 313 unnumbered point to point links, the far end address can be used for 315 Expiration Date May 1996 [Page 8]FORMFEED 316 identification of a link. 318 4 Conclusions 320 Different approaches to SVC-based Data Link subnetworks used by 321 TCP/IP yield substantially different results with respect to the 322 ability of TCP/IP applications to efficiently exploit the 323 functionality provided by such subnetworks. For example, in the case 324 of ATM both LAN Emulation [LANE] and "classical" IP over ATM 325 [RFC1577] localize host changes below the IP layer, and therefore may 326 be good first steps in the ATM deployment. However, these approaches 327 alone are likely to be inadequate for the full utilization of ATM. 329 It appears that any model that does not allow SVC management based on 330 QoS and/or traffic requirements will preempt the full use of SVC- 331 based Data Link subnetworks. Enabling more direct connectivity for 332 applications that could benefit from the functionality provided by 333 SVC-based Data Link subnetworks, while relying on strict hop by hop 334 paths for other applications, could facilitate exploration of the 335 capabilities provided by the subnetworks. 337 While this document does not define any specific coupling between 338 various QoS, traffic characteristics and other parameters, and SVC 339 management, it is important to stress that efforts towards 340 standardization of various QoS, traffic characteristics, and other 341 parameters than an application could use (through an appropriate API) 342 to influence SVC management are essential for flexible and adaptive 343 use of SVC-based Data Link subnetworks. 345 The proposed model utilizes the SVC-based infrastructure for the 346 applications that could benefit from the capabilities supported 347 within such an infrastructure, and take advantage of a based router- 348 based overlay for all other applications. The router based overlay 349 could be based on RFC1577 if the restriction prohibiting subnet 350 shortcut connections is eliminated from RFC1577, replacing it with a 351 statement that any shortcut requires mechanisms beyond what is 352 described in RFC1577. Use of a point to point model is suggested as 353 an alternate to the LIS model for situations where the NBMA LIS model 354 simply does not fit. As such it provides a balanced mix of router- 356 Expiration Date May 1996 [Page 9]FORMFEED 357 based and switch-based infrastructures, where the balance could be 358 determined by the applications requirements. 360 The approach proposed in this document combines switch-based 361 infrastructure with router-based overlay and uses each for that which 362 it is best suited: switch-based infrastructure for applications that 363 can justify an SVC establishment; router-based overlay for all other 364 applications. 366 6 Security Considerations 368 Security issues are not discussed in this document. 370 7 Acknowledgements 372 The authors would like to thank Joel Halpern (NewBridge), Allison 373 Mankin (ISI), Tony Li (cisco Systems), Andrew Smith (BayNetworks) for 374 their review and comments. 376 References 378 [LANE] "LAN Emulation over ATM specification- version 1", ATM Forum, 379 Feb.95. 381 [Postel 81] Postel, J., Sunshine, C., Cohen, D., "The ARPA Internet 382 Protocol", Computer Networks, 5, pp. 261-271, 1983. 384 [RFC792] Postel, J., "Internet Control Message Protocol- DARPA 385 Internet Program Protocol Specification", STD 5, RFC 792, ISI, 386 September 1981. 388 [RFC1122] Braden, R., Editor, "Requirements for Internet Hosts - 389 Communication Layers", STD 3, RFC 1122, USC/ISI, October 1989. 391 Expiration Date May 1996 [Page 10]FORMFEED 393 [RFC1577] Laubach, M., "Classical IP and ARP over ATM", January 1994. 395 [RFC1620] Braden, B., Postel, J., Rekhter, Y., Internet Architecture 396 Extensions for Shared Media", May 1994. 398 [RFC1755] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., 399 Malis, A., "ATM Signalling Support for IP over ATM", January 1995. 401 14 Authors' Address 403 Yakov Rekhter 404 Cisco Systems 405 170 West Tasman Drive, 406 San Jose, CA 95134-1706 407 Phone: (914) 528-0090 408 email: yakov@cisco.com 410 Dilip Kandlur 411 T.J. Watson Research Center IBM Corporation 412 P.O. Box 704 413 Yorktown Heights, NY 10598 414 Phone: (914) 784-7722 415 email: kandlur@watson.ibm.com 417 Curtis Villamizar 418 ANS 419 100 Clearbrook Road 420 Elmsford, N.Y. 10523 421 email: curtis@ans.net 423 Expiration Date May 1996 [Page 11]FORMFEED