Network Working Group Sina Mirtorabi Internet Draft Michael Barnes Document: draft-mirtorabi-ospfv3-af-01.txt Abhay Roy Expiration Date: December 2003 Cisco Systems June 2003 Support of address families in OSPFv3 draft-mirtorabi-ospfv3-af-01.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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 document describes an extensible mechanism to support Address Families in OSPFv3. One undefined field in the Router-LSA is used to define the address-families on a link. A router may participate in multiple address families on different links. This information needs to be advertised so that only applicable links are used in the SPF calculation when building an address family specific shortest path tree. 1. Motivation OSPFv3 has been defined with a network protocol independent core. It's accomplished by Router-LSA and Network-LSA conveying only Mirtorabi, Barnes, Roy [Page 1]
Internet Draft AF in OSPFv3 June 2003 topology information. There is also implicit support for IPv6 address-family by using V6 bit in Options field. When a router supports multiple address-families, some of the links may participate in only a subset of the address-families. So there is a need to explicitly include or exclude links that participate in a given address-family. This is needed in order to compute the shortest path tree correctly. Otherwise packets will be dropped by routers which are not participating in the address-family. Example of other address-families could be IPv6 Multicast, IPv4 Unicast, IPv4 Multicast etc. 2. Address Family capability option A new bit is defined in the Options field for address-family support. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+ | | | | | | | | | | | | | | | | |AF|DC| R| N|MC| E|V6| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+ AF-bit If this bit is set, it indicates that the router supports Address Families as defined in this draft. When a router supports address-family it MUST set the AF-bit in the Options field of Hello Packets, DD packets and LSAs. 3. Proposed Solution We define an AddressFamilies (AF) field in the Router-LSA. This field is currently set to Zero [Ref1] and ignored in reception. Each bit in the AF field corresponds to one address-family. When a link participates in a given AF the corresponding bit MUST be set, otherwise it MUST be cleared. Mirtorabi, Barnes, Roy [Page 2]
Internet Draft AF in OSPFv3 June 2003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |W|V|E|B| Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |AddressFamilies| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |AddressFamilies| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. AddressFamilies field This document only defines the IPv6 address-family. Additional address-families will define and use bits in this field (one per new address-family defined). +--+--+--+--+--+--+--+-----+ | | | | | | | |V6-AF| +--+--+--+--+--+--+--+-----+ V6-AF bit: Unicast IPv6 address-family. If the interface participates in Unicast IPv6 address-family this bit MUST be set. Otherwise it MUST be cleared. Note 1: A link participating in multiple address-families will set all of the corresponding AF bits when the same metric is used Mirtorabi, Barnes, Roy [Page 3]
Internet Draft AF in OSPFv3 June 2003 among those address-families otherwise multiple link descriptions are used to advertise different metrics for different address-families. Note 2: OSPFv3 [Ref1] defines a V6 bit in the Options field. This bit is used in order to include or exclude a node (all links) in the IPv6 address-family. The V6-AF bit defined in this document (in the AddressFamilies field) is link based. Therefore, when the V6-AF bit is set to include some links in the IPv6 AF, the V6 bit in the Options field MUST be set too. Note 3: Documents defining other address-families in OSPFv3 MUST introduce the equivalent of V6 bit in the Options field so that a node can be globally included / excluded in the corresponding topology. 5. Extending router functionality to be address-family aware There is a requirement to have the [Nt|W|V|E|B] octet defined in each address-family. For example a router may be ABR or ASBR for the IPv6 address-family without having the same functionality for another AF. Therefore we define a new LSA type called the AF-Functionality-LSA. AF-Functionality-LSA is not used for IPv6 address-family as Router-LSA already contains this information. This LSA describes a router's functionality in a given address-family. It needs to be flooded within the area, which can be done by setting the Unknown bit (U bit) as described in [Ref1]. LSA function code LS Type Description ---------------------------------------------------- 12 0xA00C AF-Functionality-LSA Mirtorabi, Barnes, Roy [Page 4]
Internet Draft AF in OSPFv3 June 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |1|0|1| 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamilies| 0 | Nt W V E B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamilies| 0 | Nt W V E B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamilies| 0 | Nt W V E B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AddressFamilies : This field is defined in section 4 of this document. W,V,E,B : These fields are defined in [Ref1] Nt : This field is defined in [Ref2] All other fields are similar to router-lsa fields as described in [Ref1]. When all the bits are clear for an AF, a Router does not need to generate AF-Functionality-LSA as it is implicitly assumed that those bits are cleared. 6. Inter-Area-Router-LSAs for address-family inter-area-router-LSAs are originated by area border routers and they describe routes to routers in other areas. This is required in order to advertise the location of ASBR. Since ASBR's are defined independently within each address-family (see section 5), there is a need to define an address-family aware LSA. We define a new LSA called AF-inter-area-router-LSA below. This LSA is not used for IPv6 Unicast address-family as inter-area-router-LSAs already contains this information. This LSA needs to be flooded within the area, which can be done by setting the Unknown bit (U bit) as described in [Ref1]. Mirtorabi, Barnes, Roy [Page 5]
Internet Draft AF in OSPFv3 June 2003 LSA function code LS Type Description ---------------------------------------------------- 13 0xA00D AF-inter-area-router-LSAs 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |1|0|1| 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #AF | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFMetricLen |AddressFamilies| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFMetricLen |AddressFamilies| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #AF : The number of AddressFamilies block carrying a metric AFMetricLen : The length of the metric (in 4 byte unit) within each AddressFamilies block. This field can be used for future extension and has currently the value of 4 (3 byte metric and 1 byte zero). AddressFamilies : as defined in section 4 of this document. All other fields are similar to inter-area-router-LSA fields as described in [Ref1]. Each AF-inter-area-router-LSA describes one Destination Router ID. When ASBR's are common within address-families, and if the same metric is used among these address-families, a single AF-inter-area-router-LSA is generated setting all the corresponding bits in AddressFamilies field. Otherwise multiple AF-inter-area-router-LSAs are generated. Mirtorabi, Barnes, Roy [Page 6]
Internet Draft AF in OSPFv3 June 2003 7. Participating in an address-family over a multi-access link On a multi-access link the Designated Router (DR) is responsible for flooding and establishing adjacencies with all other routers on the link. It is possible that the DR does not support an AF. However, because OSPFv3 floods unknown LSA types, the DR will flood the LSAs defined for an AF that it doesn't support. Therefore, any router can be the DR regardless of whether or not it supports any particular AF. It should be noted that although DR functionality is AF independent, DR is also responsible to generate additional LSAs (ideally for each AF) for the attached multi-access link. Therefore for each active AF, the router MUST elect a LSA Generator (LG). LG takes the role of generating any AF specific LSAs for the multi-access link. We propose the following LG election algorithm for an address-family: Call the router doing the calculation Router X. The list of neighbors attached to the link L supporting the address-family (address-family specific Options bit set in the Hello) and having established bidirectional communication with Router X is examined. This list includes Router X itself. 1) If Router X is the only router on the list, exit (no election is required) 2) If DR is on the list, elect DR as LG 3) If BDR is on the list, elect BDR as LG 4) Otherwise the router with highest Router ID is elected as LG When the router's interface to link L transitions to the InterfaceUp state, the router MUST wait for WaitTimer before running LG election algorithm. This algorithm SHOULD be invoked every time there is a NeighborChange event as specified in [Ref3]. The LG will advertise AF specific LSAs (intra-area-prefix-LSA and potentially other LSAs) for the multi-access link once it has at least one Full adjacency. If a router is no longer the LG it SHOULD flush the AF specific LSAs it previously originated for the multi-access link. It MUST NOT flush its AF specific LSAs before the WaitTimer. This will allow enough time for the newly elected LG to generate the AF specific LSAs. It is important to note that DR functionality is AF independent. That is any router on the multi-access link can be elected DR and generate Network-LSA. However, AF specific information for a multi-access link is advertised in LSAs generated for the multi-access link by the router that wins the LG election for the particular AF. Mirtorabi, Barnes, Roy [Page 7]
Internet Draft AF in OSPFv3 June 2003 8. Interacting with non-AF capable routers Routers that are not AF-capable will clear the V6-AF bit in the Router-LSA. Therefore an AF-capable router will exclude this router from the IPv6 topology. In order to avoid this problem, we define a new parameter in the area data structure called AFCapability. This Flag MUST be set consistently in all routers inside an area. The AFCapability flag can have two values: Enabled and Disabled. The flag is set to Disabled when an area data structure is created. If the area's AFCapability flag is set to Disabled, the router: 1) MUST set the AF bit in the Options field. 2) MUST set the V6-AF bit in the Router-LSA links, for all the links which need to participate in IPv6 AF. 3) Ignore the Hello reception as specified in section 9. 4) Ignore the V6-AF bit while doing SPF. If the area's AFCapability flag is set to Enabled, the router: 1) MUST set the AF bit in the Options field. 2) MUST set the V6-AF bit in the Router-LSA links, for all the links which need to participate in IPv6 AF. 3) Check the Hello reception as specified in section 9. 4) Check the V6-AF bit while doing SPF, as specified in section 10. AFCapability can be enabled when all routers in an area are AF capable. Then the V6-AF bit, and any other AddressFamilies bit, will be considered during the SPF. Once all of the routers in an area are AF capable, a non-AF capable router that might join the area would ignore the AddressFamilies bits and treat all links as if they are part of the IPv6 topology. It might then forward IPv6 traffic to an AF-Capable router which has interfaces that are not in the IPv6 AF, and packets would be dropped. In order to avoid this problem, an adjacency will not be formed with a non-AF capable router when the AFCapability flag is set to Enabled, as specified in section 9. 9. Change to the Hello Reception when AFCapability flag is Enabled Receiving Hello Packets is specified in section 3.2.2.1 of [Ref1]. The following check is added to Hello reception: When AFCapability flag is set to Enabled, Hello packets having the AF bit clear in the Options field are discarded. 10. Change to the SPF when AFCapability is Enabled Each address-family may have a different topology, therefore a router Mirtorabi, Barnes, Roy [Page 8]
Internet Draft AF in OSPFv3 June 2003 may run a different SPF for each address-family. While doing a SPF for an address-family, only links that are part of that address-family (they have the corresponding AF bit set) should be included in the SPF. This will assure that a packet will never be sent to a router that does not support the address-family. 11. Compatibility issues Section 8. details interoperability between AF capable and non-AF capable routers. When AFCapability is Disabled (default mode) there is no interoperability issues. 12. Acknowledgments The authors would like to thank Acee Lindem and Manral Vishwas for their comments on this work. 13. Security Considerations The technique described in this document does not introduce any new security issues to the OSPFv3 protocol. 14. References [Ref1] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [Ref2] P. Murphy, "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. [Ref3] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 15. Authors' address Sina Mirtorabi Abhay Roy Cisco Systems Cisco Systems 170 W. Tasman Dr. 170 W. Tasman Dr. San Jose, CA 95134 San Jose, CA 95134 USA USA E-mail: sina@cisco.com E-mail: akr@cisco.com Michael Barnes Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA E-mail: mjbarnes@cisco.com Mirtorabi, Barnes, Roy [Page 9]