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<ASE | +---+ +---+ \ | +-----+ / + \ ARA | ARA / \+---+ +---+ +---+ |RT4|----|RT5|---|RT6|<ASBR +---+ +---+ +---+ + ARA / | | | +---+ / | ARA + N2|--|RT3|/ | +---+ | | +---+ | |RT7|---|N5(ARA) + | +---+ | ------------------------|-------------------- + Area 1.1.1.1 | OSPF Backbone Figure 2: Sample Area Topology 3.3 Example 3: Multiple Logical Networks The ARA option supports the existence of disjoint switched networks within an OSPF domain. To accomplish this, an ARA may include an iden- tifier (the logical network ID) for a specific switched network. When associations are added to the routing table during the OSPF routing table calculation (see the Section 9.1 "Adding ARA Routing Table Extensions") only the associations that include a logical network ID that matches one of the router's configured logical network IDs are added to the routing table. This function may also be used to support a variation of closed user groups so that shortcuts are limited to those routers that are configured to be in the same logical network. The single-area topology described in Figure 3 below divides an OSPF area into logical networks X and Y. In this example RT1, RT2 and RT4 support the ARA option and RT3 supports the Opaque LSA option only. RT1 is connected to logical network (LN) X, RT2 is connected LN Y and RT4 is connected to both LN X and LN Y. RT1, RT2 and RT4 all ori- ginate R-ARAs. As a result of running their routing table calculation, RT1 and RT2 have entries for N1-N5 in their routing table. In both routing tables, the N3-N5 entries reference the link-layer associations dis- tributed in RT4's R-ARA. However, RT1's routing table does not refer- ence RT2's link-layer associations for N2 and RT2's routing table does Coltun, Heinanen [Page 8]
Internet-Draft ARA March 1998 not reference RT1's link-layer associations for N1 (i.e., they would not be able to set up shortcuts to each other and would be forced to use a hop-by-hop path to communicate). + ARA (LN=X) | +---+ N3 N5 N1|--|RT1|\ \ N4 / | +---+ \ \ | / + \ \|/ \+---+ +---+ |RT3|------------|RT4| ARA (LN=X,Y) +---+ +---+ / + ARA (LN=Y) | +---+ / N2|--|RT2|/ | +---+ + Figure 3: Sample Topology With Logical Networks 4.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 Coltun, Heinanen [Page 9]
Internet-Draft ARA March 1998 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 parti- cipation 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. Coltun, Heinanen [Page 10]
Internet-Draft ARA March 1998 o The ARA option may easily be extended to support inter-subnet multicast shortcuts. 5.0 ARA Components The ARA option is comprised of several components including Address Resolution Advertisements, the ARA association table, a logical net- work ID List, routing table extensions and methods for restricting shortcut connectivity. The following sections gives an overview of these components. 5.1 Address Resolution Advertisements The ARA option defines a set of link-state advertisements called address resolution advertisements (ARAs). ARAs are used to distribute the link-layer associations of routers and their directly connected networks. ARAs are distributed within a single area and may be dis- tributed 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 7.0 for a further description of the ARA packet formats. 5.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 are the Vertex Type, Vertex ID and the Ver- tex 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) and the Ver- tex Originator is the Router ID of the router originating the ARA. Coltun, Heinanen [Page 11]
Internet-Draft ARA March 1998 5.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 4.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). 5.4 Routing Table Extensions Associations are added to the routing table during the OSPF routing table calculation (see Section 9.1 entitled "Adding ARA Routing Table 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 10.0 "Receiving ARAs"), or 3) the router's logical network connec- tivity 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. 5.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 not be. The ARA option allows for several methods which can limit shortcut connectivity. o [HEIN] proposes that shortcuts are setup by ingress routers Coltun, Heinanen [Page 12]
Internet-Draft ARA March 1998 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 occurred. 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. 6.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 4) 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. 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 Coltun, Heinanen [Page 13]
Internet-Draft ARA March 1998 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. 7.0 Description Of ARA Packet Formats ARA LSAs (ARAs) include the information necessary to associate an IP entity (i.e., a router, network or host) with a link-layer address. The ARA option allows further refinement so that an association may additionally include information about QoS control services and link- layer functionality (e.g., for Point-to-MultiPoint and MultiPoint-to- point connections). ARA advertisements may also include a logical network identifier field, which is used when multiple switched net- works are present within the OSPF domain. The ARA format allows more than one equivalent association to be advertised by a router for a specific vertex. Equivalent associations are ones that have identical link service type, integrated service type and logical network identifier fields, but have different resolu- tion information. Associations can include a preference which identi- fies the advertising router's relative preference for the equivalent associations (a higher numeric preference denotes a better choice). ARA information is encapsulated in Opaque LSAs. Three LS Types (LS Type 9, 10 and 11) constitute the Opaque class of link-state adver- tisements. Each of the three Opaque link-state types have a scope associated with them so that distribution may be limited appropriately by the originator of the LSA. Opaque LSAs have a sub-type which iden- tifies the specific information that is carried within the LSA. The ARA Opaque types are Opaque-types 1 - 4. Because the flooding scope for ARAs is always area local, ARAs are encapsulated in LS Type 10 LSAs. 7.1 Vertex Types And Vertex Identifiers The Vertex Type identifies the piece of IP topology that the link- layer information is being associated with. The Vertex Type may be a router or a network (a host is considered a network with a mask of 255.255.255.255). Vertex Type 1 ARAs advertise intra-area router resolution associa- tions. These associations distribute the router's link-layer attach- ments. A Vertex Type of 1 is identified by an Opaque type of 1. The Vertex Identifier for a R-ARA is the advertising router field in the ARA header. Vertex Type 2 ARAs advertise intra-area IP network address resolution Coltun, Heinanen [Page 14]
Internet-Draft ARA March 1998 associations. These associations distribute the link-layer associa- tions for a router's directly connected networks. A Vertex Type of 2 is identified by an Opaque type of 2. The Vertex Identifier (the net- work and mask) for a N-ARA is contained in the body of the advertise- ment. N-ARAs may only contain a single network (i.e., lists of net- works are not permitted). Vertex Type 3 ARAs advertise inter-area IP network address resolution associations. These associations are used to distribute link-layer associations for networks into remote areas. A Vertex Type of 3 is identified by an Opaque type of 3. The Vertex Identifier (the network and mask) for an inter-area N-ARA is contained in the body of the advertisement. N-ARAs may only identify a single network (i.e., lists of networks are not permitted). Vertex Type 3 N-ARAs are originated by an area border router (ABR) into an area when 1) the ABR originates a type-3 LSA for the network into the target area, 2) the network is not included in any of the area border router's configured area ranges, 3) there is a N-ARA for the network in the source area, 4) the source N-ARA may be an intra or inter-area N-ARA. If it is an intra- area N-ARA the P-bit must be set in its options field. The setting of the P-bit by the originator denotes that the associations contained in the N-ARA are allowed to be propagated into other areas. The default setting for the P-bit is off. Vertex Type 4 ARAs advertise inter-area router address resolution associations. These R-ARAs redistribute associations for ASBRs into remote areas. A Vertex Type of 4 is identified by an Opaque type of 4. The Vertex Identifiers for an inter-area R-ARA are the advertising router field of the ARA header and the ASBR Router ID found in the body of the ARA. Vertex Type 4 R-ARAs are originated by an area border router (ABR) into a target area when 1) the ABR originates a type-4 LSA for the ASBR into the target area, 2) there is a R-ARA for the network in the source area, 3) the source R-ARA may be an intra or inter-area R-ARA. If the source R-ARA is an intra-area R-ARA its P- bit must be set in the options field. The setting of the P-bit by the originator denotes that the associations contained in the R-ARA are allowed to be propagated into other areas. The default setting for the P-bit is off. If a router wishes to advertise several associations for a single ver- tex it has two options. It may originate multiple (N or R) ARAs each containing different associations or it may originate a single (N or R) ARA containing a list of associations. An implementation must not include identical associations in more than one ARA. 8.0 Distribution Of ARA Information Coltun, Heinanen [Page 15]
Internet-Draft ARA March 1998 In general, OSPF is composed of two components. It's transport com- ponent handles adjacency formation and reliable distribution of topol- ogy information. The second component tracks topology changes and organizes the topology information that has been gathered from other routers into to a topology map. This map is used to build the router's routing table. The ARA option uses both the OSPF transport component and the topology map component. ARA uses the OSPF Opaque LSA as defined in [OPAQ] for distribution of resolution information. The Opaque LSA is an optional mechanism to allow for distribution of information which may be used directly by OSPF or by other protocols and mechanisms. Opaque LSAs use the stan- dard OSPF link-state database flooding mechanisms for distribution. Each of the three Opaque types (LS Types 9, 10 and 11) have a scope associated with them (link-local, area-local or domain-wide, respec- tively). Scoping provides an application with a method to limit the range of information distribution. ARA information is distributed with area-local scope (i.e., ARA information is encapsulated in LS Type 10 LSAs). The ARA option uses the topology map component of OSPF to validate the information that is received by the distribution mechanism and to install the associations into the ARA routing table extensions. Vali- dation is necessary because topology information contained in the OSPF link-state database may be stale and therefore unusable (e.g., the originator of the information is no longer reachable). It is envisioned that an implementor designs an ARA user application interface which facilitates 1) flooding of ARA information to other routers in the OSPF network, 2) receiving ARA information from other routers in the OSPF network and 3) determines the validity (and change of validity) of ARA information. For the realization of 1 above, an implementation must provide an API to facilitate the ARA user application's "hand off" of resolution information to its local OSPF entity who will then distribute the information throughout the OSPF topology. In addition, the API must support the purging of associations that were previously originated by the router if they are no longer valid and send out new versions when the association information has changed. For the realization of 2 and 3 above, this option extends the rout- ing table to include the associations that have been advertised by the ARA capable routers (i.e,. the routing table provides the API for the ARA user application). That is, in addition to the standard informa- tion fields contained in the routing table (i.e., IP network number, IP mask, next-hop interface, etc.), the routing table is extended to contain link-layer associations. The associations are added to the Coltun, Heinanen [Page 16]
Internet-Draft ARA March 1998 routing table during the OSPF routing table calculation. Section 8.0 defines the mechanism to calculate the ARA routing table extensions. The use of the extensions are ARA user application specific and beyond the scope of this document. See [HEIN] for an example of an ARA user application. 8.1 Originating Inter-Area ARAs Inter-area ARAs provide a mechanism to distribute link-layer associa- tions to other areas. Inter-area ARAs (consisting of Vertex Type-3 and Type-4 ARAs) have a one-to-one correspondence to Summary LSAs (LS type-3 and type-4 LSAs). Vertex Type-3 ARAs advertise the link-layer associations of IP networks whereas Vertex Type-4 ARAs advertise the link-layer associations of autonomous system boundary routers (ASBR). As with Summary LSAs, inter-area ARAs are originated by area border routers into a target area based on a set of conditions in the source area. For both intra and inter-are ARAs, there may be more than one ARA which collectively make up the complete set of link-layer associa- tions (recall that an implementation must not include identical asso- ciations in more than one ARA). Inter-area ARAs must include, in one or more ARA, all of the link-layer associations contained in their 'trigger' ARAs (see below for a description of the conditions for ABRs to trigger inter-area ARAs). The link-layer associations that comprise the 'trigger' ARAs (in the source area) may include logical network IDs that are not in the ABR's configured list of logical network IDs (i.e., the ABR itself may not be able to set up a shortcut because it may be connected to a disjoint set of logical networks). Despite the ABR's logical network affilia- tion, all trigger ARAs' link-layer associations are included in the newly originated inter-area ARAs. The origination process for type-3 and type-4 Summary LSAs (as dis- cussed in Section 12.4.3 of [OSPF]) consists of an ABR evaluating each entry in the routing table. If an entry satisfies a set of condi- tions, the ABR originates a Summary LSA into the target area. This process is extended for inter-area ARA origination so that when a Summary LSA is originated into an area by an ABR, the conditions for the origination of inter-area ARAs are also evaluated. When these con- ditions are satisfied, an inter-area ARA is originated into the target area. Conversely, when a Summary route is withdrawn from an area by an ABR and a corresponding ARA was previously originated into the area, the ARA must be withdrawn from the target area. The following sections describe the conditions for inter-area ARA origination. Coltun, Heinanen [Page 17]
Internet-Draft ARA March 1998 The conditions for inter-area N-ARA origination are as follows. o The ABR is originating a type-3 LSA for a network into the tar- get area. The network and mask that triggered the origination of the type-3 LSA must be identical to the network and mask of the type-3 LSA. (i.e., the 'trigger network' is not included in the area border router's configured area ranges). o There are one or more reachable N-ARAs for the network in the source area. These N-ARAs 1) must be valid (e.g., their ages must not be MaxAge), 2) must have the same advertising router as the LSA that triggered the origination of the type-3 LSA and 3) the Vertex Type must correspond to the 'trigger' network's LSA type (recall that only the contents of intra-area ARAs are adver- tised into the backbone, whereas the contents of intra-area or inter-area ARAs may be advertised into the other areas). These conditions are verified by looking up an entry in source area's ARA Association Table. The Vertex Type is 2 if the 'trigger' network is an intra-area LSA and is Vertex Type 3 if the 'trigger' network is an inter-area LSA. The Vertex Identifier is the 'trigger' network's IP network number and mask. The Vertex Originator is the router ID of the trigger network's originator. o The set of link-layer associations that are to be included in the advertisement are contained in the ARA Association Table entry. However, if the network that triggered the origination of the type-3 LSA is an intra-area route, only the link-layer asso- ciations whose ARA's P-bit were set may be advertised. (if no associations have their P-bit set the inter-area N-ARA must not be originated). The setting of the P-bit in the N-ARA by its originator gives the ABRs permission to propagate the resolution information into other areas. Inter-area R-ARAs redistribute link-layer associations for ASBRs to other areas. Inter-area R-ARAs have a Vertex Type of 4. The Vertex Identifiers for an inter-area R-ARA are 1) the advertising router field of the ARA header and 2) the ASBR's Router ID which is found in the body of the ARA. Vertex Type-4 R-ARAs are originated by an area border router (ABR) into an area if the following conditions are met. o The ABR originates a type-4 LSA for the ASBR into the target area. o Only the contents of intra-area ARAs are advertised into the backbone, whereas the contents of intra-area or inter-area ARAs may be advertised into the other areas. If the router advertise- ment that triggered the origination of a type-4 LSA is an intra- Coltun, Heinanen [Page 18]
Internet-Draft ARA March 1998 area advertisement (i.e., a type-1 LSA) then there must be a corresponding intra-area R-ARA in the source area. o If the router advertisement that triggered the origination of the type-4 LSA is also a type-4 LSA (the source area is the OSPF backbone), there must be a corresponding inter-area R-ARA in the source area. o The set of link-layer associations that are to be included in the advertisement are contained in the ARA Association Table entry. However, if the router advertisement that triggered the origination of the type-3 LSA is an intra-area route, only the link-layer associations whose ARA's P-bit are set may be adver- tised in the newly originated inter-area R-ARA (if no associa- tions have their P-bit set the inter-area N-ARA must not be ori- ginated). The setting of the P-bit in the R-ARA by its origina- tor gives the ABRs permission to propagate the resolution infor- mation into other areas. 9.0 ARA Routing Table Extensions OSPF determines reachability and topology changes by performing the algorithms described in the Section 16 of [OSPF] entitled "Calculation of the routing table". ARAs are included in this calculation for the purpose of binding link-layer associations to IP routing table entries. A link-layer association consists of the list of link-layer addresses, link-layer service types and other link-layer objects such as Point- to-MultiPoint call identifiers and QoS service specific information (see Appendix A for a more complete description of the specific link- layer information distributed in ARAs). The associations that are bound to a routing table entry are the associations that are 1) closest to the destination and 2) are on the same logical network as the calculating router (as identified by the logical network ID). The closest associations are determined during to the construction of the OSPF topology map. The associations that are bound to the routing table entries are subsequently used by the ARA user application (e.g., a shortcut manager) to setup shortcut paths. Multiple link-layer associations may be bound to a single routing table entry when multiple link-layer association are advertised by the source or when the routing table calculation discovers equal cost paths. These may be used as alternate entries (e.g., when a call set up to a one association fails another may be used) or may be used to set up equal-cost shortcuts. Coltun, Heinanen [Page 19]
Internet-Draft ARA March 1998 Because a link-layer association may be bound to more than one entry in the routing table, an ARA implementation keeps a table of ARA derived link-layer associations which is referenced by the routing table entry. Each area has its own ARA Association table. An entry in the ARA Association Table consists of a list of all associations for a specific vertex and vertex type by a specific originator; the lookup keys for an entry in the table include the Vertex Type, Vertex ID and the Vertex Originator. 9.1 Adding ARA Routing Table Extensions Section 16 of the OSPF specification is modified for the purpose of adding the ARA routing table extensions. Transit vertex data struc- tures and the internal representation of Type-3, Type-4 and Type-5 LSAs are extended to be able to reference a list of link-layer associ- ations (i.e., they have a reference to the ARA Association Table). The vertex and LSA's list of link-layer associations are added to the routing table along with the entry. Prior to running the intra-area route calculation the ARA Association Table is examined. Associations containing a logical network ID that matches an entry in the router's list of logical network IDs are marked 'active'. 9.1.1 Modifications To The Intra-Area Route Calculation The intra-area route calculation is enhanced (specifically Section 16.1 step 3 of [OSPF]) as follows. o Call the vertex that is about to be added to the SPF tree ver- tex M. If vertex M was originated by the calculating router skip this procedure. o If vertex M is a transit network vertex lookup the link-layer association entry in the ARA Association Table. This entry's Vertex Type will be 2, the Vertex Identifier will be vertex M's network and mask, the Vertex Originator will be vertex M's Router ID and its area ID will be the one that is associated with the shortest-path calculation. o If an active entry is found, copy this entry to vertex M's link-layer association list. o If vertex M is a router vertex lookup the an entry in the ARA Association Table. This entry's Vertex Type will be 1, the Ver- tex Identifier will be vertex M's advertising router, the Vertex Coltun, Heinanen [Page 20]
Internet-Draft ARA March 1998 Originator will be vertex M's advertising router and its area ID will be the one that is associated with the shortest-path calcu- lation. o If an an active entry is found, add this entry to vertex M's link-layer association list. o If no active link-layer association entries are found, and ver- tex M's parent vertex has link-layer association information, vertex M inherits it's parent vertex's information (else the information field is left blank). o When vertex M is added to the routing table, copy the active associations from vertex M's link-layer association list into the routing table entry's link-layer association field. The following describes the enhancements to Section 16.1 step 2 of [OSPF] which adds intra-area stub networks to the routing table. o Before adding the stub network to the routing table lookup the entry in the ARA Association Table. This entry's Vertex Type will be 2, the Vertex Identifier will consist of the network and mask of the stub network, the Vertex Originator will be the advertising router's Router ID and its area ID will be the one that is associated with the shortest-path calculation. o If an active entry is found copy the entry's active association information into the routing table entry's link-layer association field. o If an entry is not found and the stub network's advertising router vertex has link-layer association information, the routing table entry will inherit the advertising router's information (else the information field is left blank). 9.1.2 Modifications To The Inter-Area Route Calculation The following describes the enhancements to OSPF Sections 16.2, 16.3, 16.5 which calculate inter-area routes. Before the destination associ- ated with the LSA is added to the routing table the following is per- formed. o If the LSA is a Type-3 Summary LSA, lookup the entry in the ARA Association Table. This entry's Vertex Type will be 3, the Vertex Coltun, Heinanen [Page 21]
Internet-Draft ARA March 1998 Identifier will be the Summary LSA's network and mask, the Vertex Originator will be the advertising router's Router ID and its area ID will be the one that is associated with the shortest-path calculation. If an active entry is found copy the entry's active association information into the routing table entry's link-layer association field. o If the LSA is a Type-4 Summary LSA, lookup a type-4 ARA in the ARA Association Table. This entry's Vertex Type will be 4, the Vertex Identifier will be the Summary LSA's ASBR ID, the Vertex Originator will be the advertising router's Router ID and its area ID will be the one that is associated with the shortest-path calculation. If an active entry is found copy the entry's active association information into the routing table entry's link-layer association field. o If an active entry was not found for the type-3 or type-4 LSA, locate the area border router (ABR) that originated the adver- tisement. If link-layer association information is available for the ABR entry, copy the contents of the ABR's link-layer associa- tion information field into the routing table entry's link-layer association field. If no active entry was found for the ABR the routing table entry's information field will be left blank. 9.1.3 Modifications To The AS External Route Calculation The following describes the enhancements to OSPF Sections 16.4 and 16.6 which calculate AS external routes. Before the destination asso- ciated with the LSA is added to the routing table the following is performed. o If the LSA has a forwarding address, look up the forward address in the routing table (this will be an internal OSPF route). Copy the contents of the route's link-layer association information field into the external route's routing table entry's link-layer association field. The forwarding address' link-layer association information may have been added as a result of pro- cessing intra-area or inter-area N-ARAs. o If the LSA does not have a forwarding address, copy the con- tents of the advertising ASBR's link-layer association informa- tion field into the routing table entry's link-layer association field. The ASBR's link-layer association information may have been added as a result of processing intra-area or inter-area R- ARAs. Coltun, Heinanen [Page 22]
Internet-Draft ARA March 1998 9.2 Routing Table Extension Completion Upon completing the calculation of ARA routing table extensions the entity that manages shortcuts must be informed so that it can reevalu- ate existing shortcuts and determine if new shortcuts are to be setup. Reevaluation of existing shortcuts is necessary so that the router can determine if shortcuts that it has previously set up are no longer on the path to their target destinations. Packets that are sent on these invalid shortcuts may result in packet loss or forwarding loops. Reevaluating existing shortcuts requires comparing the shortcut's currently active link-layer associations with the link-layer associa- tions that have just been derived. If a destination is no longer in the routing table or no longer has an association, the shortcut must be terminated. If there is a mismatch between the associations currently being used by an active shortcut (for a specific target net- work) and the associations that have just been derived, the currently active shortcut must be terminated and if warranted, a new shortcut must be set up. An implementation may want to consider methods for dampening the number of existing shortcuts that are terminated and set up immedi- ately following a route calculation. One dampening model would be to configure a maximum number of changes per time period. If the number of changes exceeds the maximum number, the router must either stop forwarding on invalid paths (dropping all packets for the destinations unsing invalid shortcuts) or revert to hop-by-hop forwarding until the invalid shortcuts are terminated and new ones have been set up. An enhancement to this model would be to allow "pretty good" shortcuts to exist for a some time after a route calculation has completed. That is, the list of associations for a destination would be extended to include both the associations that are closest to the target net- work and ones that are on the path towards the destination. To imple- ment this, during the calculation of the ARA routing table extensions, the list of associations for a specific target network would be extended to inherit all associations from it's parents (in addition to the associations that it has determined to be closest to the target network). After running the calculation the shortcut manager would check each the of the currently active shortcut's associations: o If the associations currently being used by the shortcut is the closest one to the target network, evaluate the next shortcut. o If the associations currently being used by the shortcut are not the closest ones to the target network but are on the path to the target network the shortcut may remain. Coltun, Heinanen [Page 23]
Internet-Draft ARA March 1998 o If the associations currently being used by the shortcut are not on the path to the target network, forwarding must cease on the shortcut and the shortcut must be terminated. 10.0 Receiving ARAs After the ARA has been processed according to Section 13 of [OSPF] the ARA has been determined to be 1) a new ARA, 2) a newer instance of an existing ARA with the same contents, 3) a newer instance with dif- ferent contents, or 4) an ARA that is being withdrawn by it's origina- tor. If the ARA is new, the contents of the ARA have changed or the ARA is being withdrawn, the following actions must be taken. o Lookup the entry for the ARA in the ARA Association Table. If there is no existing entry and the ARA has determined to be new, create an entry in the ARA Association Table which contains the associations found in the ARA. The newly added associations should reflect the state of the ARA's P-bit. o If the there is an existing entry and the newly received ARA contents have changed modify the entry to reflect the associa- tions found in the newly received ARA. The changed associations should reflect the state of the ARA's P-bit. o If the ARA is being withdrawn and there is an existing entry, remove the associations from the link-layer entry that were pre- viously included in the ARA. If the contents of the table entry is now empty remove the entry from the table. If the above process has resulted in a modification to the ARA table, the SPF calculation must be rescheduled (see Section 8.1 entitled "Adding ARA Routing Table Extensions"). If the receiving router is an ABR the inter-area origination process must be scheduled to be run following the SPF calculation (see Section 8.1 entitled "Originating Inter-area ARAs"). 11.0 Additional Data Structures And APIs This section lists the additional data structures and APIs needed to support the OSPF ARA option. Coltun, Heinanen [Page 24]
Internet-Draft ARA March 1998 o The implementation must support the Opaque LSA option as defined in [OPAQ]. o A configuration knob to enable the OSPF ARA option. o 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 in the inter-area ARA origination process. The indexes for an entry in this table 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 Ver- tex ID identifies a piece of a specific OSPF network's topology (i.e., a router ID or an IP network number). The Vertex Origina- tor is the originator of the ARA's router ID. Entries in this table may be either active or non-active. Active entries are ones whose Logical Network IDs match one of the router's config- ured (and currently active) Logical Network IDs. o Transit vertex data structures and the internal representation of Type-3, Type-4 and Type-5 LSAs are extended to contain a reference to the an entry in the ARA Association Table. o The routing table is extended to contain a reference to the an entry in the ARA Association Table. o To be able to flood ARA information to other ARA capable routers an implementation must provide an API which allows the ARA user application to have its local OSPF entity distribute resolution information in ARA format (if the scope is area-local, a reference to the area must also be supplied). Additionally, the API must allow for associations to be withdrawn when they are no longer valid and for new versions of associations to be ori- ginated when association information has changed. o A router running the ARA option may be configured with a list of logical network IDs. This list is used when the router calcu- lates the link-layer associations for its routing table and when receiving ARAs to determine the change in active status for its ARA Association Table entries. Status information is kept for each of the router's attached logical network so that a router can determine which logical networks are active at a given point in time. To insure that ARA reachability is up-to-date, a change in status of one of the router's connected logical networks must result in the SPF calculation being rerun. The absence of entries in the router's list of Logical Network Coltun, Heinanen [Page 25]
Internet-Draft ARA March 1998 IDs means that the router will only activate ARA Association Table entries with the default Logical Network ID which is Logi- cal Network ID 0. A router may originate ARAs with Logical Network IDs that are not contained in its list of Logical Network IDs. This may be used, for example, to enable shortcuts to be set up from any router to any server but to disable shortcuts from being set up between routers that are not associated with a server. 12.0 Security Considerations There are two types of issues that need be addressed when looking at protecting routing protocols from misconfigurations and malicious attacks. The first is authentication and certification of routing protocol information. The second is denial of service attacks result- ing from repetitive origination of the same router advertisement or origination a large number of distinct advertisements resulting in database overflow. Note that both of these concerns exist indepen- dently of a router's support for the ARA option. To address the authentication concerns, OSPF protocol exchanges may be authenticated. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network seg- ment basis. One of OSPF's authentication types, namely the Crypto- graphic authentication option, is believed to be secure against pas- sive attacks and provide significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and received digest to verify that each received OSPF packet is authentic. The quality of the security provided by the Cryptographic authentica- tion option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm speci- fied), the strength of the key being used, and the correct implementa- tion of the security mechanism in all communicating OSPF implementa- tions. It also requires that all parties maintain the secrecy of the shared secret key. None of the standard OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. For more information on the standard OSPF security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF]. [DIGI] describes the extensions to OSPF required to add digital Coltun, Heinanen [Page 26]
Internet-Draft ARA March 1998 signature authentication to Link State data and to provide a certifi- cation mechanism for router data. [DIGI] also describes the added LSA processing and key management as well as a method for migration from, or co-existence with, standard OSPF V2. Repetitive origination of advertisements are addressed by OSPF by man- dating a limit on the frequency that new instances of any particular LSA can be originated and accepted during the flooding procedure. The frequency at which new LSA instances may be originated is set equal to once every MinLSInterval seconds, whose value is 5 seconds (see Sec- tion 12.4 of [OSPF]). The frequency at which new LSA instances are accepted during flooding is once every MinLSArrival seconds, whose value is set to 1 (see Section 13, Appendix B and G.5 of [OSPF]). Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of gracefully handling unanticipated database overflows. Appendix A: ARA Packet Formats This document defines four different types of Address Resolution Advertisements. Each type of ARA begins with a standard 20-byte Opaque LSA header [OPAQ]. This header is described in section A.1. Subsequent sections describe the specific advertisements and their content including the formats of the resolution information. An ARA capable router may use the ARAs to build shortcut paths to other ARA capable routers. Each ARA describes a link-layer association for a piece of the OSPF routing domain. Any router may originate intra-area router and network ARAs. These ARAs advertise address resolution information for routers and networks within the local area and are advertised locally (they have an area-local scope). Area border routers may originate inter-area network and router ARAs. These ARAs advertise address resolution to areas that are beyond the source local area. Inter-area network and router ARAs correspond to LS Type-3 and LS Type-4 advertisements. A.1 The ARA Header Coltun, Heinanen [Page 27]
Internet-Draft ARA March 1998 All ARAs begin with a common 20-byte header. This header contains enough information to uniquely identify the ARA. The header, which is a subset of the standard LSA header, includes the ARA Vertex Type and distribution scope. The Vertex Type is derived from the Opaque Type field; the distribution scope is derived from the LS type field. ARAs have an area-local scope (LS Type = 10). The Vertex Identifier for an intra-area Router ARA is the advertising router field of the ARA header; for inter-area Router ARAs the vertex is identified by the advertising router field and the ASBR Router ID field which is in the body of the advertisement. The Vertex Identifier for both intra and inter-area Network ARAs is contained in the network and mask field (which is in the body of the advertisement). A N-ARA may only identify a single network (i.e., lists of networks are not permitted). ARAs make use of the P-bit in the same as the NSSA option [NSSA]. That is, ARAs may not be advertised beyond area borders unless the P- bit is set in the original intra-area ARA. See the section entitled "Originating Inter-Area ARAs" for a further discussion on this topic. All of a router's associations for a specific vertex may be described in a single ARA or they may distributed over several ARAs. That is, a router may originate multiple (N or R) ARAs each containing different associations or may originate a single (N or R) ARA containing a list of associations. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coltun, Heinanen [Page 28]
Internet-Draft ARA March 1998 LS age The time in seconds since the ARA was originated. Options The optional capabilities supported by the described portion of the routing domain. The ARA uses two option bits. O-bit This bit describes the router's willingness to receive and forward Opaque-LSAs as specified in [OPAQ]. All routers supporting the ARA option as described in this document support the Opaque option. P-Bit ARAs make use of the P-Bit in a manner consistent with [NSSA]. An ARA may not be advertised beyond an area border unless the P-bit is set in the ori- ginal intra-area ARA. The remainder of OSPF's optional capabilities are documented in Section A.2 of [OSPF]. LS Type The type of the LSA. Each LSA type has a separate advertise- ment format. The ARA LSA as defined in this document are LS Type-10 advertisements (they all have an intra-area scope). Opaque Type The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 8 bits) and an Opaque ID (the remaining 24 bits). The Address Resolution Advertisements are Opaque-types 1 - 4. The Opaque Type field identifies the Vertex Type. Opaque Type-1 advertisements are intra-area Router Address Resolution Advertisements and contain link-layer associa- tions for the advertising router. These ARAs are advertised throughout the local area. Opaque Type-2 advertisements are intra-area Network Address Resolution Advertisements and contain link-layer associa- tions for a router's directly connected IP networks (or hosts). These ARAs are advertised throughout the local area. Opaque Type-3 advertisements are inter-area Network Address Resolution Advertisements and contain link-layer Coltun, Heinanen [Page 29]
Internet-Draft ARA March 1998 associations for IP networks that reside in other areas. Inter-area N-ARAs are coordinated with inter-area network (LS Type-3) advertisements. Opaque-type 4 advertisement are inter-area Router Address Resolution Advertisements and contain link-layer associa- tions for ASBR that reside in other areas. Inter-area R- ARAs are coordinated with inter-area ASBR (LS Type-4) adver- tisements. Opaque ID A 24-bit semantic-less LSA identifier which serves to dif- ferentiate between multiple LSAs originated by the same router. The Opaque ID must be unique for an advertising router within the advertising scope of the LSA. Advertising Router The Router ID of the router that originated the ARA. For intra-area R-ARAs the Advertising Router also serves as the ARA Vertex Identifier. LS Sequence Number Detects old or duplicate ARAs. Successive instances of an ARA are given successive LS sequence numbers. See Section 12.1.6 of [OSPF] for more details. LS Checksum The Fletcher checksum of the complete contents of the ARA, including the ARA header but excluding the LS age field. See Section 12.1.7 of [OSPF] for more details. Length The length in bytes of the ARA. This includes the 20 byte ARA header. A.2 Intra-Area Router ARAs Opaque Type-1 advertisements are intra-area Router Address Resolution Advertisements and contain associations for the advertising router. If the originating router is an ASBR and wishes to have the contents of the R-ARA distributed beyond the local area (i.e., translated into an inter-area R-ARA), the R-ARA must have the P-bit set in its Options field. Coltun, Heinanen [Page 30]
Internet-Draft ARA March 1998 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The body of the R-ARA consists of a list of associations for the advertising router. Each Vertex Association begins with a common 6- byte header (described in Section A.6) followed by association- specific resolution information (described in Section A.7). A.3 Intra-Area Network ARAs Opaque Type-2 advertisements are intra-area Network Address Resolution Advertisements and contain associations for one of the advertising router's directly connected IP networks (or hosts). If the originating router is wishes the contents of the N-ARA are to be distributed beyond the local area (i.e., translated into an inter- area N-ARA) the N-ARA must have the P-bit set in its Options field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coltun, Heinanen [Page 31]
Internet-Draft ARA March 1998 | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +++ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Network Number One of the router's directly connect network. This number represents an IP network/subnet/supernet. IP Network Mask A 32-bit number indicating the range of IP addresses resid- ing on a single IP network/subnet/supernet. The body of the N-ARA consists of a list of associations for this IP Network Number. Each Vertex Association begins with a common 6-byte header (described in Section A.6) followed by association-specific resolution information (described in Section A.7). A.4 Inter-Area Network ARAs Opaque Type-3 advertisements are inter-area Network Address Resolution Advertisements and contain associations for a remote area's IP Coltun, Heinanen [Page 32]
Internet-Draft ARA March 1998 networks (or hosts). Inter-area N-ARAs are coordinated with LS type-3 advertisements. Inter-area network ARAs are originated by an area border router into a target area if 1) the ABR originates a type-3 LSA for the network into the target area, 2) the network is not included in any of the area border router's configured area ranges, 3) there is an N-ARA for the network in the source area and 4) the source N-ARA is an intra-area N-ARA with a P-bit set in the options field (which denotes that the originator of the N-ARA will allow the N-ARA to be propagated into other areas) or the source N-ARA is an inter-area N-ARA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +++ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Network Number One of the router's directly connect network. This number Coltun, Heinanen [Page 33]
Internet-Draft ARA March 1998 represents an IP network/subnet/supernet. IP Network Mask A 32-bit number indicating the range of IP addresses resid- ing on a single IP network/subnet/supernet. The body of the N-ARA consists of a list of associations for this IP Network Number. Each Vertex Association begins with a common 6-byte header (described in Section A.6) followed by association-specific resolution information (described in Section A.7). A.5 Inter-Area Router ARAs Opaque Type-4 advertisements are inter-area Router Address Resolution Advertisements and contain associations for the an autonomous system boundary router. Inter-area R-ARAs are coordinated with LS type-4 advertisements. Inter-area router ARAs are originated into a target area if 1) the ABR originates a type-4 LSA for the ASBR into the target area, 2) there is a R-ARA for the ASBR in the source area and 3) the source R-ARA is an intra-area R-ARA with a P-bit set in the options field (which denotes that the originator of the R-ARA will allow the R-ARA to be propagated into other areas) or the source R-ARA is an inter-area R-ARA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +-+ Coltun, Heinanen [Page 34]
Internet-Draft ARA March 1998 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ Vertex Association +-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASBR Router ID The router ID of the ASBR being advertised. This field corresponds to the link-state ID of the LS type-4 advertise- ment. The body of the inter-area R-ARA consists of a list of associations for the advertising router. Each Vertex Association begins with a common 6-byte header (described in Section A.6) followed by association-specific resolution information (described in Section A.7). A.6 Vertex Association The Vertex Association field consists of the link service type, IntServ service name, administrative weight, association length, logi- cal network ID followed by the association-specific resolution infor- mation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Svc Type | IS Svc Name | Admin Weight | Assoc Length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Logical Network ID | Resolution Information + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Remaining Octets of Resolution Information padded to 32-bits + | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coltun, Heinanen [Page 35]
Internet-Draft ARA March 1998 Link Svc Type Identifies the link-layer functionality for this associa- tion. Link Service Types 1, 2 and 3 are defined by this specification. All other Link Service Types are reserved for definition by the IANA (iana@isi.edu). The current list of Link Service Types is described below in Table 1. Link Service Type Description ------------------------------------------------- 1 ATM Point-To-Point 2 ATM MultiPoint-To-Point 3 ATM Point-To-MultiPoint Table 1 IS Svc Name The IntServ Service Name. Refer to [IS] as a reference for the IETF defined service specifications. Admin Weight When more than one equivalent association has been adver- tised for a specific vertex, this field is used to denote the advertising router's preference for each association. Equivalent associations are ones that have identical Link Service Type, IS Svc Name and Logical Network Identifier fields. Assoc Length The length in bytes of this association. Logical Network ID When more than one overlay network is used to establish shortcut paths within the OSPF domain, this number identi- fies a specific logical network. This function may also be used to support a variation of closed user groups so that shortcuts are limited to those routers that are configured to be in the same logical network. To use the association information, a router must have an active attachment to the specific logical network identified in the resolution infor- mation. An ARA capable router is configured with a list of Logical Network IDs. The default value (i.e., only one overlay network or too lazy to care) for the ID is 0. Resolution Information Coltun, Heinanen [Page 36]
Internet-Draft ARA March 1998 The resolution information field includes link-layer and service-type specific information. The contents of this field is defined in section A.7 of this document. The Ver- tex Association may include several resolution information items. A.7 Resolution Information The resolution information field is an extensible field that includes link-layer and service-type specific information. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res Type | Res Length | Resolution Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | remaining octets of Resolution Value padded to 32-bits | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res Type Identifies the resolution being advertised. Resolution Types 1 and 2 are defined by this specification. Resolution Type 1 is defined in A.7.1, Type 2 is defined in A.7.2. All other resolution types are reserved for definition by the IANA (iana@isi.edu). The current list of resolution types is described below in Table 2. Resolution Type Description ------------------------------------------------- 1 ATM Address 2 ATM LIJ Call Identification Table 2 Res Length The total length in octets of this resolution information Coltun, Heinanen [Page 37]
Internet-Draft ARA March 1998 field This value includes the Res Type and Res Length fields. Resolution Value The resolution type-specific data. A.7.1 ATM Address An ATM address is the Resolution Type 1. This includes the type and length of ATM number (8 bits), the type and length of ATM subaddress (8 bits), the ATM number (x octets) and possibly the ATM subaddress (y octets). 8 7 6 5 4 3 2 1 +---+---+---+---+---+---+---+---+ | Type And Len Of ATM Number | +---+---+---+---+---+---+---+---+ | Type And Len Of ATM Subaddr | +-----+-----+-----+-----+-----+-----+-----+-----+ | ATM Number... +-----+-----+-----+-----+-----+-----+-----+-----+ | ATM Subaddress... +-----+-----+-----+-----+-----+-----+-----+-----+ Format Of The ATM Address The Type and Length field of ATM number and ATM subaddress are encoded as follows. MSB 8 7 6 5 4 3 2 1 LSB +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1/0 | Octet length of address | +-----+-----+-----+-----+-----+-----+-----+-----+ Where: Bit(s) Description ------------------------------------------------- 8 Reserved = 0 (for future use) 7 Type = 0 ATM Forum NSAPA format Coltun, Heinanen [Page 38]
Internet-Draft ARA March 1998 = 1 E.164 format 6-1 Length = 6 bit unsigned octet length of address (MSB = bit.6, LSB = bit.1). Value range is from 0 to 20 (decimal). A non-existing ATM subaddress is indicated by setting the subaddress length to zero. If the subaddress length is zero, the corresponding type field MUST be ignored and the ATM subaddress field MUST NOT con- sume any octets in the packet. The ATM number and ATM subaddress fields are encoded as defined by the ATM Forum UNI 3.1 [AF1] signalling specification. A.7.2 ATM LIJ Call Identification An ATM LIJ Call Identification is the Resolution Type 2. This includes an ATM address as defined in A.7.1 followed by a four octet Leaf Initiated Join Call Identifier Value, which together uniquely identify an ATM Point-To-Multipoint or Multipoint-To-Point call at a root's interface. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM Address as defined in A.7.1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Remaining Octets of ATM Address + | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf Initiated Join Call Identifier Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format Of LIJ Call Identification The Leaf Initiated Join Call Identifier Value is encoded as defined in Section 6.1.2.1 of the ATM Forum UNI 4.0 [AF2] signalling specifica- tion. Coltun, Heinanen [Page 39]
Internet-Draft ARA March 1998 References [AF1] ATM Forum, "ATM User-Network Interface (UNI) Specification Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper Saddle River, NJ, 07458, September, 1994. [AF2] ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification", July 1996. [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures", RFC 2154, Trusted Information Systems, June 1997. [HEIN] Heinanen, J., "Intra-area IP unicast among routers over legacy ATM", Internet Draft, July 1997, <draft-ietf-ion-intra-area-unicast-00.txt> [IS] S. Shenker and J. Wroclawski. "Network Element QoS Control Service Specification Template". Internet Draft, July 1996, <draft- ietf-intserv-svc-template-03.txt> [NHRP] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA Next-Hop Resolution Protocol", Internet Draft, March 1997, <draft-ietf-rolc-nhrp-15.txt> [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, <draft-ietf-ospf-opaque-04.txt> [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]
