Network Working Group A. D. Zinin Internet Draft AMT Group Expiration Date: August 1999 February 1999 File name: draft-ietf-ospf-abr-behavior-00.txt OSPF ABR Behavior Alternative Implementation and Deployment Considerations draft-ietf-ospf-abr-behavior-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract OSPF [Ref1] is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the ABR in the current OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met all traffic, destined for the areas not connected to such ab ABR or out of the OSPF domain, is dropped. The rules of originating and processing Summary-LSAs given in the current OSPF standard [Ref1] can also result in suboptimal inter-area routing. Though all these problems Zinin [Page 1]
Internet Draft OSPF ABR Behavior January 1999 can be fixed using virtual links, this memo describes an alternative implementation of the OSPF ABR behavior, which allows the administrator to avoid it or, if virtual links are still used, to decrease the number of configured virtual links. This memo also describes possible situations where the proposed implementation can be used. Acknowledgements The author would like to acknowledge Christian Hopps for his help in finding weak points in early versions of this document and Thomas M. Thomas II for technical and grammar review. This document is a result of the discussion between the author, Christian Hopps, and Acee Lindem about Cisco Systems OSPF implementation. 1 Overview 1.1 Introduction An OSPF routing domain can be split into several subdomains, called areas, which limit the scope of LSA flooding. A router having attachments to multiple areas is called an "area border router" (ABR). The primary function of an ABR is to provide its attached areas with Type-3 and Type-4 LSAs (which are used for describing routes and ASBRs in other areas) as well as to perform actual inter- area routing. 1.2 Motivation In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" technique. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, permitting ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database. The last restriction leads to a problem when an ABR has no backbone Zinin [Page 2]
Internet Draft OSPF ABR Behavior January 1999 connection (in OSPF an ABR does not need to be attached to the backbone). Consider a sample OSPF domain depicted in the Figure 1. . . . Area 0 . +--+ +--+ ..|R1|.. ..|R2|.. . +--+ .. +--+ . . .. . . +--+ . . Area1 |R3| Area2 . . +--+ +--+ . . .. |R4| . . . . +--+ . ....... ....... Figure 1. ABR dropping transit traffic In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone connections, while R3 doesn't. Following the section 12.4.1 of [Ref1], R3 will identify itself as an ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only consider summary-LSAs from the backbone when building the routing table (according to section 16.2 of [Ref1]), so it will not have any inter-area routes in its routing table, but only intra-area routes from both Area 1 and Area 2. Consequently, according to the section 12.4.3 of [Ref1], R3 will originate for Areas 1 and 2 only summary- LSAs covering destinations in the directly attached areas, i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the summary- LSAs for Area 2. At the same time, router R2, as an ABR connected to the backbone, will inject into Area 2 summary-LSAs describing the destinations in Area 0 (the backbone), Area 1 and other areas reachable through the backbone. This results in a situation, where internal router R4 calculates its routes to destinations in the backbone and areas other than Area 1 via R2. The topology of Area 2 itself can be such that the best path from R4 to R2 is via the R3, so all traffic destined for the backbone and backbone-attached areas goes through R3. Router R3 in turn, having only intra-area routes for areas 1 and 2, will effectively drop all traffic not destined for the areas directly attached to it. The same problem can be seen when a backbone-connected ABR loses all of its adjacencies in the backbone---even if there are other normally functioning ABRs in the attached areas, all traffic going to the Zinin [Page 3]
Internet Draft OSPF ABR Behavior January 1999 backbone (destined for it or for other areas) will be dropped. In a standard OSPF implementation this situation can be remedied by use of the Virtual Links (see section 15 of [Ref1] for more details). In this case, router R3 will have a virtual backbone connection, will form an adjacency over it, will receive all summary-LSAs directly from a backbone-attached router (R1 or R2, or both in our example) and will install inter-area routes. While being an unavoidable technique for repairing a partitioned backbone area, the use of virtual links in the described situation adds extra configuration headaches and system traffic overhead. Consider another example, illustrated by the Figure 2: . Area 2 . . . . +--+ . ......|R5|....... . +--+ . . / \ . . / \ . . BB /10Mb \ 2Mb . . / \ . . | \ . . +--+ +--+ . ..|R1|......|R2|.. . +--+ +--+ . . | 10Mb |\ . . ------------ | . . | . . +--+ . . |R4| . . Area 1 +--+ . .................. Figure 2. Suboptimal inter-area routing In this example router R2 has a 2Mb link to R5. At the same time R1 has a better link (10 Mbps), but R2 cannot route traffic going to area 2 through R1. This is because according to [Ref1] R2 is not allowed to consider summary-LSAs from non-backbone areas and, consequently, does not have routes covering destinations in area 2 via R1. The situation looks even more interesting if R4's routing table is considered. Since R2 floods summary-LSAs from R1 to R4, router R4 will have routes to the area 2 via R1 (the best path), expecting traffic to go via 10Mbps links. In reality R2 will not Zinin [Page 4]
Internet Draft OSPF ABR Behavior January 1999 direct traffic to R1, but will forward it via 2Mbps link attached to itself. The last example shows how the main principle of the OSPF---prefer the shortest path---is broken due to distance vector approach used for inter-area routing. Again, the problem can be fixed using the virtual links between R1 and R2 in standard OSPF, but the solution proposed in this document appears to be more elegant and involving no administrative and traffic overhead. 2 Proposed Changes to ABR Behavior This section describes two alternative implementations of ABR behavior. The two solutions vary in details of Type 1 and Type 3/4 LSA origination, as well as routing table calculation. These details are described below. Any other parts of standard OSPF are not changed. The first solution, named "short-cut ABR", is an improvement on standard ABR behavior, based on relaxation of the restrictions applied to the calculation of the inter-area routes. ABRs are allowed to consider summary-LSAs from all attached areas (no matter if it is connected to the backbone or not). The routing loop prevention is done by restricting origination of summary-LSAs---inter-area routes are readvertised only if there is a valid summary-LSA for the destination learned from the backbone. Origination of summary-LSAs for intra-area routes is done as in standard OSPF, described in [Ref1]. The relaxation of the routing table calculation allows router R3 in the first example (Figure 1) to route traffic between the attached areas, as well as to route traffic destined for the backbone and other areas using the routes derived from the summary-LSAs in each attached area. This approach also enables router R2 in the second example to route inter-area traffic via R1. The second solution, named "transit router", is targeted to the situation when an ABR has no backbone connection. It implies that a router connected to multiple areas without a backbone connection is not an ABR and must function as a router internal to every attached area. This solution emulates a situation where separate OSPF processes are run for each area and supply routes to the routing table. It only remedies the situation described in the first example and only in the meaning of not dropping transit traffic. This approach is not ideal, though, as a router following it does not function as a real border router---it doesn't originates summary- LSAs. Nevertheless such a behavior may be desirable in certain Zinin [Page 5]
Internet Draft OSPF ABR Behavior January 1999 situations. Note that the proposed solutions do not obviate the need of virtual link configuration in case an area has no physical backbone connection at all (except for a stub area, as described in section 5). The methods described here improve the behavior of a router connecting two or more backbone-attached areas. Note also, that in the following two subsections, an "active backbone attachment" means existence of at least one fully adjacent neighbor in the area 0. Though this document is initially oriented to processing Type-3 LSAs and, consequently, is targeted to improving OSPF inter-area routing, it's acceptable to apply described methods to Type-4 LSAs, which will lead to improvement of external routing in an OSPF domain. 2.1 Solution 1 ("short-cut ABR") The following changes are made to the base OSPF described in [Ref1]: 1. The algorithm of Type 1 LSA (router-LSA) origination is not changed, the router still identifies itself as an ABR by setting the bit B in its router-LSA when it has more than one attached area. 2. The algorithm of the routing table calculation is changed to allow the router to consider the summary-LSAs from all attached areas. Note that if the router has no physical (from OSPF's standpoint) interface in the backbone, it does not need to consider summary-LSAs from the backbone, as in this case they are received via the virtual links and the ABRs at the other ends of the VLs already injected summary-LSAs into the transit areas. Also, an ABR doesn't need to perform the calculations described in the section 16.3 of [Ref1], as summaries from other ABRs in the transit area are considered by the main algorithm. So, the paragraph 1 of section 16.2 of [Ref1] should be read as follows: "The inter-area routes are calculated by examining summary-LSAs. If the router has active attachments to multiple areas, summary- LSAs from all active areas must be considered, i.e., the router must perform the inter-area route computation algorithm given below for each attached area (one at a time). If all of the router's links to the backbone are virtual, the router must run the algorithm only for non-backbone areas. Routers attached to a single area examine that area's summary-LSAs..." 3. The algorithm of the summary-LSAs origination is changed to Zinin [Page 6]
Internet Draft OSPF ABR Behavior January 1999 include an explicit restriction not to originate summary-LSAs for inter-area routes if the router doesn't have a summary-LSA for the destination from the backbone[1]. If the ABR in question has no backbone connection, it will not originate summary-LSA for any inter-area route in any area. The ABR will also not readvertise an inter-area route from non-backbone area if its backbone link state database does not contain a summary-LSA for the destination. In order to implement described policy, the paragraph 2 in section 12.4.3 of [Ref1] should be read as follows: "... Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas. Also, summary-LSAs for inter- area routes are originated if and only if the backbone area's link-state database contains a valid summary-LSA for the destination (to prevent loops of summary-LSAs)." The 7th step of the algorithm given in sections 12.4.3 of [Ref1] must be read as shown below: "Else, the Destination type is network. If this is an inter-area route then do a lookup in the backbone area's link state database to find a summary-LSA for this destination. If there is no such LSA---examine the next routing table entry. If the LSA was found and the routing table contains an entry associated with the backbone for the originating ABR, generate a Type 3 summary-LSA for the destination..." Described changes in the ABR behavior allow a multi-area connected router to function as normal area border router, forwarding traffic between attached areas and still not dropping the traffic destined for the backbone and backbone-attached areas, not connected to the router itself. In case this behavior is used when an ABR loses all its backbone connections, the administrator doesn't need to configure virtual links to other ABRs in the attached areas. This solution also allows an ABR to consider inter-area routes provided by another ABRs in the same area, thus fixing the situation described in the second example in section 1. 2.2 Solution 2 ("transit router") The following changes are made to the base OSPF, described in [Ref1]: 1. The algorithm of Type 1 LSA (router-LSA) origination is changed to prevent a multi-area connected router from identifying itself as an ABR by the bit B until it has at least one active backbone Zinin [Page 7]
Internet Draft OSPF ABR Behavior January 1999 attachment. The paragraph 3 in section 12.4.1 of [Ref1] must be read is given below: "...Bit B should be set when the router is actively attached to two or more areas and if the router has at least one active backbone attachment..." Note, that as soon as the router finds itself actively connected to the backbone, it must revert to standard OSPF ABR behavior, including setting the bit B in its router-LSA and flooding it through all attached areas (see section 2.3 for more details). The router can also revert to the short-cut ABR behavior. 2. The algorithm of the routing table calculation is changed to allow the router to consider the summary-LSAs from all attached areas, as described in section 2.1 of this document. The router is allowed to do this only if it doesn't have a backbone connection. If it does, standard rules must be applied. 3. The algorithm of the summary-LSAs origination is changed to prevent from originating summary-LSAs, i.e., to prevent a router with multiple attached areas from acting as a real ABR until it has an active backbone connection. In order to implement described policy, the following sentence must be added to the paragraph 2 in section 12.4.3 of [Ref1]: "...Also, if none of the actively attached areas is the backbone, then the router must refrain from summary-LSA origination until it has at least one active backbone connection. " The changes in the ABR behavior described in this solution allow a multi-area connected router to successfully route traffic destined for the backbone and other areas. The difference from the first solution is that the router does not actively attract inter-area traffic, because it does not originate summary-LSAs. It still can forward traffic from one attached area to another along intra-area routes in case other routers in corresponding areas have the best inter-area paths over it, as described in section 1.2. Note, that when a router, following this strategy, finds an active backbone connection, it can start acting as either standard or short-cut ABR. 2.3 Handling Transitions While the "short-cut ABR" solution does not imply changes of LSA origination and routing table computation depending upon the backbone Zinin [Page 8]
Internet Draft OSPF ABR Behavior January 1999 connection state, the "transit router" approach requires special processing when the router finds a connection to the backbone or loses the last one. 2.3.1 First backbone adjacency found The actions given below must be performed after an adjacency on an interface that belongs to the OSPF backbone has reached the state Full and this is the first full adjacency in the backbone. 1. If the current behavior strategy is the "transit router", then do the following: a) reconstruct the router-LSAs for all area databases, setting the bit B to 1. b) flood the new router-LSA to all neighbors according to [Ref1]. c) if the router must revert to the standard ABR behavior--- schedule the routing table recalculation for all areas to get rid of the inter-area routes through non-backbone areas. 2. Else, the behavior strategy is the "short-cut ABR" and nothing must be done. 2.3.2 Last backbone adjacency lost The actions given below must be performed when the router loses the last adjacency in the OSPF backbone and all of the adjacencies in the backbone area are in the state lesser than ExStart. 1. If the target behavior strategy is the "transit router", then do the following: a) reconstruct the router-LSAs for all areas, setting the bit B to 0. b) flood the new router-LSA to all neighbors according to [Ref1]. c) schedule the routing table recalculation to install the inter-area routes via non-backbone areas. d) flush all locally originated summary-LSAs from all non- backbone areas. 2. Else, the target behavior strategy is the "short-cut ABR" and Zinin [Page 9]
Internet Draft OSPF ABR Behavior January 1999 nothing must be done. 3 Implementation Details If the current implementation of OSPF uses the standard described in [Ref1], then support of the proposed ABR behavior strategies must be implemented as a configurable option, allowing to specify two types of the strategies---the first one (standard, short-cut or transit) to instruct the router how to behave without a backbone connection, and the second one (standard or short-cut) to instruct the router how to behave when it has a backbone connection. The default value of the second behavior strategy (with a backbone connection) must be standard, while the default for the first strategy can be either of the values. If the implementation originally follows one of the alternative behaviors, there must also be an option to revert to the standard one. 4 Compatibility The changes of the OSPF ABR operations do not influence any aspects of the router-to-router cooperation and do not create routing loops, and hence are fully compatible with standard OSPF. Proof of compatibility is outside the scope of this document. 5 Deployment Considerations This section discusses the deployments details of the ABR behaviors described in this document. Note that both approaches are fully compatible with standard ABR behavior, so ABRs acting as described in [Ref1] and in this document can coexist in an OSPF domain and will function without problems. Considerations of short-cut ABR and transit router deployment are given in separate subsections below. 5.1 Short-cut ABR 5.1.1 Necessity of virtual links First of all it should be repeated that short-cut ABR behavior does not obviate the need for virtual links in case an area has no physical backbone connection except for a stub area (see section 5.1.4). The difference with standard OSPF is that the administrator does not need to configure virtual links through all areas he or she wants the inter-area traffic to go through. A short-cut ABR needs a single backbone connection (physical or virtual) to achieve optimal routing, since it considers summary-LSAs from all attached areas. Zinin [Page 10]
Internet Draft OSPF ABR Behavior January 1999 5.1.2 Change of traffic patterns Use of short-cut ABR can lead to changes in the paths inter-area traffic flows take comparing to those experienced with standard OSPF. This happens because the short-cut ABR approach allows a router to find paths better than it is possible with the standard OSPF. While standard OSPF tries to forward all inter-area traffic through the backbone area (though it does not guarantee it), the short-cut ABR finds best routes in the domain even across non-backbone areas. With short-cut ABR the backbone area is used as a dedicated place of inter-area routing information exchange and inter-area traffic is allowed to cross non-backbone area borders if such a path is really the best. 5.1.3 Optimized inter-area routing Use of short-cut ABR improves inter-area routing in OSPF domains by allowing ABRs to consider summary-LSAs from all attached area and consequently readvertise them into non-backbone areas. Consider an example show in the Figure 3: ....................... . Backbone . ......... . . . . . +--+ +--+ . . |R1| |R5|--| . . +--+ +--+ 1| . . 8/ 8\ 1/ . | . . / \ -------- . | . . 8/ 8\ /1 1\ . | Net N . .+--+ +--+ +--+ 1| . ......|R2|.....|R3|.......|R4|--| . . +--+ +--+ +--+ . . .|1 1/ \1 1/ . . Area 3 . . .-------- -------- . .......... . . . . . . .Area 1 . Area 2 . ....... ................... Figure 3. Optimized inter-area routing In case all ABRs use standard OSPF approach, routing to the net N would be as follows: - R4 and R5 inject summary-LSAs into the backbone Zinin [Page 11]
Internet Draft OSPF ABR Behavior January 1999 - R4 also inject a summary-LSA into area 2 - R3 is limited to consider summary-LSAs from the backbone only, so it doesn't see the alternative path through area 2 and always routes through the backbone (though parallel paths are available) - R3 injects summary-LSA for the inter-area routes derived from the backbone summary-LSAs and received from R4 and R5 into Area 2 - R2 is not allowed to consider non-backbone summary-LSAs and routes via serial links to R2, though more optimal paths do exist If at least R2 and R3 use short-cut ABR approach inter-area routing is improved as shown below: - R4 and R5 inject summary-LSAs into the backbone - R4 also inject a summary-LSA into area 2 - R3 considers summary-LSAs from both attached areas and installs the route through area 2 (it has three routes in the routing table---via R5, via R4 through the backbone, and via R4 through area 2) and performs traffic sharing between the two ethernet links. - R3 injects summary-LSA for the inter-area routes to N (it will be the same as in the previous case, actually) - R2 considers summary-LSAs from all attached areas and prefers the route through area 2 rather than the backbone. 5.1.4 Connecting a stub area with a short-cut ABR Short-cut ABRs can be used to connect a stub area to another non- backbone area without a virtual link configured on the ABR. One restriction that is applied to such a scheme is that the stub area must use default routing for both external and inter-area destinations. Consider Figure 4. Zinin [Page 12]
Internet Draft OSPF ABR Behavior January 1999 . Backbone . . +--+ . .......|R1|....... . +--+ . . . . Area 1 . . . . +--+ . .......|R2|....... . +--+ . . . . Stub Area 2 . . . .................. Figure 4. Connecting a stub area with short-cut ABR With standard OSPF router R2 would need to have a virtual link with R1, because otherwise R2 would have no inter-area routes (OSPF standard would limit R2 to consider only backbone summary-LSA while calculating its routing table) and would drop all traffic going out of the stub area 2. If short-cut ABR approach is used, R2 is allowed to consider summary-LSAs injected into area 1 by R1, so R2 is not required to have a virtual link to the backbone. Without it R2 is not allowed to readvertise inter-area routes into the stub area, but the default summary injected by each ABR connected to a stub area can do the job in most cases. 5.2 Transit router Deployment of ABRs using the transit router behavior is limited to the situations where the ABR does not need to perform actual inter- area routing, though in certain circumstances inter-area traffic will be routed from one attached area to another. This can lead to unexpected routing asymmetry, as described below. 5.2.1 Possible asymmetry in inter-area routing Consider an OSPF domain depicted in Figure 5. Zinin [Page 13]
Internet Draft OSPF ABR Behavior January 1999 ....................... . Backbone . . . . --------------------- . . |1 1| . ..+--+.............+--+.. ..|R1|..... ....|R4|.. . +--+ . . +--+ . . 1| . . /4 . . | 8 +--+ 4 / . . | +-|R3|---+ . . 1| / +--+\4 . . +--+ / . . \ 4 +--+ . . |R2|/8 . . +--|R5| . . +--+ . . +--+ . . | . . | . . --------- . . -------- . . net N . . net M . . . . . . Area 1 . . Area 2 . ........... .......... Figure 5. Inter-area routing asymmetry Assume that R3 uses the transit router approach. In this case R2 will have inter-area routes to network M via ABR R1 only. R5 in turn will have its inter-area route to network N via R4, but as far as R4 is only reachable via R3, all traffic destined to network N will get into R3. R3 will have an intra-area route to network N via R2 and will, of course, route it directly to it (because intra-area routes are always preferred over inter-area ones). Traffic going back from network N to network M will get into R2 and will be routed to R1, as R2 will not have any inter-area routes via R3. So, traffic from N to M will always go through the backbone while traffic from M to N will cross the areas directly via R3 and, in this example, will not use a more optimal path through the backbone. Note that this problem is not caused by the fact that R3 uses the transit router approach, in fact it would remain even in case of short-cut ABR. The reason for attracting the attention to it is that R3 is not really functioning as an ABR in case the transit router behavior is used, i.e., it does not inject summary-LSAs into the attached areas, but inter-area traffic can still go through it. 6 Footnotes [1] In standard OSPF, it is implicitly prohibited for an ABR to originate summary-LSAs for inter-area routes via non-backbone area by limiting an ABR consider only backbone summary-LSAs when Zinin [Page 14]
Internet Draft OSPF ABR Behavior January 1999 calculating the routing table. As far as we relaxed the restriction of the routing table calculation, we need to introduce a similar one for summary-LSA origination. 7 References [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet Engineering Task Force, 1998. ftp://ftp.isi.edu/in- notes/rfc2328.txt. 8 Author's Address Alex D. Zinin AMT Group 8 Maly Znamensky per., bld. 1 Office 3b 121019 Moscow, Russia Phone : (7-095) 725-76-60 Fax : (7-095) 725-76-63 E-mail: zinin@amt.ru Zinin [Page 15]
