Internet-Draft ARA March 1998 Expiration Date: May 1998 File name: draft-ietf-ospf-ara-02.txt The OSPF Address Resolution Advertisement Option Rob Coltun FORE Systems (703) 245-4543 rcoltun@fore.com Juha Heinanen Telia Finland, Inc. +358 303 944 808 jh@telia.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 March 1998 Table Of Contents 1.0 Abstract ................................................. 4 2.0 Overview ................................................. 4 2.1 Acknowledgments .......................................... 5 3.0 Examples ................................................. 6 3.1 Example 1: Intra-Area .................................... 6 3.2 Example 2: Inter-Area .................................... 7 3.3 Example 3: Multiple Logical Networks ..................... 8 4.0 A Brief Comparison Of Address Resolution Models .......... 9 5.0 ARA Components ........................................... 11 5.1 Address Resolution Advertisements ........................ 11 5.2 ARA Association Table .................................... 11 5.3 Logical Network ID List .................................. 12 5.4 Routing Table Extensions ................................. 12 5.5 Restricting Shortcut Connectivity ........................ 12 6.0 ARA Associations ......................................... 13 7.0 Description Of ARA Packet Formats ........................ 14 7.1 Vertex Types And Vertex Identifiers ...................... 14 8.0 Distribution Of ARA Information .......................... 15 8.1 Originating Inter-Area ARAs .............................. 17 9.0 ARA Routing Table Extensions ............................. 19 9.1 Adding ARA Routing Table Extensions ...................... 20 9.1.1 Modifications To The Intra-Area Route Calculation ...... 20 9.1.2 Modifications To The Inter-Area Route Calculation ...... 21 Coltun, Heinanen [Page 2] Internet-Draft ARA March 1998 9.1.3 Modifications To The AS External Route Calculation ..... 22 9.2 Routing Table Extension Completion ....................... 23 10.0 Receiving ARAs .......................................... 24 11.0 Additional Data Structures And APIs ..................... 24 12.0 Security Considerations ................................. 24 Appendix A: ARA Packet Formats ............................... 27 A.1 The ARA Header ........................................... 27 A.2 Intra-Area Router ARA .................................... 30 A.3 Intra-Area Network ARA ................................... 31 A.4 Inter-Area Router ARA .................................... 32 A.5 Inter-Area Network ARA ................................... 34 A.6 Vertex Association ....................................... 35 A.7 Resolution Information ................................... 37 A.7.1 ATM Address ............................................ 38 A.7.2 ATM LIJ Call Identification ............................ 39 References ................................................... 40 Coltun, Heinanen [Page 3] Internet-Draft ARA March 1998 1.0 Abstract This document defines an optional extension to OSPF which enables 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 layer-3 forwarding intervention). Before the ingress devices is able to dynamically 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 addresses reso- lution which supports router-to-router and router-to-network inter- subnet shortcuts. Fundamentally, the option provides a mechanism for routers to distribute their IP to link-layer address resolution infor- mation (referred to in this document as link-layer associations), and for routers to determine the link-layer association which are closest to their target networks (within an OSPF domain). Address Resolution Advertisements (ARAs) are used to distribute the link-layer associa- tions of routers (Router ARAs) and their directly connected networks (Network ARAs) within and between OSPF areas. Distribution of ARAs is performed using standard OSPF flooding mechanisms. ARA information is encapsulated in Opaque LSAs [OPAQ] and flooded using the mechanisms defined in [OPAQ]. The ARA option supports both topology-derived and data-driven shortcut architectures with this simple extensions to OSPF. 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 sup- port the following types of 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. Coltun, Heinanen [Page 4] Internet-Draft ARA March 1998 Distributed router architectures. Interoperation with ION NHRP and ATMF MPOA. Inter-subnet multicast shortcuts using LIJ or Point-to-MultiPoint procedures. 2.1 Acknowledgments The authors would like to thank Atul Bansal, Lou Berger, Yiqun Cai, John Moy, Stephen Shew, George Swallow and the rest of the OSPF Working Group for the ideas and support they have given to this project. Coltun, Heinanen [Page 5] Internet-Draft ARA March 1998 3.0 Examples In this section three example ARA topologies are presented for the purpose of explaining the ARA model and capabilities. These examples include a single-area topology with intra-area shortcuts, a multiple- area topology with inter-area shortcuts and an example of shortcuts using the ARA multiple logical network capability. 3.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 Router ARA (R-ARA) with an intra-area router association and RT5 has originated a Network ARA (N-ARA) with an intra-area network associa- tion 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 6] Internet-Draft ARA March 1998 + ARA | +---+ N3 N5 (ARA) N1|--|RT1|\ \ N4 / | +---+ \ \ | / + \ \|/ \+---+ +---+ |RT4|------------|RT5| ARA +---+ +---+ + ARA / | N7 | +---+ / | / N2|--|RT2|/ | / | +---+ +---+ +---+/ + |RT3|-----------|RT6|----N8 +---+ +---+ | | +---------+ N6 Figure 1: Sample Single-Area Topology 3.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 7] Internet-Draft ARA March 1998 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, [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. [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", Internet Draft May 1997, [OSPF] Moy, J., "OSPF Version 2", RFC 2178, July 1997 [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, Cascade, March 1995. Coltun, Heinanen [Page 40]