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 2008Table 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 20081. Introduction1.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
datatracker.ietf.org