RFC 3509 (rfc3509) - Page 2 of 12

Alternative Implementations of OSPF Area Border Routers

RFC 3509                   OSPF ABR Behavior                  April 2003


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" problem.  OSPF prevents
   inter-area routing loops by implementing a split-horizon mechanism,
   allowing 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
   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
   section 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 Area 2---the summary-LSAs for Area 1, and in Area 1---the
   summary-LSAs for Area 2.





Zinin, et al.                Informational