Network Working Group Sina Mirtorabi Internet Draft Peter Psenak Document: draft-ietf-ospf-multi-area-adj-01.txt Cisco Systems Expiration Date: January 2005 Acee Lindem Anand Oswal Redback Networks July 2004 OSPF Multi-Area Adjacency draft-ietf-ospf-multi-area-adj-01.txt Status of this Memo By submitting this Internet-Draft, I (we) certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I (we) accept the provisions of Section 4 of RFC 3667 (BCP 78). 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 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 the same link. Mirtorabi et al. [Page 1]
Internet Draft OSPF Multi-area adjacency July 2004 Table of Contents Abstract ...............................................1 1. Introduction............................................2 2. Possible Soultions .....................................2 3. Proposed Soultion ......................................3 4. Bringing up multi-area adjacencies .....................3 5. Neighbor discovery......................................3 6. Change to OSPF control packet processing................3 7. Interface data structure................................5 8. Interface FSM...........................................5 9. Neighbor data structure and neighbor FSM................5 10. Advertising multi-area adjacencies .....................5 11. Compatibility Issues....................................5 12. Other Solutions.........................................5 13. Security................................................5 14. IANA Considerations.....................................5 15. Acknowledgments.........................................5 16. Normative References....................................6 17. Informative References..................................6 18. Authors' Addresses .....................................6 Full Copyright .........................................6 IPR/Internet Society Acknowledgement ...................7 1. Introduction 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 ABRs to create multi-area adjacencies belonging to different areas. 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. Mirtorabi et al. [Page 2]
Internet Draft OSPF Multi-area adjacency July 2004 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. 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]. 4. Bringing up multi-area adjacencies Multi-area adjacencies are configured between two routers having a common interface. On physical point-to-point networks, packets are sent to the AllSPFRouters address. For all other network types, packets are unicast to the remote neighbor's IP address. 5. Neighbor discovery On point-to-point networks, neighbor discovery is dynamic since Hello packets are sent to the AllSPFRouters address. For all other network types, one needs to configure remote neighbor IP address for the multi-area adjacency. 6. Change to OSPF control packet processing 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. Mirtorabi et al. [Page 3]
Internet Draft OSPF Multi-area adjacency July 2004 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. For virtual link, 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 adjacency, if the area-id matches the configured area for multi-area adjacency, the packet is accepted and is associated with the multi-area adjacency for that area. [ Note if there is a match for both a VL and TA 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). [...] Mirtorabi et al. [Page 4]
Internet Draft OSPF Multi-area adjacency July 2004 7. Interface data structure An OSPF interface data structure is built for each configured multi-area adjacency as specified in section 9 of OSPF [OSPF]. The interface type will always be point-to-point. 8. Interface FSM The interface FSM will be the same as a point-to-point link irrespective of the underlying physical link. 9. 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 [OSPF]. 10. Advertising multi-area adjacencies Multi-area adjacencis are announced as unnumbered point-to-point links. Once the router's secondary adjacency reaches the FULL state it will be added as a link type 1 to the Router LSA with: Link ID = remote's Router ID Link ID = IfIndex This will announce a topological path through the corresponding area. 11. Compatibility Issues All mechanisms described in this document are backward-compatible with standard OSPF implementations. 12. Other Solutions The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate mechanism which satisfies this requirement as well as others. 13. Security This document does not raise any security issues that are not already covered in [OSPF]. 14. IANA Considerations This document does not require any IANA assignments of action. 15. Acknowledgments The authors wish to acknowledge Pat Murphy for bringing focus to the requirement. Mirtorabi et al. [Page 5]
Internet Draft OSPF Multi-area adjacency July 2004 16. Normative References [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 17. Informative References [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., Lindem, A., "OSPF Tunnel Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt, Work in Progress. 18. Authors' Addresses Sina Mirtorabi Peter Psenak Cisco Systems Cisco Systems 225 West Tasman drive Parc Pegasus, De Kleetlaan 6A San Jose, CA 95134 1831 Diegem, Belgium e-mail: sina@cisco.com e-mail: ppsenak@cisco.com Acee Lindem Anand Oswal Redback Networks Redback Networks 102 Carric Bend Court 300 Holger Way Cary, NC 27519 San Jose, CA 95134 email: acee@redback.com e-mail: aoswal@redback.com Full 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. 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. Mirtorabi et al. [Page 6]
Internet Draft OSPF Multi-area adjacency July 2004 Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mirtorabi et al. [Page 7]