idnits 2.17.1 draft-ietf-ospf-ara-01.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-26) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 514 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([HEIN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There is 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1475: '... type field MUST be ignored and th...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1997) is 9659 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AF1' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF2' -- Possible downref: Non-RFC (?) normative reference: ref. 'HEIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQ' ** Obsolete normative reference: RFC 2178 (ref. 'OSPF') (Obsoleted by RFC 2328) -- Possible downref: Non-RFC (?) normative reference: ref. 'NHRP' ** Obsolete normative reference: RFC 1587 (ref. 'NSSA') (Obsoleted by RFC 3101) Summary: 17 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft ARA November 1997 4 Expiration Date: May 1998 5 File name: draft-ietf-ospf-ara-01.txt 7 The OSPF Address Resolution Advertisement Option 9 Rob Coltun 10 FORE Systems 11 (301) 571-2521 12 rcoltun@fore.com 14 Juha Heinanen 15 Telecom Finland 16 +358 400 500 958 17 jh@tele.fi 19 Status Of This Memo 21 This document is an Internet-Draft. Internet-Drafts are working docu- 22 ments of the Internet Engineering Task Force (IETF), its areas, and 23 its working groups. Note that other groups may also distribute work- 24 ing documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress". 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 33 Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 36 Table Of Contents 38 1.0 Abstract ................................................. 4 40 2.0 Overview ................................................. 4 42 2.1 Address Resolution Advertisements ........................ 5 44 2.2 ARA Association Table .................................... 5 46 2.3 Logical Network ID List .................................. 5 48 2.4 Routing Table Extensions ................................. 5 50 2.5 Restricting Shortcut Connectivity ........................ 6 52 2.6 Acknowledgments .......................................... 6 54 3.0 A Brief Comparison Of Address Resolution Models .......... 7 56 4.0 ARA Associations ......................................... 8 58 5.0 Examples ................................................. 9 60 5.1 Example 1: Intra-Area .................................... 9 62 5.2 Example 2: Inter-Area .................................... 10 64 5.3 Example 3: Multiple Logical Networks ..................... 11 66 6.0 Description Of ARA Packet Formats ........................ 12 68 6.1 Vertex Types And Vertex Identifiers ...................... 13 70 7.0 Distribution Of ARA Information .......................... 14 72 7.1 Originating Inter-Area ARAs .............................. 15 74 8.0 ARA Routing Table Extensions ............................. 17 76 8.1 Adding ARA Routing Table Extensions ...................... 18 78 8.1.1 Modifications To The Intra-Area Route Calculation ...... 18 80 8.1.2 Modifications To The Inter-Area Route Calculation ...... 19 82 8.1.3 Modifications To The AS External Route Calculation ..... 20 83 9.0 Receiving ARAs ........................................... 21 85 10.0 Additional Data Structures And APIs ..................... 21 87 Appendix A: ARA Packet Formats ............................... 23 89 A.1 The ARA Header ........................................... 23 91 A.2 Intra-Area Router ARA .................................... 26 93 A.3 Intra-Area Network ARA ................................... 27 95 A.4 Inter-Area Router ARA .................................... 28 97 A.5 Inter-Area Network ARA ................................... 30 99 A.6 Vertex Association ....................................... 31 101 A.7 Resolution Information ................................... 32 103 A.7.1 ATM Address ............................................ 34 105 A.7.2 ATM LIJ Call Identification ............................ 35 107 References ................................................... 35 108 1.0 Abstract 110 This document defines an OSPF option to enable routers to distribute 111 IP to link-layer address resolution information. An OSPF Address 112 Resolution Advertisement (ARA) may include media-specific information 113 such as a multipoint-to-point connection identifier along with the 114 address resolution information to support media-specific functions. 115 The ARA option can be used to support router-to-router inter-subnet 116 shortcut architectures such as those described in [HEIN]. 118 2.0 Overview 120 Along with the evolution of switched layer 2 technologies comes the 121 ability to provide inter-subnet shortcut data switching (bypassing 122 router intervention). Before the ingress devices is able to dynami- 123 cally set up the switched path it must have the link-layer address of 124 the egress device. Acquisition of the egress device's link-layer 125 address may be through configuration or through a dynamic mechanism 126 which resolves an IP address (or an IP end-point identifier) to a 127 link-layer address. 129 This document introduces a method for IP to link-layer address resolu- 130 tion to support router-to-router and router-to-network inter-subnet 131 shortcuts. The ARA option supports both topology-derived and data- 132 driven shortcuts architectures with simple extensions to OSPF. Dis- 133 tribution of address resolution information is performed using stan- 134 dard OSPF flooding mechanisms. This document does not define an 135 architecture but is meant to be used with architectures such as those 136 defined in [HEIN]. The ARA option is designed to support the follow- 137 ing operations. 139 Shortcuts between core or access routers within ISP Backbones. 141 Shortcuts in enterprise networks between routers in the same OSPF 142 autonomous system, between OSPF internal routers and autonomous 143 system border routers (ASBR) or between routers and servers. 145 Distributed router architectures. 147 Interoperation with ION NHRP and ATMF MPOA. 149 Inter-subnet multicast shortcuts using LIJ or Point-to-MultiPoint 150 procedures. 152 2.1 Address Resolution Advertisements 154 The ARA option defines a set of link-state advertisements called 155 address resolution advertisements (ARAs). ARAs are used to distribute 156 link-layer information of routers and their directly connected net- 157 works within and between OSPF areas. ARA information is encapsulated 158 in Opaque LSAs (see [OPAQ] for a further description of Opaque LSAs). 159 Three LS Types (LS Type 9, 10 and 11) constitute the Opaque class of 160 link-state advertisements. Each of the three Opaque link-state types 161 have a scope associated with them so that distribution of the informa- 162 tion may be limited appropriately by the originator of the LSA. 163 Because the flooding scope for ARAs is always area local, ARAs are 164 encapsulated in LS Type 10 LSAs. Opaque LSAs have a sub-type which 165 identifies the specific information that is carried within the LSA. 166 ARA uses Opaque-types 1, 2, 3 and 4. See section 6.0 for a further 167 description of the ARA packet formats. 169 2.2 ARA Association Table 171 A router implementing the ARA option maintains a table of link-layer 172 associations for each of its OSPF areas. The ARA Association Table is 173 used in calculating the ARA routing table extensions and by area 174 border routers in the inter-area ARA origination process. The indexes 175 for an entry in this table entry are the Vertex Type, Vertex ID and 176 the Vertex Originator. The Vertex Type identifies the type of IP 177 topology element that the link-layer information is being associated 178 with (i.e., a router or a network). The Vertex ID identifies a piece 179 of the OSPF topology (i.e., a router ID or an IP network number). The 180 Vertex Originator is the ARA originator's Router ID. 182 2.3 Logical Network ID List 184 An ARA capable router maintains a configured list of logical networks 185 IDs. This list represents the logical networks that a router is con- 186 nected to and may be used to restrict the set of devices that the 187 router may setup shortcuts to (see section 2.5 "Restricting Shortcut 188 Connectivity"). The absence of entries in the router's list of Logi- 189 cal Network IDs means that the router will only activate ARA Associa- 190 tion Table entries with the default Logical Network ID (Logical Net- 191 work ID 0). 193 2.4 Routing Table Extensions 195 Associations are added to the routing table during the OSPF routing 196 table calculation (see section 8.1 entitled "Adding ARA Routing Table 197 Extensions"). That is, in addition to the standard information fields 198 contained in the routing table (IP network number, IP mask, next-hop 199 interface, etc.), the routing table is extended to contain link-layer 200 associations. However, only 'active' link-layer associations are 201 added to the routing table. Associations containing a logical network 202 ID that matches a currently enabled entry in the router's list of log- 203 ical network IDs are considered to be active. Both active and non- 204 active link-layer associations may be included in inter-area ARAs that 205 are originated by an ABR. 207 The routing table (and its ARA routing table extensions) must be 208 recalculated if 1) there is a change to the OSPF topology, 2) there is 209 a change to the components in the ARA Association Table (see section 210 9.0 "Receiving ARAs"), or 3) the router's logical network connectivity 211 has changed (e.g., the logical network ID list is modified or the 212 status of the router's connections to one of its logical networks has 213 changed). 215 The use of the routing table extensions are application specific and 216 beyond the scope of this document. See [HEIN] for an example of an 217 ARA user application. 219 2.5 Restricting Shortcut Connectivity 221 As a result of setting up shortcuts in an OSPF topology between ARA- 222 capable routers, the shortcut connectivity may become fully meshed. 223 In many environments this may be desirable whereas in in others this 224 may be undesirable. The ARA option allows for several methods to be 225 used which can limit shortcut connectivity. 227 o [HEIN] proposes that shortcuts are setup by ingress routers 228 only after the sending data rate has passed a configured thres- 229 hold. 231 o ARA-capable routers may choose not to advertise their resolu- 232 tion information until some event has occured. 234 o Routers may be associated with "closed user shortcut groups" so 235 that only routers that are within the same shortcut group may 236 set-up shortcuts to each other. This is done by coordinating the 237 configuration of a router's logical network ID list with the log- 238 ical network ID advertised in ARA associations. 240 2.6 Acknowledgments 242 The author would like to thank Atul Bansal, Lou Berger, Yiqun Cai, 243 John Moy and the rest of the OSPF Working Group for the ideas and sup- 244 port they have given to this project. 246 3.0 A Brief Comparison Of Address Resolution Models 248 Current models of inter-subnet address resolution have taken the form 249 of a query/response protocol as in the case of [NHRP]. In this model 250 the ingress device originates a resolution request which is forwarded 251 hop-by-hop through a series of NHRP servers towards the destination IP 252 address contained in the request. The the last-hop server (the one 253 that is closest to the destination) responds to the request with the 254 link-layer address that it associates with the requested IP address. 255 The address that is returned may be the address of the requested host 256 system or the address of a router which is on the path to the destina- 257 tion. Upon receiving a response to its request, the ingress device 258 sets up a shortcut path to be used for data transfer. The resolution 259 request mechanism has the following characteristics. 261 o Routers and hosts may participate in the request mechanism. 262 The participating devices are discovered through polling. 264 o The request mechanism requires polling by the ingress device to 265 detect topology and reachability changes. Changes in the topology 266 could result in packet loss for the polling interval. Stable 267 routing loops may form as a result of topology changes (given a 268 limited set of failure conditions and topologies). 270 o Requests are unreliable and are subject to packet loss. 272 o It is recommended that the request mechanism be limited to 273 intra-area shortcuts (although with correctly designed topologies 274 this limitation may be over restrictive). 276 o The target of a request may be a host or network addresses 277 (excluding class D (multicast) networks). 279 o The response to the request allows the requesting entity to set 280 up a point-to-point shortcut. 282 Given the above characteristics, the query-response protocol may not 283 be the optimal mechanism for particular applications such as the one 284 described in [HEIN]. The ARA option has the following characteristics. 286 o Only routers participate in the ARA option. A router's 287 participation in the ARA option is discovered through its address 288 resolution advertisements. 290 o The ARA option does not require polling by the ingress device 291 to detect topology and reachability changes. Changes in the 292 topology and system reachability may result in packet loss (or 293 transient loops) for the OSPF convergence time. Additionally, 294 since topology changes are determined as a result of OSPF's SPF 295 calculation (which results in loop-free paths), shortcuts derived 296 from the ARA option can never result in stable routing loops. 298 o Address resolution distribution is reliable and is not subject 299 to packet loss. 301 o The target of ARA derived shortcuts may be routers and and 302 their connected networks within the OSPF autonomous system. 303 Shortcuts are also supported when the destination is associated 304 with an OSPF AS boundary router advertisement (e.g., networks 305 external to the OSPF autonomous system). 307 o The ARA option allows the requesting entity to set up point- 308 to-point shortcuts as well as shortcuts that join point-to- 309 multipoint and multipoint-to-point trees. 311 o Routers that run the ARA option can interoperate with systems 312 running NHRP. 314 o The ARA option may easily be extended to support inter-subnet 315 multicast shortcuts. 317 4.0 ARA Associations 319 The ARA option defines four types of advertisements. These include 1) 320 intra-area router associations, 2) intra-area network associations, 3) 321 inter-area network associations and 3) inter-area autonomous system 322 boundary router (ASBR) associations. Associations correspond to a 323 piece of the OSPF topology. Intra-area router associations correspond 324 to link-layer reachability of a router within the local area, intra- 325 area network associations correspond to the link-layer reachability of 326 a router's directly connected network (also within the local area), 327 inter-area network associations correspond to the link-layer reacha- 328 bility of a remote area router's directly connected network, and 329 inter-area ASBR associations correspond to ASBRs that are in remote 330 OSPF areas. Note that an inter-area network association may be ori- 331 ginated by an area border router (ABR) only if the network is not a 332 component of a configured net range. An ingress router can use these 333 associations as follows. 335 Intra-area router associations are used to setup shortcuts to 336 routers within the local area. Data sent over the shortcut will 337 be forwarded to destinations local to and beyond the router 338 including ones that are in the local area, in a remote area or 339 external to the autonomous system. Destinations that are "beyond 340 the router" are determined by the OSPF topology map. 342 Intra-area network associations (which may advertise hosts or 343 networks) are used to setup intra-area shortcuts to systems whose 344 addresses fall within the range of the advertised network. 346 Inter-area network associations (which may advertise a host or 347 network address) are used to setup inter-area shortcuts to sys- 348 tems whose address fall within the range of the advertised net- 349 work. 351 Inter-area ASBR associations are used to setup shortcuts to ASBRs 352 that are in a remote area. These shortcuts are used to send data 353 to destinations that are external to the autonomous system and 354 reachable via the ASBR. 356 5.0 Examples 358 5.1 Example 1: Intra-Area 360 Consider the sample single-area topology in Figure 1 below. In this 361 example RT1, RT2 and RT5 support the ARA option (by definition they 362 also support the Opaque LSA option) and RT4 supports the Opaque LSA 363 option only (this is necessary so that RT4 redistributes the ARAs ori- 364 ginated by RT1, RT2 and RT5). RT2 and RT5 have each originated a R- 365 ARA with an intra-area router association and RT5 has originated a N- 366 ARA with an intra-area network association for N5. 368 As a result of running the routing table calculation, RT1 has entries 369 for N1-N8 in its routing table. The entry for N2 references the 370 link-layer associations distributed in RT2's R-ARA, the entries for 371 N3, N4, N6, N7, N8 references the link-layer associations distributed 372 in RT5's R-ARA and the entry for N5 references the link-layer associa- 373 tions distributed in RT5's intra-area N-ARA. 375 + ARA 376 | +---+ N3 N5 (ARA) 377 N1|--|RT1|\ \ N4 / 378 | +---+ \ \ | / 379 + \ \|/ 380 \+---+ +---+ 381 |RT4|------------|RT5|ARA 382 +---+ +---+ 383 + ARA / | N7 384 | +---+ / | / 385 N2|--|RT2|/ | / 386 | +---+ +---+ +---+/ 387 + |RT3|-----------|RT6|----N8 388 +---+ +---+ 389 | 390 | 391 +---------+ 392 N6 394 Figure 1: Sample Single-Area Toplogy 396 5.2 Example 2: Inter-Area 398 Consider the sample 2-area topology in Figure 2 below. In this exam- 399 ple RT1, RT2, RT3, RT4, RT6 and RT7 support the ARA option, and RT5 400 supports the Opaque option. N4 is an AS external route (which is 401 flooded to all areas) and RT6 is an ASBR. RT4 is an area-border 402 router and originates an LS Type-4 LSA on behalf of RT6 and a LS 403 Type-3 LSA for N5 into area 1.1.1.1. 405 Within area 1.1.1.1, RT1, RT2, RT3 and RT4 originate intra-area R- 406 ARAs. Within the backbone RT6 and RT7 originate intra-area R-ARAs and 407 R7 originates a N-ARA for N5. All backbone ARAs of have their the P- 408 bit set (this bit informs ABRs that the ARA may be propagated between 409 areas). RT4 originates an inter-area R-ARA for RT6 (which is an ASBR) 410 as well as an inter-area N-ARA for N5 into area 1.1.1.1 RT4 does not 411 originate an inter-area R-ARA for RT7 because it is not an ASBR. 413 As a result of running the routing table calculation, RT1 has entries 414 for N1-N5 in its routing table. The entry for N2 references the 415 link-layer associations distributed in RT3's R-ARA, the entry for N3 416 references the link-layer associations distributed in RT4's intra-area 417 R-ARA, the entry for N4 references the link-layer associations distri- 418 buted in RT4's inter-area R-ARA (indirectly referencing RT6's R-ARA) 419 and the entry for N5 references the link-layer associations 420 distributed in RT4's inter-area N5 N-ARA. 422 + ARA ARA | 423 | +---+ +---+ | 424 N1|--|RT1|----|RT2|\ | N3 N4 1519 [IS] S. Shenker and J. Wroclawski. "Network Element QoS Control 1520 Service Specification Template". Internet Draft, July 1996, 1523 [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", Internet Draft 1524 May 1997, 1526 [OSPF] Moy, J., "OSPF Version 2", RFC 2178, July 1997 1528 [NHRP] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA 1529 Next-Hop Resolution Protocol", Internet Draft, March 1997, 1530 1532 [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 1533 RainbowBridge Communications, Stanford University, March 1994.