Network Working Group Acee Lindem
Internet Draft Anand Oswal
Expiration Date: January 2004 Redback Networks
July 2002
OSPF Multi-Area Links
draft-lindem-ospf-multi-area-links-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 and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as
"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
This memo documents an extension to OSPF to allow a single physical
link to be shared by multi-areas. This is necessary to allow the
link to be considered as an intra-area link in multiple areas and
be preferred over high cost intra-area paths. Unlike existing
mechanisms, this extension does not require additional layer 2
encapsulations or secondary addresses.
Lindem, Oswal [Page 1]
Internet Draft OSPF Multi-Area Links July 2003
Table of Contents
Abstract ............................................... 1
1 Motivation.............................................. 2
2 Proposed Soultion ...................................... 3
3 Backward compatibility ................................. 4
4 Other Solutions ........................................ 4
5 Security Considerations ................................ 4
6 References ............................................. 4
7 Acknowledgments ........................................ 4
8 Authors' Addresses ..................................... 4
1. Motivation
In OSPF routing domains, it is common for the OSPF backbone links
to be higher bandwidth than the non-backbone links. It is also
common for non-backbone areas to be connected via multiple ABRs
which are also connected by backbone links. For example:
R5
| Area 0
|
R1 ------- Area 0 --------- R2
| Oc48 |
Area 1 Area 1
Oc3 Area 1 Oc3
| |
R3----------Area 1 --------- R4
DS1 |
N1
The backbone Oc48 link connecting R1 and R2 in area 0 is clearly
the highest bandwidth and lower cost path between R1 and N4.
However, the path R1->R3->R4->N1 will be preferred since it is
an Area 1 intra-area path. In this situation, one would like the
higher bandwidth link between R1 and R2 to be treated as a link
in both Area 1 and Area 0.
Lindem, Oswal [Page 2]
Internet Draft OSPF Multi-Area Links July 2003
2. Proposed Solution
For numbered interfaces, the OSPF specification [OSPF] allows a
separate OSPF interface to be configured in each area using a
secondary address. The disadvantages of this approach are that
this doesn't apply to unnumbered interfaces and advertising
secondary addresses will result in a larger overall routing table.
Allowing a link with a single address to simply be configured in
multiple areas would also solve the problem. However, this would
result in the subnet corresponding to the interface residing in
multiple areas which is contrary to the definition of an OSPF
area as a collection of subnets.
The above problems can be avoided by simply allowing unnumbered
links to be configured in multiple areas. This will allow a
higher bandwidth link to be used in multiple areas without using
additonal layer 2 encapsulations or secondary addresses. Section
8.2. of the OSPF specification already specifies that the OSPF
area ID should be used to de-multiplex received OSPF packets.
One limitation is that multi-access networks are not supported.
However, this limitation may be overcome for LAN media with
support of "Point-to-Point operation over LAN in link-state
routing protocols" [P2PLAN].
Lindem, Oswal [Page 3]
Internet Draft OSPF Multi-Area Links July 2003
3. Backward compatibility
This proposal does not introduce any backward compatibility
issues with to other routers in the OSPF routing domain or area.
For interoperability, both endpoints of the link must support
allow configuration in multiple areas.
4. Other Solutions
The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate
mechanism which satisfies this requirement as well as others.
5. Security Considerations
The described technique does not introduce any new security issues
into OSPF protocol.
6. References
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[P2PLAN] Shen, N., et al, "Point-to-point operation over LAN in
link-state routing protocols",
draft-ietf-isis-igp-p2p-over-lan-01.txt,
Work in progress.
[OSPFTA] Mirtorabi, S., Psenak, P., "OSPF Tunnel Adjacency",
draft-mirtorabi-ospf-tunnel-adjacency-00.txt,
Work in Progress.
7. Acknowledgments
The authors wish to acknowledge Pat Murphy for bringing focus
to the requirement.
8. Authors' Addresses
Acee Lindem Anand Oswal
Redback Networks Redback Networks
102 Carric Bend Court 300 Holger Way
Cary, NC 27519 San Jose, CA 95134
e-mail: acee@redback.com e-mail: aoswal@redback.com
Lindem, Oswal [Page 4]