OSPF Working Group S. Kini Internet-Draft W. Lu Intended Status: Standards Track A. Tian Expires: April 2011 Ericsson October 18, 2010 OSPF Fast Notifications draft-kini-ospf-fast-notification-00.txt Status of this Memo Distribution of this memo is unlimited. 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 21, 2011. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kini et al Expires April 2011 [Page 1] Internet Draft OSPF Fast Notification October 18, 2010 Abstract Several applications could use a mechanism to quickly notify one or more routers about control-protocol events. Current mechanisms to convey such information to routers multiple hops away involves hop- by-hop protocol-specific control plane processing as well as hop-by- hop control plane forwarding. The delay due to control planes involvement in processing/forwarding, adversely affects the application's goal (e.g. fast convergence). This document describes a framework to use data plane forwarding to convey control protocol information multiple hops away. It also defines some sample applications within this framework. Kini et al Expires April 2011 [Page 2] Internet Draft OSPF Fast Notification October 18, 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A: OSPF fast convergence on link-down using FN . . . . . . 7 A.1. OSPF procedural changes . . . . . . . . . . . . . . . . . 7 A.2. FN service using spanning tree . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Kini et al Expires April 2011 [Page 3] Internet Draft OSPF Fast Notification October 18, 2010 1. Introduction There are several applications that could use a mechanism to quickly notify one or more routers in a network about a specific control- protocol event. If the destination router(s) is more than one hop away then the message has to be forwarded by the intermediate routers. This forwarding typically does not exclusively happen via the forwarding plane. Some applications establish adjacent neighbor relationship with single hop neighbors. Information that needs to be conveyed multiple hops away is first conveyed to adjacent neighbors that are a single hop away. Each neighbor then performs application specific processing and forwards information further. The delay in receiving the information at a router is gated by the processing and forwarding speed of the control plane at each hop along a path from the originating router. A typical example of an application that sends information to directly connected adjacent neighbors is a link-state routing interior gateway protocol (IGP) such as [OSPF]. When conveying a Link State Advertisement (LSA) to all routers in the area, OSPF's flooding algorithm transmits the LSA to its single hop away adjacent neighbor. The received LSA undergoes processing according to OSPF's processing rules and is then forwarded to OSPF neighbors further away from the router originating the LSA. As explained earlier the delay in receiving a LSA at a router is gated by the processing and forwarding speed of the control plane at each hop along a path from the originating OSPF router. Some applications need to send information to routers that are multiple hops away even though they do not have adjacency relationship with directly connected neighbors. In such cases the forwarding of application messages depends on the forwarding plane being setup by an underlying protocol that has established adjacent neighbor relationship with routers that are a single hop away. In scenarios where the data plane forwarding is changing due to the underlying protocol, the applications message forwarding speed and reliability is gated by the speed and mechanisms of the underlying protocols hop-by-hop message processing and forwarding by control- plane. A typical example of an application that could use a mechanism to send information to non-directly connected neighbors is IP FastReroute (IP-FRR). It could use a forwarding mechanism that has been setup by an underlying protocol to trigger (on failure) a non- directly connected neighbor, to switch traffic to an alternate path. To reliably deliver the applications message, the forwarding Kini et al Expires April 2011 [Page 4] Internet Draft OSPF Fast Notification October 18, 2010 mechanism has to be resilient against failures and the changed topology. 2. Conventions used in this document 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 [RFC2119]. 3. Scope This document describes a framework for quickly delivering notifications from one router to one or more routers using data plane as the main forwarding mechanism. It also defines some solutions under this framework to address the needs of some specific applications. 4. Requirements Fast notifications (henceforth referred to as FN) must be designed as a set of services that can satisfy the requirements of different control-protocol applications. FN should avoid introducing new protocols and should re-use existing, commonly used protocols as much as possible. Deploying FN must not introduce new encapsulation requirements for routers unless those encapsulations are already available in the data plane for those applications. Notifying multiple routers should use multicast whenever possible. 5. Architecture A choice of protocol to realize FN must be based on the set of commonly deployed protocols. These protocols must preferably have applicability in a wide set of network architectures such as IP- routing, L3VPN, L2VPN etc. Also, the knowledge of the network topology would be particularly useful for path computation purposes. The logical candidate for these requirements would be a link-state interior gateway protocol (IGP) such as OSPF or IS-IS. To implement a specific FN service, a router must convey its capability to the set of routers that setup forwarding to one or more routers in that set for specific packets in a way such that data- plane forwarding of notifications. It must also convey its share of the information that is needed to implement that FN service. To convey this information via OSPF, an opaque LSA is used. An Opaque type field "FN" is defined. The type specific ID indicates a Kini et al Expires April 2011 [Page 5] Internet Draft OSPF Fast Notification October 18, 2010 particular FN service. The content of the LSA is a variable list of TLVs that include information required to implement that FN service. Different FN services will have different sets of TLVs. A specific instance of a FN service and how an application might use it is specified in Appendix A. 5. Security Considerations Security considerations of the application also apply when FN service is used by the application. If additional security considerations arise due to the way in which FN is used by the application, then those should be resolved in the document that explains how an application uses FN. 6. IANA Considerations IANA needs to allocate a OSPF opaque type field for FN. Within that LSID values for different FN services will have to be allocated. Also a TLV type field will have to be allocated. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 8. Acknowledgements The authors would like to thank Joel Halpern for his comments. Kini et al Expires April 2011 [Page 6] Internet Draft OSPF Fast Notification October 18, 2010 Appendix A: OSPF fast convergence on link-down using FN OSPF fast convergence is gated by how quickly the flooding algorithm can propagate the LSA throughout the area. This requires hop-by-hop processing and forwarding by control plane. If a FN service can transmit the link-down notification to all routers in the area then OSPF's fast convergence can be improved in the link-down scenario. A.1. OSPF procedural changes OSPF's procedures must be modified to use the FN service as follows. OSPF transmits a copy of the updated Router LSA (on link-down) using a FN service in addition to the normal processing and flooding done by OSPF. The destination IP address of the link-state update (LSU) packet is set to the one dictated by the FN service. If Cryptographic authentication is required, a shared secret key must be configured for the area. The Cryptographic sequence number in the LSU must be set to zero. On receiving a LSU via FN, the router accepts it if authentication succeeds. There must be no acknowledgement for such an LSU. If the received LSA is older than the one in the LSDB, the received LSA is discarded. If the received LSA is newer, the LSA is stored alongside the older copy and a timer T-discard-FN-LSA is started. A flag FN- LSA-present is used in the LSDB entry to indicate that a newer version of the LSA (received via FN) is present. SPF is triggered. During SPF, if the FN-LSA-present flag is true then the LSA received via FN is used instead. When a LSA is received via the flooding procedure of [OSPF], and is determined to be newer, it is compared with the LSA copy received via FN (if one exists). If the two copies are the same, the LSA received via FN becomes the only entry in the LSDB. If the two copies are different, the LSA received through the flooding procedure of [OSPF] becomes the only copy in the LSDB and SPF is triggered. In both cases the flag FN-LSA-present is cleared and the timer T-discard-FN-LSA is canceled. When the timer T-discard- FN-LSA expires, the corresponding LSA copy received via FN is discarded (FN-LSA-present flag is cleared) and SPF is triggered. A.2. FN service using spanning tree One way to provide the FN service for this application is as follows. A multicast spanning tree (with a specially allocated multicast destination IP address) is used to send the link-down notification message. The tree must be consistently computed at all routers. It must be computed as a shortest path tree rooted at the highest router-id. During tree computation only routers that are capable of this FN service are picked. When multiple paths are available the neighboring node in the graph with highest LSID is picked. When multiple paths are available through multiple interfaces to a neighboring node, a numbered interface is preferred over an Kini et al Expires April 2011 [Page 7] Internet Draft OSPF Fast Notification October 18, 2010 unnumbered interface. A higher IP address is preferred among numbered interfaces and a higher ifIndex is preferred among unnumbered interfaces. Multicast forwarding state is installed using such a tree as a bi-directional tree. Each router on the tree can send packets to all other routers on that tree. Even when the topology changes such that the tree breaks, the link-down notification is delivered to all routers. Kini et al Expires April 2011 [Page 8] Internet Draft OSPF Fast Notification October 18, 2010 Authors' Addresses Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com Wenhu Lu Ericsson 300 Holger Way, San Jose, CA 95134 EMail: wenhu.lu@ericsson.com Albert Tian Ericsson 300 Holger Way, San Jose, CA 95134 EMail: albert.tian@ericsson.com Kini et al Expires April 2011 [Page 9]