idnits 2.17.1 draft-ietf-ospf-ara-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-03-29) 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 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 576 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 1624: '... 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 (March 1998) is 9511 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' ** Downref: Normative reference to an Experimental RFC: RFC 2154 (ref. 'DIGI') -- Possible downref: Non-RFC (?) normative reference: ref. 'HEIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NHRP' ** Obsolete normative reference: RFC 1587 (ref. 'NSSA') (Obsoleted by RFC 3101) -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQ' ** Obsolete normative reference: RFC 2178 (ref. 'OSPF') (Obsoleted by RFC 2328) ** Downref: Normative reference to an Experimental RFC: RFC 1765 (ref. 'OVERFLOW') Summary: 18 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 March 1998 4 Expiration Date: May 1998 5 File name: draft-ietf-ospf-ara-02.txt 7 The OSPF Address Resolution Advertisement Option 9 Rob Coltun 10 FORE Systems 11 (703) 245-4543 12 rcoltun@fore.com 14 Juha Heinanen 15 Telia Finland, Inc. 16 +358 303 944 808 17 jh@telia.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 Acknowledgments .......................................... 5 44 3.0 Examples ................................................. 6 46 3.1 Example 1: Intra-Area .................................... 6 48 3.2 Example 2: Inter-Area .................................... 7 50 3.3 Example 3: Multiple Logical Networks ..................... 8 52 4.0 A Brief Comparison Of Address Resolution Models .......... 9 54 5.0 ARA Components ........................................... 11 56 5.1 Address Resolution Advertisements ........................ 11 58 5.2 ARA Association Table .................................... 11 60 5.3 Logical Network ID List .................................. 12 62 5.4 Routing Table Extensions ................................. 12 64 5.5 Restricting Shortcut Connectivity ........................ 12 66 6.0 ARA Associations ......................................... 13 68 7.0 Description Of ARA Packet Formats ........................ 14 70 7.1 Vertex Types And Vertex Identifiers ...................... 14 72 8.0 Distribution Of ARA Information .......................... 15 74 8.1 Originating Inter-Area ARAs .............................. 17 76 9.0 ARA Routing Table Extensions ............................. 19 78 9.1 Adding ARA Routing Table Extensions ...................... 20 80 9.1.1 Modifications To The Intra-Area Route Calculation ...... 20 82 9.1.2 Modifications To The Inter-Area Route Calculation ...... 21 83 9.1.3 Modifications To The AS External Route Calculation ..... 22 85 9.2 Routing Table Extension Completion ....................... 23 87 10.0 Receiving ARAs .......................................... 24 89 11.0 Additional Data Structures And APIs ..................... 24 91 12.0 Security Considerations ................................. 24 93 Appendix A: ARA Packet Formats ............................... 27 95 A.1 The ARA Header ........................................... 27 97 A.2 Intra-Area Router ARA .................................... 30 99 A.3 Intra-Area Network ARA ................................... 31 101 A.4 Inter-Area Router ARA .................................... 32 103 A.5 Inter-Area Network ARA ................................... 34 105 A.6 Vertex Association ....................................... 35 107 A.7 Resolution Information ................................... 37 109 A.7.1 ATM Address ............................................ 38 111 A.7.2 ATM LIJ Call Identification ............................ 39 113 References ................................................... 40 115 1.0 Abstract 117 This document defines an optional extension to OSPF which enables 118 routers to distribute IP to link-layer address resolution information 119 An OSPF Address Resolution Advertisement (ARA) may include media- 120 specific information such as a multipoint-to-point connection identifier 121 along with the address resolution information to support media-specific 122 functions. The ARA option can be used to support router-to-router 123 inter-subnet shortcut architectures such as those described in [HEIN]. 125 2.0 Overview 127 Along with the evolution of switched layer 2 technologies comes the 128 ability to provide inter-subnet shortcut data switching (bypassing 129 layer-3 forwarding intervention). Before the ingress devices is able 130 to dynamically set up the switched path it must have the link-layer 131 address of the egress device. Acquisition of the egress device's 132 link-layer address may be through configuration or through a dynamic 133 mechanism which resolves an IP address (or an IP end-point identifier) 134 to a link-layer address. 136 This document introduces a method for IP to link-layer addresses reso- 137 lution which supports router-to-router and router-to-network inter- 138 subnet shortcuts. Fundamentally, the option provides a mechanism for 139 routers to distribute their IP to link-layer address resolution infor- 140 mation (referred to in this document as link-layer associations), and 141 for routers to determine the link-layer association which are closest 142 to their target networks (within an OSPF domain). Address Resolution 143 Advertisements (ARAs) are used to distribute the link-layer associa- 144 tions of routers (Router ARAs) and their directly connected networks 145 (Network ARAs) within and between OSPF areas. Distribution of ARAs is 146 performed using standard OSPF flooding mechanisms. ARA information is 147 encapsulated in Opaque LSAs [OPAQ] and flooded using the mechanisms 148 defined in [OPAQ]. 150 The ARA option supports both topology-derived and data-driven shortcut 151 architectures with this simple extensions to OSPF. This document does 152 not define an architecture but is meant to be used with architectures 153 such as those defined in [HEIN]. The ARA option is designed to sup- 154 port the following types of operations. 156 Shortcuts between core or access routers within ISP Backbones. 158 Shortcuts in enterprise networks between routers in the same OSPF 159 autonomous system, between OSPF internal routers and autonomous 160 system border routers (ASBR) or between routers and servers. 162 Distributed router architectures. 164 Interoperation with ION NHRP and ATMF MPOA. 166 Inter-subnet multicast shortcuts using LIJ or Point-to-MultiPoint 167 procedures. 169 2.1 Acknowledgments 171 The authors would like to thank Atul Bansal, Lou Berger, Yiqun Cai, 172 John Moy, Stephen Shew, George Swallow and the rest of the OSPF 173 Working Group for the ideas and support they have given to this project. 175 3.0 Examples 177 In this section three example ARA topologies are presented for the 178 purpose of explaining the ARA model and capabilities. These examples 179 include a single-area topology with intra-area shortcuts, a multiple- 180 area topology with inter-area shortcuts and an example of shortcuts 181 using the ARA multiple logical network capability. 183 3.1 Example 1: Intra-Area 185 Consider the sample single-area topology in Figure 1 below. In this 186 example RT1, RT2 and RT5 support the ARA option (by definition they 187 also support the Opaque LSA option) and RT4 supports the Opaque LSA 188 option only (this is necessary so that RT4 redistributes the ARAs ori- 189 ginated by RT1, RT2 and RT5). RT2 and RT5 have each originated a 190 Router ARA (R-ARA) with an intra-area router association and RT5 has 191 originated a Network ARA (N-ARA) with an intra-area network associa- 192 tion for N5. 194 As a result of running the routing table calculation, RT1 has entries 195 for N1-N8 in its routing table. The entry for N2 references the 196 link-layer associations distributed in RT2's R-ARA, the entries for 197 N3, N4, N6, N7, N8 references the link-layer associations distributed 198 in RT5's R-ARA and the entry for N5 references the link-layer associa- 199 tions distributed in RT5's intra-area N-ARA. 201 + ARA 202 | +---+ N3 N5 (ARA) 203 N1|--|RT1|\ \ N4 / 204 | +---+ \ \ | / 205 + \ \|/ 206 \+---+ +---+ 207 |RT4|------------|RT5| ARA 208 +---+ +---+ 209 + ARA / | N7 210 | +---+ / | / 211 N2|--|RT2|/ | / 212 | +---+ +---+ +---+/ 213 + |RT3|-----------|RT6|----N8 214 +---+ +---+ 215 | 216 | 217 +---------+ 218 N6 220 Figure 1: Sample Single-Area Topology 222 3.2 Example 2: Inter-Area 224 Consider the sample 2-area topology in Figure 2 below. In this exam- 225 ple RT1, RT2, RT3, RT4, RT6 and RT7 support the ARA option, and RT5 226 supports the Opaque option. N4 is an AS external route (which is 227 flooded to all areas) and RT6 is an ASBR. RT4 is an area-border 228 router and originates an LS Type-4 LSA on behalf of RT6 and a LS 229 Type-3 LSA for N5 into area 1.1.1.1. 231 Within area 1.1.1.1, RT1, RT2, RT3 and RT4 originate intra-area R- 232 ARAs. Within the backbone RT6 and RT7 originate intra-area R-ARAs and 233 R7 originates a N-ARA for N5. All backbone ARAs of have their the P- 234 bit set (this bit informs ABRs that the ARA may be propagated between 235 areas). RT4 originates an inter-area R-ARA for RT6 (which is an ASBR) 236 as well as an inter-area N-ARA for N5 into area 1.1.1.1 RT4 does not 237 originate an inter-area R-ARA for RT7 because it is not an ASBR. 239 As a result of running the routing table calculation, RT1 has entries 240 for N1-N5 in its routing table. The entry for N2 references the 241 link-layer associations distributed in RT3's R-ARA, the entry for N3 242 references the link-layer associations distributed in RT4's intra-area 243 R-ARA, the entry for N4 references the link-layer associations distri- 244 buted in RT4's inter-area R-ARA (indirectly referencing RT6's R-ARA) 245 and the entry for N5 references the link-layer associations 246 distributed in RT4's inter-area N5 N-ARA. 248 + ARA ARA | 249 | +---+ +---+ | 250 N1|--|RT1|----|RT2|\ | N3 N4 1671 [IS] S. Shenker and J. Wroclawski. "Network Element QoS Control 1672 Service Specification Template". Internet Draft, July 1996, 1675 [NHRP] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA 1676 Next-Hop Resolution Protocol", Internet Draft, March 1997, 1677 1679 [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 1680 RainbowBridge Communications, Stanford University, March 1994. 1682 [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", Internet Draft 1683 May 1997, 1685 [OSPF] Moy, J., "OSPF Version 2", RFC 2178, July 1997 1687 [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, 1688 Cascade, March 1995.