Network Working Group Sina Mirtorabi Internet Draft Peter Psenak Document: draft-ietf-ospf-multi-area-adj-00.txt Cisco Systems Expiration Date: September 2004 Acee Lindem Anand Oswal Redback Networks March 2004 OSPF Multi-Area Adjacency draft-ietf-ospf-multi-area-adj-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 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 March 2004 Table of Contents Abstract ...............................................1 1. Motivation..............................................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................................4 8. Interface FSM...........................................4 9. Neighbor data structure and neighbor FSM................4 10. Advertising multi-area adjacencies .....................5 11. Compatibility Issues....................................5 12. Other Solutions.........................................5 13. Security................................................5 14. Acknowledgments.........................................5 15. Reference...............................................5 16. Authors' Addresses .....................................5 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 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. 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. Mirtorabi et al. [Page 2]
Internet Draft OSPF Multi-area adjacency March 2004 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. 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. Mirtorabi et al. [Page 3]
Internet Draft OSPF Multi-area adjacency March 2004 (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 from now on 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). [...] 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]. Mirtorabi et al. [Page 4]
Internet Draft OSPF Multi-area adjacency March 2004 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. Acknowledgments The authors wish to acknowledge Pat Murphy for bringing focus to the requirement. 15. 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., Lindem, A., "OSPF Tunnel Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt, Work in Progress. 16. 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 Mirtorabi et al. [Page 5]
