Network Working Group A. Lindem Internet-Draft Ericsson Intended status: Standards Track A. Roy Expires: April 8, 2010 S. Mirtorabi Cisco Systems October 5, 2009 OSPF Transport Instance Extensions draft-ietf-ospf-transport-instance-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 8, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Lindem, et al. Expires April 8, 2010 [Page 1] Internet-Draft OSPF Transport Instance Extensions October 2009 Abstract OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4 2.1. OSPFv2 Transport Instance Packets Differentiation . . . . 4 2.2. OSPFv3 Transport Instance Packets Differentiation . . . . 4 2.3. Instance Relationship to Normal OSPF Instances . . . . . . 4 2.3.1. Ships in the Night Relationship to Normal OSPF Instances . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2. Tighter Coupling with Normal OSPF Instances . . . . . 5 2.4. Network Prioritization . . . . . . . . . . . . . . . . . . 5 2.5. OSPF Transport Instance Omission of Routing Calculation . 5 2.6. Non-routing Instance Separation . . . . . . . . . . . . . 6 2.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 6 2.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . . 7 3. OSPF Transport Instance Information Encoding . . . . . . . . . 8 3.1. OSPFv2 Transport Instance Information Encoding . . . . . . 8 3.2. OSPFv3 Transport Instance Information Encoding . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Lindem, et al. Expires April 8, 2010 [Page 2] Internet-Draft OSPF Transport Instance Extensions October 2009 1. Introduction OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3] include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. 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 [RFC-KEYWORDS]. Lindem, et al. Expires April 8, 2010 [Page 3] Internet-Draft OSPF Transport Instance Extensions October 2009 2. OSPF Transport Instance In order to isolate the overhead of flooding non-routing information, its flooding will be relegated to a separate protocol instance. This instance should be given lower priority when contending for router resources including processing, backplane bandwidth, and line card bandwidth. How that is realized is an implementation issue and is beyond the scope of this document. Throughout the document, non-routing refers to routing information that is not used for IP or IPv6 routing calculations. The OSPF transport instance is ideally suited for dissemination of routing information for other protocols and layers. 2.1. OSPFv2 Transport Instance Packets Differentiation OSPFv2 currently doesn't offer a mechanism to differentiate Transport instance packets from normal instance packets sent and received on the same interface. However, the [MULTI-INST] provides the necessary packet encoding to support multiple OSPF protocol instances. 2.2. OSPFv3 Transport Instance Packets Differentiation Fortunately, OSPFv3 already supports separate instances within the packet encodings. The existing OSPFv3 packet header instance ID field will be used to differentiate packets received on the same link (refer to section 2.4 in [OSPFV3]). 2.3. Instance Relationship to Normal OSPF Instances There are basically two alternatives for the relationship between a normal OSPF instance and a Transport Instance. In both cases, we must guarantee that any information we've received is treated as valid if and only if the router sending it is reachable. We'll refer to this as the "condition of reachability" in this document. 1. Ships in the Night - The Transport Instance has no relationship or dependency on any other OSPF instance. 2. Child Instance - The Transport Instance has a child-parent relationship with a normal OSPF instance and is dependent on this for topology information and assuring the "condition of reachability". Lindem, et al. Expires April 8, 2010 [Page 4] Internet-Draft OSPF Transport Instance Extensions October 2009 2.3.1. Ships in the Night Relationship to Normal OSPF Instances In this mode, the Transport Instance is not dependent on any other OSPF instance. It does, however, have much of the overhead as topology information must be advertised to satisfy the condition of reachability. Prefix information does this need to be advertised. This implies that for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary- LSAs need to be advertised. In the router-LSAs, the stub (type 3) links may be suppressed. For OSPFv3, this implies that router-LSAs, Network-LSAs, and inter-area-router-LSAs must be advertised. 2.3.2. Tighter Coupling with Normal OSPF Instances Further optimization and coupling between the transport instance and a normal OSPF instance are beyond the scope of this document. This is an area for future study. 2.4. Network Prioritization While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP precedence Internetwork Control, any packets sent by a transport instance will be sent with IP precedence Flash (B'011'). This is only appropriate given that this is a pretty flashy mechanism. Similarly, OSPFv3 transport instance packets will be sent with the traffic class mapped to flash (B'011') as specified in ([OSPFV3]. By setting the IP/IPv6 precedence differently for OSPF transport instance packets, normal OSPF routing instances can be given priority during both packet transmission and reception. In fact, some router implementations map the IP precedence directly to their internal packet priority. However, implementation issues are beyond the scope of this document. 2.5. OSPF Transport Instance Omission of Routing Calculation Since the whole point of the transport instance is to separate the routing and non-routing processing and fate sharing, a transport instance SHOULD NOT install any routes. OSPF routers SHOULD NOT advertise any transport instance LSAs containing IP or IPv6 prefixes and OSPF routers receiving LSAs advertising prefixes SHOULD ignore them. This implies that an OSPFv2 transport instance Link State Database should not include any Summary-LSAs (type 3) , AS-External- LSAs (type 5), or NSSA-LSAs (type 7) and the Router-LSAs should not include any stub (type 3) links. An OSPFv3 transport instance Link State database should not include any Inter-Area-Prefix-LSAs (type Lindem, et al. Expires April 8, 2010 [Page 5] Internet-Draft OSPF Transport Instance Extensions October 2009 0x2003), AS-External-LSAs (0x4005), NSSA-LSAs (type 0x2007), or Intra-Area-Prefix-LSAs (type 0x2009). If they are erroneously advertised, they MUST be ignored by OSPF routers supporting this specification. 2.6. Non-routing Instance Separation It has been suggested that an implementation could obtain the same level of separation between IP routing information and non-routing information in a single instance with slight modifications to the OSPF protocol. The authors refute this contention for the following reasons: o Adding internal and external mechanisms to prioritize routing information over non-routing information are much more complex than simply relegating the non-routing information to a separate instance as proposed in this specification. o The instance boundary offers much better separation for allocation of finite resources such as buffers, memory, processor cores, sockets, and bandwidth. o The instance boundary decreases the level of fate sharing for failures. Each instance may be implemented as a separate process or task. o With non-routing information, many times not every router in the OSPF routing domain requires knowledge of every piece of routing information. In these cases, groups of routers which need to share information can be segregated into sparse topologies greatly reducing the amount of non-routing information any single router needs to maintain. 2.7. Non-Routing Sparse Topologies With non-routing information, many times not every router in the OSPF routing domain requires knowledge of every piece of routing information. In these cases, groups of routers which need to share information can be segregated into sparse topologies. This will greatly reduce the amount of information any single router needs to maintain with the core routers possibly not requiring any non-routing information at all. With normal OSPF, every router in an OSPF area must have every piece of topological and IP or IPv6 prefix routing information. With non- routing information, only the routers needing to share a set of information need be part of the corresponding sparse topology. For directly attached routers, one only needs to configure the desired Lindem, et al. Expires April 8, 2010 [Page 6] Internet-Draft OSPF Transport Instance Extensions October 2009 topologies on the interfaces with routers requiring the non-routing information. When the routers making up the sparse topology are not part of a uniconnected graph, two alternatives exist. The first alternative is configure tunnels to form a fully connected graph including only those routers in the sparse topology. The second alternative is use remote neighbors as described in Section 2.7.1. 2.7.1. Remote OSPF Neighbor With sparse topologies, OSPF routers sharing non-routing information may not be directly connected. OSPF adjacencies with remote neighbors are formed exactly as they are with regular OSPF neighbors. The main difference is that a remote OSPF neighbor's address is configured and IP routing is used to deliver packet to the remote neighbor. Other salient feature of remote neighbor include: o All OSPF packets are addressed to the remote neighbor's configured IP address. o The adjacency is represented in the router Router-LSA as a router (type-1) link with the link data set to the remote neighbor address. o Similar to NBMA networks, a poll-interval is configured to determine if the remote neighbor is reachable. This value is normally much higher than the hello interval. Lindem, et al. Expires April 8, 2010 [Page 7] Internet-Draft OSPF Transport Instance Extensions October 2009 3. OSPF Transport Instance Information Encoding The format of the TLVs within the body of an LSA containing non- routing information is the same as the format used by the Traffic Engineering Extensions to OSPF [TE]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Format However, each unique application using the mechanisms defined in this document will have it's own unique ID. Whether to encode this ID as the top-level TLV or make it part of the OSPF LSA ID is open for debate. The specific TLVs and sub-TLVs relating to a given application and the corresponding IANA considerations MUST for standard applications MUST be specified in the document corresponding to that application. 3.1. OSPFv2 Transport Instance Information Encoding Application specific information will be flooded in opaque LSAs as specified in [OPAQUE]. 3.2. OSPFv3 Transport Instance Information Encoding Application specific information will be flooded in separate LSAs with separate function codes. Refer to section A.4.2.1 of [OSPFV3] for information on the LS Type encoding in OSPFv3. Lindem, et al. Expires April 8, 2010 [Page 8] Internet-Draft OSPF Transport Instance Extensions October 2009 4. Security Considerations The security considerations for the Transport Instance will not be different for those for OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3]. Lindem, et al. Expires April 8, 2010 [Page 9] Internet-Draft OSPF Transport Instance Extensions October 2009 5. IANA Considerations No new IANA assignments are required for this draft. Lindem, et al. Expires April 8, 2010 [Page 10] Internet-Draft OSPF Transport Instance Extensions October 2009 6. References 6.1. Normative References [MULTI-INST] Lindem, A., Mirtorabi, S., and A. Roy, "OSPF Multi- Instance Extensions", draft-acee-ospf-multi-instance-01.txt (work in progress). [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003. 6.2. Informative References [ISIS-GEN-APP] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", draft-ietf-isis-genapp-01.txt (work in progress). Lindem, et al. Expires April 8, 2010 [Page 11] Internet-Draft OSPF Transport Instance Extensions October 2009 Appendix A. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. Although very different mechanisms are utilized, the concept of using a separate instance to advertise non-routing information in an IGP was first introduced in "Advertising Generic Information in IS-IS" [ISIS-GEN-APP]. Thanks to Jonathan Sadler for comments on the document. Lindem, et al. Expires April 8, 2010 [Page 12] Internet-Draft OSPF Transport Instance Extensions October 2009 Authors' Addresses Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519 USA Email: acee.lindem@ericsson.com Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: akr@cisco.com Sina Mirtorabi Cisco Systems 3 West Plumeria Drive San Jose, CA 95134 USA Email: sina@cisco.com Lindem, et al. Expires April 8, 2010 [Page 13]