OSPF Multi-Area Adjacency
RFC 5185

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

Network Working Group                                       S. Mirtorabi
Request for Comments: 5185                                 Nuova Systems
Category: Standards Track                                      P. Psenak
                                                           Cisco Systems
                                                          A. Lindem, Ed.
                                                                A. Oswal
                                                        Redback Networks
                                                                May 2008

                       OSPF Multi-Area Adjacency

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes an extension to the Open Shortest Path First
   (OSPF) protocol to allow a single physical link to be shared by
   multiple areas.  This is necessary to allow the link to be considered
   an intra-area link in multiple areas.  This would create an intra-
   area path in each of the corresponding areas sharing the same link.

Mirtorabi, et al.           Standards Track                     [Page 1]
RFC 5185               OSPF Multi-Area Adjacency                May 2008

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Possible Solutions  . . . . . . . . . . . . . . . . . . . . 3
     1.3.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . 4
     1.4.  Requirements Notation . . . . . . . . . . . . . . . . . . . 4
   2.  Functional Specifications . . . . . . . . . . . . . . . . . . . 4
     2.1.  Multi-Area Adjacency Configuration and Neighbor
           Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Multi-Area Adjacency Packet Transmission  . . . . . . . . . 5
     2.3.  Multi-Area Adjacency Control Packet Reception Changes . . . 5
     2.4.  Interface Data Structure  . . . . . . . . . . . . . . . . . 6
     2.5.  Interface FSM . . . . . . . . . . . . . . . . . . . . . . . 6
     2.6.  Neighbor Data Structure and Neighbor FSM  . . . . . . . . . 6
     2.7.  Advertising Multi-Area Adjacencies  . . . . . . . . . . . . 6
   3.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 7
     3.1.  Adjacency Endpoint Compatibility  . . . . . . . . . . . . . 7
   4.  OSPFv3 Applicability  . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 9

Mirtorabi, et al.           Standards Track                     [Page 2]
RFC 5185               OSPF Multi-Area Adjacency                May 2008

1.  Introduction

1.1.  Motivation

   It is often a requirement to have an Open Shortest Path First (OSPF)
   [OSPF] link in multiple areas.  This will allow the link to be
   considered as an intra-area path in each area and be preferred over
   higher cost links.  A simple example of this requirement is to use a
   high-speed link between two Area Border Routers (ABRs)in multiple
   areas.

   Consider the following topology:

                          R1-------Backbone------R2
                           |                      |
                         Area 1                 Area 1
                           |                      |
                          R3--------Area 1--------R4

                            Multi-Link Topology

   The backbone area link between R1 and R2 is a high-speed link, and it
   is desirable to forward Area 1's traffic between R1 and R2 over that
   link.  In the current OSPF specification [OSPF], intra-area paths are
   preferred over inter-area paths.  As a result, R1 will always route
   traffic to R4 through Area 1 over the lower speed links.  R1 will
   even use the intra-area Area 1 path though R3 to get to Area 1
   networks connected to R2.  An OSPF virtual link cannot be used to
   solve this problem without moving the link between R1 and R2 to Area
   1.  This is not desirable if the physical link is, in fact, part of
   the network's backbone topology.

   The protocol extension described herein will rectify this problem by
   allowing the link between R1 and R2 to be part of both the backbone
   area and Area 1.

1.2.  Possible Solutions

   For numbered interfaces, the OSPF (Open Shortest Path First)