OSPF Working Group S. Kini Internet-Draft W. Lu Intended Status: Standards Track A. Tian Expires: September 2011 Ericsson March 14, 2011 OSPF Fast Notification draft-kini-ospf-fast-notification-01.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 September 15, 2011. Copyright Notice Copyright (c) 2011 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 September 2011 [Page 1] Internet Draft OSPF Fast Notification March 14, 2011 Abstract The current OSPF link-state database (LSDB) flooding mechanism involves control-plane processing and forwarding at each hop. The delay due to the involvement of the control-plane adversely affects OSPF convergence. This document describes a mechanism to transmit link-state advertisements (LSA) multiple hops away without involving control-plane processing at the intermediate routers. This helps to achieve faster convergence. It complements the current LSDB flooding mechanism. Kini et al Expires September 2011 [Page 2] Internet Draft OSPF Fast Notification March 14, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Kini et al Expires September 2011 [Page 3] Internet Draft OSPF Fast Notification March 14, 2011 1. Introduction The LSDB flooding mechanism of OSPF is described in [OSPF]. On receiving a LSA from an adjacent neighbor, the router performs several consistency checks and also compares it with the LSA instance in its LSDB to determine the more recent version. The next step in the flooding procedure involves sending the LSA to its adjacent neighbors and that includes acknowledgements and retransmission to ensure reliability. These procedures involve the control-plane and are therefore gated by the processing and forwarding speed of the control-plane at each hop. The solution described in this document does not involve control- plane processing at the intermediate nodes. Details are provided in section 3. 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. Solution The document describes a mechanism to quickly notify a LSA to all the routers within an OSPF area. This does not require control-plane processing at an intermediate hop and such a mechanism is also referred to as a fast notification (FN) as described in [FN-FRWK]. The solution in this document uses such a fast-notification mechanism and makes it work with the OSPF procedures (including its flooding mechanism) and is henceforth referred to as OSPF-FN. OSPF-FN does not aim to replace the current OSPF flooding mechanism. The details of this solution are described below. A variety of mechanisms to encode and transport FN messages are described in [FN-TRNS]. For message encoding, this document uses the minimal extra encapsulation i.e, it uses the multicast FN address 'MC-FN' as the destination address of a OSPF-FN link-state update (LSU) packet. Note that when the redundant-tree mode as described in [FN-TRNS] is used, there will be two such multicast addresses. Such an LSU packet is henceforth referred to as the OSPF-FN-LSU packet. This LSU packet contains LSAs that need to be quickly notified to all routers within the OSPF area. At this time the redundant-tree mode of transporting OSPF-FN-LSU packets is the preferred method. OSPF-FN works in conjunction with the OSPF flooding mechanism as follows. An OSPF router that originates a LSA that is determined to require FN, creates a OSPF-FN-LSU packet containing the LSA and Kini et al Expires September 2011 [Page 4] Internet Draft OSPF Fast Notification March 14, 2011 transports it using a method chosen from [FN-TRNS]. Note that this is in addition to any OSPF procedures and specifically does not change the current flooding mechanism in OSPF. If the redundant tree mode is used then an OSPF-FN-LSU packet is sent on each of the redundant trees. When a LSA is received through a OSPF-FN-LSU packet, the normal OSPF procedures on receiving a LSU packet should be executed with the exception that there is no acknowledgement for the LSU packet. Also, the LSA is noted as received by OSPF-FN and the older instance of the LSA MUST be retained. The older LSA instance is discarded only if the current OSPF flooding mechanism confirms that the LSA from the OSFP-FN-LSU is the correct instance. This confirmation should occur within a short time of receiving the OSPF- FN-LSU packet. This time period is henceforth called T-discard-FN-LSA time and has a recommended default of 5 seconds. If this timer expires then the LSA received via the OSPF-FN-LSU packet is discarded and the older instance is used as the correct instance. After updating the LSDB with the LSA received from the OSPF-FN-LSA as described above, all the route processing is performed except that the new and changed routes are not activated in the forwarding plane. The activation is done on receiving the the LSA via the current OSPF flooding procedures. It is desirable for OSPF-FN-LSU packets to use area-wide authentication parameters so that OSPF-FN-LSU messages can be forwarded by intermediate routers similar to any normal data packet. The LSA sequence number can provide protection against replay attacks. A separate per-link (or network) authentication parameter introduces the complexity of rewriting the packet at each hop as described in [FN-TRNS]. This is an area for further study. The determination of which LSAs require a fast notification is dependent on the event that caused the LSA update. The benefits of using FN for a link or adjacency going down is straightforward. Other cases require further study. 4. Security Considerations Area wide authentication (if used) parameters could bring associated security concerns. This is an area for further study. 5. IANA Considerations A TLV id to identify this capability and multicast IP addresses to transport the OSPF-FN-LSU messages are required. Kini et al Expires September 2011 [Page 5] Internet Draft OSPF Fast Notification March 14, 2011 6. References 6.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. [FN-FRWK] Lu, W., et al, "Fast Notification Framework", draft-lu- fast-notification-framework-01 (Work in progress), March 2011. [FN-TRNS] Lu, W., et al, "Transport of Fast Notfication Messages", draft-lu-fn-transport-00 (Work in progress), March 2011. 7. Acknowledgements The authors would like to thank Joel Halpern for his comments. Kini et al Expires September 2011 [Page 6] Internet Draft OSPF Fast Notification March 14, 2011 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 September 2011 [Page 7]