TOC 
Network Working GroupS. Mirtorabi
Internet-DraftNuova Systems
Intended status: Standards TrackP. Psenak
Expires: October 25, 2008Cisco Systems
 A. Lindem (Editor)
 A. Oswal
 Redback Networks
 April 23, 2008


OSPF Multi-Area Adjacency
draft-ietf-ospf-multi-area-adj-09.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 October 25, 2008.

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.



Table of Contents

1.  Introduction
    1.1.  Requirements notation
    1.2.  Motivation
    1.3.  Possible Solutions
    1.4.  Proposed Solution
2.  Functional Specifications
    2.1.  Multi-Area Adjacency Configuration and Neighbor Discovery
    2.2.  Multi-Area Adjacency Packet Transmission
    2.3.  Multi-Area Adjacency Control Packet Reception Changes
    2.4.  Interface Data Structure
    2.5.  Interface FSM
    2.6.  Neighbor Data Structure and Neighbor FSM
    2.7.  Advertising Multi-Area Adjacencies
3.  Compatibility
    3.1.  Adjacency Endpoint Compatibility
4.  OSPFv3 Applicability
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Acknowledgments
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction



 TOC 

1.1.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC‑KEYWORDS] (Bradner, S., “Key words for use in RFC's to Indicate Requirement Levels,” March 1997.).



 TOC 

1.2.  Motivation

It is often a requirement to have an Open Shortest Path First (OSPF) [OSPF] (Moy, J., “OSPF Version 2,” April 1998.) 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 is to use a high-speed backbone link between two Area Border Routers (ABRs) to create multi-area adjacencies belonging to different areas.

Consider the following topology:



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

 Multi-Link Topology 

The backbone 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, 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 and Area 1.



 TOC 

1.3.  Possible Solutions

For numbered interfaces, the OSPF (Open Shortest Path First) specification [OSPF] (Moy, J., “OSPF Version 2,” April 1998.) 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 that 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] (Shen, N. and A. Zinin, “Point-to-point operation over LAN in link-state routing protocols,” .), it may not be acceptable to configure the link as unnumbered due to network management policies. Many popular network management applications individually test the path to each interface and an IP address facilitates this task.



 TOC 

1.4.  Proposed Solution

ABRs will simply establish multiple adjacencies belonging to different areas. Each multi-area adjacency is announced as a point-to-point link in the configured area. However, unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. 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 in a manner consistent with RFC 2328 [OSPF] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

2.  Functional Specifications



 TOC 

2.1.  Multi-Area Adjacency Configuration and Neighbor Discovery

Multi-area adjacencies are configured between two routers having a common interface. On point-to-point interfaces, 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.



 TOC 

2.2.  Multi-Area Adjacency Packet Transmission

On point-to-point interfaces, 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.



 TOC 

2.3.  Multi-Area Adjacency Control Packet Reception Changes

Receiving protocol packets is described in section 8.2 of [OSPF] (Moy, J., “OSPF Version 2,” April 1998.). The text starting with the second paragraph and continuing through the third bullet beneath that paragraph is changed as follows:

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:

  • The version number field must specify protocol version 2.
  • 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.
    3. Indicate the backbone. In this case, the packet has been sent over a virtual link or a multi-area adjacency.
  • 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.
  • 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.
  • 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.
  • 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] (Moy, J., “OSPF Version 2,” April 1998.)).
  • [...] The remainder of section 8.2 [OSPF] (Moy, J., “OSPF Version 2,” April 1998.) is unchanged.



 TOC 

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] (Moy, J., “OSPF Version 2,” April 1998.). The interface type will always be point-to-point.



 TOC 

2.5.  Interface FSM

The interface FSM will be the same as a point-to-point link irrespective of the underlying physical link.



 TOC 

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] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

2.7.  Advertising Multi-Area Adjacencies

Multi-area adjacencies are announced as 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 Advertisement (LSA) with:

Link ID = Remote's Router ID
Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered).

Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies.



 TOC 

3.  Compatibility

All mechanisms described in this document are backward compatible with standard OSPF implementations [OSPF] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

3.1.  Adjacency Endpoint Compatibility

Since multi-area adjacencies are modeled as unnumbered point-to-point links, it is only necessary for the router at the other end of the adjacency to model the adjacency as a point-to-point link. However, the network topology will be easier to represent and troubleshoot if both neighbors are symmetrically configured as multi-area adjacencies.



 TOC 

4.  OSPFv3 Applicability

The mechanisms defined in this document also apply to OSPFv3 [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.). As in OSPF, a multi-area adjacency is advertised as an unnumbered point-to-point link in the advertising router's router-LSA. Since OSPFv3 router-LSA links are independent of addressing semantics and unambiguously identify OSPFv3 neighbors (refer section 3.4.3.1 [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.)), the change to router-LSA links described in Section 2.7 (Advertising Multi-Area Adjacencies) is not applicable to OSPFv3. Furthermore, no prefixes corresponding to the multi-area adjacency are advertised in the router's intra-area-prefix-LSA.

A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The neighbor's IPv6 link local address can be learned in other ways, e.g., it can be extracted from the IPv6 header of Hello packets received over the multi-area adjacency. The neighbor IPv6 link local address is required for the OSPFv3 route next-hop calculation on multi-access networks (refer section 3.8.1.1 [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.)).



 TOC 

5.  Security Considerations

This document does not raise any security issues that are not already covered in [OSPF] (Moy, J., “OSPF Version 2,” April 1998.) or [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.).



 TOC 

6.  IANA Considerations

This document does not require any IANA assignments or action.



 TOC 

7.  References



 TOC 

7.1. Normative References

[OSPF] Moy, J., “OSPF Version 2,” RFC 2328, April 1998.
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” RFC 2740, December 1999.
[RFC-KEYWORDS] Bradner, S., “Key words for use in RFC's to Indicate Requirement Levels,” RFC 2119, March 1997.


 TOC 

7.2. Informative References

[P2PLAN] Shen, N. and A. Zinin, “Point-to-point operation over LAN in link-state routing protocols,” draft-ietf-isis-igp-p2p-over-lan-06.txt (work in progress).


 TOC 

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.

Thanks to Padma Pillay-Esnault for her last call review and comments. Also thanks to Padma for comments on the OSPFv3 applicability section that was last called separately.

Thanks to Nischal Seth for pointing out that the document inadvertently precluded point-to-point over LAN interfaces.

Thanks to Ben Campbell for performing the General Area Review.

Thanks to Jari Arkko for comments during the IESG review.

The RFC text was produced using Marshall Rose's xml2rfc tool.



 TOC 

Authors' Addresses

  Sina Mirtorabi
  Nuova Systems
  3 West Plumeria Drive
  San Jose, CA 95134
  USA
Email:  sina@nuovasystems.com
  
  Peter Psenak
  Cisco Systems
  Apollo Business Center
  Mlynaki nivy 43
  821 09 Bratislava, Sovakia
  Slovakia
Email:  ppsenak@cisco.com
  
  Acee Lindem
  Redback Networks
  102 Carric Bend Court
  Cary, NC 27519
  USA
Email:  acee@redback.com
  
  Anand Oswal
  Redback Networks
  300 Holger Way
  San Jose, CA 95134
  USA
Email:  aoswal@redback.com


 TOC 

Full Copyright Statement

Intellectual Property