draft-ietf-ospf-abr-alt-04.txt   draft-ietf-ospf-abr-alt-05.txt 
Network Working Group Alex Zinin Network Working Group Alex Zinin
Internet Draft Cisco Systems Internet Draft Alcatel
Expiration Date: September 2001 Acee Lindem Expiration Date: April 2003 Acee Lindem
File name: draft-ietf-ospf-abr-alt-04.txt Redback Networks File name: draft-ietf-ospf-abr-alt-05.txt Redback Networks
Derek Yeung Derek Yeung
Procket Networks Procket Networks
February 2001 October 2002
Alternative OSPF ABR Implementations Alternative OSPF ABR Implementations
draft-ietf-ospf-abr-alt-04.txt draft-ietf-ospf-abr-alt-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
draft" or "work in progress". draft" or "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
OSPF [Ref1] is a link-state intra-domain routing protocol used for OSPF is a link-state intra-domain routing protocol used for routing
routing in IP networks. Though the definition of the ABR in the in IP networks. Though the definition of the Area Border Router (ABR)
current OSPF specification does not require a router with multiple in the OSPF specification does not require a router with multiple
attached areas to have a backbone connection, it is actually attached areas to have a backbone connection, it is actually
necessary to provide successful routing to the inter-area and necessary to provide successful routing to the inter-area and
external destinations. If this requirement is not met, all traffic external destinations. If this requirement is not met, all traffic
destined for the areas not connected to such an ABR or out of the destined for the areas not connected to such an ABR or out of the
OSPF domain, is dropped. This document describes alternative ABR OSPF domain, is dropped. This document describes alternative ABR
behaviors implemented in Cisco and IBM routers. behaviors implemented in Cisco and IBM routers.
1 Overview 1 Overview
1.1 Introduction 1.1 Introduction
skipping to change at page 2, line 22 skipping to change at page 2, line 22
router" (ABR). The primary function of an ABR is to provide its 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 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 describing routes and ASBRs in other areas) as well as to perform
actual inter-area routing. actual inter-area routing.
1.2 Motivation 1.2 Motivation
In OSPF domains the area topology is restricted so that there must be 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 a backbone area (area 0) and all other areas must have either
physical or virtual connections to the backbone. The reason for this physical or virtual connections to the backbone. The reason for this
star-like topology is that OSPF inter-area routing uses the star-like topology is that OSPF inter-area routing uses the distance-
distance-vector approach and a strict area hierarchy permits vector approach and a strict area hierarchy permits avoidance of the
avoidance of the "counting to infinity" problem. OSPF prevents "counting to infinity" problem. OSPF prevents inter-area routing
inter-area routing loops by implementing a split-horizon mechanism, loops by implementing a split-horizon mechanism, allowing ABRs to
allowing ABRs to inject into the backbone only Summary-LSAs derived inject into the backbone only Summary-LSAs derived from the intra-
from the intra-area routes, and limiting ABRs' SPF calculation to area routes, and limiting ABRs' SPF calculation to consider only
consider only Summary-LSAs in the backbone area's link-state Summary-LSAs in the backbone area's link-state database.
database.
The last restriction leads to a problem when an ABR has no backbone The last restriction leads to a problem when an ABR has no backbone
connection (in OSPF, an ABR does not need to be attached to the connection (in OSPF, an ABR does not need to be attached to the
backbone). Consider a sample OSPF domain depicted in the Figure 1. backbone). Consider a sample OSPF domain depicted in the Figure 1.
. . . .
. Area 0 . . Area 0 .
+--+ +--+ +--+ +--+
..|R1|.. ..|R2|.. ..|R1|.. ..|R2|..
. +--+ .. +--+ . . +--+ .. +--+ .
skipping to change at page 3, line 10 skipping to change at page 3, line 10
Figure 1. ABR dropping transit traffic Figure 1. ABR dropping transit traffic
In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone
connections, while R3 doesn't. connections, while R3 doesn't.
Following the section 12.4.1 of [Ref1], R3 will identify itself as an 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 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 consider summary-LSAs from the backbone when building the routing
table (according to section 16.2 of [Ref1]), so it will not have any 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 inter-area routes in its routing table, but only intra-area routes
from both Area 1 and Area 2. Consequently, according to the section from both Area 1 and Area 2. Consequently, according to section
12.4.3 of [Ref1], R3 will originate for Areas 1 and 2 only summary- 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only summary-
LSAs covering destinations in the directly attached areas, i.e., in 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- Area 2---the summary-LSAs for Area 1, and in Area 1---the summary-
LSAs for Area 2. LSAs for Area 2.
At the same time, router R2, as an ABR connected to the backbone, At the same time, router R2, as an ABR connected to the backbone,
will inject into Area 2 summary-LSAs describing the destinations in will inject into Area 2 summary-LSAs describing the destinations in
Area 0 (the backbone), Area 1 and other areas reachable through the Area 0 (the backbone), Area 1 and other areas reachable through the
backbone. backbone.
This results in a situation, where internal router R4 calculates its This results in a situation where internal router R4 calculates its
routes to destinations in the backbone and areas other than Area 1 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 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 from R4 to R2 is via R3, so all traffic destined for the backbone and
and backbone-attached areas goes through R3. Router R3 in turn, backbone-attached areas goes through R3. Router R3 in turn, having
having only intra-area routes for areas 1 and 2, will effectively only intra-area routes for areas 1 and 2, will drop all traffic not
drop all traffic not destined for the areas directly attached to it. destined for the areas directly attached to it. The same problem can
The same problem can be seen when a backbone-connected ABR loses all occur when a backbone-connected ABR loses all of its adjacencies in
of its adjacencies in the backbone---even if there are other normally the backbone---even if there are other normally functioning ABRs in
functioning ABRs in the attached areas, all traffic going to the the attached areas, all traffic going to the backbone (destined for
backbone (destined for it or for other areas) will be dropped. it or for other areas) will be dropped.
In a standard OSPF implementation this situation can be remedied by In a standard OSPF implementation this situation can be remedied by
use of the Virtual Links (see section 15 of [Ref1] for more details). use of Virtual Links (see section 15 of [Ref1] for more details). In
In this case, router R3 will have a virtual backbone connection, will this case, router R3 will have a virtual backbone connection, will
form an adjacency over it, will receive all LSAs directly from a form an adjacency over it, will receive all LSAs directly from a
backbone-attached router (R1 or R2, or both in our example) and will backbone-attached router (R1 or R2, or both in our example) and will
install intra- or inter-area routes. install intra- or inter-area routes.
While being an unavoidable technique for repairing a partitioned While being an unavoidable technique for repairing a partitioned
backbone area, the use of virtual links in the described situation backbone area, the use of virtual links in the described situation
adds extra configuration headaches and system traffic overhead. adds extra configuration headaches and system traffic overhead.
Another situation where standard ABR behavior does not provide Another situation where standard ABR behavior does not provide
acceptable results is when it is necessary to provide redundant acceptable results is when it is necessary to provide redundant
skipping to change at page 4, line 17 skipping to change at page 4, line 17
+--+ +--+ +--+ +--+
..|R1|.. ..|R2|.. ..|R1|.. ..|R2|..
. +--+ .. +--+ . . +--+ .. +--+ .
. .. . . .. .
. .. . . .. .
. Area1 .. Area2 . . Area1 .. Area2 .
. .. . . .. .
. .. . . .. .
. +--+ . . +--+ .
.......|R3|....... .......|R3|.......
+--+ ASBR+--+
ASBR /..\
--+- -+--
CN1 CNx
Customer Networks Advertised Customer Networks (CN1--CNx) Advertised
as AS External or NSSA External Routes as AS External or NSSA External Routes
Figure 2. Dual Homed Customer Router Figure 2. Dual Homed Customer Router
This technique is already used in a number of networks including one This technique is already used in a number of networks including one
of a major provider. of a major provider.
The next section describes alternative ABR behaviors, implemented in The next section describes alternative ABR behaviors, implemented in
Cisco and IBM routers. The changes are in the ABR definition and Cisco and IBM routers. The changes are in the ABR definition and
inter-area route calculation. Any other parts of standard OSPF are inter-area route calculation. Any other parts of standard OSPF are
not changed. not changed.
Described solutions are targeted to the situation when an ABR has no These solutions are targeted to the situation when an ABR has no
backbone connection. It implies that a router connected to multiple backbone connection. They imply that a router connected to multiple
areas without a backbone connection is not an ABR and should function areas without a backbone connection is not an ABR and should function
as a router internal to every attached area. This solution emulates a as a router internal to every attached area. This solution emulates a
situation where separate OSPF processes are run for each area and situation where separate OSPF processes are run for each area and
supply routes to the routing table. It remedies the situation supply routes to the routing table. It remedies the situation
described in the examples above in the meaning of not dropping described in the examples above by not dropping transit traffic.
transit traffic. Note that a router following it does not function Note that a router following it does not function as a real border
as a real border router---it doesn't originate summary-LSAs. router---it doesn't originate summary-LSAs. Nevertheless such a
Nevertheless such a behavior may be desirable in certain situations. behavior may be desirable in certain situations.
Note that the proposed solutions do not obviate the need of virtual Note that the proposed solutions do not obviate the need of virtual
link configuration in case an area has no physical backbone link configuration in case an area has no physical backbone
connection at all. The methods described here improve the behavior of connection at all. The methods described here improve the behavior of
a router connecting two or more backbone-attached areas. a router connecting two or more backbone-attached areas.
2 Changes to ABR Behavior 2 Changes to ABR Behavior
2.1 Definitions 2.1 Definitions
skipping to change at page 6, line 18 skipping to change at page 6, line 18
only backbone summary-LSAs are examined. Otherwise (either the only backbone summary-LSAs are examined. Otherwise (either the
router is not an ABR or it has no Active Backbone Connection), router is not an ABR or it has no Active Backbone Connection),
the router should consider summary-LSAs from all Actively the router should consider summary-LSAs from all Actively
Attached areas..." Attached areas..."
3. For Cisco ABR approach, the algorithm of the summary-LSAs 3. For Cisco ABR approach, the algorithm of the summary-LSAs
origination is changed to prevent loops of summary-LSAs in origination is changed to prevent loops of summary-LSAs in
situations where the router considers itself an ABR but doesn't situations where the router considers itself an ABR but doesn't
have an Active Backbone Connection (and, consequently, examines have an Active Backbone Connection (and, consequently, examines
summaries from all attached areas). The algorithm is changed to summaries from all attached areas). The algorithm is changed to
allow an ABR announce only intra-area routes in such a situation. allow an ABR to announce only intra-area routes in such a
situation.
So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be
interpreted as follows: interpreted as follows:
"Summary-LSAs are originated by area border routers. The precise "Summary-LSAs are originated by area border routers. The precise
summary routes to advertise into an area are determined by summary routes to advertise into an area are determined by
examining the routing table structure (see Section 11) in examining the routing table structure (see Section 11) in
accordance with the algorithm described below. Note that only accordance with the algorithm described below. Note that while
intra-area routes are advertised into the backbone, both intra- only intra-area routes are advertised into the backbone, if the
area and inter-area routes are advertised into the other areas, router has an Active Backbone Connection, both intra-area and
provided that the router has an Active Backbone Connection. inter-area routes are advertised into the other areas; otherwise,
Otherwise the router is allowed to advertise only intra-area the router only advertises intra-area routes into non-backbone
routes into non-backbone areas." areas."
For this policy to be applied we change steps 6 and 7 in the For this policy to be applied we change steps 6 and 7 in the
summary origination algorithm to be as follows: summary origination algorithm to be as follows:
Step 6: Step 6:
"Else, if the destination of this route is an AS boundary "Else, if the destination of this route is an AS boundary
router, a summary-LSA should be originated if and only if the router, a summary-LSA should be originated if and only if the
routing table entry describes the preferred path to the AS routing table entry describes the preferred path to the AS
boundary router (see Step 3 of Section 16.4). If so, a Type 4 boundary router (see Step 3 of Section 16.4). If so, a Type 4
skipping to change at page 7, line 31 skipping to change at page 7, line 32
it, as described in section 1.2. it, as described in section 1.2.
By processing all summaries when the backbone is not active, we By processing all summaries when the backbone is not active, we
prevent the ABR, which has just lost its last backbone adjacency, prevent the ABR, which has just lost its last backbone adjacency,
from dropping any packets going through the ABR in question to from dropping any packets going through the ABR in question to
another ABR and destined towards the backbone or other areas not another ABR and destined towards the backbone or other areas not
connected to the ABR directly. connected to the ABR directly.
3 Virtual Link Treatment 3 Virtual Link Treatment
Cisco ABR approach described in this document requires an ABR to have The Cisco ABR approach described in this document requires an ABR to
at least one active interface in the backbone area. This requirement have at least one active interface in the backbone area. This
may cause problems with virtual links in those rare situations where requirement may cause problems with virtual links in those rare
the backbone area is purely virtual, as shown in Figure 3, and the situations where the backbone area is purely virtual, as shown in
state of the VL is determined as in [Ref1]. Figure 3, and the state of the VL is determined as in [Ref1].
....... ........... ...... ....... ........... ......
. . . . . . . .
+--+ VL +--+ +--+ VL +--+
|R1|***********|R2| |R1|***********|R2|
+--+ +--+ +--+ +--+
Area 1 . . Area 2 . . Area 3 Area 1 . . Area 2 . . Area 3
....... ........... ...... ....... ........... ......
Figure 3. Purely Virtual Backbone Figure 3. Purely Virtual Backbone
skipping to change at page 8, line 4 skipping to change at page 8, line 6
....... ........... ...... ....... ........... ......
. . . . . . . .
+--+ VL +--+ +--+ VL +--+
|R1|***********|R2| |R1|***********|R2|
+--+ +--+ +--+ +--+
Area 1 . . Area 2 . . Area 3 Area 1 . . Area 2 . . Area 3
....... ........... ...... ....... ........... ......
Figure 3. Purely Virtual Backbone Figure 3. Purely Virtual Backbone
If R1 and R3 treat virtual links as in [Ref1], their virtual links If R1 and R3 treat virtual links as in [Ref1], their virtual links
will never go up, because their router-LSAs do not contain the B-bit, will never go up, because their router-LSAs do not contain the B-bit,
which is, in turn, because the routers do not have active interfaces which is, in turn, because the routers do not have active interfaces
(virtual links) in the backbone and do not consider themselves ABRs. (virtual links) in the backbone and do not consider themselves ABRs.
Note that this problem does not appear if one of the routers has a Note that this problem does not appear if one of the routers has a
real interface in the backbone, as it usually is in real networks. real interface in the backbone, as it usually is in real networks.
Though described situation is deemed to be rather rare, Though the situation described is deemed to be rather rare,
implementations supporting Cisco ABR behavior may consider changing implementations supporting Cisco ABR behavior may consider changing
VL-specific code so that a virtual link is reported up (an VL-specific code so that a virtual link is reported up (an
InterfaceUp event is generated) when a router with corresponding InterfaceUp event is generated) when a router with corresponding
router-ID is seen via Dijkstra, no matter whether its router-LSA router-ID is seen via Dijkstra, no matter whether its router-LSA
indicates that it is an ABR or not. This means that checking of indicates that it is an ABR or not. This means that checking of
configured virtual links should be done not in step 4 of the configured virtual links should be done not in step 4 of the
algorithm in 16.1 of [Ref1] when a router routing entry is added, but algorithm in 16.1 of [Ref1] when a router routing entry is added, but
every time a vertex is added to the SPT in step 3 of the same every time a vertex is added to the SPT in step 3 of the same
algorithm. algorithm.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
. . . . . . . .
. Area 1 . . Area 2 . . Area 1 . . Area 2 .
........... .......... ........... ..........
Figure 4. Inter-area routing asymmetry Figure 4. Inter-area routing asymmetry
Assume that R3 uses the approach described in this document. In this Assume that R3 uses the approach described in this document. In this
case R2 will have inter-area routes to network M via ABR R1 only. R5 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 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 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 will pass through R3. R3 will have an intra-area route to network N
R2 and will, of course, route it directly to it (because intra-area via R2 and will, of course, route it directly to it (because intra-
routes are always preferred over inter-area ones). Traffic going back area routes are always preferred over inter-area ones). Traffic going
from network N to network M will get into R2 and will be routed to back from network N to network M will pass through R2 and will be
R1, as R2 will not have any inter-area routes via R3. So, traffic routed to R1, as R2 will not have any inter-area routes via R3. So,
from N to M will always go through the backbone while traffic from M traffic from N to M will always go through the backbone while traffic
to N will cross the areas directly via R3 and, in this example, will from M to N will cross the areas directly via R3 and, in this
not use a more optimal path through the backbone. 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 Note that this problem is not caused by the fact that R3 uses the
alternative approach. The reason for attracting the attention to it alternative approach. The reason for attracting the attention to it
is that R3 is not really functioning as an ABR in case this new is that R3 is not really functioning as an ABR in case this new
behavior is used, i.e., it does not inject summary-LSAs into the behavior is used, i.e., it does not inject summary-LSAs into the
attached areas, but inter-area traffic can still go through it. attached areas, but inter-area traffic can still go through it.
6 Security Considerations 6 Security Considerations
The alternative ABR behavior specified in this document does not The alternative ABR behaviors specified in this document do not raise
raise any security issues that are not already covered in [Ref1]. any security issues that are not already covered in [Ref1].
7 Acknowledgements 7 Acknowledgements
Authors would like to thank Alvaro Retana, Russ White, and Liem Authors would like to thank Alvaro Retana, Russ White, and Liem
Nguyen for their review of the document. Nguyen for their review of the document.
8 Disclaimer 8 Disclaimer
This document describes OSPF ABR implementations of respective This document describes OSPF ABR implementations of respective
vendors "as is", only for informational purposes, and without any vendors "as is", only for informational purposes, and without any
skipping to change at page 10, line 41 skipping to change at page 10, line 41
10 References 10 References
[Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998. ftp://ftp.isi.edu/in- Engineering Task Force, 1998. ftp://ftp.isi.edu/in-
notes/rfc2328.txt. notes/rfc2328.txt.
11 Authors' Addresses 11 Authors' Addresses
Alex Zinin Derek M. Yeung Alex Zinin Derek M. Yeung
Cisco Systems Procket Networks Alcatel Procket Networks
150 West Tasman Dr. 3850 N.First Street E-mail: zinin@psg.com 3850 N.First Street
San Jose, CA 95134 San Jose, CA 95134 San Jose, CA 95134
E-mail: azinin@cisco.com Phone: 408-954-7911 Phone: 408-954-7911
E-mail: myeung@procket.com E-mail: myeung@procket.com
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Apex, NC 27502 USA Apex, NC 27502 USA
919-387-6971 919-387-6971
E-mail: acee@redback.com E-mail: acee@redback.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/