Network Working Group S. Mirtorabi
Internet-Draft P. Psenak
Expires: March 19, 2006 Cisco Systems
A. Lindem (Editor)
Cisco Systems, Inc
A. Oswal
Cisco Systems
September 15, 2005
OSPF Multi-Area Adjacency
draft-ietf-ospf-multi-area-adj-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on March 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo documents an extension to OSPF 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 to the corresponding areas sharing
Mirtorabi, et al. Expires March 19, 2006 [Page 1]
Internet-Draft OSPF Multi-Area Adjacency September 2005
the same link.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Possible Solutions . . . . . . . . . . . . . . . . . . . . 3
1.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . 3
1.4 Other Solutions . . . . . . . . . . . . . . . . . . . . . 3
2. Functional Specifications . . . . . . . . . . . . . . . . . . 4
2.1 Multi-Area Adjacency Configuration and Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Multi-Area Adjacency Packet Transmission . . . . . . . . . 4
2.3 Multi-Area Adjacency Control Packet Reception Changes . . 4
2.4 Interface Data Structure . . . . . . . . . . . . . . . . . 5
2.5 Interface FSM . . . . . . . . . . . . . . . . . . . . . . 5
2.6 Neighbor Data Structure and Neighbor FSM . . . . . . . . . 5
2.7 Advertising Multi-Area Adjacencies . . . . . . . . . . . . 5
3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Mirtorabi, et al. Expires March 19, 2006 [Page 2]
Internet-Draft OSPF Multi-Area Adjacency September 2005
1. Introduction
1.1 Motivation
There could be a requirement to have a link in multiple areas in
order to allow the link to be considered as an intra-area link in
multiple areas and be preferred over high cost intra-area paths. A
simple example is to use a high speed backbone link between two Area
Border Routers (ABRS) to create multi-area adjacencies belonging to
different areas.
1.2 Possible Solutions
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 it
requires additional IP address configuration, 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.
Another approach is to simply allow unnumbered links to be configured
in multiple areas. 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 of this approach is that
multi-access networks are not supported. Although this limitation
may be overcome for LAN media with support of "Point-to-Point
operation over LAN in link-state routing protocols" [P2PLAN], it may
not be acceptable to configure the link as unnumbered.
1.3 Proposed Solution
ABRs will simply establish multiple adjacencies belonging to
different areas. Each multi-area adjacency is announced as a point-
to-point unnumbered link in the configured area. This point-to-point
link will provide a topological path for that area. The first or
primary adjacency using the link will operate and advertise the link
consistent with RFC 2328 [OSPF].
1.4 Other Solutions
The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate
mechanism which satisfies this requirement as well as others.
Mirtorabi, et al. Expires March 19, 2006 [Page 3]
Internet-Draft OSPF Multi-Area Adjacency September 2005
2. Functional Specifications
2.1 Multi-Area Adjacency Configuration and Neighbor Discovery
Multi-area adjacencies are configured between two routers having a
common interface. On physical point-to-point networks, there is no
need to configure the neighbor's address since there can be only one
neighbor. For all other network types, the neighbor address of each
multi-area adjacency must be configured or automatically discovered
via a mechanism external to OSPF.
2.2 Multi-Area Adjacency Packet Transmission
On physical point-to-point networks, OSPF control packets are sent to
the AllSPFRouters address. For all other network types, OSPF control
packets are unicast to the remote neighbor's IP address.
2.3 Multi-Area Adjacency Control Packet Reception Changes
Receiving protocol packets is described in section 8.2 of [OSPF] and
is changed as follow:
Next, the OSPF packet header is verified. The fields specified in
the header must match those configured for the receiving interface.
If they do not, the packet should be discarded:
o The version number field must specify protocol version 2.
o The Area ID found in the OSPF header must be verified. If all of
the following cases fail, the packet should be discarded. The
Area ID specified in the header must either:
1. Match the Area ID of the receiving interface. In this case,
the packet has been sent over a single hop. Therefore, the
packet's IP source address is required to be on the same
network as the receiving interface. This can be verified by
comparing the packet's IP source address to the interface's IP
address, after masking both addresses with the interface mask.
This comparison should not be performed on point-to-point
networks. On point-to-point networks, the interface addresses
of each end of the link are assigned independently, if they
are assigned at all.
2. Indicate a non-backbone area. In this case, the packet has
been sent over a multi-area adjacency. If the area-id matches
the configured area for multi-area adjacency, the packet is
accepted and is from now on associated with the multi-area
adjacency for that area.
Mirtorabi, et al. Expires March 19, 2006 [Page 4]
Internet-Draft OSPF Multi-Area Adjacency September 2005
3. Indicate the backbone. In this case, the packet has been sent
over a virtual link or a multi-area adjacency.
o For virtual links, the receiving router must be an area border
router, and the Router ID specified in the packet (the source
router) must be the other end of a configured virtual link. The
receiving interface must also attach to the virtual link's
configured transit area. If all of these checks succeed, the
packet is accepted and is from now on associated with the virtual
link.
o For multi-area adjacencies, if the area-id matches the configured
area for the multi-area adjacency, the packet is accepted and is
from now on associated with the multi-area adjacency for that
area.
o Note that if there is a match for both a virtual link and a multi-
area adjacency then this is a configuration error that should be
handled at the configuration level.
o Packets whose IP destination is AllDRouters should only be
accepted if the state of the receiving interface is DR or Backup
(see Section 9.1 [OSPF]).
o [...] The remainder of section 8.2 [OSPF] is unchanged.
2.4 Interface Data Structure
An OSPF interface data structure is built for each configured multi-
area adjacency as specified in section 9 of [OSPF]. The interface
type will always be point-to-point.
2.5 Interface FSM
The interface FSM will be the same as a point-to-point link
irrespective of the underlying physical link.
2.6 Neighbor Data Structure and Neighbor FSM
Both the neighbor data structure and neighbor FSM are the same as for
standard OSPF, specified in section 10 of [OSPF].
2.7 Advertising Multi-Area Adjacencies
Multi-area adjacencies are announced as unnumbered point-to-point
links. Once the router's multi-area adjacency reaches the FULL state
it will be added as a link type 1 to the Router Link State
Mirtorabi, et al. Expires March 19, 2006 [Page 5]
Internet-Draft OSPF Multi-Area Adjacency September 2005
Advertisement (LSA) with:
Link ID = Remote's Router ID
Link Data = IfIndex
This will announce a topological path through the corresponding area.
Mirtorabi, et al. Expires March 19, 2006 [Page 6]
Internet-Draft OSPF Multi-Area Adjacency September 2005
3. Compatibility
All mechanisms described in this document are backward-compatible
with standard OSPF implementations [OSPF].
Mirtorabi, et al. Expires March 19, 2006 [Page 7]
Internet-Draft OSPF Multi-Area Adjacency September 2005
4. Security Considerations
This document does not raise any security issues that are not already
covered in [OSPF].
Mirtorabi, et al. Expires March 19, 2006 [Page 8]
Internet-Draft OSPF Multi-Area Adjacency September 2005
5. IANA Considerations
This document does not require any IANA assignments or action.
Mirtorabi, et al. Expires March 19, 2006 [Page 9]
Internet-Draft OSPF Multi-Area Adjacency September 2005
6. References
6.1 Normative References
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
6.2 Informative References
[OSPFTA] Mirtorabi, S., Psenak, P., and A. Lindem, "OSPF Tunnel
Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt
(work in progress).
[P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN
in link-state routing protocols",
draft-ietf-isis-igp-p2p-over-lan-05.txt (work in progress).
Authors' Addresses
Sina Mirtorabi
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
Email: sina@cisco.com
Peter Psenak
Cisco Systems
Parc Pegasus, De Kleetlaan 6A
1831 Diegem
Belgium
Email: ppsenak@cisco.com
Acee Lindem
Cisco Systems, Inc
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
Email: acee@cisco.com
Mirtorabi, et al. Expires March 19, 2006 [Page 10]
Internet-Draft OSPF Multi-Area Adjacency September 2005
Anand Oswal
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
Email: aoswal@cisco.com
Mirtorabi, et al. Expires March 19, 2006 [Page 11]
Internet-Draft OSPF Multi-Area Adjacency September 2005
Appendix A. Acknowledgments
The authors wish to acknowledge Pat Murphy for bringing focus to the
requirement.
Thanks to Mitchell Erblich's for his last call review and comments.
The RFC text was produced using Marshall Rose's xml2rfc tool.
Mirtorabi, et al. Expires March 19, 2006 [Page 12]
Internet-Draft OSPF Multi-Area Adjacency September 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mirtorabi, et al. Expires March 19, 2006 [Page 13]