Network Working Group S. Mirtorabi Internet-Draft P. Psenak Expires: January 30, 2005 Cisco Systems A. Lindem Redback Networks A. Oswal Cisco Systems August 2004 OSPF Multi-Area Adjacency draft-ietf-ospf-multi-area-adj-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 January 30, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 Mirtorabi, et al. Expires January 30, 2005 [Page 1] Internet-Draft OSPF Multi-Area Adjacency August 2004 would create an intra-area path to the corresponding areas sharing 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 6.2 Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Mirtorabi, et al. Expires January 30, 2005 [Page 2] Internet-Draft OSPF Multi-Area Adjacency August 2004 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 January 30, 2005 [Page 3] Internet-Draft OSPF Multi-Area Adjacency August 2004 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. 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 Mirtorabi, et al. Expires January 30, 2005 [Page 4] Internet-Draft OSPF Multi-Area Adjacency August 2004 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). 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 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 January 30, 2005 [Page 5] Internet-Draft OSPF Multi-Area Adjacency August 2004 3. Compatibility All mechanisms described in this document are backward-compatible with standard OSPF implementations [OSPF]. Mirtorabi, et al. Expires January 30, 2005 [Page 6] Internet-Draft OSPF Multi-Area Adjacency August 2004 4. Security Considerations This document does not raise any security issues that are not already covered in [OSPF]. Mirtorabi, et al. Expires January 30, 2005 [Page 7] Internet-Draft OSPF Multi-Area Adjacency August 2004 5. IANA Considerations This document does not require any IANA assignments or action. Mirtorabi, et al. Expires January 30, 2005 [Page 8] Internet-Draft OSPF Multi-Area Adjacency August 2004 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 Redback Networks 102 Carric Bend Court Cary, NC 27519 USA EMail: acee@redback.com Mirtorabi, et al. Expires January 30, 2005 [Page 9] Internet-Draft OSPF Multi-Area Adjacency August 2004 Anand Oswal Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: aoswal@cisco.com Mirtorabi, et al. Expires January 30, 2005 [Page 10] Internet-Draft OSPF Multi-Area Adjacency August 2004 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 January 30, 2005 [Page 11] Internet-Draft OSPF Multi-Area Adjacency August 2004 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 (2004). 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 January 30, 2005 [Page 12]