Internet-Draft ARA November 1997 Expiration Date: May 1998 File name: draft-ietf-ospf-ara-01.txt The OSPF Address Resolution Advertisement Option Rob Coltun FORE Systems (301) 571-2521 rcoltun@fore.com Juha Heinanen Telecom Finland +358 400 500 958 jh@tele.fi Status Of This Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Coltun, Heinanen [Page 1] Internet-Draft ARA November 1997 Table Of Contents 1.0 Abstract ................................................. 4 2.0 Overview ................................................. 4 2.1 Address Resolution Advertisements ........................ 5 2.2 ARA Association Table .................................... 5 2.3 Logical Network ID List .................................. 5 2.4 Routing Table Extensions ................................. 5 2.5 Restricting Shortcut Connectivity ........................ 6 2.6 Acknowledgments .......................................... 6 3.0 A Brief Comparison Of Address Resolution Models .......... 7 4.0 ARA Associations ......................................... 8 5.0 Examples ................................................. 9 5.1 Example 1: Intra-Area .................................... 9 5.2 Example 2: Inter-Area .................................... 10 5.3 Example 3: Multiple Logical Networks ..................... 11 6.0 Description Of ARA Packet Formats ........................ 12 6.1 Vertex Types And Vertex Identifiers ...................... 13 7.0 Distribution Of ARA Information .......................... 14 7.1 Originating Inter-Area ARAs .............................. 15 8.0 ARA Routing Table Extensions ............................. 17 8.1 Adding ARA Routing Table Extensions ...................... 18 8.1.1 Modifications To The Intra-Area Route Calculation ...... 18 8.1.2 Modifications To The Inter-Area Route Calculation ...... 19 8.1.3 Modifications To The AS External Route Calculation ..... 20 Coltun, Heinanen [Page 2] Internet-Draft ARA November 1997 9.0 Receiving ARAs ........................................... 21 10.0 Additional Data Structures And APIs ..................... 21 Appendix A: ARA Packet Formats ............................... 23 A.1 The ARA Header ........................................... 23 A.2 Intra-Area Router ARA .................................... 26 A.3 Intra-Area Network ARA ................................... 27 A.4 Inter-Area Router ARA .................................... 28 A.5 Inter-Area Network ARA ................................... 30 A.6 Vertex Association ....................................... 31 A.7 Resolution Information ................................... 32 A.7.1 ATM Address ............................................ 34 A.7.2 ATM LIJ Call Identification ............................ 35 References ................................................... 35 Coltun, Heinanen [Page 3] Internet-Draft ARA November 1997 1.0 Abstract This document defines an OSPF option to enable routers to distribute IP to link-layer address resolution information. An OSPF Address Resolution Advertisement (ARA) may include media-specific information such as a multipoint-to-point connection identifier along with the address resolution information to support media-specific functions. The ARA option can be used to support router-to-router inter-subnet shortcut architectures such as those described in [HEIN]. 2.0 Overview Along with the evolution of switched layer 2 technologies comes the ability to provide inter-subnet shortcut data switching (bypassing router intervention). Before the ingress devices is able to dynami- cally set up the switched path it must have the link-layer address of the egress device. Acquisition of the egress device's link-layer address may be through configuration or through a dynamic mechanism which resolves an IP address (or an IP end-point identifier) to a link-layer address. This document introduces a method for IP to link-layer address resolu- tion to support router-to-router and router-to-network inter-subnet shortcuts. The ARA option supports both topology-derived and data- driven shortcuts architectures with simple extensions to OSPF. Dis- tribution of address resolution information is performed using stan- dard OSPF flooding mechanisms. This document does not define an architecture but is meant to be used with architectures such as those defined in [HEIN]. The ARA option is designed to support the follow- ing operations. Shortcuts between core or access routers within ISP Backbones. Shortcuts in enterprise networks between routers in the same OSPF autonomous system, between OSPF internal routers and autonomous system border routers (ASBR) or between routers and servers. Distributed router architectures. Interoperation with ION NHRP and ATMF MPOA. Inter-subnet multicast shortcuts using LIJ or Point-to-MultiPoint procedures. Coltun, Heinanen [Page 4] Internet-Draft ARA November 1997 2.1 Address Resolution Advertisements The ARA option defines a set of link-state advertisements called address resolution advertisements (ARAs). ARAs are used to distribute link-layer information of routers and their directly connected net- works within and between OSPF areas. ARA information is encapsulated in Opaque LSAs (see [OPAQ] for a further description of Opaque LSAs). Three LS Types (LS Type 9, 10 and 11) constitute the Opaque class of link-state advertisements. Each of the three Opaque link-state types have a scope associated with them so that distribution of the informa- tion may be limited appropriately by the originator of the LSA. Because the flooding scope for ARAs is always area local, ARAs are encapsulated in LS Type 10 LSAs. Opaque LSAs have a sub-type which identifies the specific information that is carried within the LSA. ARA uses Opaque-types 1, 2, 3 and 4. See section 6.0 for a further description of the ARA packet formats. 2.2 ARA Association Table A router implementing the ARA option maintains a table of link-layer associations for each of its OSPF areas. The ARA Association Table is used in calculating the ARA routing table extensions and by area border routers in the inter-area ARA origination process. The indexes for an entry in this table entry are the Vertex Type, Vertex ID and the Vertex Originator. The Vertex Type identifies the type of IP topology element that the link-layer information is being associated with (i.e., a router or a network). The Vertex ID identifies a piece of the OSPF topology (i.e., a router ID or an IP network number). The Vertex Originator is the ARA originator's Router ID. 2.3 Logical Network ID List An ARA capable router maintains a configured list of logical networks IDs. This list represents the logical networks that a router is con- nected to and may be used to restrict the set of devices that the router may setup shortcuts to (see section 2.5 "Restricting Shortcut Connectivity"). The absence of entries in the router's list of Logi- cal Network IDs means that the router will only activate ARA Associa- tion Table entries with the default Logical Network ID (Logical Net- work ID 0). 2.4 Routing Table Extensions Associations are added to the routing table during the OSPF routing table calculation (see section 8.1 entitled "Adding ARA Routing Table Coltun, Heinanen [Page 5] Internet-Draft ARA November 1997 Extensions"). That is, in addition to the standard information fields contained in the routing table (IP network number, IP mask, next-hop interface, etc.), the routing table is extended to contain link-layer associations. However, only 'active' link-layer associations are added to the routing table. Associations containing a logical network ID that matches a currently enabled entry in the router's list of log- ical network IDs are considered to be active. Both active and non- active link-layer associations may be included in inter-area ARAs that are originated by an ABR. The routing table (and its ARA routing table extensions) must be recalculated if 1) there is a change to the OSPF topology, 2) there is a change to the components in the ARA Association Table (see section 9.0 "Receiving ARAs"), or 3) the router's logical network connectivity has changed (e.g., the logical network ID list is modified or the status of the router's connections to one of its logical networks has changed). The use of the routing table extensions are application specific and beyond the scope of this document. See [HEIN] for an example of an ARA user application. 2.5 Restricting Shortcut Connectivity As a result of setting up shortcuts in an OSPF topology between ARA- capable routers, the shortcut connectivity may become fully meshed. In many environments this may be desirable whereas in in others this may be undesirable. The ARA option allows for several methods to be used which can limit shortcut connectivity. o [HEIN] proposes that shortcuts are setup by ingress routers only after the sending data rate has passed a configured thres- hold. o ARA-capable routers may choose not to advertise their resolu- tion information until some event has occured. o Routers may be associated with "closed user shortcut groups" so that only routers that are within the same shortcut group may set-up shortcuts to each other. This is done by coordinating the configuration of a router's logical network ID list with the log- ical network ID advertised in ARA associations. 2.6 Acknowledgments The author would like to thank Atul Bansal, Lou Berger, Yiqun Cai, Coltun, Heinanen [Page 6] Internet-Draft ARA November 1997 John Moy and the rest of the OSPF Working Group for the ideas and sup- port they have given to this project. 3.0 A Brief Comparison Of Address Resolution Models Current models of inter-subnet address resolution have taken the form of a query/response protocol as in the case of [NHRP]. In this model the ingress device originates a resolution request which is forwarded hop-by-hop through a series of NHRP servers towards the destination IP address contained in the request. The the last-hop server (the one that is closest to the destination) responds to the request with the link-layer address that it associates with the requested IP address. The address that is returned may be the address of the requested host system or the address of a router which is on the path to the destina- tion. Upon receiving a response to its request, the ingress device sets up a shortcut path to be used for data transfer. The resolution request mechanism has the following characteristics. o Routers and hosts may participate in the request mechanism. The participating devices are discovered through polling. o The request mechanism requires polling by the ingress device to detect topology and reachability changes. Changes in the topology could result in packet loss for the polling interval. Stable routing loops may form as a result of topology changes (given a limited set of failure conditions and topologies). o Requests are unreliable and are subject to packet loss. o It is recommended that the request mechanism be limited to intra-area shortcuts (although with correctly designed topologies this limitation may be over restrictive). o The target of a request may be a host or network addresses (excluding class D (multicast) networks). o The response to the request allows the requesting entity to set up a point-to-point shortcut. Given the above characteristics, the query-response protocol may not be the optimal mechanism for particular applications such as the one described in [HEIN]. The ARA option has the following characteristics. o Only routers participate in the ARA option. A router's Coltun, Heinanen [Page 7] Internet-Draft ARA November 1997 participation in the ARA option is discovered through its address resolution advertisements. o The ARA option does not require polling by the ingress device to detect topology and reachability changes. Changes in the topology and system reachability may result in packet loss (or transient loops) for the OSPF convergence time. Additionally, since topology changes are determined as a result of OSPF's SPF calculation (which results in loop-free paths), shortcuts derived from the ARA option can never result in stable routing loops. o Address resolution distribution is reliable and is not subject to packet loss. o The target of ARA derived shortcuts may be routers and and their connected networks within the OSPF autonomous system. Shortcuts are also supported when the destination is associated with an OSPF AS boundary router advertisement (e.g., networks external to the OSPF autonomous system). o The ARA option allows the requesting entity to set up point- to-point shortcuts as well as shortcuts that join point-to- multipoint and multipoint-to-point trees. o Routers that run the ARA option can interoperate with systems running NHRP. o The ARA option may easily be extended to support inter-subnet multicast shortcuts. 4.0 ARA Associations The ARA option defines four types of advertisements. These include 1) intra-area router associations, 2) intra-area network associations, 3) inter-area network associations and 3) inter-area autonomous system boundary router (ASBR) associations. Associations correspond to a piece of the OSPF topology. Intra-area router associations correspond to link-layer reachability of a router within the local area, intra- area network associations correspond to the link-layer reachability of a router's directly connected network (also within the local area), inter-area network associations correspond to the link-layer reacha- bility of a remote area router's directly connected network, and inter-area ASBR associations correspond to ASBRs that are in remote OSPF areas. Note that an inter-area network association may be ori- ginated by an area border router (ABR) only if the network is not a component of a configured net range. An ingress router can use these associations as follows. Coltun, Heinanen [Page 8] Internet-Draft ARA November 1997 Intra-area router associations are used to setup shortcuts to routers within the local area. Data sent over the shortcut will be forwarded to destinations local to and beyond the router including ones that are in the local area, in a remote area or external to the autonomous system. Destinations that are "beyond the router" are determined by the OSPF topology map. Intra-area network associations (which may advertise hosts or networks) are used to setup intra-area shortcuts to systems whose addresses fall within the range of the advertised network. Inter-area network associations (which may advertise a host or network address) are used to setup inter-area shortcuts to sys- tems whose address fall within the range of the advertised net- work. Inter-area ASBR associations are used to setup shortcuts to ASBRs that are in a remote area. These shortcuts are used to send data to destinations that are external to the autonomous system and reachable via the ASBR. 5.0 Examples 5.1 Example 1: Intra-Area Consider the sample single-area topology in Figure 1 below. In this example RT1, RT2 and RT5 support the ARA option (by definition they also support the Opaque LSA option) and RT4 supports the Opaque LSA option only (this is necessary so that RT4 redistributes the ARAs ori- ginated by RT1, RT2 and RT5). RT2 and RT5 have each originated a R- ARA with an intra-area router association and RT5 has originated a N- ARA with an intra-area network association for N5. As a result of running the routing table calculation, RT1 has entries for N1-N8 in its routing table. The entry for N2 references the link-layer associations distributed in RT2's R-ARA, the entries for N3, N4, N6, N7, N8 references the link-layer associations distributed in RT5's R-ARA and the entry for N5 references the link-layer associa- tions distributed in RT5's intra-area N-ARA. Coltun, Heinanen [Page 9] Internet-Draft ARA November 1997 + ARA | +---+ N3 N5 (ARA) N1|--|RT1|\ \ N4 / | +---+ \ \ | / + \ \|/ \+---+ +---+ |RT4|------------|RT5|ARA +---+ +---+ + ARA / | N7 | +---+ / | / N2|--|RT2|/ | / | +---+ +---+ +---+/ + |RT3|-----------|RT6|----N8 +---+ +---+ | | +---------+ N6 Figure 1: Sample Single-Area Toplogy 5.2 Example 2: Inter-Area Consider the sample 2-area topology in Figure 2 below. In this exam- ple RT1, RT2, RT3, RT4, RT6 and RT7 support the ARA option, and RT5 supports the Opaque option. N4 is an AS external route (which is flooded to all areas) and RT6 is an ASBR. RT4 is an area-border router and originates an LS Type-4 LSA on behalf of RT6 and a LS Type-3 LSA for N5 into area 1.1.1.1. Within area 1.1.1.1, RT1, RT2, RT3 and RT4 originate intra-area R- ARAs. Within the backbone RT6 and RT7 originate intra-area R-ARAs and R7 originates a N-ARA for N5. All backbone ARAs of have their the P- bit set (this bit informs ABRs that the ARA may be propagated between areas). RT4 originates an inter-area R-ARA for RT6 (which is an ASBR) as well as an inter-area N-ARA for N5 into area 1.1.1.1 RT4 does not originate an inter-area R-ARA for RT7 because it is not an ASBR. As a result of running the routing table calculation, RT1 has entries for N1-N5 in its routing table. The entry for N2 references the link-layer associations distributed in RT3's R-ARA, the entry for N3 references the link-layer associations distributed in RT4's intra-area R-ARA, the entry for N4 references the link-layer associations distri- buted in RT4's inter-area R-ARA (indirectly referencing RT6's R-ARA) and the entry for N5 references the link-layer associations Coltun, Heinanen [Page 10] Internet-Draft ARA November 1997 distributed in RT4's inter-area N5 N-ARA. + ARA ARA | | +---+ +---+ | N1|--|RT1|----|RT2|\ | N3 N4 [IS] S. Shenker and J. Wroclawski. "Network Element QoS Control Service Specification Template". Internet Draft, July 1996, [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", Internet Draft May 1997, [OSPF] Moy, J., "OSPF Version 2", RFC 2178, July 1997 [NHRP] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA Next-Hop Resolution Protocol", Internet Draft, March 1997, [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. Coltun, Heinanen [Page 36]